Re: Future directions for Fedora Cloud

[Colin Walters]

On Wed, 2013-09-11 at 12:01 -0400, Matthew Miller wrote:

> So, idea one is to make something like CoreOS (http://coreos.com/): a
> lightweight distribution made for running containers on top of. We wouldn't
> attempt to be _as_ lightweight as CoreOS (for that, there's CoreOS), but aim
> to be small while still providing key features like SELinux. 

How SELinux would work in a coreos/container deployment setup is an
interesting question.  One could imagine docker containers coming with
policy modules, but that ends up tying them to a specific host version,
which is kind of against the point of containers.

More realistically I think one would have a relatively permissive domain
(generic_container_t), and use something like MCS labels to restrict the
flow of information between containers and the host.

> Perhaps this
> could be built with Colin Walter's OSTree (see
> https://wiki.gnome.org/OSTree) for atomic updates.

To follow up on this, I have been working slowly on this tool called
"yum-ostree" which is designed to capture packages as OSTree commits.
At the moment it's just a lame python script, but it's nearly to the
point of being useful.  I'll post to the generic fedora-devel-list when
it's ready.

As far as OSTree compared to CoreOS; the biggest difference is that the
CoreOS updater mandates a particular filesystem chosen on the build
server, because it sends block-level diffs.  OSTree operates at the
filesystem layer (like rsync), and this allows more flexibility.  (At
the moment though, OSTree is significantly less efficient on the network
side).


___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

min-metadata-service 2014.2

[Colin Walters]

Hi,

https://github.com/cgwalters/min-metadata-service

is a new project of mine which might be of interest to a potential few 
people here in the cloud space that are building smaller operating 
systems - small enough to not include Python (or other scripting 
languages).


I just released 2014.2, and it successfully provisions SSH keys from 
OpenStack.



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ostree and fedora cloud

[Colin Walters]

On Mon, Feb 10, 2014 at 1:37 AM, Matthew Miller 
 wrote:
So at my Fedora.next talk at DevConf, I mentioned that OSTree might 
be an
interesting thing for Fedora Cloud to look at. 



I am obviously interested in this =)  I have some forthcoming work to 
post within a week or so.



But I also mentioned that we
haven't really talked about it here. So let's talk about it. I'm 
interested
in it for two reasons: it gives us part of an answer to what CoreOS 
offers,
and we miht have a space where it's an easier problem than for the 
general
Fedora distro, and therefore could be an incubation/test area. 
Discuss!



Ok so there are two cases:

1) Fedora provides OSTree repository
2) Downstream consumes RPMs and creates internal OSTree repository

It's #2 that I think is going to be most interesting for cloud 
consumers at present. That's feedback I got from talking to people at 
devconf - they could definitely see the use case where organizations 
make their own internal trees and replicate them out to their servers 
(or clients).


Right now if we just shipped a cloud image that used OSTree (model #1) 
most people would just say "but how do I install stuff"? =)   

Though we should have a continuously generated and tested tree for the 
default cloud that'd be used for development - this is the broader 
rpm-ostree story.  I'll post more about that soon too.




___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: min-metadata-service 2014.2

[Colin Walters]

On Tue, Feb 11, 2014 at 6:32 PM, Colin Walters  
wrote:

Hi,

https://github.com/cgwalters/min-metadata-service


And here's the Fedora review request:

https://bugzilla.redhat.com/show_bug.cgi?id=1066176

This got bumped up in priority for me because it needs SELinux policy 
(equivalent to cloud-init) in order to function in enforcing mode, and 
my best bet for landing the policy is landing in Fedora itself.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Automatic Smoketests for the Cloud Images: What to Test?

[Colin Walters]

On Wed, Mar 5, 2014 at 6:58 AM, Sandro red Mathys 
 wrote:

Heads-up: I've taken ownership for the external need "Automatic
Smoketests on Image Build" [0]

Testing an image takes time and resources, and with several images, it
takes several times that. Since that simply doesn't scale - well,
doesn't even work well without scaling - we want to automate the
smoketests using Taskotron. 



rpm-ostree has included in it an (unnamed) custom qemu-based testing 
hypervisor, which derives from gnome-continuous.  Most of the code is 
in here:

https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/tasks/testbase.js

What makes the rpm-ostree testing hypervisor fundamentally different 
from a lot of other testing systems out there is it works without IP 
networking.


Basically:

1) Use libguestfs to inject testing code into the guest
2) The host offers a dbus-over-virtio-serial channel for guests to 
request things like screenshots

3) Watch the systemd journal from the guest for events

Again, operating without guest IP networking and having the ability to 
watch early boot events like the console.log and systemd journal are 
key.


Where I'm going with this eventually is that this testing code acts as 
a basic smoketest, performed on the same physical host as the image 
(tree) composition servers.  If that passes, then we have an OS version 
that can be sanely provisioned at a larger scale - say to OpenStack, or 
to things like AutoTest/Beaker physical hardware inventory/provisioning 
systems.


For example the basic smoketest:
https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/tasks/task-smoketest.js

All it does is watch the systemd journal for two events.  If we reached 
multi-user.target, we're good.  If any service crashed, we failed.


This testing code is rather deeply intertwined with the larger 
rpm-ostree/ostree deployment model - but I'd consider patches to help 
test traditional RPM-on-the-client OSes.


(Really it's not even *that* much code, it wouldn't be too hard to 
fork/rewrite it)



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Thu, Mar 6, 2014 at 1:39 AM, Sandro red Mathys 
 wrote:


I agree it's a nice model but wouldn't set N to a very high value.



Right, I agree with that.  In the same way that going to a restaurant 
with 500 menu items is overwhelming. 


Also, I worry a bit about the QA and tracking down bugs (most devs
will always point at ostree). But happy to explore the possibility.



Remember that "rpm -qa" works - a tree is always composed of a set of 
packages.  So you can determine what versions of packages you have, 
file bugs against them, etc.   OSTree is just pre-computing on the 
build server what in the traditional package world happens per-client.



Oh, totally. Still, I would rather have a statement from Colin Walters
that states it's in a good enough state for our use case. Leading-edge
is good, broken edges aren't :)



Short answer: Yes, I think so.  Longer answer: It varies a bit.  Most 
of the core design has been implemented for ~1.5 years, and I and 
others have done many upgrades using it.  The rpm-ostree layer being in 
a functional state is much newer, and things like the SELinux 
integration are quite new.


  - The atomic model has some flexibility issues, and really 
assumes
another container layer on top for actually using it for 
anything,




I would agree with this - except that a model I think many people will 
like is using the rpm-ostree tool to spin their own *internal* OSTree 
repositories from the Fedora package set plus their custom stuff.


Then they can replicate out their content from there.

A good example of this use case is the "coporate standard build" laptop 
deployment, where the user has no ability to add/remove stuff.


In my food analogy, traditional RPM delivery is like a grocery store, 
and OSTree is more like a restaurant (attached to the grocery store, 
using its ingredients).


This model then is like a corporate cafeteria that buys ingredients 
from the upstream grocery store, and creates their own food, likely 
reusing recipies from the restaurant, and adding their own ingredients.



Which we do, and that technology is called Fedora! ;) But sure, why
not do Fedora < ostree < Docker. Can't hurt to staple the
blood-smeared edges, right? :)



=)


One last question: even with ostree, we'd still create the image using
ImageFactory/Anaconda, right?

So rpm-ostree also contains code to make .qcow disks.  It's not as 
flexible as Anaconda, e.g. the partition layout, bootloader, etc. is 
hardcoded:


https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/libqa.js#L119

Right now, Anaconda has no idea about OSTree.  But this is a very high 
priority for me.




___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Thu, Mar 6, 2014 at 8:19 AM, Sandro red Mathys 
 wrote:


- Create image using ImageFactory (and initialize ostree in %post)


This is possible, but in the realm of options which range from:

1) Hack up current rpm-ostree direct .qcow2 generation code
2) ImageFactory with custom %post
3) Anaconda support

I'd rather at least *attempt* to go straight from #1 to #3.

If anyone wants to play around with #2 though, the relevant code is 
here:

https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/libqa.js#L338

One thing that's pretty important to understand about all of this is 
that OSTree needs to own writing the bootloader configuration - not 
anaconda, not grubby out of a %post. That's how the atomic upgrades 
work.


So you can see the code above creates a "stub" extlinux configuration, 
and then "ostree admin deploy" will end up updating it.



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Thu, Mar 6, 2014 at 11:52 AM, Matthew Miller 
 wrote:


I think it will eventually be pretty useful for servers, although 
without a

good layer on top, we would just be, to extend your analogy, forcing
everyone to buy their groceries from a restaurant, and making them 
build and

run the restaurant if they don't have one already.



I wouldn't say it that way; we already require everyone to assemble the 
ingredients.  This is just making it easier to reliably replicate the 
meals.


Right now, it's not just any typical American restaurant. It's more 
like a
restuarants with a prix fixe menu, where your soup, salad, appetizer, 
main
dish, dessert, and beverage are all preselected together. Is that 
fair?




That is fair indeed!  It's true that it'll be a lot more interesting 
when one can install packages on top.  For those who haven't read it 
before:


https://wiki.ubuntu.com/ImageBasedUpgrades
https://wiki.ubuntu.com/ImageBasedUpgrades/ExtraPackageInstallation

are interesting comparison point.  What makes OSTree more a lot more 
flexible than Ubuntu's ImageBasedUpgrades is that we can make a new 
chroot containing any content we want at any time, transparently 
sharing storage.  This is completely different from trying to layer on 
top of a read-only base.


The important thing isn't Anaconda. It's that we can do it in Koji. 
Making
this be an ImageFactory plugin makes it easy to add to the upcoming 
Koji

release which has ImageFactory integration.



Yes, I'm increasingly thinking tree construction should be in Koji 
indeed.  I mean, that is kind of its purpose - take as input some 
source + build dependencies, perform computation, output more packages 
or derived data.


It would require teasing apart some things in the current code, but 
quite doable.  I think on my priority list this is after Anaconda and 
some other things though.



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Thu, Mar 6, 2014 at 11:58 AM, Joe Brockmeier  wrote:


How would this go over for people coming from $other_images that have 
cloud-init and expect to use it? If I understand correctly, you're 
saying their existing stuff isn't going to work well w/Fedora even if 
we 
have cloud-init, but I wonder if not having it is going to be seen as 
a 
negative?



Yes, I worry about this.  It would have to be messaged very clearly.

On the other hand, I think Matt has identified a small set of 
additional features that would make min-metadata-service have 
sufficient coverage that it wouldn't be too difficult for a lot of 
users to transition.


I admit I don't have much data - but from my view we should just allow 
the admin to bootstrap to better tools which fit the configuration 
management space, like Ansible or Puppet or whatever.



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Fri, Mar 7, 2014 at 4:42 AM, Sandro red Mathys 
 wrote:


Sorry, missing something here. What would I need that code for? I was
actually thinking about writing something like:



Yep, that code is just the JS implementation of the shell script you 
posted.



Hm, does Anaconda write the bootloader config before or after
executing %post scripts? Either the above could still work or not, I
guess.

Now that I dove more into Anaconda code last night, there is an 
important detail: we need to pass the kernel arguments like root= to 
OSTree.  That's the "--karg" option to "ostree admin deploy".


(We could edit it after but that'd be ugly)


___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

- How does one activate the deployed product if extlinux is the active
bootloader? The website has only instructions for GRUB (bls_import,
etc).



Ah, you probably hit this:
https://bugzilla.gnome.org/show_bug.cgi?id=726007
This is also related:
https://bugzilla.gnome.org/show_bug.cgi?id=722845

Basically to make ostree drive extlinux, the layout needs to look like 
this:

https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/libqa.js#L359
- How does one get rid of the 'traditional Fedora' once the product 
is active?




Maybe something like:
rpm -qal | while read line; do rm $line || rmdir $line; done
rpm -qal | while read line; do rm $line || rmdir $line; done


...figure both won't be necessary anymore once we can use Anaconda to
install a product directly, but in the meantime it would be helpful
for some testing and more generally help my understanding. :)


Yep, Anaconda support will fix both.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Mon, Mar 10, 2014 at 8:26 PM, Steven Dake  wrote:




‘1’

I would say that there are many valid ways to provision and manage 
machines, of which Heat/CloudFormation is one.  min-metadata-service 
does exactly what it needs to do to provide the fundamental basis for 
secure remote access to the machine, and with

https://github.com/cgwalters/min-metadata-service/issues/2
the guest will also be able to reach out and register on bootup 
(perhaps by first pulling a docker container), which is all one needs 
to implement higher order management tools.


And there implementation will stop =)

But I'd agree with you (and others have expressed this sentiment) that 
we should be conservative with backing away from cloud-init in the near 
future.


At least for Fedora Cloud.  That said, I am trying to create momentum 
for a smaller but still useful core, ideally written in lovingly hand 
crafted C code, with languages like Python and Ruby still *available*.


I am a bit confused at the scope because min-metadata-server was 
mentioned early on, but is unnecessary if the target of this OS is to 
only run on hosts.




Running as a guest is definitely in scope.

Ideally a python run time would still be available to run 
virtualization 
platforms like OpenStack. 



Sure, of course.  No one is talking about making python unavailable.  
Just possibly not installed by default in all builds.


 Such a bare-bones operating system would make 
alot of sense, but I've copied a TripleO upstream developer (James) 
for 
his thoughts on atomic + ostree and its relationship to how TripleO 
handles continuous deployment through imaging.


I'm certainly interested in the discussion!  OSTree was made from the 
very start to do continuous deployment - at the moment with rpm-ostree 
I am restricting myself to merely accepting RPMs as input, so no 
continuous integration.  But gnome-continuous is a custom build system 
that takes git repositories and writes to the OSTree repository 
directly (with no intermediate package step).




___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Tue, Mar 11, 2014 at 9:33 AM, James Slagle  
wrote:


There are 2 image upgrade paths being pursued by TripleO. In both 
cases, the
end goal is to have your instances running with a read-only root 
partition
and your stateful data you need preserved mounted on a separate 
partition.




Such a model is incompatible with packaging.  In contrast, I think it's 
very important
to note that with OSTree your /etc and /var work (mostly) as they 
always have.


In fact, /etc is better since you now have "ostree admin config-diff", 
which

I always wanted from Unix myself.

The first upgrade path is updating your image id's in your heat 
template and
then doing a "heat stack-update" on a deployed TripleO stack. Heat 
sees that
you're requesting a new image, and triggers a Nova rebuild[1]. After 
the

reboot, the ephemeral partition is preserved for your stateful data.



Right, this model makes a lot of sense in a cloud world.  Configure 
stuff in /etc
via external templates or configuration management, and just drop out 
the

OS and redeploy the configuration.

The second path is for upgrades where you don't want to have to 
reboot, or
rebuild the whole instance to pick up a small change. You update the 
image id
in the heat template (somewhere, probably not the same spot as for 
the case
above). os-refresh-config, which actually runs every 5 minutes in the 
instance,
sees the Heat metadata change. It then operates on that change, by 
pulling down
the new image from glance, cracking it open, remounting root as rw, 
then
rsyncing the changes to the root partition, remounting root as ro, 
etc. 



OSTree is somewhat like this except:

0) It is fully atomic
1) We're not live-mutating your running filesystem (which can easily 
break things)

2) It knows about stuff like /boot and /etc and how to manage them
3) The updates work over plain HTTP, can be GPG signed, etc. just like 
packages


For ostree, I believe you can host the ostree repositories via http?  
I'm
probably reaching here, but I suppose it might be possible for Nova 
to have a
rebuild implementation that used ostree, or even some type of glance 
backend or
"image type" that used ostree. 



There is the concept of a "repository" for OSTree - and it would really 
work best
when placed in an object store like Swift.  I've been meaning to 
prototype out

an OSTree-Swift backend.  But you can just use any static
webserver with whatever Unix file backend you want.

Then you have operating system images which have a particular version 
of a tree

stored in Glance.


 and not really using TripleO at that point, since
you wouldn't be using OpenStack services directly to do the upgrades.

Bare metal upgrades without cloud infrastructure are absolutely a key 
use

case for OSTree.

It is designed for the same use cases as traditional packages - and 
more particularly
to *complement* traditional packages by fixing some of their weaknesses 
like

the lack of atomic updates.


___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Tue, Mar 11, 2014 at 5:17 PM, James Slagle  
wrote:


How is it incompatible with packaging? The read only root support that
already exists in Fedora today is what would be used. 



In that /etc and /var are read-only.  Now you're right, there is 
read-only root which makes sense for certain cases, but changing the OS 
content to write to a special data partition is taking one farther away 
from the generality of the package/FHS model.


How do the images get built? Can you use existing image building 
tools, or it

something ostree specific?



The trees (not images) get composed using rpm-ostree.  It's just a 
wrapper around yum --installroot + ostree commit.


From there after Anaconda support lands, one can install a tree (just 
like a set of packages) into a disk image or bare metal.  In this 
model, Anaconda will be doing far less - it'll just be copying data, 
not depsolving or running through the SELinux labeling, etc.



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Colin Walters]

On Wed, Mar 12, 2014 at 12:33 PM, James Slagle  
wrote:


But, to be clear, someone* saying the TripleO approach is 
"incompatible with
packaging" is equivalent to saying Fedora's builtin readonly root 
support is
"incompatible with packaging". 



You are right, I was assuming that what you were talking about was a 
more simplistic "data goes in /mnt/data" type approach.  While the 
readonly root approach is a little hacky (IMO), I would describe it as 
compatible with packaging.


Is there any similar equivalent for dpkg, like a dpkg-ostree? 



There is one I know of, but it is not public.  I don't think it's 
secret sauce, so I may ping the people to ask it be opened up.


My personal opinion is that TripleO, and OpenStack in general, should 
offer
differing implementations where it makes sense. Things like the Nova 
driver
model, storage backends, etc. I'd like to see TripleO offer such 
choices as

well where it makes sense.



I would say that some level of duplication of effort is unavoidable.  
TripleO can't depend on OSTree (for example, I'm sure TripleO targets 
EL6), and neither can OSTree depend on TripleO (since it needs to 
support non-cloud bare metal).


The key is just to make sure that duplication is minimized and that 
when both features are available, they work in concert as much as 
possible.


I'm certainly very interested in having OSTree work well in the cloud 
space.  As we discussed before, while in many ways if one does things 
"right" in cloud, some of the OSTree features such as preserving the 
traditional /etc and /var aren't necessary.  On the other hand - I'd 
say it's still quite sane to deploy "traditional" servers in a cloud 
environment, and OSTree is useful there too.


FWIW, I definitely "see the light" so to speak with what ostree has 
to offer.
I've been hovering aound different package management solutions for 
quite a
while. Besides rpm, I spent a few years working closely with Conary, 
which you

mention on your RelatedProjects wiki. Even though I have a limited
understanding of the ostree implementation, it appears to hit the 
mark of what

I see as a very compelling update model.

Thanks! =)  I appreciate that.  
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Cloud Workgroup Meeting Minutes 01 May 2014

[Colin Walters]

On Thu, May 1, 2014 at 2:37 PM, Mike Ruckman  
wrote:



* Crucial basic Docket Host Image decisions  (jzb, 08:07:23)
  * https://fedorahosted.org/cloud/ticket/47  (jzb, 08:07:36)
  * AGREED: fedora atomic docker-specific image will not include 
yum/dnf

(mattdm, 08:15:47)


OK, but with rpm-ostree I'd like to highlight that it does already link 
to libhawkey and rpm, which are the same C libraries underlying dnf.  
This is important preparatory work for package layering.


That said, has anyone built a list of blockers/issues they see?  I have 
made a good amount of progress on Anaconda, and I'm pretty confident of 
delivery by next month.


  * AGREED: try min-metadata-service for fedora atomic image for 
alpha,

fall back to cloud-init for beta if it doesn't work out  (mattdm,
08:29:56)


I'm interested in this as well, although I don't see it as so critical. 
Investing in thinning down cloud-init is also likely viable.



  * AGREED: aim for getting python out of the fedora atomic image too,
if all of the previous things line up.  (mattdm, 08:34:36)


One issue I see here is that there are a lot of valid reasons to want 
Python on the host for configuration management type tasks, and the 
answer to this is to still support local package layering on top of a 
base tree.


I'm relatively confident I can have basic package layering by Alpha.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Cloud Workgroup Meeting Minutes 01 May 2014

[Colin Walters]

 I'm not sure what you are saying here. This is about yum/dnf/etc. 
being

in the minimal install image for the Atomic host.
 Do you plan to ship rpm-ostree in that?


I thought that was the plan?

 I guess you are saying that you are planning on shipping more than 
just

ostree, so people can do the rpm packages diff thing? Or for other
features too?


Packages diff, plus future support for layering packages.  Concretely, 
I really want the ability to add stuff like strace and gdb.



 Are you sure this feature is worth bringing in the entire
libhawkey/librepo/libcomps/librpm chain?


Yeah, they're not large.  Or put another way, at least I'm seeing far 
larger space offenders.



 Not really. puppet is in ruby, cpanel is in perl. I'm not saying it's
sane, but users really hate python deps. ... so we'd probably want 
more

than "It's a sane language, and could be useful"


There's Ansible, but yeah; I was more saying I think the configuration 
management space is another reason to support general package layering, 
not for/against Python specifically.




___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

The special extlinux + grub1 situation in current Fedora Cloud

[Colin Walters]

Hello cloud dwellers,

So I was looking at rpm-ostree + EC2 stuff, and digging into the 
current Fedora cloud image, I hadn't realized just how special it is.  

Basically we have extlinux in the VBR, and 
/boot/extlinux/extlinux.conf.  This is used by qemu-kvm/OpenStack.  But 
in order to support EC2's pv-grub, we also have /boot/grub/grub.conf 
which is generated by hand from the kickstart file.


Then for upgrades, grubby knows how to update both config files.  Due 
to the way grubby is implemented, it also handles the fact that they 
have *different* kernel arguments.  We're conflating EC2 with grub1, 
and setting console=hvc0.


So...ostree is really not set up to handle this.  A bit of background - 
ostree is designed around the BLS:

http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
Concretely it writes /boot/loader.[01]/entries/ostree-.conf
for each root.  Why [01]?  That's how the atomic updates are 
implemeted, when we want to update the config, we create a new dir, 
write files, then swap the symlink.


Not every bootloader implements the BLS (in fact it's mostly just 
gummiboot and pjones' patch for grub2).  So what OSTree does is update 
traditional config files like /boot/syslinux.cfg from that config.


Now, I could probably with not too much effort synthesize both extlinux 
and grub1 configs.  But that wouldn't handle this case where we 
actually have different kernel arguments.


What makes this situation uglier is writing the grub1 config by hand - 
Anaconda still has code to write grub1 configs, even though the grub1 
package no longer exists in Fedora.


Would anyone be opposed to having separate kickstarts for EC2 versus 
qemu/kvm?  It feels like with EC2 it'd be less magical if we used the 
new "bootloader --disabled" to skip installing extlinux (or grub2) at 
all, and kept our hack to create the grub1 config.


Then for OpenStack we use extlinux.  These kickstart files would of 
course inherit from a common content definition/configuration base.


BTW - another argument for splitting is that with GCE, we'll likely 
want a custom configuration for cloud-init (or min-metadata-service) to 
have it DTRT.  


Thoughts?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The special extlinux + grub1 situation in current Fedora Cloud

[Colin Walters]

 new "bootloader --disabled" to skip installing extlinux (or grub2) 
at all, and kept our hack to create the grub1 config.


A perhaps better variant of this is (since I have the Anaconda source 
code open for ostree stuff anyways) is to support bootloader --pvgrub 
which would tell Anaconda to just write out the config, but not 
actually attempt to install the bootloader.



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Cloud Workgroup Meeting Minutes 01 May 2014

[Colin Walters]

On Wed, May 7, 2014 at 9:28 AM, Joe Brockmeier  wrote:


Any chance you can make it to tomorrow's meeting? We might have more
questions that you are uniquely qualified to help us sort out.


I'll be on IRC, but unfortunately I have a time conflict on that slot 
(as I imagine many people do as it's a prime time that's reachable by 
PST, EST, and GMT).


And don't hesitate to send email at other times of course!
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reviewer needed for renamed min-cloud-agent

[Colin Walters]

Hello world,

I finally got some time this weekend to work on min-metadata-service; 
it's

now more featureful, and has a better name: min-cloud-agent.

https://bugzilla.redhat.com/show_bug.cgi?id=1096479

Is the new package review request, per policy since it's renamed.  A 
reviewer would be appreciated!  Should be easy as it's really just a 
rename, there's no license changes or anything.




___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora @ Google Cloud

[Colin Walters]

On Wed, Jun 18, 2014, at 01:49 PM, Dennis Gilmore wrote:
>
> The issue is we are trying to build one image to run in all clouds, so
> cloud provider specific tools are out. 

I faced a similar problem with the images I am generating with ostree,
and what I ended up doing was producing a base image, and then
"postprocessing" it via libguestfs to enable/disable services.

So if we did decide to ship the GCE agent software, it would be possible
to produce one cloud image with both cloud-init and GCE agent, with
*both disabled by default* (note requires changing cloud-init package to
stop auto-enabling itself)

Then the script boils down to:

$ cp fedora-cloud.qcow2 fedora-cloud-standard.qcow2
$ guestmount /path/to/fedora-cloud-standard.qcow2 /mnt
$ systemctl --root=/mnt/ enable cloud-init.service
$ fusermount -u /mnt

$ cp fedora-cloud.qcow2 fedora-cloud-google.qcow2
$ guestmount /path/to/fedora-cloud-google.qcow2 /mnt
$ systemctl --root=/mnt/ enable google-daemon.service
$ fusermount -u /mnt

Each takes literally just a second or two to execute and can be easily
scripted on a rel-eng server (though I guess you'd want to wrap mock
around it).

FWIW the code I wrote is here:
https://github.com/projectatomic/rpm-ostree-toolbox/blob/master/src/js/builtins/postprocess_disk.js
I had to make custom code for rpm-ostree based images, but the concept
would work for mainline as well.
(An important but tricky part of this is ensuring the labels are correct
on newly generated files; see
https://www.redhat.com/archives/libguestfs/2014-May/msg00094.html .  I
also handle that specially with ostree).

> extend the functionality of
> cloud-init if you feel its useful. Ideally its something that can work
> in all providers.

All of the above said, I agree and would prefer investing in cloud-init,
even at the cost of the image deviating a bit from the "GCE standard". 
Any other opinions?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora @ Google Cloud

[Colin Walters]

On Sun, Jun 22, 2014, at 11:27 AM, Dennis Gilmore wrote:
> 
> 1) the image is intended to be just ran without tweaks

For reference I meant that Fedora rel-eng performs this operation,
ending up with two distinct cloud images but without significant pain in
generating them.

Anyways though I think we're agreed that it'd be better if it used
cloud-init, so let's see how far we can get down that path.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora @ Google Cloud

[Colin Walters]

