From Fedora Project Wiki
Line 41: Line 41:
= Questions =
= Questions =


* Items under "Provide the best platform for secure application deployment" - are cgroups / containers meant here?
* '''Items under "Provide the best platform for secure application deployment"''' - are cgroups / containers meant here?
* Difference between server and devops?
* '''Difference between server and devops?'''
* Difference between Server and Cloud products vs compute nodes?
* '''Difference between Server and Cloud products vs compute nodes?'''
** "Traditional servers [like pets] have names, personalities, and are lovingly cared for. When they get sick, you diagnose the problem and carefully nurse them back to health, sometimes at great expense. Like pets. On the other hand, cattle sre numbered, and thought of as basically identical, and if they get sick, you put them down and get another one." --mattdm
** "Traditional servers [like pets] have names, personalities, and are lovingly cared for. When they get sick, you diagnose the problem and carefully nurse them back to health, sometimes at great expense. Like pets. On the other hand, cattle sre numbered, and thought of as basically identical, and if they get sick, you put them down and get another one." --mattdm
** "This was my thinking, I thought the cloud WG is about building lean images that do not have much in the way of wizards, installers, and hand-holding software, but are focused toward rapid deployment, either as lean hosts or as computing/elastic guests, all controlled via some configuration engine like puppet etc... basically single task machines. I see the server WG more about building heavier, long term, multipurpose servers (be it on bare metal or as guest)." --simo
** "This was my thinking, I thought the cloud WG is about building lean images that do not have much in the way of wizards, installers, and hand-holding software, but are focused toward rapid deployment, either as lean hosts or as computing/elastic guests, all controlled via some configuration engine like puppet etc... basically single task machines. I see the server WG more about building heavier, long term, multipurpose servers (be it on bare metal or as guest)." --simo
Line 49: Line 49:
** "I would say single purpose servers/vm/containers all fall under the server WG as well but I think we should be looking at this from application stand point as in which of those services/daemon fall under the server WG and that means we could make up to about 500 550 applications or "products" that can be deployed on bare metal in vm's or containers we would be delivering." --johannbg
** "I would say single purpose servers/vm/containers all fall under the server WG as well but I think we should be looking at this from application stand point as in which of those services/daemon fall under the server WG and that means we could make up to about 500 550 applications or "products" that can be deployed on bare metal in vm's or containers we would be delivering." --johannbg
** "I think it would make most sense for Cloud and Server to "share applications", i.e. the same application package can be deployed either within a single-purpose Cloud image (automatically managed for horizontal scaling), or as a single instance within a Server (one of many applications running on this particular Server). Given that,  I think the Server WG should indeed choose a very limited set of "applications" / "services" to include within the Server product and to make management of this limited set of services really good." --mitr
** "I think it would make most sense for Cloud and Server to "share applications", i.e. the same application package can be deployed either within a single-purpose Cloud image (automatically managed for horizontal scaling), or as a single instance within a Server (one of many applications running on this particular Server). Given that,  I think the Server WG should indeed choose a very limited set of "applications" / "services" to include within the Server product and to make management of this limited set of services really good." --mitr
* Balance between OS packages and more rapidly moving frameworks in collections...
* '''Balance between OS packages and more rapidly moving frameworks in collections...'''
* Visibility of packages
* '''Visibility of packages'''
** "Would it be radical to suggest that "packages" should be invisible to an admin that doesn't want to see them?  "Enable the DNS server", configure what it is serving, *product's magic here*, the DNS server runs." --mitr
** "Would it be radical to suggest that "packages" should be invisible to an admin that doesn't want to see them?  "Enable the DNS server", configure what it is serving, *product's magic here*, the DNS server runs." --mitr
* '''Overlap between other working groups'''
** "Basically where I stand any application that runs daemon/service as in it's an application (or set of applications) that runs in the background
waiting to be used, or carrying out essential tasks on an pyshical/vm or in container or in other words basically it's an systemd/upstart/sysv unit/service or an container that can be started and enable with the systemd and service commands and is not part of the desktop/graphical target ( such as gdm.service which thus makes it part of the workstation group ), as well is not part of the base/coreOS ( like device mapper etc ) it belongs within the server WG." --johannbg
** "I tentatively agree, although I guess there may be desktop-oriented daemons we may not care about. Say a desktop-oriented backup daemon, that is sort of single user or anyway ill-suited for a multi-user server. Also should we care much about Graphical UIs ? Or should we freeze early and maintain whatever version was considered stable in the Desktop WG at the start of the cycle ? And who is going to maintain it if we do so and happen to have a longer term cycle than the desktop ?" --simo

Revision as of 16:38, 31 October 2013

Warning.png
This is a draft document!
This document is a work-in-progress draft and has not been agreed upon yet.

Discussion

