cloud October 2015

cloud@lists.fedoraproject.org

24 participants
89 discussions

[cloud] #131: make docker archived image get imported with lowercase tag
by Fedora Cloud Trac Tickets 20 Apr '16

20 Apr '16

#131: make docker archived image get imported with lowercase tag -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting -----------------------+--------------------- Our docker image has a repositories file with this in it: ``` {"Fedora-Docker-Base-23_TC1-20150929.x86_64": {"latest": "27653b989fba2fada76e804f4112b87d7b013758e99bbb88a26c070dbcae5962"}} ``` This means that the docker image gets tagged with Fedora-Docker-Base- 23_TC1-20150929.x86_64 when it gets loaded in. Unfortunately if you try to build on top of this image by having a Dockerfile with `FROM Fedora- Docker-Base-23_TC1-20150929.x86_64` then you will get an error because only lowercase letters are allowed in tags of images in a registery: "[a-z0-9]+(?:[._-][a-z0-9]+)*" We should update this so that users can have a better experience. [1] - //dl.fedoraproject.org/pub/alt/stage/23_TC1/Docker/x86_64/Fedora- Docker-Base-23_TC1-20150929.x86_64.tar.xz -- Ticket URL: <https://fedorahosted.org/cloud/ticket/131> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 8

[cloud] #123: Document process for using Fedora-Dockerfile branches
by Fedora Cloud Trac Tickets 23 Mar '16

23 Mar '16

#123: Document process for using Fedora-Dockerfile branches ----------------------+-------------------- Reporter: scollier | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: ----------------------+-------------------- This should probably go on the github repo home page. Need to provide instructions for users to submit to a specific branch, and not just to master. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/123> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 10

[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] #121: Migrate all Dockerfiles / Images to systemd where possible
by Fedora Cloud Trac Tickets 11 Jan '16

11 Jan '16

#121: Migrate all Dockerfiles / Images to systemd where possible ----------------------+-------------------- Reporter: scollier | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: ----------------------+-------------------- There are some images that still use supervisord. We need to migrate those to systemd. One example: https://github.com/fedora-cloud/Fedora- Dockerfiles/tree/master/lighttpd -- Ticket URL: <https://fedorahosted.org/cloud/ticket/121> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 16

[cloud] #122: Clean up READMEs.
by Fedora Cloud Trac Tickets 06 Jan '16

06 Jan '16

#122: Clean up READMEs. ----------------------+-------------------- Reporter: scollier | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: ----------------------+-------------------- The readmes need to be cleaned up a bit and standardized. Some have "Tested on Docker 1.4.0" We need to update those. Needs standard sections: Build Run Test -- Ticket URL: <https://fedorahosted.org/cloud/ticket/122> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 5

[DISCUSS] Cloud and Server Workgroup relationship
by Joe Brockmeier 20 Nov '15

20 Nov '15

Hi all, During today's Cloud Working Group meeting we had a short but spirited discussion on the roles of the Cloud and Server Working Group and the editions we're producing. I wanted to open a discussion on that topic (see also [1]) ahead of planning for F24 to see if the current setup makes sense, how we can collaborate, and so forth. I have opinions but I want to kick off a discussion without starting from a specific viewpoint. And... go! [1] https://fedorahosted.org/cloud/ticket/127 -- Joe Brockmeier | Community Team, OSAS jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

15 34

[cloud] #116: Fedora Vagrant Boxes in Atlas
by Fedora Cloud Trac Tickets 16 Nov '15

16 Nov '15

#116: Fedora Vagrant Boxes in Atlas -----------------------+----------------------- Reporter: dustymabe | Owner: dustymabe Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting -----------------------+----------------------- We need to get our boxes into atlas to make it easier for people to pull down our vagrant boxes. lala/KB have got a few centos boxes in there. Let's get Fedora in there too. I will work with lala to add boxes and co-maintain. We'll use this ticket as an update on the progress. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/116> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 13

[cloud] #127: Working with the Server WG
by Fedora Cloud Trac Tickets 11 Nov '15

11 Nov '15

#127: Working with the Server WG -------------------------------------------+--------------------- Reporter: roshi | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Collaboration & Communication | Keywords: meeting -------------------------------------------+--------------------- It was brought up in today's Server WG meeting [0] that they wanted to do some coordination with Workstation and Cloud. Ideas for WS are already there, but some thought should be put into how Server and Cloud can make things easier for both to work together when they're deployed. This ticket is a call to arms for some brain storming on this topic. [0] https://meetbot.fedoraproject.org/fedora- meeting-1/2015-10-13/serversig.2015-10-13-15.00.log.html -- Ticket URL: <https://fedorahosted.org/cloud/ticket/127> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 6

[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

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud October 2015