cloud October 2013

cloud@lists.stg.fedoraproject.org

33 participants
35 discussions

Short links to Fedora Cloud Images
by Matthew Miller 17 Dec '14

17 Dec '14

These links all work now: http://cloud.fedoraproject.org/fedora-19.x86_64.qcow2 http://cloud.fedoraproject.org/fedora-19.i386.qcow2 http://cloud.fedoraproject.org/fedora-latest.i386.qcow2 http://cloud.fedoraproject.org/fedora-latest.x86_64.qcow2 (They will redirect to a mirror link provided by mirrormanager.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

5 6

Vagrant in Fedora
by Alex Drahon 14 Jan '14

14 Jan '14

Hi all, I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;) It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation: 1. I have a vagrant RPM that installs and works as expected, there's some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it. So, as a summary: - yum install vagrant should work, at which point you need to install VirtualBox and it will run as expected - vagrant-kvm installs but I don't know how to add the right polkit rules (I need help) Looks pretty good, right? Alex

5 34

ZOMG WHAT ARE WE BUILDING?!
by Joe Brockmeier 07 Nov '13

07 Nov '13

Hi all, (For those who weren't in today's IRC meeting, I sorta apologize for the subject line. Sorta.) As we were discussing today - we need to decide what we are building, and (almost as importantly) what we're not building. We've agreed that we want to be cooperating with the server SIG, but don't necessarily plan to build a foundation for an IaaS ourselves. Some of the questions that were raised during the meeting: - Should we drop 32-bit? - Should we be targeting ARM? - Do we worry about supporting ALL THE METHODS of building the image, or no? (I recommend we focus on One True Way so as not to confuse everyone with 80 different ways they *could* do it.) Other questions, thoughts, comments, flames? I also want to recommend that we think hard about not just what we build, but accompanying it with appropriate amounts of documentation for the developers/users we expect to be consuming the image. I'm sure it goes without saying that we would document what we do, but I would like to see this thought about each step of the way so that when we get to a finished product, it's dead easy to adopt. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb(a)redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/

12 17

Cloud product kernel requirements
by Josh Boyer 06 Nov '13

06 Nov '13

Hi All, I realize the WG is just forming up and you have a lot of other items to cover for now, but I wanted to get this sent out and have people start thinking about it sooner rather than later. The kernel team has heard in the past that the Cloud group would like to see something of a more minimal kernel for usage in cloud images. We'd like to hear the requirements for what this smaller image would need to cover. Right now, a default x86_64 kernel package on f20 is ~134MB installed. Most of that is device drivers installed in /lib/modules/`uname -r`/. The vmlinux binary is about 5MB and the initramfs (which is created at install time and can actually vary quite widely depending on various things) is about 11MB. Drivers can be trimmed to a degree, but please keep in mind that the kernel is already relatively small for the functionality it provides. For example, it is not much bigger than glibc-common (119MB). So, some caveats to keep in mind while you're thinking about this: 1) We're mostly talking about packaging here, not building a separate cloud kernel package or vmlinux. The kernel team really wants to have a single vmlinux across the 3 products if at all possible. We can't scale to much else. 2) What usecases is the cloud image going to cover? E.g. is it just virtio stuff, or will it also fit PCI passthru (which then requires drivers for those PCI devices)? 3) What are the common provisioning requirements that are driving the size reduction? (See comment about glibc-common. I would think change is needed in multiple packages, not just the kernel.) 4) Other "cloudy" stuff that I'm entirely unaware of that might be relevant. Explain it to me like I'm a child. Thanks! josh

9 12

Re: [Fedora-legal-list] Hosting Fedora cloud images
by Richard W.M. Jones 01 Nov '13

01 Nov '13