On Fri, Jun 13, 2014, at 08:47 PM, Renich Bon Ciric wrote:

> I'm, currently, working on a Fedora image for Google Cloud; just for fun.

A semi-related followup here: For the Atomic Cloud Image our original
thought was to try min-cloud-agent, but I haven't had much time to
invest in it recently, and stuff like GCE coming along means that we
should probably focus on one agent.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Taking a break or whatever - action needed, I guess

[Colin Walters]

On Wed, Jul 2, 2014, at 07:58 AM, Matthew Miller wrote:
>
> * http://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image

I jumped in and added my name to this page, and cleaned it up a bit. 
What do people think?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Minutes from today's Cloud SIG meeting (2014-07-10)

[Colin Walters]

Hi,

I have a regular meeting time conflict with this one, sorry I wasn't
able to make it.  I'll try to ensure I at least am on IRC for the
meeting.

On Thu, Jul 10, 2014, at 08:07 AM, Matthew Miller wrote:
> 
> * Atomic Cloud Image  (mattdm, 14:41:59)
>   * this one needs a new owner  (mattdm, 14:42:08)
>   * HELP: Atomic Cloud Image needs a new co-owner/coordinator  (mattdm,
> 14:45:28)
>   * ACTION: mattdm to ask about atomic change owner on list  (mattdm,
> 14:45:42)

I posted earlier, but it may have been missed; I'd like to join in on
this one too.  It looks like Joe is now an owner as well.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[PATCH] Don't enable by default

[Colin Walters]

[ Posting here for increased visibility ]

Right now, cloud-init is only installed in the cloud images, so it's OK
if it enables itself by default.

However, for future Atomic work, we'll likely only have one tree
that's also running on bare metal, and that will include cloud-init.

This change should be safe because the Fedora Cloud kickstart in
spin-kickstarts uses services --enabled=cloud-init.
---
 cloud-init.spec | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

From 71d73e3ae96fd66f401db44e74a6aacecc030ecc Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Mon, 14 Jul 2014 16:55:33 -0400
Subject: [PATCH] Don't enable by default

Right now, cloud-init is only installed in the cloud images, so it's OK
if it enables itself by default.

However, for future Atomic work, we'll likely only have one tree
that's also running on bare metal, and that will include cloud-init.

This change should be safe because the Fedora Cloud kickstart in
spin-kickstarts uses services --enabled=cloud-init.
---
 cloud-init.spec | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/cloud-init.spec b/cloud-init.spec
index 206aec6..71d22f4 100644
--- a/cloud-init.spec
+++ b/cloud-init.spec
@@ -7,7 +7,7 @@
 
 Name:   cloud-init
 Version:0.7.5
-Release:6%{?dist}
+Release:7.atomic%{?dist}
 Summary:Cloud instance init scripts
 
 Group:  System Environment/Base
