March 2015 - cloud - Fedora Mailing-Lists

[cloud] #99: AMI lifetimes (Cloud WG members vote needed)

by Fedora Cloud Trac Tickets

#99: AMI lifetimes (Cloud WG members vote needed) -------------------------------------+------------------------------------- Reporter: oddshocks | Owner: oddshocks Type: task | Status: new Priority: normal | Milestone: Fedora 22 Component: Infrastructure & | Keywords: aws, images, vote, Release Engineering | policy -------------------------------------+------------------------------------- This ticket is to discuss and vote on appropriate lifetimes for Fedora Cloud AMIs on our official and community cloud accounts, as discussed on the Cloud SIG list this month[1] and in this week's meeting. Everyone seems to agree that after a final release, all TC, RC, Alpha, Beta, and scratch builds should be deleted. This makes sense because there'd be no reason to use any of these AMIs after the final release. Still, we need to definitively decide on: 1. When should TC, RC, Alpha, Beta, and scratch builds be deleted? (1) After a final release? (2) Progressively, when a newer build of the same type comes out? (3) After a set amount of time, depending on the build type? Note that with (2) or (3), we'd need some way to mark each build with it's type. I don't think that necessarily happens now. 2. When should final release AMIs be deleted? (1) After a certain number of newer final releases? (2) After a certain amount of time? (3) Never? Also note that if we choose any age-based deletion policies, we'd need to set up some sort of regular polling of *all* our AMIs on both accounts. We want to hold as few AMIs at one time as is reasonable. There are many AMIs created for each image build that happens, so our AWS storage charges will become quite high if we don't keep our accounts clean. Discuss, and then perhaps a vote? [1]: https://lists.fedoraproject.org/pipermail/cloud/2015-March/005087.html -- Ticket URL: <https://fedorahosted.org/cloud/ticket/99> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

3 years, 10 months

1
18
0 / 0

[cloud] #94: Producing Updated Cloud/Atomic Images

by Fedora Cloud Trac Tickets

#94: Producing Updated Cloud/Atomic Images ------------------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Cloud Base Image | Keywords: meeting ------------------------------+--------------------- We need to finalize our policy around producing updated images and then start doing it. Right now we have loosely decided to release new images once a month or whenever security updates require it. Additionally, as part of this we should also decide on a policy that determines when we stop updating images for a particular release. I imagine that we don't want to be producing updated images for Fedora X, Y, and Z all at the same time. Ideally we would only be producing updated images for the current/latest major version. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/94> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

4 years, 2 months

1
24
0 / 0

[cloud] #84: publicize fedora-dockerfiles

by Fedora Cloud Trac Tickets

#84: publicize fedora-dockerfiles -------------------------------------------+------------------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Fedora 21 (Final) Component: Collaboration & Communication | Keywords: meeting -------------------------------------------+------------------------------- https://github.com/fedora-cloud/Fedora-Dockerfiles is a) cool b) useful c) active d) a great place for new contributors We should popularize this. Articles, blog posts, wiki documentation, non- wiki documentation, etc. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/84> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

4 years, 3 months

1
21
0 / 0

[cloud] #97: Maintaining Fedora docker images for f22

by Fedora Cloud Trac Tickets

#97: Maintaining Fedora docker images for f22 -----------------------------------+----------------------- Reporter: jzb | Owner: Type: task | Status: new Priority: blocker | Milestone: Fedora 22 Component: Docker Base Container | Keywords: meeting -----------------------------------+----------------------- f22 docker alpha images were not tested or really looked after afaict. According to dgilmore we have pulled in server pkgs instead of cloud, and have cockpit packages coming into the container. That's bad. We need to see who "owns" testing of the base images. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/97> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

4 years, 6 months

1
8
0 / 0

[cloud] #96: Atomic as separate spin (or, going the other way, main cloud edition)?

by Fedora Cloud Trac Tickets

#96: Atomic as separate spin (or, going the other way, main cloud edition)? -------------------------+--------------------- Reporter: mattdm | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting -------------------------+--------------------- See https://lists.fedoraproject.org/pipermail/cloud/2015-March/004996.html I'm wondering if we should consider: A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a home at "http://atomic.fedoraproject.org/" (not currently valid), similar to http://kde.fedoraproject.org — with its own design, theming, etc. B. The other way around: double down on Atomic as the primary thing the Cloud WG releases as the Fedora cloud product. Here, the focus would be more on containers as the basis for the future of "cattle-style" scale-out computing, and Atomic as Fedora's cool solution for that. of course, it's always an option to do C. Keep as it is, with both options presented as equals for different cases. Personally, I like "B" from a high-level Fedora perspective, as it's an opinionated solution for a target use case. That's what we _want_ for the Fedora Editions — Wrkstation is a software dev desktop, Server focuses on role deployment via rolekit and cockpit. On the other hand, it's a pretty big bet on Atomic, and maybe we're not ready for that (or collectively don't think that it's the right bet). "C" would be a more cautious wait-and-see approach. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/96> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

