[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
8 years, 1 month
Fedora 23 Cloud Atomic Developer Mode Preview
by Jonathan Lebon
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
8 years, 3 months
[cloud] #133: Hand off Atlas release process for vagrant boxes to releng
by Fedora Cloud Trac Tickets
#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
8 years, 3 months
[cloud] #122: Clean up READMEs.
by Fedora Cloud Trac Tickets
#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
8 years, 3 months
rpm-ostree, failed upgrade, failed rollback
by Chris Murphy
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
8 years, 3 months