[NB: CC'd to the Fedora cloud SIG mailing list] On Tue, Oct 01, 2013 at 09:22:44AM -0400, Matthew Miller wrote: > On Tue, Oct 01, 2013 at 02:20:11PM +0100, Richard W.M. Jones wrote: > > > Is there a reason to not use the official Fedora cloud images? > > That's part 2 of this exercise. Would like to talk to you > > about that separately at some point. > > Okay. Any time. :) So there are a few immediate problems (some of them in virt-builder itself). (1) Virt-builder really needs to be able to source images from multiple places. At the moment there is only one source location allowed, unless the user clumsily uses the --source option to point at another one. (2) Virt-builder currently assumes the image format is xz-compressed. Actually I notice the raw.xz images are in the correct format already, so we're good here. (3) Virt-builder requires all images to be GPG-signed. It worries me that these images are neither signed nor downloaded over https. (4) Virt-builder requires a (signed) index file describing each cloud image. I believe it would be a good thing for the cloud images to include an index file, so that tools can automatically find out what's there. The format of the index file is described here: http://libguestfs.org/virt-builder.1.html#creating-and-signing-the-index-fi… However having the index file will be less useful until (1) is fixed. (5) Digital signatures: Currently virt-builder requires all indexes and images to be signed by yours truly unless you go through an involved process described here: http://libguestfs.org/virt-builder.1.html#setting-up-a-gpg-key We need to fix this, but key management is a non-trivial problem, since we cannot host the public key in the same place as the index & images (an attacker could replace both the images & key at the same time). What's the strategy going to be for signing these cloud images? ---------------------------------------------------------------------- To test this out, I created an index file for the 64 bit Fedora 19 cloud image, which is attached. I also signed it (signature also attached). You can test this if you want by putting all 3 files into a directory anywhere and using commands such as: virt-builder --source file:///path/to/index.asc -l virt-builder --source file:///path/to/index.asc --notes fedora-cloud-19 virt-builder --source file:///path/to/index.asc \ fedora-cloud-19 \ --size 20G \ --root-password password:123456 \ --install @development-tools And basically it works: $ virt-builder --source file:///mnt/scratch/index.asc fedora-cloud-19 --size 20G --root-password password:123456 --install @development-tools[ 0.0] Downloading: file:///mnt/scratch/Fedora-x86_64-19-20130627-sda.raw.xz [ 0.0] Creating disk image: fedora-cloud-19.img [ 1.0] Uncompressing: file:///mnt/scratch/Fedora-x86_64-19-20130627-sda.raw.xz [ 14.0] Running virt-resize to expand the disk to 20.0G [ 44.0] Opening the new disk [ 47.0] Setting a random seed [ 47.0] Setting root password [ 47.0] Installing packages: @development-tools [ 156.0] Finishing off Output: fedora-cloud-19.img Total usable space: 19.7G Free space: 18.6G (94%) I didn't test this one to see if it boots. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

4 10

Redesign of Landing page [Roles]
by Frankie 31 Oct '13

31 Oct '13

Hi team, As agreed in the meeting yesterday I am having a look at our landing page which is at: https://fedoraproject.org/wiki/Cloud_WG I am however not too sure of the roles we have in the community. Instead of taking all the general roles specified at: https://fedoraproject.org/wiki/Join I would like to proceed with: - Cloud Architect - OS developer - System Admin - Web Designer - Documentation team Kindly let us brain storm on this so I can kick of with redesigning the page. Kind Regrds, Onuonga Frankie -- Skype: Frankie.Onuonga twitter: Frankie onuonga irc #freenode: Frankie.onuonga

3 5

First cut - Cloud PRD outline
by Robyn Bergeron 30 Oct '13

30 Oct '13

Hi folks, I took an initial cut at the framework/outline for a PRD, and started filling in... some bits of it, mostly in an "example" type format so people can get an idea of context, other parts in a more "this is a description of what should be here," etc. https://fedoraproject.org/wiki/Cloud_PRD This is about as "traditional" of a PRD as I have gotten it to at this point - given that typically, in a proprietary-type company setting, one group might do a MRD (marketing), then product managers would do a PRD, and then engineers might dive in and do a more detailed requirements document, and then Dilbert-type things start happening (Engineers inform the product managers that they are living in a dream world, the product managers tell them that is nice but it needs to be finished by next week, etc.. http://garbuz.com/blog/wp-content/uploads/2013/02/dilbert-agile-user-storie… :D ) And we're trying to cover most of those bases in one document, and also be realistic (i hope) in the process. There is still plenty of basic explanatory stuff that can be filled in here, so I hope that people can bear with the fact that more is coming along that might give them better context, but I wanted to get this out for a few reasons: * Validate that this is even remotely on the right track - I wanted basic framework but... at some point release early/often kicks in. ...hmm, okay, maybe there aren't any more reasons. There are clearly some sections where I'm questioning which way might be the better way to do things (user stories vs. primary use cases, for example), feedback welcome on that or anything else, obv. Other things I'd just like to put on the table as food for thought: * There are likely a lot of cases for overlap with the other working groups. I would still prefer to list them out explicitly, just so we can track / ensure that any dependencies are being coordinated / worked through (with our help, or not, or whatever) with the other teams, and also so people don't come along and say "OMG YOU FORGOT XYZ" and we don't have to explain that we already thought through this and decided it would be best passed on to another team. * In line with that, it would probably be useful to explicitly describe somewhere towards the beginning of the document what we expect is *within* our scope, vs. outside of it, particularly when it comes to server WG / cloud WG things; and also ensure that we have mutual agreement with the other WGs on that, so that we don't get into some situation of questioning whose call it is, or worse, just assuming that another working group has those bases covered. (Johann's mail that he sent just a bit ago to the list, https://lists.fedoraproject.org/pipermail/cloud/2013-October/002837.html more or less illustrates the need for this, IMO.) Also: I realize that there is often times a desire to just think about all the cool things we could add in in terms of packages but I do think it is useful for us to actually think through the use cases or user profiles, to ensure we have something that is useful in a variety of environments, for multiple purposes, user types, etc. If you're a sysadmin or developer, or know people who are, by all means, share what would make a cloud "product" useful for you in your day to day work, or ask people what would make it useful. If you know people who are explicitly avoiding Fedora like the plague for cloud usage, ask them why. This is the kind of stuff that helps us ensure that we are not just talking to ourselves, more or less ;) Anyway: I know some folks are going to want to dive in and start filling things out - and perhaps I should have maybe put this in a separate file as a "template" and then have the actual filled-out thing on in the Cloud_PRD spot, but ... maybe we can take a snapshot of it at some point soon and save that as the template. In any case: I'd like to make sure that we make sure that this is an effective way to format a PRD that will allow us to produce useful results before we go filling it all in, so that we don't wind up making a bunch of folks all sadfaced that they spent a bunch of time writing stuff before we decided that this sucks and we should do it some other way. :) Finally (I'm wordy today, sorry) - I have no idea what the other WGs are planning offhand for their PRDs. I don't know if it would be useful for everyone to standardize on one template, or have each WG decide what works best for them, and I'm not going to try and sort that out here :) but it might be useful to keep an eye on what the other teams are putting together so that we can make sure anything that does need cross-coordination can be captured appropriately. -robyn

5 5

Summary/Minutes for Cloud WG (2013-10-30)
by Matthew Miller 30 Oct '13

30 Oct '13

===================================== #fedora-meeting-1: Cloud (2013-10-30) ===================================== Meeting started by mattdm at 19:00:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedora-meeting… . Meeting summary --------------- * Intro (mattdm, 19:02:02) * Mailing List vs. IRC Meetings (mattdm, 19:05:31) * AGREED: weekly irc meetings to start. (mattdm, 19:08:19) * more like a checkpoint/coordination than a "$topic: DISCUSS" type of meeting (mattdm, 19:10:22) * "$topic: DISCUSS" should be on the mailing list (mattdm, 19:10:36) * ACTION: mattdm will coordinate time for next/ongoing meeting (mattdm, 19:10:53) * Trac Instance (mattdm, 19:11:07) * LINK: https://fedorahosted.org/cloud/ (mattdm, 19:11:23) * adding rbergeron and number80 as trac admins, will add others who want to be bothered with it on request :) (mattdm, 19:14:54) * for example frankieonuonga (mattdm, 19:15:05) * Draft Governance (mattdm, 19:15:53) * LINK: https://fedoraproject.org/wiki/Cloud_WG (mattdm, 19:15:59) * ACTION: mattdm will reorganize 'landing page' aspects of current draft into actual landing page (mattdm, 19:18:03) * IDEA: borrow from https://fedoraproject.org/wiki/Infrastructure (mattdm, 19:18:30) * AGREED: the liaison to fesco will preferably be a member of fesco, but in the case there isn't a fesco member willing to work on the behalf of the cloud WG, a non-fesco member can be appointed liaison (samkottler) (number80, 19:34:24) * AGREED: the liaison to fesco will preferably be a member of fesco, but in the case there isn't a fesco member willing to work on the behalf of the cloud WG, a non-fesco member can be appointed liaison (samkottler) +6 (number80, 19:35:15) * AGREED: one member of the cloud wg will be elected to serve as chair of the group, organizing meetings and driving; other people will step up as needed if chair is temporarily unavailable (+7) (mattdm, 19:47:34) * AGREED: Because continuity is important, Working Group members serve as long as they are able and willing. When a position on the group becomes available, that position will be filled by unanimous consent of the existing members (+7) (number80, 19:58:19) * ACTION: mattdm to draft an update to the governance document and bring it back to the mailing list (mattdm, 20:03:47) * PRD Framework (mattdm, 20:04:13) * LINK: https://fedoraproject.org/wiki/Cloud_PRD (mattdm, 20:04:17) Meeting ended at 20:24:41 UTC. Action Items ------------ * mattdm will coordinate time for next/ongoing meeting * mattdm will reorganize 'landing page' aspects of current draft into actual landing page * mattdm to draft an update to the governance document and bring it back to the mailing list Action Items, by person ----------------------- * mattdm * mattdm will coordinate time for next/ongoing meeting * mattdm will reorganize 'landing page' aspects of current draft into actual landing page * mattdm to draft an update to the governance document and bring it back to the mailing list * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mattdm (161) * rbergeron (93) * samkottler (76) * number80 (76) * frankieonuonga (50) * jzb (28) * red_trela (27) * geppetto (13) * dgilmore (11) * zodbot (10) * jwb (6) * abadger1999 (3) * nirik (2) * sgallagh (1) * orc_emac_ (1) * hguemar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

1 0

ec2/README generic/README README
by Matthew Miller 30 Oct '13

30 Oct '13

README | 6 ++++++ ec2/README | 1 + generic/README | 1 + 3 files changed, 8 insertions(+) New commits: commit aab2f3a96cf9c04613f5c51eb4162cbb2106a151 Author: Matthew Miller <mattdm(a)mattdm.org> Date: Wed Oct 30 12:00:06 2013 -0400 add readme about new location diff --git a/README b/README new file mode 100644 index 0000000..f0476e4 --- /dev/null +++ b/README @@ -0,0 +1,6 @@ +The kickstart file from which the Fedora Cloud image is built now lives in + +https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/ + +This repository remains for a) historical purposes and b) future +experimentation. \ No newline at end of file diff --git a/ec2/README b/ec2/README new file mode 120000 index 0000000..59a23c4 --- /dev/null +++ b/ec2/README @@ -0,0 +1 @@ +../README \ No newline at end of file diff --git a/generic/README b/generic/README new file mode 120000 index 0000000..59a23c4 --- /dev/null +++ b/generic/README @@ -0,0 +1 @@ +../README \ No newline at end of file

1 0

Re: Agenda for Today's Cloud WG Meeting (2013-10-30 19:00 UTC)
by Matthew Miller 30 Oct '13

30 Oct '13

On Wed, Oct 30, 2013 at 09:06:30AM -0400, Josh Boyer wrote: > You have basically the top-level landing page for the WG there. It > has all the relevant information one would expect, but I think some of > the sections go beyond governance. Specifically, the Mission, Role in > Fedora, and Communications section aren't really related to the > governance _of_ the WG. Maybe create a ==Governance== section and > split it to it's own page? Yeah, that's good feedback. Some of it is more "charter" than "governance". > Under the membership section, you don't have anything regarding what > happens if you have a member relinquish their seat. I added the > following to the Workstation draft. Just an FYI: *nod* I think that partly depends on whether we want to follow the election or appointee model. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud October 2013