Draft Use Cases

  1. Users of Fedora server will be able to install - at their option - a select set of software with graphical interfaces, and they will be able to successfully use these graphical interfaces via trusted X-forwarding (ssh -Y). [1]
  2. Provide a platform for acting as a node in an OpenStack rack.
  3. Provide a platform and simple setup for certain infrastructure services, e.g.
    • FreeIPA Domain Controller
    • BIND DNS
    • DHCP
    • Database server (both free and commercial).
      • (Should Fedora care about proprietary ones? We shouldn't be hostile, but neither cater for them too much, most of the contributors wouldn't have the means to do it anyway, and proprietary vendors can better install on RHEL and interact with RH. --simo)
    • Samba Ad Domain Controller
      • (that is mostly blocked due to upstream work, and I am not sure we can do much here, beyond encouraging upstream. --simo)
  4. Provide simple setup of a file-server (on par with Windows).
  5. Platform for deploying web applications with high-value frameworks.
    • Frameworks:
      • Ruby on Rails
      • Django
      • Turbogears
      • Node.js
    • (Are we going to do this via Software Collections? The main issue I see with these is that various apps requires at times, conflicting versions of the same base framework/language. --simo )
  6. Make Fedora the best platform to deploy JBoss applications.
  7. Come up with standardized mechanisms for centralized monitoring
  8. Come up with standardized mechanisms for centralized configuration and management
  9. Simple enrollment into FreeIPA and Active Directory domains
  10. Provide the best platform for secure application deployment
  11. Isolation of OS from applications
  12. Isolation of applications from each other
  13. Isolation of application users from each other
  14. Management of application resource consumption
  15. Simplify management and deployment.[1]
  16. Deliver the world's best leading edge DevOps platform.

Questions

  • Items under "Provide the best platform for secure application deployment" - are cgroups / containers meant here?
  • Difference between server and devops?
  • Difference between Server and Cloud products vs compute nodes?
    • "Traditional servers [like pets] have names, personalities, and are lovingly cared for. When they get sick, you diagnose the problem and carefully nurse them back to health, sometimes at great expense. Like pets. On the other hand, cattle sre numbered, and thought of as basically identical, and if they get sick, you put them down and get another one." --mattdm
    • "This was my thinking, I thought the cloud WG is about building lean images that do not have much in the way of wizards, installers, and hand-holding software, but are focused toward rapid deployment, either as lean hosts or as computing/elastic guests, all controlled via some configuration engine like puppet etc... basically single task machines. I see the server WG more about building heavier, long term, multipurpose servers (be it on bare metal or as guest)." --simo
    • "I think it would make sense for the Base Design and Environments/Stacks WGs to define how to install, build and package the runtimes and the applications that use them (including the conflicting/multiple versions issue), without focusing on a specific use (e.g. treating web applications, GUI applications and CLI applications equally), and for the Server WG to handle deploying the web applications within the web server and managing deployed web applications." --mitr
    • "I would say single purpose servers/vm/containers all fall under the server WG as well but I think we should be looking at this from application stand point as in which of those services/daemon fall under the server WG and that means we could make up to about 500 550 applications or "products" that can be deployed on bare metal in vm's or containers we would be delivering." --johannbg
    • "I think it would make most sense for Cloud and Server to "share applications", i.e. the same application package can be deployed either within a single-purpose Cloud image (automatically managed for horizontal scaling), or as a single instance within a Server (one of many applications running on this particular Server). Given that, I think the Server WG should indeed choose a very limited set of "applications" / "services" to include within the Server product and to make management of this limited set of services really good." --mitr
  • Balance between OS packages and more rapidly moving frameworks in collections...
  • Visibility of packages
    • "Would it be radical to suggest that "packages" should be invisible to an admin that doesn't want to see them? "Enable the DNS server", configure what it is serving, *product's magic here*, the DNS server runs." --mitr
  • Overlap between other working groups
    • "Basically where I stand any application that runs daemon/service as in it's an application (or set of applications) that runs in the background

waiting to be used, or carrying out essential tasks on an pyshical/vm or in container or in other words basically it's an systemd/upstart/sysv unit/service or an container that can be started and enable with the systemd and service commands and is not part of the desktop/graphical target ( such as gdm.service which thus makes it part of the workstation group ), as well is not part of the base/coreOS ( like device mapper etc ) it belongs within the server WG." --johannbg

    • "I tentatively agree, although I guess there may be desktop-oriented daemons we may not care about. Say a desktop-oriented backup daemon, that is sort of single user or anyway ill-suited for a multi-user server. Also should we care much about Graphical UIs ? Or should we freeze early and maintain whatever version was considered stable in the Desktop WG at the start of the cycle ? And who is going to maintain it if we do so and happen to have a longer term cycle than the desktop ?" --simo
Retrieved from "https://fedoraproject.org/w/index.php?title=Server/Use_Cases&oldid=358890"