cloud May 2015

cloud@lists.stg.fedoraproject.org

18 participants
74 discussions

dnf in Dockerfiles
by Joe Brockmeier 15 May '16

15 May '16

Hey all, So dgilmore pointed out that f22 docker images will not have yum installed - which means we need to update the Dockerfiles for f22 to use dnf and not yum. We probably ought to go through and sanity-check them all to ensure they work with the f22 image as well before, say, beta. I'm CC'ing Scott b/c, if I'm not mistaken, he's done quite a lot of the work so far on the Dockerfiles - but also, I think he's looking for assistance there in keeping the effort going. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

10 12

[cloud] #88: Social Media for Dockerfiles
by Fedora Cloud Trac Tickets 24 Feb '16

24 Feb '16

#88: Social Media for Dockerfiles -----------------------------------+--------------------- Reporter: jzb | Owner: jzb Type: task | Status: new Priority: normal | Milestone: Future Component: Docker Base Container | Keywords: meeting -----------------------------------+--------------------- We need to work with marketing to tweet about things regularly. I'd like to put out regular tweets to promote individual Dockerfiles. Thoughts? -- Ticket URL: <https://fedorahosted.org/cloud/ticket/88> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 7

[cloud] #99: AMI lifetimes (Cloud WG members vote needed)
by Fedora Cloud Trac Tickets 24 Feb '16

24 Feb '16

#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

1 18

[cloud] #94: Producing Updated Cloud/Atomic Images
by Fedora Cloud Trac Tickets 11 Nov '15

11 Nov '15

#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

1 24

[cloud] #84: publicize fedora-dockerfiles
by Fedora Cloud Trac Tickets 23 Sep '15

23 Sep '15

#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

1 21

[cloud] #105: Missing Cockpit RPMs in Fedora Atomic 22
by Fedora Cloud Trac Tickets 23 Sep '15

23 Sep '15

#105: Missing Cockpit RPMs in Fedora Atomic 22 -------------------------------+----------------------- Reporter: jzb | Owner: Type: defect | Status: new Priority: blocker | Milestone: Fedora 22 Component: Docker Host Image | Keywords: meeting -------------------------------+----------------------- We seem to be missing the cockpit rpm that includes the systemd files (e.g. /usr/lib/systemd/system/cockpit.socket). Can we add cockpit-ws for the next update? We'll probably not be able to respin the images, but an atomic update can pull in the package. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/105> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 25

[cloud] #97: Maintaining Fedora docker images for f22
by Fedora Cloud Trac Tickets 22 Jul '15

22 Jul '15

#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

1 8

basic plan for two-week atomic images
by Matthew Miller 17 Jun '15

17 Jun '15

This is a strawman based on my understanding of current abilities, available software/systems, and of what the developers want. Please poke holes, reorder, add and subtract, etc. Phase I 1. F22 trees built nightly (already happening) 2. Images built from those nightly (I think right now only rawhide?) 3. Images go through automated tests, automatically (tunir; not fully automatic yet, right?) 4. Every two weeks, latest image to pass those tests gets linked on atomic.fpo, again all automatically (NEEDS DESIGN AND CODE) - probably need a manual override - page will present these images with appropriate setting of expectations ("fedora qa not to blame for anything here"). - need something to happen if there aren't any that pass for two weeks, which should not happen I hope, but, y'know) * automatic message about image being out of date * next successful image automatically posted? Or do we skip two weeks? - also needs: commitment to follow and fix if things break Phase II 5. Ability to include packages from a side tag, repo, something. All full, legit Fedora packages destined for main repo but maybe at a different speed. (Implementation needs work) - possibly initially just selected packages from updates-testing? Phase III 6. Something to only expose Atomic users to _update sets_ that pass the tests (because, hey, we have tests!) 7. Presumably, there will be a switch to F23 as base at F23 release; will there be overlap (beta images) to make that smooth? 8. What else? Phase IV 9. Expand tests beyond tunir — test installs on hardware, etc. 10. Maybe create a new, special Fedora repository for packages with version skew mainline Fedora — e.g. newer systemd or hold older Docker version for some reasons. (Up for discussion — that's why this is in phase 3!) 11. More what else? Does this seem basically sane and in line with what people are expecting? What's missing? What's extra? What's just wrong? :) -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

6 15

[cloud] #96: Atomic as separate spin (or, going the other way, main cloud edition)?
by Fedora Cloud Trac Tickets 17 Jun '15

17 Jun '15

#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

1 6

Log from this week's meeting
by Kushal Das 29 May '15

29 May '15

=================================== #fedora-meeting-1: Fedora Cloud SIG =================================== Meeting started by kushal at 19:00:15 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-27/fedora-meeting… . Meeting summary --------------- * Roll Call (kushal, 19:00:23) * Fedora 22 release (kushal, 19:03:54) * LINK: https://github.com/cockpit-project/cockpit/wiki/Atomic (nzwulfin, 19:08:47) * ACTION: kushal will work to get a -latest.box link up for vagrant boxes (kushal, 19:12:50) * ACTION: scollier write blog for using Cockpit container on Atomic / Fedora 22 (jzb, 19:14:00) * nzwulfin is reviewing the getting started guide based on the release (kushal, 19:18:10) * Fedora 23 (kushal, 19:19:02) * LINK: https://fedoraproject.org/wiki/Cloud/Cloud_PRD (kushal, 19:21:54) * Open Floor (kushal, 19:34:55) * ACTION: everyone start working on an agenda for Cloud WG meeting at Flock (number80, 19:37:13) Meeting ended at 19:41:03 UTC. Action Items ------------ * kushal will work to get a -latest.box link up for vagrant boxes * scollier write blog for using Cockpit container on Atomic / Fedora 22 * everyone start working on an agenda for Cloud WG meeting at Flock Action Items, by person ----------------------- * kushal * kushal will work to get a -latest.box link up for vagrant boxes * scollier * scollier write blog for using Cockpit container on Atomic / Fedora 22 * **UNASSIGNED** * everyone start working on an agenda for Cloud WG meeting at Flock People Present (lines said) --------------------------- * kushal (58) * roshi (21) * jzb (20) * number80 (19) * sgallagh (16) * scollier (11) * dustymabe (11) * zodbot (8) * nzwulfin (6) * adimania (4) * mattdm (4) * purpleidea (4) * oddshocks (3) * jsmith (2) * maxamillion (2) * jbrooks (1) * stefw (1) * lsm5 (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Fedora Cloud Engineer CPython Core Developer Director @ Python Software Foundation http://kushaldas.in

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud May 2015