4 years, 7 months

1
6
0 / 0

Fedora Cloud Docs

by Pete Travis

Hey cloud team, I think we need some cloud docs. Fedora has a lot to offer in the cloud area, and I'm sure that those engaged in the space are excited that Fedora has what they are looking for. The uninitiated, on the other hand, are looking for what Fedora has, and we can do better to demonstrate that. We have a cloud guide, https://git.fedorahosted.org/cgit/docs/cloud-guide.git/ . It covers some basics, ie euca2ools, but never really made it out of draft state, and your work has left it far behind. We don't have anyone on the Docs team fully engaged to track the cloud space, or anyone on the cloud team engaged to maintain that guide. Also, it's written in docbook, and a lot of folks aren't into that. So, as I'm working on some tooling for a new Fedora Docs site, I'd like to know what would get *you* into writing about Fedora Cloud. In the most direct sense, it's a question about markup and delivery, ie a collection of markdown or reStructuredText files in a git repo. In a broad sense, anything along the lines of "I would write docs for using Fedora Cloud, if..." would be great. Hopefully, we can find some balance between cloud and writing expertise and deliver something exciting. At this point, I'm focusing on enabling you; let's work that out. -- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org

4 years, 7 months

6
16
0 / 0

[cloud] #58: get vagrant-libvirt (and/pr vagrant-kvm) plugins into the distro

by Fedora Cloud Trac Tickets

#58: get vagrant-libvirt (and/pr vagrant-kvm) plugins into the distro --------------------+-------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: --------------------+-------------------- See http://ttboj.wordpress.com/2014/05/13/vagrant-on-fedora-with-libvirt- reprise/ and the call for help at the end. Also the discussion there, and also previous work at * https://bugzilla.redhat.com/show_bug.cgi?id=998503 * https://fedoraproject.org/wiki/Changes/Vagrant -- Ticket URL: <https://fedorahosted.org/cloud/ticket/58> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

4 years, 8 months

1
1
0 / 0

[cloud] #92: Need rootfiles package in fedora:latest Docker base image

by Fedora Cloud Trac Tickets

#92: Need rootfiles package in fedora:latest Docker base image -----------------------------------+-------------------- Reporter: scollier | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker Base Container | Keywords: -----------------------------------+-------------------- We need the .bashrc in order to properly change the bash prompt once changed into the image. For example, here's the fedora:20 image: -bash-4.2# docker run -it fedora:20 bash [root@845950cd95f1 /]# cat /etc/fedora-release Fedora release 20 (Heisenbug) [root@845950cd95f1 /]# rpm -qf /root/.bashrc rootfiles-8.1-16.fc20.noarch For example, here's the fedora:latest image: -bash-4.2# docker run -it fedora:latest bash bash-4.3# rpm -qf /root/.bashrc error: file /root/.bashrc: No such file or directory -- Ticket URL: <https://fedorahosted.org/cloud/ticket/92> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

4 years, 8 months

1
4
0 / 0

[cloud] #86: qcow2 images text is a bit obscure / OpenStack-only

by Fedora Cloud Trac Tickets

#86: qcow2 images text is a bit obscure / OpenStack-only ----------------------------+-------------------- Reporter: jzb | Owner: jzb Type: task | Status: new Priority: normal | Milestone: Future Component: Website & Wiki | Keywords: ----------------------------+-------------------- Lars Kellogg-Stedman sent a note to the Fedora Cloud list today noting, rightly, that the libvirt audience might miss the qcow2 images because it's labeled "OpenStack" (only) rather than being more expansive. We need to correct this and add instructions for using cloud-init with the image in Virt-Manager, etc. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/86> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

4 years, 9 months

1
1
0 / 0

Atomic 2 week releases

by Mike McGrath

Hey all, I wanted to start a thread about doing more frequent Atomic releases in Fedora. In particular I'd like to start building a new atomic release every two weeks that includes the latest version of Docker, Kubernetes, and OSTree for the Fedora Atomic images. The problem I'm trying to solve here is that there is a lot of work going on upstream in the Docker and Kubernetes communities and there isn't a very good way to consume that upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more regular releases, we can fix some of the issues we've seen (like demoing new features at a conference that people can't actually use). There are still some details to work out like whether to base this image on Fedora $CURRENT or rawhide and what to do when the builds fail. Fortunately, this can possibly be done without much additional change to the release process. We're already rebuilding the docker/kubernetes/ostree rpms almost daily, and there are nightly builds as well (at least in rawhide). If we can pull a 2 week process off, I'd like to see that followed by a 4 week process in CentOS which will behave similarly but with the slightly slower-moving, more stable bits. Thoughts? [1] http://www.projectatomic.io/download/ -- Mike McGrath | mmcgrath(a)redhat.com | (312) 660-3547 Atomic | Red Hat Chicago | http://projectatomic.io/

4 years, 9 months

16
45
0 / 0

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud March 2015