@@ -112,26 +112,8 @@ cp -p systemd/*  $RPM_BUILD_ROOT/%{_unitdir}
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-
-%post
-if [ $1 -eq 1 ] ; then
-# Initial installation
-# Enabled by default per "runs once then goes away" exception
-/bin/systemctl enable cloud-config.service >/dev/null 2>&1 || :
-/bin/systemctl enable cloud-final.service  >/dev/null 2>&1 || :
-/bin/systemctl enable cloud-init.service   >/dev/null 2>&1 || :
-/bin/systemctl enable cloud-init-local.service >/dev/null 2>&1 || :
-fi
-
 %preun
-if [ $1 -eq 0 ] ; then
-# Package removal, not upgrade
-/bin/systemctl --no-reload disable cloud-config.service >/dev/null 2>&1 || :
-/bin/systemctl --no-reload disable cloud-final.service  >/dev/null 2>&1 || :
-/bin/systemctl --no-reload disable cloud-init.service   >/dev/null 2>&1 || :
-/bin/systemctl --no-reload disable cloud-init-local.service >/dev/null 2>&1 || :
-# One-shot services -> no need to stop
-fi
+%systemd_preun cloud-config.service cloud-final.service cloud-init.service cloud-init-local.service
 
 %postun
 /bin/systemctl daemon-reload >/dev/null 2>&1 || :
-- 
1.8.3.1

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [PATCH] Don't enable by default

[Colin Walters]

On Tue, Jul 15, 2014, at 02:52 AM, Garrett Holmstrom wrote:

> This would be a great thing to add to the bug report for this issue [1] 
> as well.

Done, patch attached.

> If the kickstart explicitly enables cloud-init then yes, let's drop the 
> self-enabling bits.  We should really be using per-product service 
> presets for that instead; I suppose I should work on a policy for that 
> [2] now that it is finally clear which packages those belong in.  8^)

I think we're OK with the kickstart file enabling the services.  I
tested
an upgrade from F20 works, which it would as you'd expect, because
nothing is going to touch the existing links in
/etc/.../multi-user.wants.d.

I didn't test a fresh ImageFactory compose as my main laptop is
RHEL7 and it isn't yet packaged for that.  (Though I am investigating
running these types of tools out of mock or Docker containers, it's
just ugly as ImageFactory requires virt)

> Please remove .atomic from the release tag.  The spec file will also 
> need to use %systemd_post and %systemd_postun in addition to 
> %systemd_preun if we're to follow the packaging guidelines [3].

Fixed both, thanks.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Cockpit in Cloud images?

[Colin Walters]

Hi,

I was originally including Cockpit in

https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image

but rel-eng raised the concern that

https://fedoraproject.org/wiki/Changes/CockpitManagementConsole

is only listed for Server.  Should we include it in Cloud too?  Right
now it's promoted as part of the Project Atomic, so I think it'd make
sense to include there.

Perhaps a relevant difference here is that Cloud is more often treated
as cattle instead of pets - disposable stateless systems managed as a
group, and thus there's less need to configure things node by node. 
Even then though, Cockpit offers visualization on a per-node level.

Thoughts?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Cockpit in Cloud images?

[Colin Walters]

On Tue, Jul 22, 2014, at 03:57 PM, Matthew Miller wrote:

> +1 -- let's aim to implement the Atomic patterns unless there's a
> compelling
> reason not to (and, if that happens, see if we can work with the upstream
> project to straighten out whatever problem).

A specific reason to include Cockpit by default in Atomic is also that
there's no way to add it post-install.

Per this discussion then:
https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?h=f21&id=727d794d7db2ba4538a8721dbb020320536a0872

(This still leaves open the topic of Cockpit in the mainline Cloud)
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New Fedora 22 Change Proposal: Fedora Atomic

[Colin Walters]

Hi,

Trying to get ahead of the Change process this time =)

I'd like to move Atomic under the Server WG as I feel it's a more
appropriate home for Fedora 22, with the increased scope to bare metal
installation.  (Really it crosses both as Atomic should run in all the
clouds that mainline does, but I see Cloud as a specialization of Server
personally)

I started a Change page here:

https://fedoraproject.org/wiki/Changes/Atomic_Server

Comments (and improvements to the Change proposal) are appreciated.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Minutes for Cloud 2014-08-01

[Colin Walters]

===
#fedora-meeting Meeting
===


Meeting started by walters at 16:07:39 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-08-01/fedora-meeting.2014-08-01-16.07.log.html
.



Meeting summary
---
* LINK: https://fedorahosted.org/cloud/report/9 (meeting items for
  anyone who wants to check)  (number80, 17:07:11)
* LINK: http://fedoraproject.org/wiki/Zodbot#Meeting_Functions
  (number80, 17:09:40)
* ACTION: agrimm to do something about
  https://fedorahosted.org/cloud/ticket/43 and
  https://fedorahosted.org/cloud/ticket/51  (mattdm, 17:33:19)
* HELP: still need help with QA and test plan  (mattdm, 17:43:20)
* ACTION: number80 to contact roshi about next qa steps  (mattdm,
  17:44:43)

Meeting ended at 17:58:02 UTC.




Action Items

* agrimm to do something about https://fedorahosted.org/cloud/ticket/43
  and https://fedorahosted.org/cloud/ticket/51
* number80 to contact roshi about next qa steps




Action Items, by person
---
* agrimm
  * agrimm to do something about
https://fedorahosted.org/cloud/ticket/43 and
https://fedorahosted.org/cloud/ticket/51
* number80
  * number80 to contact roshi about next qa steps
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* walters (70)
* mattdm (62)
* number80 (27)
* agrimm (22)
* imcleod (9)
* zodbot (2)
* geppetto (2)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Terminology for docker/atomic images

[Colin Walters]

On Sun, Sep 7, 2014, at 11:22 PM, Dusty Mabe wrote:
> 
> In a nutshell, it would be great if we added "Container" to references we
> make to the container image (in conversation and docs).

I tend to say "Docker Base Image" - that's the terminology upstream
Docker uses: https://docs.docker.com/articles/baseimages/
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updated Atomic alpha w/Bash update(s)?

[Colin Walters]

On Thu, Sep 25, 2014, at 12:25 PM, Joe Brockmeier wrote:
> Hi all,
> 
> It occurs to me that the bash update isn't going to be available for the
> Atomic image(s) since the users can't install new packages.

Right - and this is different from the Docker image base, where users
can use yum "manually".

> What do we need to do to get new images spun up and get a new tree for
> people to grab with rpm-ostree update?

There are a few streams of images; there is a rawhide compose that comes
from a custom box outside of Fedora official rel-eng, and then there's
the F21 composes which are done manually by rel-eng.

> My understanding is this is manual now, how much lifting do we have yet
> to do to make this automatic?

The rawhide trees/images was automated, then stopped being automated
when we started working on a new script, now I'll be looking at
automating it again.

I'm doing a new compose now, and it does have bash-4.3.24-2.fc22. 
(Which, AIUI, may not actually fix everything per
https://lists.fedoraproject.org/pipermail/test/2014-September/122976.html
...but we'll keep the trees flowing)

This content will land in:
http://dl.fedoraproject.org/pub/alt/fedora-atomic/repo/  under the
"fedora-atomic/rawhide/x86_64/docker-host" ref.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updated Atomic alpha w/Bash update(s)?

[Colin Walters]

On Thu, Sep 25, 2014, at 06:43 PM, David Gay wrote:
> > I'm doing a new compose now, and it does have bash-4.3.24-2.fc22.
> > (Which, AIUI, may not actually fix everything per
> > https://lists.fedoraproject.org/pipermail/test/2014-September/122976.html
> > ...but we'll keep the trees flowing)
> 
> Hey -- any chance you can send me the Koji IDs for the createImage tasks
> when they're done? Then I can register new AMIs.

There's two steps.  First the tree is composed, that's:

https://git.fedorahosted.org/cgit/releng/tree/scripts/run-pungi#n40

Then imaagefactory runs using that as input:

https://git.fedorahosted.org/cgit/releng/tree/scripts/build-cloud-images#n37

At the moment, my understanding is the scripts are only run manually for
Alpha/Beta/RC type situations.  AIUI someone in infrastructure would
have to kick off the compose tree, and then anyone with createImage
privileges could use it as input?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updated Atomic alpha w/Bash update(s)?

[Colin Walters]

On Thu, Sep 25, 2014, at 04:36 PM, Colin Walters wrote:
> 
> This content will land in:
> http://dl.fedoraproject.org/pub/alt/fedora-atomic/repo/  under the
> "fedora-atomic/rawhide/x86_64/docker-host" ref.

This is done now, and I'm starting a f21 compose now too.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic Updates - do we follow traditional model or a new one?

[Colin Walters]

On Wed, Oct 8, 2014, at 12:26 AM, James Antill wrote:
>
>  At least one view of the model is that you have atomic upgrades, and
> thus. rollback/downgrades. This fits perfectly with the f21/f21/f23
> release model (although "rpm-ostree rebase" is very surprising when it
> deletes your refs, you can still atomic downgrade).

If it *didn't* do that, the storage space from the old tree would
continue
to be taken up over time unless you took explicit action.

We could add an option to keep it though?  I'll admit that some of
these choices in the command line tooling are a bit arbitrary - the
underlying library and model is extremely flexible though.

>  Certainly one of the benefits of ostree, to me, is that it should be
> possible to freely move between N stable releases.

Right.

At the moment, we're actually in a model where updates are
initiated manually.  A feature of doing automatic updates would
be a good place to also implement this behavior of automatically
tracking the latest.

(If we *do* have multiple branches, then an interesting question
 arises as to how the client learns about new releases)
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ostree compose script developments

[Colin Walters]

On Thu, Oct 16, 2014, at 11:29 PM, David Gay wrote:
> Hi --
> 
> At this point, I thought I'd send out an email with my current
> understanding of the processes we need to add to the releng scripts for
> ostree, as well as some questions regarding these compose scripts,
> specifically:

Awesome, thanks for sending this out!
>
> It seems to me that we should add in the bulk of the ostree processes
> after the compose process completes, but before the rsync. In
> buildbranched, this is at line 180. In buildrawhide, this is at line 172.
> This would be where we'd init an ostree repo somewhere like
> /srv/ostree/repo, use our treefile to run the compose (which captures
> RPMs to build the tree), and then generate a summary of the repo with
> `ostree summary -u`. 

Right.  An interesting question around this though is how much history
to retain.  I'd hope for at least two commits.  That way users are less
likely to see objects vanish underneath them they try to upgrade while a
rsync runs for a mirror.

> For our purposes, the summary file resulting from
> this process would serve a comparable purpose as the repomd.xml file we
> use for our "standard" builds.

Yep, that's the intention.

> 1. n00b question: I'm not sure how what needs to go *in* an image is
> decided. In order to run the ostree compose, we need to generate a
> treefile that contains -- among other things -- a list of RPMs that need
> to be installed. What's the best way to get content for that list?

This is in https://git.fedorahosted.org/cgit/fedora-atomic.git

> 2. The treefile also needs a branch name for the content. Any input on
> the naming scheme?

At the moment the branch name is specified in the treefile, although it
doesn't have to be.  If rel-eng has input on what they want for the
branch
names I'd be happy to discuss.  The current one is just a convention.

> 3. The treefile can also take a number of optional values. I'm not sure
> if any are needed for this process, but they are listed here:
> https://github.com/projectatomic/rpm-ostree/blob/master/doc/treefile.md
> Perhaps `gpg_key`, `boot_location`, and/or `units`?

I'd like to maintain the content definition upstream - signing for
Fedora
at the moment is going to have to be on the summary file.  Let's get
to that later - the HTTPS protection on the metalink is going to be good
enough.

Thanks again for looking at this!
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ostree/atomic composes + MM update

[Colin Walters]

Thanks again for hacking on this!

On Thu, Oct 23, 2014, at 06:38 PM, Luke Macken wrote:
>
> This could be done by looking at the filesystem timestamp, or Colin said
> he would probably add a timestamp field to the summary file that we
> could pull from.

Let's go with filesystem timestamp for now, but I filed a bug for the
latter.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: help wanted -- test/karma docker-storage-setup

[Colin Walters]

On Thu, Oct 30, 2014, at 09:12 PM, Dusty Mabe wrote:
> 
> So.. not the easiest thing to test because I couldn't find any atomic
> images with this package installed. 

It is possible to compose trees on your own too, using local packages. A  quick 
HOWTO:

yum install rpm-ostree
cd /srv
git clone https://fedorahosted.org/fedora-atomic/
mkdir /srv/repo
ostree --repo=/srv/repo init --mode=archive-z2
mkdir local-repo
cp /path/to/docker-storage-setup.rpm local-repo
(cd local-repo && createrepo .)
# edit fedora-atomic/fedora-atomic-base.json to add a yum repo pointing to 
/srv/local-repo
rpm-ostree compose tree --repo=/srv/repo 
fedora-atomic/fedora-atomic-docker-host.json

Then set up a static webserver pointing at /srv/repo.  In the client system:

ostree remote add local --set=gpg-verify=false http://192.168.122.1/repo
atomic rebase local:

> rpm2cpio docker-storage-setup-0.0.3-1.fc21.noarch.rpm | cpio -idv
> cp usr/bin/docker-storage-setup /usr/local/bin/docker-storage-setup

That works too though.  Thanks for testing!
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: help wanted -- test/karma docker-storage-setup

[Colin Walters]

On Thu, Oct 30, 2014, at 09:34 AM, Matthew Miller wrote:
> As Joe noted the other day, Fedora Atomic is intended to come with this
> service, which will create storage space for Docker images. As
> mentioned in the IRC meeting, at this point, the plan is to get this to
> stable after the beta (before the feature freeze, as soon as possible),
> to update the Atomic tree definition, and then to request a test
> candidate including it.
> 
> But the first step is getting it to stable. So, testers wanted --
> 
> https://admin.fedoraproject.org/updates/docker-storage-setup-0.0.3-1.fc21

Still need one more karma.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

final mirrorlist location for Atomic

[Colin Walters]

Currently, the Atomic cloud image still tries to contact the compose server 
internal mirror for updates.  

Do we know what the final mirrorlist URL will be?  Where are we on getting 
content sync'd out?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: final mirrorlist location for Atomic

[Colin Walters]

On Tue, Nov 4, 2014, at 10:17 AM, Matthew Miller wrote:

> Assuming that this is correct, what needs to change? Is this a
> kickstart line? We should make the appropriate change _today_.

That's not a globally replicated location, it means we're not taking advantage 
of mirrorlists.  Particularly for cloud, I think we really want content 
replicated in each provider's AZ to avoid transit costs.  Not sure if Fedora 
does this now.

Also:

1) That data comes from the atomic01.qa box that was provisioned as a testbed 
for Atomic work, with the idea that official composes would be done in rel-eng
2) It's only composing rawhide right now

And also note that until I get a chance to push some changes to 
spin-kickstarts, we're not going to have optimized LVM, which is 36% of the 
point of Atomic.

The most realistic option to me seems to be to deliver Atomic 21 asynchronously 
from Fedora 21 final.  Ideally within a few weeks?  Welcome to other ideas 
though.





___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: final mirrorlist location for Atomic

[Colin Walters]

On Mon, Nov 3, 2014, at 11:24 AM, Luke Macken wrote:

> I'm not sure exactly where the final bits will live, or what the URL
> will be, but the fedmsg-atomic-composer is up and running on the
> composer.stg box and successfully spitting out rawhide & f21 trees.

Nice.  Maybe we can deprecate atomic01.qa.fp.org in favor of this?
You could change it to take over the rawhide sync to dl.fedoraproject.org at 
least?

> Pushing this out to a production releng box will be simple once we
> determine where the trees will live on /pub.

Who owns that decision/how do we move forward?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: help wanted -- test/karma docker-storage-setup

[Colin Walters]

I backported some changes from fedora-atomic master to f21:
https://git.fedorahosted.org/cgit/fedora-atomic.git/log/?h=f21

Here are 4 patches for spin-kickstarts master for fedora-cloud-atomic.ks.  I 
tried to actually test them against rawhide but hit 
https://bugzilla.redhat.com/show_bug.cgi?id=290

So I backported them to f21 and then I hit a different (presumably anaconda, 
but maybe dracut) bug where it loops forever at shutdown (haven't searched 
for/filed a bug yet).

However if I terminated the VM in imagefactory, the resulting qcow2 works.

To save you all the pain of testing this until we get patches landed, please 
try:
https://alt.fedoraproject.org/pub/alt/fedora-atomic/testing/f21/20141104.0/fedora-atomic-cloud-direct-lvm-walters-20141104.qcow2.gz
From c314ed756cc3579d305867a7da13127fa6ceeb98 Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Tue, 4 Nov 2014 08:30:28 -0500
Subject: [PATCH 1/4] cloud-atomic: Use LVM by default in combination with
 docker-storage-setup

This will allow flexible expansion of direct Docker LVM.
---
 fedora-cloud-atomic.ks | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index 2f94492..5b75865 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -24,7 +24,10 @@ services --enabled=network,sshd,rsyslog,cloud-init,cloud-init-local,cloud-config
 zerombr
 clearpart --all
 # Atomic differs from cloud - we want LVM
-autopart
+part /boot --size=300 --fstype="xfs"
+part pv.01 --grow
+volgroup atomicos pv.01
+logvol / --size=3000 --fstype="xfs" --name=root --vgname=atomicos
 
 # Equivalent of %include fedora-repo.ks
 ostreesetup --nogpg --osname=fedora-atomic-host --remote=installmedia --url=http://kojipkgs.fedoraproject.org/mash/atomic/ --ref=fedora-atomic/rawhide/x86_64/docker-host
-- 
1.8.3.1

From 4fbf117c9819bb618c9a3e0d01a24f53b1ad3241 Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Tue, 4 Nov 2014 08:30:58 -0500
Subject: [PATCH 2/4] cloud-atomic: Point to dl.fedoraproject.org

Since this is the repository that's actually getting updates.
---
 fedora-cloud-atomic.ks | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index 5b75865..5ec2dcf 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -30,7 +30,7 @@ volgroup atomicos pv.01
 logvol / --size=3000 --fstype="xfs" --name=root --vgname=atomicos
 
 # Equivalent of %include fedora-repo.ks
-ostreesetup --nogpg --osname=fedora-atomic-host --remote=installmedia --url=http://kojipkgs.fedoraproject.org/mash/atomic/ --ref=fedora-atomic/rawhide/x86_64/docker-host
+ostreesetup --nogpg --osname=fedora-atomic-host --remote=installmedia --url=http://dl.fedoraproject.org/pub/alt/fedora-atomic/repo --ref=fedora-atomic/rawhide/x86_64/docker-host
 
 reboot
 
-- 
1.8.3.1

From d6b0df5916914921a67b74dcaf0433f8089fb9ec Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Tue, 4 Nov 2014 09:07:27 -0500
Subject: [PATCH 3/4] cloud-atomic: We use GRUB2 now instead of extlinux

In order to have one bootloader per architecture for rpmostreepayload.
---
 fedora-cloud-atomic.ks | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index 5ec2dcf..b077712 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -16,7 +16,7 @@ user --name=none
 
 firewall --disabled
 
-bootloader --timeout=1 --append="no_timer_check console=tty1 console=ttyS0,115200n8" --extlinux
+bootloader --timeout=1 --append="no_timer_check console=tty1 console=ttyS0,115200n8"
 
 network --bootproto=dhcp --device=eth0 --activate --onboot=on
 services --enabled=network,sshd,rsyslog,cloud-init,cloud-init-local,cloud-config,cloud-final
@@ -42,10 +42,6 @@ passwd -l root
 # remove the user anaconda forces us to make
 userdel -r none
 
-# Kickstart specifies timeout in seconds; syslinux uses 10ths.
-# 0 means wait forever, so instead we'll go with 1.
-sed -i 's/^timeout 10/timeout 1/' /boot/extlinux/extlinux.conf
-
 # If you want to remove rsyslog and just use journald, remove this!
 echo -n "Disabling persistent journal"
 rmdir /var/log/journal/ 
@@ -125,15 +121,6 @@ echo "---"
 # Note that running rpm recreates the rpm db files which aren't needed/wanted
 rm -f /var/lib/rpm/__db*
 
-
-# This is a temporary workaround for
-# <https://bugzilla.redhat.com/show_bug.cgi?id=1147998>
-# where sfdisk seems to be messing up the mbr.
-# Long-term fix is to address this in anaconda directly and remove this.
-# <https://bugzilla.redhat.com/show_bug.cgi?id=1015931>
-dd if=/usr/share/syslinux/mbr.bin of=/dev/vda
-
-
 echo "Zeroing out empty space with fstrim."
 /usr/sbin/fstrim /
 
-- 
1.8.3.1

From cdf0383c05c35d714b6439e2f7a6fa19d856901f Mon Sep 

Re: help wanted -- test/karma docker-storage-setup

[Colin Walters]

On Tue, Nov 4, 2014, at 09:20 PM, Matthew Miller wrote:

> Applied to master -- I had to update the one about extlinux because an
> unrelated change you hadn't pulled. Can you rebase for f21? They don't
> apply cleanly -- I think just for minor things but I'll need more focus
> than I have right now to do it right. (Will look again tomorrow.)

These are the two patches that should go on f21, backported from master.  And 
only the first is really needed.
From 6986a630452bb4ed75dbbdb40c0629d238c1e64b Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Tue, 4 Nov 2014 08:30:28 -0500
Subject: [PATCH 1/2] cloud-atomic: Use LVM by default in combination with
 docker-storage-setup

This will allow flexible expansion of direct Docker LVM.
---
 fedora-cloud-atomic.ks | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index 6e10fc0..f881e4d 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -24,7 +24,10 @@ services --enabled=network,sshd,rsyslog,cloud-init,cloud-init-local,cloud-config
 zerombr
 clearpart --all
 # Atomic differs from cloud - we want LVM
-autopart
+part /boot --size=300 --fstype="xfs"
+part pv.01 --grow
+volgroup atomicos pv.01
+logvol / --size=3000 --fstype="xfs" --name=root --vgname=atomicos
 
 ostreesetup --nogpg --osname=fedora-atomic-host --remote=installmedia --url=http://compose-x86-02.phx2.fedoraproject.org/compose/atomic/ --ref=fedora-atomic/f21/x86_64/docker-host
 
-- 
1.8.3.1

From a4eb88794fbcac93c685c282bb54ce3e8080f603 Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Tue, 4 Nov 2014 09:09:45 -0500
Subject: [PATCH 2/2] cloud-atomic: Drop yum/rpm bits from %post

While it makes sense to import the GPG key, it has to be done
as part of the treecompose, because it'll drop out of the rpmdb
on the next upgrade.

For yum, it was run as part of the treecompose, not Anaconda, so
there's already no history.
---
 fedora-cloud-atomic.ks | 10 --
 1 file changed, 10 deletions(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index f881e4d..ea28fcf 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -152,16 +152,6 @@ echo "RUN_FIRSTBOOT=NO" > /etc/sysconfig/firstboot
 echo "Removing random-seed so it's not the same in every image."
 rm -f /var/lib/random-seed
 
-echo "Cleaning old yum repodata."
-yum history new
-yum clean all
-truncate -c -s 0 /var/log/yum.log
-
-echo "Import RPM GPG key"
-releasever=$(rpm -q --qf '%{version}\n' fedora-release)
-basearch=$(uname -i)
-rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
-
 echo "Packages within this cloud image:"
 echo "---"
 rpm -qa
-- 
1.8.3.1

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: help wanted -- test/karma docker-storage-setup

[Colin Walters]

On Wed, Nov 5, 2014, at 11:45 AM, Matthew Miller wrote:
> On Wed, Nov 05, 2014 at 10:37:02AM -0500, Colin Walters wrote:
> > These are the two patches that should go on f21, backported from master.  
> > And only the first is really needed.
> 
> Applied. Don't we also need "Point to dl.fedoraproject.org"?

I'd like to get a final confirmation that's what we should do for release 
before we hardcode the URL.  Client systems can at least change that after the 
fact, whereas partitioning is baked in.



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: help wanted -- test/karma docker-storage-setup

[Colin Walters]

On Wed, Nov 5, 2014, at 04:11 PM, Matthew Miller wrote:
> On Wed, Nov 05, 2014 at 12:22:33PM -0500, Matthew Miller wrote:
> > > In the meantime, I'd argue that changing it for the test candidates is
> > > a step forward from the internal URL.
> > Although obviously we need it to be more than rawhide.
> 
> And also -- we _want_ it to hit the internal URL in koji but be
> configured to access the outside URL after, right? So, that should be
> changed in %post, I guess?

Right.  This is a complex topic, because when I wrote the original Anaconda 
rpmostreepayload patches, I had been thinking of a boot.iso scenario, whereas 
it's awkward for the ImageFactory-on-server.

The short answer is to change it in %post.

The long term answer is for Anaconda's rpmostreepayload to be aware of the 
distinction between "distribution side" composes and downstream composes.  (And 
for that matter, for Anaconda itself to understand this.  We shouldn't have to 
rm /var/lib/systemd/random-seed in %post)
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Debugging the failed Atomic compose

[Colin Walters]

Koji task: http://koji.fedoraproject.org/koji/taskinfo?taskID=7978937

OZ log: 
https://kojipkgs.fedoraproject.org//work/tasks/8937/7978937/oz-x86_64.log

It looks to me like we hung in the rpm -qa listing.  Hard to guess why without 
being able to get in there with a debugger or something =/  Any ideas?

We can try submitting kickstart files with debugging bits.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Two more (mostly cosmetic) Atomic patches

[Colin Walters]

I don't think either of these are the cause of the hang, but I believe they're 
both correct.  Tested with a local ImageFactory run.
From 41f019b6d58f59863e282727e695ef196deac87e Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Thu, 6 Nov 2014 20:34:38 -0500
Subject: [PATCH 1/2] atomic: Drop package deinstallation

This isn't supported; at the moment the tree has authconfig and
linux-firmware, but not firewalld.
---
 fedora-cloud-atomic.ks | 14 --
 1 file changed, 14 deletions(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index 1c4d959..5b3a62b 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -81,20 +81,6 @@ echo -n "Disabling persistent journal"
 rmdir /var/log/journal/ 
 echo . 
 
-# this is installed by default but we don't need it in virt
-echo "Removing linux-firmware package."
-yum -C -y remove linux-firmware
-
-# Remove firewalld; was supposed to be optional in F18+, but is required to
-# be present for install/image building.
-echo "Removing firewalld."
-yum -C -y remove firewalld --setopt="clean_requirements_on_remove=1"
-
-# Another one needed at install time but not after that, and it pulls
-# in some unneeded deps (like, newt and slang)
-echo "Removing authconfig."
-yum -C -y remove authconfig --setopt="clean_requirements_on_remove=1"
-
 echo -n "Getty fixes"
 # although we want console output going to the serial console, we don't
 # actually have the opportunity to login there. FIX.
-- 
1.8.3.1

From dd923232d35f65ba43f24487127f7133e9d138b0 Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Thu, 6 Nov 2014 20:36:09 -0500
Subject: [PATCH 2/2] atomic: We do not support pv-grub

Atomic is HVM only, since OSTree doesn't understand grub1 at the
moment, and incentive to have it do so is low.
---
 fedora-cloud-atomic.ks | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index 5b3a62b..7b683c2 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -37,29 +37,6 @@ reboot
 
 %post --erroronfail
 
-# Create grub.conf for EC2. This used to be done by appliance creator but
-# anaconda doesn't do it. And, in case appliance-creator is used, we're
-# overriding it here so that both cases get the exact same file.
-# Note that the console line is different -- that's because EC2 provides
-# different virtual hardware, and this is a convenient way to act differently
-echo -n "Creating grub.conf for pvgrub"
-rootuuid=$( awk '$2=="/" { print $1 };'  /etc/fstab )
-mkdir /boot/grub
-echo -e 'default=0\ntimeout=0\n\n' > /boot/grub/grub.conf
-for kv in $( ls -1v /boot/vmlinuz* |grep -v rescue |sed s/.*vmlinuz-//  ); do
-  echo "title Fedora ($kv)" >> /boot/grub/grub.conf
-  echo -e "\troot (hd0,0)" >> /boot/grub/grub.conf
-  echo -e "\tkernel /boot/vmlinuz-$kv ro root=$rootuuid no_timer_check console=hvc0 LANG=en_US.UTF-8" >> /boot/grub/grub.conf
-  echo -e "\tinitrd /boot/initramfs-$kv.img" >> /boot/grub/grub.conf
-  echo
-done
-
-
-#link grub.conf to menu.lst for ec2 to work
-echo -n "Linking menu.lst to old-style grub.conf for pv-grub"
-ln -sf grub.conf /boot/grub/menu.lst
-ln -sf /boot/grub/grub.conf /etc/grub.conf
-
 # older versions of livecd-tools do not follow "rootpw --lock" line above
 # https://bugzilla.redhat.com/show_bug.cgi?id=964299
 passwd -l root
-- 
1.8.3.1

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: cloud init update needs testing

[Colin Walters]

On Fri, Nov 7, 2014, at 09:53 PM, Matthew Miller wrote:
> Hi all! https://admin.fedoraproject.org/updates/cloud-init-0.7.5-8.fc21 
> needs testing — let's get this into F21 (and, more to the point, into
> test candidates, so we can make sure it's thoroughly tested).

Hooray.  So for Atomic, this gets us:

[root@icarus fedora-atomic.f21]# rpm-ostree rpm diff  --repo=repo 
fedora-atomic/f21/x86_64/docker-host{^,}
ostree diff commit old: fedora-atomic/f21/x86_64/docker-host^ 
(ce8a771db37c9ef6ec980f780d2aacf972bd4c37aae3663c762989d9c630dbab)
ostree diff commit new: fedora-atomic/f21/x86_64/docker-host 
(08894c763108d2858bd9c75f557f8baf97e7367ec2f5ab4ab28e5af0bf94ec3c)
Upgraded:
 cloud-init-0.7.5-8.fc21.x86_64
* Fri Nov 07 2014 Garrett Holmstrom  - 0.7.5-8
- Dropped python-boto dependency [RH:1161257]
- Dropped rsyslog dependency [RH:986511]

Removed:
 json-c-0.12-5.fc21.x86_64
 libestr-0.1.9-4.fc21.x86_64
 liblogging-stdlog-1.0.4-4.fc21.x86_64
 logrotate-3.8.7-4.fc21.x86_64
 python-boto-2.32.1-1.fc21.noarch
 python3-3.4.1-15.fc21.x86_64
 python3-libs-3.4.1-15.fc21.x86_64
 python3-pip-1.5.6-2.fc21.noarch
 python3-setuptools-2.0-8.fc21.noarch
 rsyslog-7.4.10-5.fc21.x86_64

I also created a fresh qcow2 from it, booted it locally, and logged in fine 
with my userdata.  Ship it!
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: final mirrorlist location for Atomic

[Colin Walters]

On Fri, Nov 7, 2014, at 08:03 AM, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 02 Nov 2014 16:33:57 -0500
> Colin Walters  wrote:
> 
> > Currently, the Atomic cloud image still tries to contact the compose
> > server internal mirror for updates.  
> > 
> > Do we know what the final mirrorlist URL will be?  Where are we on
> > getting content sync'd out?
> 
> the metalink should be
> 
> https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x86_64

Thanks, Dennis.  The attached patch should implement this, once we:

1) Get https://admin.fedoraproject.org/updates/ostree-2014.11-1.fc21 through
2) Recompose the tree with it
3) Get a metalink generated pointing at that tree
4) Do some end-to-end testing of this
From e2317e1449749759d0a8895bca46f28b1739fa42 Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Fri, 7 Nov 2014 13:49:57 -0500
Subject: [PATCH] atomic: Rewrite origin to point to metalink

Basically Anaconda-in-ImageFactory is set up to pull from the
builder, so that's what ends up in the origin file.  But that's
obviously not what we want to ship to users.

ostree/rpm-ostree do not yet have a convenient command to change this,
so brute force it with sed.

Implements https://lists.fedoraproject.org/pipermail/cloud/2014-November/004570.html
---
 fedora-cloud-atomic.ks | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index be862c4..8861d1e 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -36,6 +36,9 @@ reboot
 
 
 %post --erroronfail
+# See https://github.com/projectatomic/rpm-ostree/issues/42
+ostree remote add --set=gpg-verify=false fedora-atomic 'metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-atomic-21&arch=x86_64'
+(origin_file=$(echo -n /ostree/deploy/fedora-atomic-host/deploy/*.origin); sed -e 's,installmedia:,fedora-atomic:,' < ${origin_file} > ${origin_file}.new && mv ${origin_file}{.new,})
 
 # older versions of livecd-tools do not follow "rootpw --lock" line above
 # https://bugzilla.redhat.com/show_bug.cgi?id=964299
-- 
1.8.3.1

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[PATCH] cloud-atomic: Re-shrink rootfs partitions

[Colin Walters]

mattdm changed these previously because we hit an ENOSPC error during
qcow2 image creation, but that *really* happened because the Fedora
rel-eng create-cloud-images script hardcoded 3GB.

Now that we've shrunk the content down to ~850MB, drop the defaults:

- rootfs down to 2GB.  This is enough space for a replacement of
  all content, plus a bit of spare room for logging
- /boot to 200MB.  At present, kernel+initramfs is just 30MB,
  so this is still very conservative.
---
 fedora-cloud-atomic.ks | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

From 8cae1be2139094c173cd0af86e515f363204b9af Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Sat, 8 Nov 2014 13:27:05 -0500
Subject: [PATCH] cloud-atomic: Re-shrink rootfs partitions

mattdm changed these previously because we hit an ENOSPC error during
qcow2 image creation, but that *really* happened because the Fedora
rel-eng create-cloud-images script hardcoded 3GB.

Now that we've shrunk the content down to ~850MB, drop the defaults:

- rootfs down to 2GB.  This is enough space for a replacement of
  all content, plus a bit of spare room for logging
- /boot to 200MB.  At present, kernel+initramfs is just 30MB,
  so this is still very conservative.
---
 fedora-cloud-atomic.ks | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fedora-cloud-atomic.ks b/fedora-cloud-atomic.ks
index 3906b03..9290de4 100644
--- a/fedora-cloud-atomic.ks
+++ b/fedora-cloud-atomic.ks
@@ -24,10 +24,10 @@ services --enabled=network,sshd,rsyslog,cloud-init,cloud-init-local,cloud-config
 zerombr
 clearpart --all
 # Atomic differs from cloud - we want LVM
-part /boot --size=500 --fstype="ext4"
+part /boot --size=200 --fstype="ext4"
 part pv.01 --grow
 volgroup atomicos pv.01
-logvol / --size=5000 --fstype="xfs" --name=root --vgname=atomicos
+logvol / --size=2000 --fstype="xfs" --name=root --vgname=atomicos
 
 ostreesetup --nogpg --osname=fedora-atomic-host --remote=installmedia --url=http://compose-x86-02.phx2.fedoraproject.org/compose/atomic/ --ref=fedora-atomic/f21/x86_64/docker-host
 
-- 
1.8.3.1

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Change for AtomicHost

[Colin Walters]

Initial cut: https://fedoraproject.org/wiki/Changes/AtomicHost

Notably, adding bare metal (already working) and vagrant boxes (have prototype 
code), and I'd like to do a diskless Live PXE image (code exists, need to put 
it together and polish).

This is kept in the Cloud group, but I think the division between Cloud/Server 
here is going to become rather arbitrary and weird.  Oh well.

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [atomic-devel] Fedora Change for AtomicHost

[Colin Walters]

Hi,

On Mon, Nov 10, 2014, at 08:31 AM, Josh Boyer wrote:

> Er... that's a strange interpretation of how to not call something a
> system wide change.  Even if you had someone doing the rel-eng work,
> it's still a system wide change.  Particularly since it's going across
> several groups and components.

Thanks for the feedback.  I have updated the change now to be system wide.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[PATCH] build-cloud-images: Use --version of ksflatten, and do show stderr

[Colin Walters]

Untested, but I think this will fix the Atomic compose. 
CC'ing fedora-cloud as my patch also touches the invocations
for mainline cloud as well as the docker base image.

We need to specify --version to ensure the build host is
allowed to use kickstart syntax from the target version.

Remove the >& /dev/null as we'd like to be able to debug if it's
failing.
---
 scripts/build-cloud-images | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

From 70667ab32be48c03479cc0651e01c935eee284d1 Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Tue, 11 Nov 2014 15:39:20 -0500
Subject: [PATCH] build-cloud-images: Use --version of ksflatten, and do show
 stderr

We need to specify --version to ensure the build host is
allowed to use kickstart syntax from the target version.

Remove the >& /dev/null as we'd like to be able to debug if it's
failing.
---
 scripts/build-cloud-images | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/build-cloud-images b/scripts/build-cloud-images
index bffbf27..7b39640 100755
--- a/scripts/build-cloud-images
+++ b/scripts/build-cloud-images
@@ -35,7 +35,7 @@ do
 declare -l lspin
 lspin=$spin
 kickstart=fedora-cloud-$lspin-$GITHASH.ks
-ksflatten -c fedora-cloud-$lspin.ks -o $kickstart >& /dev/null
+ksflatten --version F${RELEASE} -c fedora-cloud-$lspin.ks -o $kickstart
 echo "url --url=$url"|sed -e 's|$arch|$basearch|g' >> $kickstart
  #koji image-build fedora-cloud-$spin $VERSION --distro Fedora-20 $TARGET --ksurl=git://git.fedorahosted.org/git/spin-kickstarts.git?#$GITHASH --kickstart=fedora-cloud-$lspin.ks $url x86_64 i386 --format=qcow2 --format=raw --release=$VERSION --scratch --repo=$url --nowait --disk-size=3
 koji image-build Fedora-Cloud-$spin $BUILD --distro Fedora-20 $TARGET  --kickstart=fedora-cloud-$lspin-$GITHASH.ks $url x86_64 i386 --format=qcow2 --format=raw-xz --release=$RELEASE --scratch --repo=$url --nowait --disk-size=3
@@ -46,7 +46,7 @@ do
 declare -l lspin
 lspin=$spin
 kickstart=fedora-cloud-$lspin-$GITHASH.ks
-ksflatten -c fedora-cloud-$lspin.ks -o $kickstart >& /dev/null
+ksflatten --version F${RELEASE} -c fedora-cloud-$lspin.ks -o $kickstart
 echo "url --url=$url"|sed -e 's|$arch|$basearch|g' >> $kickstart
 sed -i -e "s|--url=http://compose-x86-02.phx2.fedoraproject.org/compose/atomic/|--url=$atomicurl|g" $kickstart
 
@@ -59,7 +59,7 @@ do
 declare -l lspin
 lspin=$spin
 kickstart=fedora-docker-$lspin-$GITHASH.ks
-ksflatten -c fedora-docker-$lspin.ks -o $kickstart >& /dev/null
+ksflatten --version F${RELEASE} -c fedora-docker-$lspin.ks -o $kickstart
 echo "url --url=$url"|sed -e 's|$arch|$basearch|g' >> $kickstart
  #koji image-build fedora-cloud-$spin $VERSION --distro Fedora-20 $TARGET --ksurl=git://git.fedorahosted.org/git/spin-kickstarts.git?#$GITHASH --kickstart=fedora-cloud-$lspin.ks $url x86_64 i386 --format=qcow2 --format=raw --release=$VERSION --scratch --repo=$url --nowait --disk-size=3
 koji image-build Fedora-Docker-$spin $BUILD --distro Fedora-20 $TARGET  --kickstart=fedora-docker-$lspin-$GITHASH.ks $url x86_64  --format=docker --release=$RELEASE --scratch --repo=$url --nowait --disk-size=3
-- 
1.8.3.1

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

cloud-init 0.7.6 now in rawhide

[Colin Walters]

cloud-init 0.7.6 now in rawhide.

This reduces the depchain even more.  Worked here in some local testing,
but this is a heads up in case anyone sees fallout:

https://bugzilla.redhat.com/show_bug.cgi?id=974327
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Please karma https://admin.fedoraproject.org/updates/rpm-ostree-2014.111-1.fc21

[Colin Walters]

https://admin.fedoraproject.org/updates/rpm-ostree-2014.111-1.fc21

Will allow Atomic to be smaller, and also fixes the "wheel" bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1164058

Please karma.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Please karma https://admin.fedoraproject.org/updates/rpm-ostree-2014.111-1.fc21

[Colin Walters]

On Mon, Nov 17, 2014, at 08:18 PM, Matthew Miller wrote:

> Colin, what's the easiest way to test this? (Or ostree updates in
> general?)

See https://lists.fedoraproject.org/pipermail/cloud/2014-October/004497.html

> It'd be pretty awesome to have a test plan:
> 
> 

Dusty posted:

https://gist.github.com/dustymabe/bf955b6afa8177ecf6fc

I guess that could maybe be turned into a plan?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Please karma https://admin.fedoraproject.org/updates/rpm-ostree-2014.111-1.fc21

[Colin Walters]

On Wed, Nov 19, 2014, at 12:06 AM, Dusty Mabe wrote:
> 
> So I tested this tonight by doing a compose with the new rpm-ostree
> and then rebasing an existing system [1]. I'll give it some karma but
> I will note that I don't really know how to test that the wheel group
> properly got created (by rebasing instead of doing a full build in koji).

Here's the command I use to make a scratch cloud image locally (via 
ImageFactory):

# rpm-ostree-toolbox imagefactory -i kvm --name fedora-atomic-host --tdl 
~walters/src/fedora-atomic/fedora-atomic-21.tdl -k 
~walters/src/spin-kickstarts/fedora-cloud-atomic.ks -o scratch

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AMIs for Test Day?

[Colin Walters]

On Wed, Nov 19, 2014, at 10:55 AM, Matthew Miller wrote:
> On Wed, Nov 19, 2014 at 01:59:45PM +0100, Joe Brockmeier wrote:
> > IIRC somebody sent the list of AMIs but I have not been able to dig it
> > up -- do we have a list of AMIs for current Atomic builds to use for
> > tomorrow's Test Day?
> 
> us-east-1   |   ami-a8c95dc0

I tested this one, it boots.  However, I screwed up with:
https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?h=f21&id=70c9fbf49d85d183405b7e39753a79e1797dc0ac
Fixed by:
https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?h=f21&id=5d545a55223e024db28d393e678862d3753a2c6d

Basically that AMI is OK, but the next one will be broken unless it picks up 
the latest commit there.


Basically I think any AMI produced last night will be broken, and when you 
upgrade you'll see:

My upgrade looked like:

-bash-4.3# atomic upgrade
Updating from: fedora-atomic:fedora-atomic/f21/x86_64/docker-host

404 metadata, 2155 content objects fetched; 27427 KiB transferred in 91 seconds
Copying /etc changes: 26 modified, 4 removed, 36 added
Transaction complete; bootconfig swap: yes deployment count change: 1)
Changed:
  PackageKit-glib-1.0.3-2.fc21.x86_64
  bash-completion-1:2.1-6.20141110git52d8316.fc21.noarch
  bind-libs-lite-32:9.9.6-4.fc21.x86_64
  bind-license-32:9.9.6-4.fc21.noarch
  ca-certificates-2014.2.1-1.5.fc21.noarch
  chkconfig-1.3.63-1.fc21.x86_64
  device-mapper-persistent-data-0.4.1-2.fc21.x86_64
  dosfstools-3.0.27-1.fc21.x86_64
  e2fsprogs-1.42.11-4.fc21.x86_64
  e2fsprogs-libs-1.42.11-4.fc21.x86_64
  glib2-2.42.1-1.fc21.x86_64
  gnutls-3.3.10-1.fc21.x86_64
  grep-2.20-6.fc21.x86_64
  initscripts-9.56.1-4.fc21.x86_64
  kernel-3.17.3-300.fc21.x86_64
  kernel-core-3.17.3-300.fc21.x86_64
  kernel-modules-3.17.3-300.fc21.x86_64
  kpartx-0.4.9-68.fc21.1.x86_64
  libcom_err-1.42.11-4.fc21.x86_64
  libreport-filesystem-2.3.0-4.fc21.x86_64
  libss-1.42.11-4.fc21.x86_64
  libteam-1.14-1.fc21.x86_64
  man-db-2.6.7.1-12.fc21.x86_64
  openssh-6.6.1p1-8.fc21.x86_64
  openssh-clients-6.6.1p1-8.fc21.x86_64
  openssh-server-6.6.1p1-8.fc21.x86_64
  ostree-2014.11-1.fc21.x86_64
  pcre-8.35-7.fc21.x86_64
  python-2.7.8-7.fc21.x86_64
  python-libs-2.7.8-7.fc21.x86_64
  sqlite-3.8.7-1.fc21.x86_64
  teamd-1.14-1.fc21.x86_64
Removed:
  mtools-4.0.18-7.fc21.x86_64
  syslinux-6.03-1.fc21.x86_64
  syslinux-extlinux-6.03-1.fc21.x86_64
  syslinux-extlinux-nonlinux-6.03-1.fc21.noarch
  syslinux-nonlinux-6.03-1.fc21.noarch
Added:
  efibootmgr-0.11.0-1.fc21.x86_64
  efivar-libs-0.13-1.fc21.x86_64
  fedora-logos-21.0.4-1.fc21.x86_64
  file-5.19-7.fc21.x86_64
  file-libs-5.19-7.fc21.x86_64
  freetype-2.5.3-11.fc21.x86_64
  gettext-0.19.2-6.fc21.x86_64
  gettext-libs-0.19.2-6.fc21.x86_64
  grub2-1:2.02-0.11.fc21.x86_64
  grub2-efi-1:2.02-0.11.fc21.x86_64
  grub2-tools-1:2.02-0.11.fc21.x86_64
  gssproxy-0.3.1-4.fc21.x86_64
  keyutils-1.5.9-4.fc21.x86_64
  libaio-0.3.110-4.fc21.x86_64
  libbasicobjects-0.1.1-24.fc21.x86_64
  libcollection-0.6.2-24.fc21.x86_64
  libcroco-0.6.8-5.fc21.x86_64
  libgomp-4.9.2-1.fc21.x86_64
  libini_config-1.1.0-24.fc21.x86_64
  libnfsidmap-0.26-2.1.fc21.x86_64
  libpath_utils-0.2.1-24.fc21.x86_64
  libpng-2:1.6.10-3.fc21.x86_64
  libref_array-0.1.4-24.fc21.x86_64
  libtalloc-2.1.1-3.fc21.x86_64
  libtevent-0.9.21-3.fc21.x86_64
  libtirpc-0.2.5-1.0.fc21.x86_64
  libunistring-0.9.3-11.fc21.x86_64
  libverto-tevent-0.2.6-4.fc21.x86_64
  libxml2-python-2.9.1-6.fc21.x86_64
  mokutil-1:0.2.0-1.fc21.x86_64
  nfs-utils-1:1.3.1-2.0.fc21.x86_64
  os-prober-1.58-11.fc21.x86_64
  ostree-grub2-2014.11-1.fc21.x86_64
  pciutils-libs-3.3.0-1.fc21.x86_64
  quota-1:4.01-14.fc21.x86_64
  quota-nls-1:4.01-14.fc21.noarch
  rpcbind-0.2.1-4.0.fc21.x86_64
  rpm-build-libs-4.12.0.1-3.fc21.x86_64
  rpm-python-4.12.0.1-3.fc21.x86_64
  shim-0.8-4.x86_64
  sos-3.2-0.1.a.fc21.noarch
  tcp_wrappers-7.6-79.fc21.x86_64
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AMIs for Test Day?

[Colin Walters]

On Wed, Nov 19, 2014, at 04:16 PM, Matthew Miller wrote:
> On Wed, Nov 19, 2014 at 03:16:19PM -0500, Colin Walters wrote:
> > I tested this one, it boots.  However, I screwed up with:
> > https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?h=f21&id=70c9fbf49d85d183405b7e39753a79e1797dc0ac
> > Fixed by:
> > https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?h=f21&id=5d545a55223e024db28d393e678862d3753a2c6d
> > Basically that AMI is OK, but the next one will be broken unless it picks 
> > up the latest commit there.
> 
> Currently, what causes a compose to pick up a given commit?

In Fedora there are two codebases going on:

Fedora releng:
https://git.fedorahosted.org/cgit/releng/tree/scripts/run-pungi#n34
As you can see, this one just does a git clone, it's run "nightly".

A fedmsg driven one:
https://github.com/fedora-infra/fedmsg-atomic-composer
Deployed by: 
https://github.com/fedora-infra/fedmsg-atomic-composer/blob/master/ansible/playbook.yml

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

cloud image network config, virtio-net, libvirt autodetection, and network vs NetworkManager, F20 vs F21

[Colin Walters]

TL;DR:

KB, I think the CentOS cloud images should use:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=98c48cb2b2051cc8ca81e95a697e4c8d7c5bd939

Dennis, we should revert:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5ae38874c7c69057abd41850ad3ca27cd967fa18

Longer story:

I tried the CentOS 7 GenericCloud image:
http://cloud.centos.org/centos/7/devel/
and it didn't have networking on boot.  Let's look at the actors:

- A base cloud image: Fedora 20, Fedora 21, CentOS 7
- Network configuration: As specified in the kickstart
- A network driver: virtio-net, rtl8139
- virt-install guest autodetection:  Determines whether or not you get 
virtio-net
- network system (or NetworkManager, or systemd-networkd)
- systemd: 
http://lists.freedesktop.org/archives/systemd-devel/2014-July/020906.html
- Anaconda/kickstart behavior

First, let's look at the current F20:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks?h=f20#n26

It hardcodes eth0. And the version of systemd there uses eth0 for virtio-net.

Now, let's look at some changes Dennis committed in the F21 cycle:

ens3:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=e1778df1fe1a035b21085023996c58ecbf3be378

link:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=98c48cb2b2051cc8ca81e95a697e4c8d7c5bd939

eth0 (but only for atomic):
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5ae38874c7c69057abd41850ad3ca27cd967fa18

(Dennis and others, can you send patches to the list for review?   This issue 
would have been more obvious if I'd noticed the changes going by)

A really critical variable here is whether or not libvirt guest autodetection 
works.  Currently:

libvirt automatically provides virtio-net: Fedora 20, Fedora 21 Generic
libvirt gives you rtl8193: Fedora 21 Atomic, CentOS 7

It took me a while to figure out here that the reason the CentOS 7 image wasn't 
working was becuase of the libvirt autodetection.

I have this utterly trivial "create-cloud-vm.sh" script I've been using:

https://gist.github.com/cgwalters/a366c14b2fc58e0f7367

It does work if I specify --os-variant rhel7 for CentOS7.  Which I'm now going 
to start doing by default in my script (I don't use it to boot anything else).

But...the change to do DHCP on all links by default is also an important 
change.  One we should highlight in the release notes.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Adding open-vm-tools package to Fedora Atomic

[Colin Walters]

Hi Ravindra,

At the moment, we do not have a formal process for this. The problem is
further compounded by the fact that there is only one tree. Meaning that
open-vm-tools would end up even on other deployment targets such as bare
metal, AWS/GCE, etc.

At a high level, we are trying to coalesce around cloud-init as much as
possible as the core agent. It looks to me like a lot of open-vm-tools
is desktop focused. The main bits here would be folder sharing, memory
ballooning?

Have you looked at running open-vm-tools as a (likely privileged)
container?

On Fri, Nov 21, 2014, at 01:51 PM, Ravindra Kumar wrote:
> Hi all,


>


> I'm the maintainer for open-vm-tools package in Fedora.


>


> For the benefit of Fedora Atomic users on VMware platform, I would
> like to add open-vm-tools package to Fedora Atomic.


>


> Could somebody please advise/help me with the process involved to get
> open-vm-tools package in Fedora Atomic?


>


> Thanks in advance,


> Ravindra


> _
> cloud mailing list cloud@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of
> Conduct: http://fedoraproject.org/code-of-conduct

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Adding open-vm-tools package to Fedora Atomic

[Colin Walters]

On Mon, Nov 24, 2014, at 11:09 AM, Peter Robinson wrote:

> It needs some fairly low level "HW" access, not sure how that would
> work containerised.

If you "docker run --privileged", the container has total access to the host, 
it's no different from any other process running as root.  Try it:

# docker run -ti --privileged -v /:/sysroot centos ls /dev
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Need help in testing the RC2 cloud images

[Colin Walters]

On Tue, Dec 2, 2014, at 03:50 PM, Kushal Das wrote:
> Hi everyone,
> 
> We have the RC2 cloud images ready [1]. You can help us by testing the
> images following [2].

It looks to me like the Atomic tree content is lagging significantly:

# atomic status
  TIMESTAMP (UTC) ID OSNAMEREFSPEC  
  
* 2014-12-01 10:18:48 1ae9d436cb fedora-atomic 
fedora-atomic:fedora-atomic/f21/x86_64/docker-host  
# rpm -q docker-io
docker-io-1.2.0-5.fc21.x86_64
# 

Yet:
https://admin.fedoraproject.org/updates/FEDORA-2014-13528/docker-io-1.3.0-1.fc21?_csrf_token=befd6ca28d6872662d1aa86fe03d06ae478fa7dd
went stable on 2014-11-01 as far as I can tell.

The repo at http://dl.fedoraproject.org/pub/fedora/linux/atomic/21/ has a 
slightly older no-op commit, so I assume this is an issue on the compose server 
side.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Need help in testing the RC2 cloud images

[Colin Walters]

On Tue, Dec 2, 2014, at 06:54 PM, Dennis Gilmore wrote:
> I suspect you're testing the wrong thing. The log file at
> http://koji.fedoraproject.org/koji/taskinfo?taskID=8277497 indicates
> the correct version was installed.
>

Yes, I was thrown for a loop after downloading because the date is
incorrect in the image: 20141102 when I presume 20141202 is right.

However *locally* I also had a "nightly" image with the correct date,
but Adam Williamson tells me the nightly images don't have freeze
exception packages.

I booted the "1102" image and it did have the right docker-io. So I
guess the bottom line is things are OK, but we should really ensure the
date is correct on the next run.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora cloud qcow2 images

[Colin Walters]

On Tue, Dec 9, 2014, at 01:05 PM, Joe Brockmeier wrote:

> It's been documented-ish but we do need to be louder about it. It would
> also be awesome if virt-manager handled cloud-init too, the "use an ISO
> to provide cloud-init info" is a little clunky.

If anyone's curious, I was trying to argue that Fedora Server should *also* be 
able to use cloud-init in:

https://www.redhat.com/archives/anaconda-devel-list/2014-December/msg8.html

If we supported that, we could more generally document cloud-init to set up 
Fedora servers (and I guess Workstation), regardless of whether they're 
intended to run in the "cloud" or not.  Dunno if anything will happen for F22, 
but we'll see...
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Atomic update available

[Colin Walters]

I should have cross posted, but here's the link:

https://lists.projectatomic.io/projectatomic-archives/atomic/2014-December/msg1.html

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Local DNSSEC resolver and Docker(containers)

[Colin Walters]

On Thu, Jan 15, 2015, at 08:57 AM, P J P wrote:

> I'm no expert on Docker(or container) applications. I was wondering if someone
> could help in testing Docker(or container) applications with the local DNSSEC
> validating resolver on F21.

See https://github.com/docker/docker/pull/9239

My thoughts on this are that the kdbus + nss module as prototyped by 
systemd-resolved is a good approach, but requires updating both containers and 
hosts with kdbus.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qcow2 version woes

[Colin Walters]

On Thu, Mar 5, 2015, at 01:48 PM, Mike Ruckman wrote:

> [0] qemu-img amend -f qcow2 -o compat=0.10 

See 
https://github.com/redhat-imaging/imagefactory/commit/7434c9e7506d5896508c23983b55544b0b244164

A version of ImageFactory with this commit just needs to be deployed.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Colin Walters]

On Mon, Mar 9, 2015, at 12:14 PM, Adam Miller wrote:

> For those not familiar with the current release process of Atomic, can
> you provide a link to documentation on how that is done as well as
> what tooling is involved?

Keep in mind that the original vision for Atomic was *not* to be a distribution 
itself - merely technology that flows-into/is-consumed-by the 3 distribution 
family.  So when we're talking about "release process for Atomic", that 
question is necessarily distribution specific, although the ideal is that they 
share code.

With that in mind then, for Fedora 21, Atomic is offered solely as a cloud 
image.  That cloud image though is generated via the "ostreesetup" kickstart 
verb:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-atomic.ks#n33

This replaces a traditional %packages section; anaconda here is *replicating*, 
not assembling.  The tree is built on a separate server using rpm-ostree:
https://git.fedorahosted.org/cgit/releng/tree/scripts/run-pungi#n39

Now for Fedora 22, we're trying to expand the scope:
https://fedoraproject.org/wiki/Changes/AtomicHost

Concurrently, CentOS has two yum repositories: virt7 and atomic7, that contain 
docker/kubernetes and the ostree/atomic stack, respectively.   These are layers 
on top of the CentOS7.0 base, distinct from the Fedora "one big repo on one 
release cycle" model.

These RPMs are built using the CentOS CBS Koji: http://cbs.centos.org/koji/
Then for Atomic, the RPMs are composed into a tree by a script.

We're still working on an Anaconda based CentOS, as backporting the ostreesetup 
changes has proved very painful.  That problem should sort itself out over time 
however.

Right now, I am looking at:
https://fedorahosted.org/rel-eng/ticket/6119
to further the Fedora integration.

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Colin Walters]

On Mon, Mar 9, 2015, at 11:34 AM, Michael P. McGrath wrote:
> 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.

There's also other components; while etcd and flannel could be thought of as 
"kubernetes enablers"
and fall under the same umbrella, they are distinct projects with their own 
release cycle.

Also, it's worth keeping in mind that it would be nice if we made more use of 
newer systemd
features, which is a big project with its own cycle.

Finally, I'll also note that rpm-ostree does link to the packaging stack 
(libhif -> hawkey/librepo)
which necessarily implies some ties to the cycle of those components.

> 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.  

Not just build failure, but runtime failure.

> 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).

I'm not actually doing the ostree side very often right now, but that will 
hopefully
change as more user-visible features land.

Anyways, the bottom line for me on this is:

Before we can do two weeks, we need to be able to do rawhide.  There are parts
of this that work (tree and cloud images are carryover from F22), but the 
installer
and PXE-to-Live are blocked on:
https://fedorahosted.org/rel-eng/ticket/6119

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Colin Walters]

On Mon, Mar 9, 2015, at 02:49 PM, Michael P. McGrath wrote:
>
> This one's new to me, I'm aware of the issues with building images but I
> was under the impression that the composed OStree was still happening 
> successfully
> whenever rawhide was building.  Are you saying there are sometimes where 
> upgrading
> to those trees would have resulted in an unbootable system?

Ah, I meant RPMs.  Generally if the RPMs work, the tree will as well.
It's possible there are tree-specific issues but so far that's been generally 
rare.
I just meant more the generic runtime issues that always happen.  A random
example from a few days ago in rawhide is an NSS build breaking curl or so,
and thus breaking everything that uses libcurl, which is obviously a lot.

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Colin Walters]

On Wed, Mar 11, 2015, at 10:52 AM, Dennis Gilmore wrote:
>
> This is not entirely true, it is just part of the picture. You can install on 
> bare metal using anaconda with extlinux, exactly the same as we do to make 
> the 
> cloud image. But it is not advertised or really well documented.

But that won't get you the partitioning defaults if used interactively, which
is an important part of Atomic.  This is
https://github.com/projectatomic/fedora-productimg-atomic

That and having the content embedded so that it can install offline.

These are the current two reasons that Atomic needs a separate
installer ISO build.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Colin Walters]

On Fri, Mar 13, 2015, at 05:13 PM, Michael P. McGrath wrote:
> 
> So the Atomic spins would be $current + the updates-testing packages we
> care about (and have tested / have some influence over).  That spin
> would then be copied to the mirrors and we'd be able to link to it.
> 
> There's a nice side benefit there which is if someone who's running non-atomic
> Fedora wants to look at the latest of docker, kubernetes, etcd, ostree,
> whatever, they could just enable updates-testing and have access.
> 
> Sounds like all of the benefits of the original rawhide suggestion with
> none of the pain.

Yeah.  We can do much better than we are now at just running through the current
official process.  Also, rather crucially there are no trademark concerns with
images generated from updates-testing or just updates.

I'd still like to experiment with a side repo implementing continuous delivery
and actually making use of the fact that both Docker and ostree allow rollbacks
and are by their nature more agile - will post more about that later.  But 
option #1
here has my vote for now - it's a matter of trying it for a few months or so, we
can always re-evaluate.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testables for beta TC2

[Colin Walters]

On Mon, Mar 16, 2015, at 03:03 PM, M. Edward (Ed) Borasky wrote:
> Are there test scenarios somewhere? I can't figure out how to get a
> working image from the Docker tarball.

We don't have automation for upload to the Hub AFAIK, and no do we have a 
distribution-specific registry (though I think we should).

(A few minutes pass)

Ok, so things here are...suboptimal.  Here's a script you can use:

https://github.com/cgwalters/fedora-docker-image-import

We'll get Koji fixed to do something more useful by default.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testables for beta TC2

[Colin Walters]

Hi,

On Mon, Mar 16, 2015, at 06:33 PM, Robyn Bergeron wrote:
> 
> Is that doing something different / using something different than the
> image linked in
> https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_TC2_Cloud?rd=Test_Results:Current_Cloud_Test

Not a different image - the Koji one just generates a Docker image named 
"Fedora-Docker-Base-22-20150316.x86_64:latest", whereas the above script allows 
importing it as "fedora:22".

One can also "docker load" and "docker tag", then "docker rmi", which may be 
easier.

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Vagrant mounting /var/lib/docker?

[Colin Walters]

On Tue, Mar 17, 2015, at 11:29 AM, Joe Brockmeier wrote:
> Hey all,
> 
> Any Vagrant wizards around? I'd like to figure out how to mount a
> directory on my local host as /var/lib/docker for the Atomic Vagrant
> boxen - so users don't have to worry about other ways of expanding the
> storage to putter around with Atomic and running containers

It doesn't really work to sync content into /var/lib/docker behind the
daemon's back.

Running a local caching registry is one option (say on a "master" box,
and configuring nodes to pull from it it).  That saves you download
time, but not storage.

It would also be possible to use something like Ceph/Gluster to
store images between VMs (patches for Docker exist), but then you
lose the LVM copy-on-write.  Overlayfs would solve this
by allowing per-node writes to stay in the machine's storage pool,
while drawing read-only data from elsewhere.

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

note: uid/gid breakage in F21 Atomic

[Colin Walters]

The latest tree update changed the gid for sshkeys (among other things).  It 
needs a backport of some rpm-ostree fixes:

https://bugzilla.redhat.com/show_bug.cgi?id=1203006

Which are waiting on karma here:

https://admin.fedoraproject.org/updates/rpm-ostree-2015.3-1.fc21
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf in Dockerfiles

[Colin Walters]

On Wed, Mar 11, 2015, at 10:23 AM, Joe Brockmeier wrote:
> 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.

Personally, this feels like a lot of pain for little gain to me.  We could 
install
dnf-yum by default?  What do others think?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf in Dockerfiles

[Colin Walters]

On Thu, Mar 19, 2015, at 10:25 AM, Daniel J Walsh wrote: 


>
I think this would break on other machines that do not have libvirt 

installed on the host. 


Right, it's a problem orthogonal to the Atomic Host. 


> Scott we found an interesting problem with libvirt protections on
/dev/kvm.  If you run this container on an atomic machine, the 

device has the wrong protections.  


In general, Docker containers that want to access host devices may need to  
replicate some of the logic from the host udev. 


___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf in Dockerfiles

[Colin Walters]

On Thu, Mar 19, 2015, at 11:19 AM, Matthew Miller wrote:
> On Thu, Mar 19, 2015 at 11:10:33AM -0400, Colin Walters wrote:
> > > 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.
> > Personally, this feels like a lot of pain for little gain to me.  We could 
> > install
> > dnf-yum by default?  What do others think?
> 
> See discussion at https://fedorahosted.org/fesco/ticket/1312

Thanks, per that discussion:

https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=961b78fbd898194b67ff51757a6883dd802fa0fc

(In case anyone was curious, first I had to shave a few yaks in the previous 
commits)
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager and network services both enabled in Fedora Atomic

[Colin Walters]

On Thu, Mar 19, 2015, at 12:56 PM, Matt Micene wrote: 

> I'd be in favor of pulling NetworkManager.  It still seems that network is  
> the way for "server" class systems to handle networking

It's not that simple, at least for Atomic, because the *exact same* tree 

in Fedora 22 can also be deployed on bare metal, and NetworkManager 

handles far more networking types than the legacy network package. 


Further on bare metal, Anaconda presently only knows how to interact 

with NetworkManager. 


Clearly 3 networking subsystems is not long term sustainable; the good 

news is that NetworkManager and networkd are sharing some code, 

NetworkManager is getting smaller, etc.  No one is investing in the legacy 

network package though AFAIK. 


The "mainline" cloud image though is a different case - I'm sure networkd 

can be quite usable there, particularly if one doesn't care about the legacy 

initscripts config file formats. 


Given that, I'd propose for now: 


@@ -19,7 +21,8 @@ firewall --disabled 

 bootloader --timeout=1 --append="no_timer_check console=tty1  
console=ttyS0,115200n8" 


 network --bootproto=dhcp --device=link --activate --onboot=on 

-services --enabled=network,sshd,rsyslog,cloud-init,cloud-init-local,cloud- 
config,cloud-final 

+services --disabled=network 

+services --enabled=sshd,rsyslog,cloud-init,cloud-init-local,cloud- 
config,cloud-final 


 zerombr 

 clearpart --all 




___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager and network services both enabled in Fedora Atomic

[Colin Walters]

On Thu, Mar 19, 2015, at 01:09 PM, Matthew Miller wrote:
> On Thu, Mar 19, 2015 at 12:47:22PM -0400, Dusty Mabe wrote:
> > I would suggest that we adopt the approach that Fedora Cloud Base
> > takes by just having the Network service enabled. This would also mean
> > we can pull the NetworkManager packages out of atomic and make the
> > image smaller.
> 
> I'm in favor. For F23, we should look at NetworkManager (or
> _possibly_ systemd-networkd) again —
> https://bugzilla.redhat.com/show_bug.cgi?id=863515 should be in place,
> so nothing will need to persist, and NetworkManager should be using the
> new lighter-weight dhcp client from systemd-networkd, 

We can do this latter bit right now.  Just tested and it works:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f22&id=cde583e3a2e2f79e0e4719a05a773b5a74a6bf92
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Note: Atomic Host integration for F22 at risk

[Colin Walters]

This change:
https://fedoraproject.org/wiki/Changes/AtomicHost
is presently blocked on:
https://fedorahosted.org/rel-eng/ticket/6119

Currently Fedora 22 will have Atomic cloud images and vagrant boxes (and an 
updated tree).

It will be *possible* to install to bare metal using kickstart, but the 
Anaconda GUI doesn't support either ostree or docker currently - the change 
above addresses the ostree part.

There is currently no movement on the PXE-to-Live portion.

Any help appreciated.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [atomic-devel] Note: Atomic Host integration for F22 at risk

[Colin Walters]

(Forgot to CC cloud, if you reply please readd
 atomic-de...@projectatomic.io )

On Thu, Mar 26, 2015, at 01:17 PM, Colin Walters wrote:
> On Thu, Mar 26, 2015, at 10:57 AM, Peter Robinson wrote:
> 
> > Ultimately the request came in 3 weeks ago, that's post freeze.
> > Rel-eng has a lot to deliver in each release and limited resources,
> > Changes that need rel-eng engagement should have our buy in long
> > before they're sent to FESCo
> 
> There's circular dependencies there...not sure how much attention
> a ticket would have for something not approved by FESCo, but on
> the other hand it's clearly true that the original 
> https://fedoraproject.org/wiki/Changes/AtomicHost
> proposed in November could have made more clear that it needed
> a separate Anaconda build, and that would have helped make
> rel-eng aware.
> 
> But debating history doesn't solve anything now. 
> What you're saying sounds like a "No, we can't do this" - why not just say
> so in the ticket?
> 
> What I was more hoping for was "We have limited resources, but
> here's how you can help/what you can change (and why)...".  Like a
> patch review.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Colin Walters]

[ Resurrecting, adding atomic-devel CC ]

On Mon, Mar 9, 2015, at 11:34 AM, Michael P. McGrath wrote:
> 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.

Most people in this thread seemed to be in favor of Atomic Host as a spin.  Now,
I use the word "Host" specifically here because I think it's important to 
distinguish Atomic Host
from the "docker + kubernetes as RPMs" set.  We should be able
to get RPMs through Bodhi.

(See 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00013.html
 on that topic)

But we need to more fully flesh out the ramifications of a Host move out.  It 
would mean:

 - Dropping the (currently rather minimal) OSTree repo + cloud image from 
mainline rel-eng
 - Standing up more regular code drops in 
https://alt.fedoraproject.org/pub/alt/fedora-atomic/images/f22/

(But if we do do this I'd like to keep open communication channels such that 
some or
 all parts of Atomic Host could be more integrated with "mainline" in the 
future)

I mentioned this before, but a critical hinge point is whether the tree + 
images are
entirely composed of RPMs built in Fedora.  AIUI for example, if we had a COPR
(or whatever) with a more bleeding edge Docker[0], or carried a patched systemd
temporarily[1], I believe that would run afoul of:
https://fedoraproject.org/wiki/Legal:Trademark_guidelines?rd=Legal/TrademarkGuidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software

...at least, I assumed so offhand, but reading it, in that page
"Fedora software" isn't defined - does COPR count or not?

Anyways...my bottom line here is that it feels really weird to me to fight all
the way for F22 and sustain that only to split it out after.  It's a lot simpler
to say F21 was our first try, we learned some things, but a lot more work
needs to be done, it'll be faster to iterate outside and then merge back
when it's ready, which may be F23 or whatever.

[0] OSTree was born to do continuous delivery, and the fact that it's wedged
 after the slow, plodding, conservative mainline koji + "daily build" + 
bodhi
 IMO weakens its value a lot.  We could also be a lot more aggressive
 with updates to the RPMs that go into Docker containers - if some http 
library
 breaks it may just affect your app and not the host, etc.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [atomic-devel] Atomic 2 week releases

[Colin Walters]

On Wed, Apr 8, 2015, at 02:51 PM, Joe Brockmeier wrote:

> Copr doesn't count. Talked to Tom Callaway about this briefly just now
> and basically - it must be built in Koji to be part of a Spin, unless we
> get an exception.

A side tag as mattdm mentioned somewhere solves that, no need to
rename.

Though this also seems like something that could go back up to the
Council..."newer upstream versions of packages already in Fedora for
a project under the Fedora umbrella" seems like it'd be quite
a different thing compared to the other types of projects the
trademark guidelines are addressing.

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Starting the Talking Points for F22

[Colin Walters]

On Tue, Apr 14, 2015, at 09:41 AM, Matthew Miller wrote:
> On Thu, Apr 09, 2015 at 08:31:49AM -0400, Joe Brockmeier wrote:
> > Here's what I'd say, lemme know if this sounds sane:
> [...]
> > So we've decided that while the technologies are maturing so rapidly,
> > it's better have a fast-moving remix or spin that gives users the
> > opportunity to use a Fedora-based Atomic Host and gives our developers
> > the ability to move fast and break things if needed."
> 
> That works for me. Any volunteers for actually working on making
> http://atomic.fedoraproject.org/?

And to clarify, we're then backing out all of the Atomic bits in Fedora 22
mainline rel-eng such as the repository and cloud image, vagrant box,
and installer?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: atomic and getfedora

[Colin Walters]

On Wed, Apr 15, 2015, at 03:40 PM, Matthew Miller wrote:
> 
> I'd still kind of like to think about moving the F22 atomic image
> release to http://atomic.fedoraproject.org/, too (especially since it's
> still non-blocking). Then, https://getfedora.org/en/cloud/download/
> could become a little less maze-like.

I'm in favor; who can help make this happen?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Creating vagrant box from fedora-cloud-base-vagrant.ks

[Colin Walters]

Hi,

On Wed, Apr 22, 2015, at 02:12 AM, Amit Saha wrote:
> Hello,
> 
> How can I create vagrant box from the above mentioned kickstart file?
> 
> I tried rather blindly on F21 host: 
> 
> appliance-creator -c fedora-cloud-base-vagrant.ks 

See:

https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=e371dd6c3cbd2edcc122a8c855131ff9903b522d

(I didn't actually test all of it at the moment, but hopefully the above is 
useful
 as a starting point.  Let's collaborate on keeping up to date docs in the 
comments)
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Creating vagrant box from fedora-cloud-base-vagrant.ks

[Colin Walters]

On Mon, Apr 27, 2015, at 12:14 AM, Amit Saha wrote:
> 
> Image build FAILED with error: Timed out waiting for guest to boot

There are a number of causes for that unfortunately.  So...what i tend
to do is hand-mirror the installer media locally, and then edit the
TDL to point to it.  This is a lot more reliable if you're using ImageFactory
often.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft for post for Cloud test day.

[Colin Walters]

On Fri, May 1, 2015, at 10:13 AM, Dusty Mabe wrote:
> 
> Hey guys,
> 
> Here is a link to a draft post I have created for the cloud test day.
> Check it out and let me know if there is anything wrong. It's simple
> but fits I think. If it is ok I'll post to Fedora Magazine, etc..
> 
> https://gist.github.com/anonymous/2c4d292df01cc87a33be

Cool, looks good.  The linked Atomic image is ancient though.
Recent composes have been blocked on
https://bugzilla.redhat.com/show_bug.cgi?id=1217578
which *should* be fixed - but isn't as of today, possibly
because the new package didn't make it into the installer
images yet.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Test day bug: Atomic and nfs-utils

[Colin Walters]

Hi,

During the Test day (and before), several people noted this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1219871

It now has a patch.  I tested it with a local tree compose.  It's nominated now 
for Blocker/FE.

If you want to see the patch without Red Hat's bugzilla mangling it beyond 
recognition, use this link:
https://bugzilla.redhat.com/attachment.cgi?id=1023799
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Why the Atomic rawhide image build is currently failing

[Colin Walters]

In case anyone is wondering:

https://bugzilla.redhat.com/show_bug.cgi?id=1217578
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

f21 docker base image and hardcoded root password

[Colin Walters]

If anyone has information on https://fedorahosted.org/rel-eng/ticket/6170
then please comment (specifically lsm5, but anyone with info).

Also this message should serve as a heads up that at least some
versions of the Fedora base image had a hardcoded root password,
and due to a snafu, we didn't assign a CVE as it was expected to be
fixed before now, but then wasn't because there's no bugzilla entry
for the base image for Fedora 

I've fixed it in spin-kickstarts, but I want to be sure we have the correct
content on the Hub before socializing more widely.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Final RC2 AMIs

[Colin Walters]

On Thu, May 21, 2015, at 11:36 AM, David Gay wrote:
> Good morning, everyone.
> 
> You'll find the final RC2 AMIs in any region by doing a search for 
> "Fedora-Cloud-Base-22-20150520" or "Fedora-Cloud-Atomic-22-20150520". Let me 
> know if there are any issues.

I did some basic non-cluster smoke testing of the Atomic AMI in us-east-1e, 
worked for me.  I see we have Docker 1.6 in too which is nice.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Test day bug: Atomic and nfs-utils

[Colin Walters]

On Sat, May 9, 2015, at 12:22 PM, Colin Walters wrote:
> Hi,
> 
> During the Test day (and before), several people noted this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1219871
> 
> It now has a patch.  I tested it with a local tree compose.  It's nominated 
> now for Blocker/FE.

So I was initially blocked from doing a build of this by:
https://bugzilla.redhat.com/show_bug.cgi?id=1220938

I only realized later that I didn't have to wait for man-db to go
stable, I could have tagged it in as an override, which would
have made this less of a chain of blockers, but oh well.

The thing is - this can't be easily fixed in an update because
you really want things like NFS to work when you first boot.

Options I see:
 - Pull it in now (needs rel-eng approval)
 - If we're talking about doing Atomic images every 2 weeks,
then why not just wait one stable cycle and pull in the fix, and do
all of the AMIs/mirroring/etc then?  I'm not sure how hard this would
be, but we could just say "Atomic images are coming in 2 weeks"
 - Live with it...would be embarrassing but not completely the end of the world



___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Test day bug: Atomic and nfs-utils

[Colin Walters]

On Thu, May 21, 2015, at 02:36 PM, Colin Walters wrote:
> 
> 
> On Sat, May 9, 2015, at 12:22 PM, Colin Walters wrote:
> > Hi,
> > 
> > During the Test day (and before), several people noted this bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1219871
> > 
> > It now has a patch.  I tested it with a local tree compose.  It's nominated 
> > now for Blocker/FE.
> 
> So I was initially blocked from doing a build of this by:
> https://bugzilla.redhat.com/show_bug.cgi?id=1220938
> 
> I only realized later that I didn't have to wait for man-db to go
> stable, I could have tagged it in as an override, which would
> have made this less of a chain of blockers, but oh well.
> 
> The thing is - this can't be easily fixed in an update because
> you really want things like NFS to work when you first boot.
> 
> Options I see:
>  - Pull it in now (needs rel-eng approval)
>  - If we're talking about doing Atomic images every 2 weeks,
> then why not just wait one stable cycle and pull in the fix, and do
> all of the AMIs/mirroring/etc then?  I'm not sure how hard this would
> be, but we could just say "Atomic images are coming in 2 weeks"
>  - Live with it...would be embarrassing but not completely the end of the 
> world

Another option:
- Create an atomic-rc-updates repo where it's pulled in but doesn't affect 
other products
This isn't very hard from the rpm-ostree side but would also need rel-eng work.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct