From Fedora Project Wiki
Fedora Cloud Work Group- 14 August 2014 - Rochester, NY - FLOCK
Base vs Atomic
- Should we consider having atomic as a default - if so we need software stacks
- base image is also good, but people say they want a minimal base with a large set of stacks to put on top that they can layer their app on top of
- We believe the people using hte Fedora base image to do anyting are using that image because they came looking for a fedora base image - they did not come with a problem they wanted to solve - they were internal users
- if we want to grow beyond that we need something exciting and that may be atomic
- Would it be better to suggest that leading edge is fedora atomic host with centos (or a mix) of containers for stable containers
- Matt envisions a ramp - bleeing on fedora with an offramp to centos for longer term stability and RH for support
- India is already seeing people doing proto-production and production in a mixed container environment - for bleeding vs stablized
- Centos is chosen for security updates (overtime) - otherwise fedora is better because some software lags or is unavailable
- Theoretically a lot of EPEL could be eliminated if fedora containers are the way to deliver newer software on CentOS
- A magic called dopr is being considered that does docker+copr for keeping things up to date and publishing to dockerhub
- Info: Fedora Atomic updates are coming out every two weeks - but marketing/announcement and QE are really not formalized. A project called autocloud is being produced that could do gating and non-gating tests on these images. Test coverage is a challenge right now - we have some tests but it needs to be grown. The Atomic team can help with this, but there is no home for it at this time. Ultimately this will run in taskotron, but we are not there yet. Today Kushal owns them. Discussion about using the CentOS Community Build System/CI system for some of this infrastructure.
- If we are going to make atomic the default image, we need to make it clear to folks that this is not the base image. But we think atomic will attract people.
- Keep the download page shared between the base image and atomic, but target the messaging toward atomic.
- Having a two-week release cycle on atomic separates it from the main distro - alternately we could have two releases. Another way to help would be to possibly eliminate things to get back effort - like 32bit - but this is not really a big help. Ultimately however, it sounds like we only need one release or we risk telling pepole that the 2 week release is unstable. Basically, if the kubernetes and docker tests pass your containers sould run. If they do not run, we need to fix that bug. So yes, update every two weeks.
- There is this idea of a "rich boot" where it differs from traditional setup and then possibly use puppet or image it for other use. Atomic is really a setup where it is configure on boot as it has to be in a known state. This means we probably need to make cloud-init great, invest in tuned, or directly integrating puppet/ansible. There will always be something that needs to be done to make it usable beyond what was downloaded. So we need to make things more context aware. There is another cloud-init under development and even CoreOS is interested in merging with it. Ovirt and Ovirt node may also be a pattern/solution.
- There is a big focus on bare metal and cloud use cases. There is a lot of desire for bare metal, but it is not an optimal experience. Bare metal customers are not excited by cloud-init and after the big cloud providers many providers do not run cloud-init either. Cloud-init works today but has limitations, especially once you need SPCs for things like rsyslog. We also need to consider that cloud-init could grow into a full system configuration tool - which is what puppet/etc. do.
Container Image
- Who owns it? Everyone wanted it. Base owned it, but has not been growing it as was expected.
- Should we have alignment between the images? Should minimal = base, essentially?
- We should slim it down further, but it is a lot of effort because you have to start removing dependencies.
- Have a small image, then have a Fedora with Batteries that has things like 'ps', etc. This way if you need more you base on that, not the bottom.
- Now that RPM has weak dependencies, lets fix packages to use them so they are not dragged in. This can be done distro wide to help combat the idea of just tossing source in a container instead of heaving packaging.
- Having a smaller image size, predates containers, it has been a common cloud complaint.
- This is a tough sell for packagers because the value of the effort is not apparent. It also means making some compromises, such as not being able to display a logo in all cases meaning a UI may be less attractive.
- Lots of conversation that showed that "Why Atomic is important or compelling" still needs a lot of messaging inside of Fedora
Vagrant Boxes
- These are being made on the two week release but they are not tested
Documentation and PRD and a FAD
- Docs are lagging because we are moving faster than the distro
- PRD is not a full story and needs to be improved
- We need a FAQ for decisions
- We need a FAD to get this done and roadmap/design work
Build service for custom cloud services
- in the plan for the future
Cloud Test Day
- 27 of August Cloud/Atomic Test Day
How to join
- It sounds like there is some confusion around how to join - and we have some inactive membership
Action Items
- AI: Joe - Proposal to be put too the list
- AI: Heikl(?) - Membership refresh to the list