cloud December 2015

cloud@lists.fedoraproject.org

29 participants
97 discussions

[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] #139: Producing 2 week atomic images
by Fedora Cloud Trac Tickets 23 Feb '16

23 Feb '16

#139: Producing 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting -----------------------+--------------------- This is upon us now. Nightly images are here: http://alt.fedoraproject.org/pub/alt/atomic/testing/ This ticket should track any issues/blockers/improvements we need to make to this process. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/139> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 11

[cloud] #135: Fedora 23 Retrospective
by Fedora Cloud Trac Tickets 17 Feb '16

17 Feb '16

#135: Fedora 23 Retrospective --------------------+--------------------- Reporter: jzb | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting --------------------+--------------------- We need to look back on the 23 process and what went right and wrong. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/135> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 5

Fedora 23 Cloud Atomic Developer Mode Preview
by Jonathan Lebon 20 Jan '16

20 Jan '16

Hi all, As some of you may already know, I've been working on adding a new feature to the Fedora 23 Cloud Atomic image called "Developer Mode" (I'm not sure yet if this is the correct name for it). The Trello card is available at [1]. The high-level goal is to make Atomic more accessible by providing a new GRUB 2 menu item labeled e.g. "Fedora 23 (Twenty Three) Developer Mode". This mode is an attempt to provide a painless experience for folks who want to try out Atomic, but (1) do not want to bother setting up a cloud- init datasource, or (2) do not know anything about cloud- init, or even (3) do not have much experience with Linux overall. Since the functionality is completely integrated into the image, there are no requirements on the host system, other than its ability to boot VMs. When booted in Developer Mode, the following happens: - cloud-init uses a local built-in datasource - a new root password is generated - the root user is automatically logged in on tty1 - the cockpit/ws image is downloaded and started - a tmux session is started on tty1 to provide all the relevant information (root password, IP address, Cockpit console address) The first Developer Mode image is available at [2]. I invite you all to try it out and let me know what you think! I've enabled the plymouth splash screen, which for now uses the Fedora theme, but might later be switched over to an Atomic theme. I'd still like to give users a more helpful welcome message after login. Maybe we could link to a new page on projectatomic.io which describes Developer Mode in more details. As Matthew Miller pointed out, one of the drawbacks of this approach is that the GRUB 2 menu timeout will probably have to be slightly increased to give users more time to make their selection (at the expense of also increasing boot times in contexts that don't care about Developer Mode). In my experience, increasing it by only 1s (for a total of 2s) was enough, but we should probably discuss it more. We can also minimize this by shipping with a grub.cfg that uses a 2s timeout, but with the default of 1s, so that at the next grub2-mkconfig (e.g. on an upgrade/rebase), it will go back to 1s. Code is available at [3]. Some modifications to the kickstart file were also necessary. Cheers, Jonathan --- TL;DR: I added a new boot menu item to the Atomic image so that you don't have to set up cloud-init. You can download it from [2]. [1] https://trello.com/c/eK54YRTp [2] https://jlebon.fedorapeople.org/atomic-devmode/latest/ [3] https://github.com/jlebon/atomic-devmode

5 13

Updating getfedora.org with atlas.hashicorp information
by Lalatendu Mohanty 15 Jan '16

15 Jan '16

I think we should update the getfedora cloud pages [1] [2] with information about Fedora cloud base and atomic images are available at atlas [3] [4] as alternate download methods. If we can't do the above, some information about having the boxes in atlas [4] in getfedora/cloud would help. So that users who likes to fetch the boxes from atlas.hashicorp will move in that direction. [1] https://getfedora.org/en/cloud/download/index.html [2] https://getfedora.org/en/cloud/download/atomic.html [3] https://fedoramagazine.org/fedora-cloud-vagrant-boxes-atlas/ [4] https://atlas.hashicorp.com/fedora -Lala

3 4

[cloud] #133: Hand off Atlas release process for vagrant boxes to releng
by Fedora Cloud Trac Tickets 11 Jan '16

11 Jan '16

#133: Hand off Atlas release process for vagrant boxes to releng -----------------------+----------------------- Reporter: dustymabe | Owner: dustymabe Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: -----------------------+----------------------- We are going to start releasing our vagrant boxes in Atlas. Right now the process is manual and not handled by releng. We are planning to give releng full access and insight into the process and work with them on making it something that can be automated and something they can own (with help from us). A few steps we need to take: 1. Have a meeting (google hangout) with releng to show them what is done today 2. Give releng access 3. Help develop a way to automate it and make it reproducible for next release. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/133> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 1

[cloud] #121: Migrate all Dockerfiles / Images to systemd where possible
by Fedora Cloud Trac Tickets 10 Jan '16

10 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

rpm-ostree, failed upgrade, failed rollback
by Chris Murphy 28 Dec '15

28 Dec '15

Questions: - Does rpm-ostree keep an upgrade log of what it did during the upgrade? If so where is it? - Is there a config file to permit it to keep more than two trees at a time? - Is there a way to correlate ostree tree hashes and their release versions? The problem: I have a Fedora-Cloud_Atomic-x86_64-23.iso with a btrfs root and ext4 boot, in an otherwise conventional (flat, no subvolumes) layout. After today's 'rpm-ostree upgrade' the new tree isn't in the /boot/efi/EFI/fedora/grub.cfg. The old tree is still there, but the path to that old tree has changed so even trying to boot that old tree fails. I'm still in the middle of the autopsy but what appears to be the case: 1. The /boot/loader.0/grub.cfg contains the 23.29 and 23.34 trees. 2. This is a UEFI system which doesn't use that grub.cfg, it uses the one at /boot/efi/EFI/fedora/grub.cfg 3. That ESP grub.cfg wasn't updated, it's stale. I don't know why it wasn't updated. It contains the 23.29 and 23 tree entries, both of which look for ostree=/ostree/boot.1 4. The next problem is on rootfs there is no /ostree/boot.1, it's /ostree/boot.0 which is a symlink to /ostree/boot.0.1. And hence the double fail. So there are in effect two fails: A. The EFI System partition grub.cfg was not updated at all. B. The /ostree path changed in such a way that made it impossible for a stale grub.cfg to boot the old working tree that's still present. I think there's a bug here somewhere, even if it might be user induced (exposed) due to a non-standard installation. But off hand I can't figure out how the non-standard install may have affected this upgrade. The 23 to 23.29 upgrade worked, except for root=UUID= was wrong, and that's due to... skip that part right now. I think there's a bug if it's intended for the priot /ostree/boot* path to change in an upgrade. That seems fragile because if either that change or the grub.cfg change doesn't happen, then the rollback is going to fail too. I think that old (current prior to upgrade reboot) tree needs to stay the same no matter. Non-standard install gory details: "ostree+grub2 will not auto-regenerate root=UUID=" https://bugzilla.redhat.com/show_bug.cgi?id=1290296 Gist is, that bug has an easy work around, and doesn't involve the ostree= parameter or a changed /ostree/boot* path at all which is why I don't think it's related. But I'm still suspicious because, well otherwise other people would be affected by now and I wouldn't be the first one posting this problem. -- Chris Murphy

2 8

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by Dusty Mabe 28 Dec '15

28 Dec '15

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2015-12-30 from 17:00:00 to 18:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/

1 0

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud December 2015