(→Base Image: add some more to-dos) |
|||
Line 9: | Line 9: | ||
=== ongoing maintenance of kickstart === | === ongoing maintenance of kickstart === | ||
==== general continuous updates and fixes === | ==== general continuous updates and fixes ==== | ||
* What: The definition of the cloud image needs ongoing work | * What: The definition of the cloud image needs ongoing work | ||
* Where: kickstart file is at https://fedorahosted.org/spin-kickstarts/ | * Where: kickstart file is at https://fedorahosted.org/spin-kickstarts/ | ||
Line 24: | Line 24: | ||
==== investigate systemd-networkd === | ==== investigate systemd-networkd ==== | ||
* What: new service to do very basic network config | * What: new service to do very basic network config | ||
* Where: remove the sysv network scripts, add config for this | * Where: remove the sysv network scripts, add config for this | ||
Line 31: | Line 31: | ||
* Who: ??? | * Who: ??? | ||
==== migrate to gpt ==== | |||
* What: use gpt with this spec http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ | |||
* Where: in the kickstart, and with support needed from build tools | |||
* Why: images could be launched as containers | |||
* When: nice for F21 alpha | |||
* Who: ??? | |||
=== updates to cloud rel-eng EC2 process === | |||
==== update to pv-grub aki used in EC2 ==== | |||
* What: We are currently using old boot images with pv grub 1.02 -- newer versions at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedKernels.html | |||
* Where: https://git.fedorahosted.org/cgit/releng/tree/scripts/cloud/fedora_ec2.py | |||
* Why: new version allows GPT partitions, works with both unpartioned and partitioned, would allow us to use a separate /boot if we want to change the filesystem for / in the future; also new version has bugfixes | |||
* When: F21 alpha; prereq of using whole-disk images | |||
* Who: ? | |||
==== upload whole disk instead of just partition ==== | |||
* What: our current ec2 images are unpartitioned dumps of /. Switch to whole-disk | |||
* Where: https://git.fedorahosted.org/cgit/releng/tree/scripts/cloud/fedora_ec2.py | |||
* Why: image more identical everywhere. no downside. | |||
* When: F21 alpha | |||
* Who: ? | |||
=== automation in rel-eng === | === automation in rel-eng === | ||
Revision as of 12:12, 12 March 2014
Intro
This is a collaborative list of current and future work for the Fedora Cloud SIG. It's meant to describe what's needed or wanted, and what is being done. (It isn't an assignment sheet or list of demands, although it would be lovely if people are interested in taking responsibility for certain areas.)
Work Areas
Base Image
ongoing maintenance of kickstart
general continuous updates and fixes
- What: The definition of the cloud image needs ongoing work
- Where: kickstart file is at https://fedorahosted.org/spin-kickstarts/
- Why: Because this is our base product
- When: As package sets change and new Fedora releases come out
- Who: Someone in cloud working group in collaboration with rel-eng and spins sig
port to anaconda/oz/imagefactory
- What: The current kickstart file is full of kludges for appliance-creator. Port to anaconda/imagefactory kludges
- Where: same as ongoing maintenance of kickstart
- Why: appliance-creator is being retired; anaconda-based installs are the way forward
- When: As soon as this is available in Koji. Need a new ImageFactory release, then patches into Koji for support, then a new Koji release, then Koji needs to be updated in Fedora production
- Who: Ian McLeod is working on ImageFactory; Jay Greguske on the Koji patches, Mike McLean is Koji maintainer, Dennis Gilmore in release engineering will do the Koji update. Need to work with them to get this in place, and then someone from cloud wg needs to do the updating.
investigate systemd-networkd
- What: new service to do very basic network config
- Where: remove the sysv network scripts, add config for this
- Why: remove very kludgey shell scripts; try the new hotness
- When: Before F21 alpha
- Who: ???
migrate to gpt
- What: use gpt with this spec http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
- Where: in the kickstart, and with support needed from build tools
- Why: images could be launched as containers
- When: nice for F21 alpha
- Who: ???
updates to cloud rel-eng EC2 process
update to pv-grub aki used in EC2
- What: We are currently using old boot images with pv grub 1.02 -- newer versions at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedKernels.html
- Where: https://git.fedorahosted.org/cgit/releng/tree/scripts/cloud/fedora_ec2.py
- Why: new version allows GPT partitions, works with both unpartioned and partitioned, would allow us to use a separate /boot if we want to change the filesystem for / in the future; also new version has bugfixes
- When: F21 alpha; prereq of using whole-disk images
- Who: ?
upload whole disk instead of just partition
- What: our current ec2 images are unpartitioned dumps of /. Switch to whole-disk
- Where: https://git.fedorahosted.org/cgit/releng/tree/scripts/cloud/fedora_ec2.py
- Why: image more identical everywhere. no downside.
- When: F21 alpha
- Who: ?
automation in rel-eng
produce scratch builds on change
- What:
- Where:
- Why:
- When:
- Who:
upload to ec2 and ftp
- What:
- Where:
- Why:
- When:
- Who:
Quality Assurance
Write Initial QA Documents
- What: Work out and write down structured test plans and test cases and, if additional are necessary, release criteria / requirements.
- Where: Fedora Wiki
- Why: So testers know how to test, and QA overlords and rel-eng know when the images are actually ready for release. Or maybe rather, when they're not.
- When: Before the very first alpha release candidate (RC) of Fedora 21 is due.
- Who: Someone in cloud working group in collaboration with QA.
Ongoing QA Documentation Work
- What: Keep above documents up to date, extend and add new documents where necessary.
- Where: Fedora Wiki
- Why: As requirements, processes or tools might change, documents need to change too. Also, some documents need to be copied (and maybe slightly changed) before every round of testing.
- When: Between releasing a new release and the next release's first alpha release candidate's due date.
- Who: Someone in cloud working group or QA.
Ongoing QA Testing Work
- What: Perform the actual testing according to the test plans and test cases from above. For every single release and re-release.
- Where: Fedora Wiki, IRC (#fedora-qa and #fedora-cloud), Bugzilla, Mailing Lists (Cloud SIG and QA), etc.
- Why: Because bugs happen, because no-one and nothing is perfect. Because we want our users to have a as flawless experience as possible. And because the automated testing is not yet implemented (and some things might not be fully automatable).
- When: From the first alpha release candidate until the final release of each and every release, at least until tests are fully automated.
- Who: As many people with as many different environments as possible. Primarily cloud working group and possibly QA people, probably.
Updates
Policies
- What: We talked about putting out updated images periodically (or aperiodically as needed). What are the rules?
- Where:
- Why:
- When:
- Who:
procedures
- What: We talked about putting out updated images periodically (or aperiodically as needed). How does it happen?
- Where:
- Why:
- When:
- Who:
automated testing
- What: How might updated images be automatically tested?
- Where:
- Why:
- When:
- Who:
other qa?
- What: What other QA do we want to do? How do we want to do it?
- Where:
- Why:
- When: initial planning, ongoing as updates happen
- Who:
mirroring updated images
- What: Do we want the updates to go out to the Fedora mirror network?
- Where:
- Why:
- When:
- Who: releng, mirror admins
legal
- What: Needs for keeping track of source for GPL compliance
- Where:
- Why:
- When:
- Who: releng, legal, and us
Docker
Docker Host Image
create kickstart file
- What: Based on the Base Image's kickstart file, write an extended kickstart file with the image-specifics.
- Where: kickstart file is at https://fedorahosted.org/spin-kickstarts/
- Why: No kickstart file, no image.
- When: Before Fedora 21's first release candidates are built.
- Who: Someone in cloud working group in collaboration with the Spins SIG
selinux work
- What:
- Where:
- Why:
- When:
- Who:
libvirt size
- What:
- Where:
- Why:
- When:
- Who:
etcd?
- What:
- Where:
- Why:
- When:
- Who:
mesos orchestration?
- What:
- Where:
- Why:
- When:
- Who:
Official Fedora Base Container
initial kickstart
- What:
- Where:
- Why:
- When:
- Who:
ongoing maintenance of kickstart
- What:
- Where:
- Why:
- When:
- Who:
More things we can do to make the base better
- What: good ideas here: https://github.com/phusion/baseimage-docker* What:
- Where:
- Why:
- When:
- Who:
Library of Dockerfiles
- What:
- Where:
- Why:
- When:
- Who:
Orchestration
- What:
- Where:
- Why:
- When:
- Who:
Big Data Image
define
- What:
- Where:
- Why:
- When:
- Who:
create
- What:
- Where:
- Why:
- When:
- Who:
test
- What:
- Where:
- Why:
- When:
- Who:
maintain
- What:
- Where:
- Why:
- When:
- Who:
Openshift Image
define
- What:
- Where:
- Why:
- When:
- Who:
create
- What:
- Where:
- Why:
- When:
- Who:
test
- What:
- Where:
- Why:
- When:
- Who:
maintain
- What:
- Where:
- Why:
- When:
- Who:
Random Bits We Could Use
Cloud-init improvements
- What:
- Where:
- Why:
- When:
- Who:
Notification of pending security updates on login
- What: A system to display a count (or list?) of updates waiting to be applied
- Where: New code needs to be written. https://bugzilla.redhat.com/show_bug.cgi?id=995537 could help.
- Why: Helpful to users. Side-effect: we can count checkins.
- When: nice by F21 release.
- Who:
Planning
this document
- What:
- Where:
- Why:
- When:
- Who:
technical specifications
- What: like https://fedoraproject.org/wiki/Workstation/Technical_Specification but for our stuff
- Where:
- Why:
- When:
- Who:
More / better statistics
- What:
- Where:
- Why:
- When:
- Who:
Ongoing user surveys
- What:
- Where:
- Why:
- When:
- Who:
Fedora.next changes list
- What: see "second deliverable" at https://fedoraproject.org/wiki/Fedora.next/boardproposal#Product_Working_Groups
- Where: Cloud_Changelist
- Why: Part of the Fedora.next plan.
- When: REAL SOON NOW (Due Feb 17th.)
- Who: Fedora Cloud WG + Fedora Cloud SIG in general
Needs for Base WG
- What: like the above, but specifically, what we'd like / need from the base
- Where:
- Why:
- When:
- Who:
Needs for Env & Stacks
- What: like the above, but specifically, what we'd like / need from Ring 2
- Where:
- Why:
- When:
- Who:
Marketing
figure out branding
- What:
- Where:
- Why:
- When:
- Who:
produce content
- What:
- Where:
- Why:
- When:
- Who:
promote!
- What:
- Where:
- Why:
- When:
- Who:
work with web team
- What:
- Where:
- Why:
- When:
- Who:
Documentation
write up what we're doing
- What:
- Where:
- Why:
- When:
- Who:
write up any or all of the above
- What:
- Where:
- Why:
- When:
- Who:
Improve Cloud SIG wiki
- What: general improvements to wiki page for both SIG and WG
- Where: https://fedoraproject.org/wiki/Cloud_SIG
- Why: keep pace with recent developments, link all the stuff together, make it easy to dive in
- When:
- Who:
Fedora Cloud Guide
- What: Fedora Cloud Guide
- Where:
- Why: Book form documentation to explain what the Cloud is, how Fedora fits in, and how to use Fedora and provided tools in the Cloud.
- When: Anytime
- Who: Anyone!
How to Contribute to the Cloud Guide
Any form of participation is welcome. You can ask for a particular tool or process to be covered, suggest improvements, critique, point out flaws or outdated content, or write content directly.
Fedora Guides are written in docbook and published using Publican. There is a slight learning curve, but don't let that dissuade you! Even if you don't want to hack on the guide directly, your feedback and guidance is valuable. Your expertise can help writers with less cloud knowledge to put together a good guide.
Public Cloud Providers
Amazon EC2
Amazon Marketplace
- What:
- Where:
- Why:
- When:
- Who:
Ongoing EC2
- What:
- Where:
- Why:
- When:
- Who:
Google Compute Image
- What:
- Where:
- Why:
- When:
- Who:
HP Cloud
- What:
- Where:
- Why:
- When:
- Who:
Rackspace
- What:
- Where:
- Why:
- When:
- Who:
Digital Ocean
- What:
- Where:
- Why:
- When:
- Who: