cloud November 2013

cloud@lists.stg.fedoraproject.org

30 participants
37 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

Feedback: Cloud image F20 TC2
by Juerg Haefliger 10 Dec '13

10 Dec '13

All, I finally found the time to do some testing with the F20 image in HP Cloud Beta which runs some sort of OpenStack Havana. Here are my comments (which are obviously very OpenStack centric): Overall it looks very sound. Good job, Matt! As mentioned by others, logging could be improved. Currently, only kernel messages are written to the (serial) console log. If something goes wrong higher up in the stack (like cloud-init is unable to contact the metadata service or a crucial initrd process fails) we can't tell, unless there's access to the virtual console of the instance which not every cloud operator provides. If we reverse the 'console' options of the kernel command line, we get those messages on the serial console which helps with debugging boot issues. Also, I'm not sure how useful the 115200n8 ttyS0 option is, it's a virtual port after all. Lastly, Ubuntu uses console=tty1 instead of tty0 for reasons explained in https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1016695. I admit I do not fully understand the impact of using tty1 (first console) vs tty0 (foreground console) and neither do I think we need to blindly copy Ubuntu but they are the cloud-init guys after all and they do provide very solid OpenStack cloud images so it seems like they know what they're doing :-) Given that, my proposal is to use the following console kernel command line options: 'console=tty1 console=ttyS0' I was quite surprised to learn that the image can be enlarged to 2TB. Other images fail because the ext4 journal is too small. I haven't looked into it in detail but do you use special parameters when formatting the root partition? ...Juerg

6 6

Fedora.next Product Branding for Cloud
by Máirín Duffy 06 Dec '13

06 Dec '13

Hi folks, With the creation of 3 products for Fedora, the Fedora Design Team anticipates many new questions around Fedora's brand. As the main caretakers of the Fedora brand, we're going to have to figure these things out within the next few months. For example, the Design Team is starting to think about how to answer these types of questions: • Should each product have its own logo? or • Can you add our product to the Fedora website? or • Can you make our product its own website? (How should we represent these products on the website? Should we allow products to have their own separate websites?) To start off the rebranding discussion, the Fedora Design Team has 4 basic questions for each of the 3 product-focused working groups to answer: (1) What problem does your product solve, in one sentence? (2) Who is the target audience for your product, in one sentence? (3) List at least 5 products that successfully target the same target audience you are after. (4) List at least 5 products that try to solve the same problem. We are reaching out to each group individually to ask that you discuss these questions and come back to us with answers by Wednesday, December 4, 2013. I was hoping you could answer these questions for the cloud product; please let me know if this isn't a reasonable timeline or if you need any help coming up with the answers! Thanks, ~m

4 10

lifespan and lifecycle
by Matthew Miller 04 Dec '13

04 Dec '13

One of the general questions that's coming up across the working groups is product lifecycle. We should talk about what we would like to see for the Fedora cloud. I often hear that a longer lifecycle would be beneficial, and if Fedora as a whole goes for that I think we would take advantage, but more important, I think, is the ability to move to a newer version without hassle -- application stack works on one version and also on the next, or at least only requires minor changes. I also _really_ think we need to do periodic respins including updates, and we could possibly call these point releases. I think monthly would be ideal but every 3 months might be a more managable bite. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

5 4

Fedora 20 TC3 AMIs
by Dennis Gilmore 02 Dec '13

02 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Final TC3 images have been uploaded to EC2 and are available at ami-c17858a8 : us-east-1 image for i386 ami-6578580c : us-east-1 image for x86_64 additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-TC3/Images/i386/Fedora-Images-… http://dl.fedoraproject.org/pub/alt/stage/20-TC3/Images/x86_64/Fedora-Image… when we get to final and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSle5NAAoJEH7ltONmPFDRaV0P/2UVBWsA9MM3jStn05XGpYJT wkyWVP0P5IEq/KhjIADO627Hgrr899OF3GBGjtsWVB7xydAzwe+itjsgGDfFCi2B I5x5vIiBRVvKRnlsfudaqZgDY7/Dp5AR3nJf2g/cb+hUwh32AC9HRuhps9L6fk9J I35Ih8xcdUJtbU9E76M/BXZweXPgzDDgH9dInBZmyv/jC9K5bGqqHOQR8DHyOUop sWPeNjDwkq1cgLE/fXG+IIkYY0Bbi+TsYZTBs9Br2K/VChSXXIHk9PPITiUO6otL CLF1QDKYZROAu8sgZI/kcglkKPNE+cp6XdDe9nDqFyyhoSqBaBpxvFrGxeCvWfp+ paG38FpAzA9juI2QSw383hkSZbD9mAwto6GPImq6CMBW50GxbUjkROVDVPUJSBLO YZT5ennNdUm+v108f4r8CdAhtgA8fVzFVS9hmGTpNPchBTqqSI0ToPScCxYVSuFV iQtQZmQGQ/UDwP4VFmV9HSeJl2QQDaReW6nDs5tenF4yWFq2dJd8dQSm8tX+YHYc swF2jQOa63qBPE1pBLLzGMjUwXRfDHTR4pgUoBmpIQR16DKm2gYQC0OAKH6hMyPI Azdqb4YPufbTkQ/cuR02LYd0ZhQp2Ow5nH+mOwLu7917/IhOL6TxHkDUb/Mm61Fw SaBNyFqbxNeWBsRmZ7lh =TDwx -----END PGP SIGNATURE-----

2 3

Minutes from today's (11/27/2013) cloud WG meeting
by Sam Kottler 27 Nov '13

27 Nov '13

Thanks everyone who was able to make it to the meeting today! For those who weren't able to make it, here are few important links: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… Log (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… Here's a summary of the meeting (link to the HTML and text versions above): ========================================== #fedora-meeting-1: Cloud WG weekly meeting ========================================== Meeting started by samkottler at 17:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… . Meeting summary --------------- * rollcall (samkottler, 17:00:37) * LINK: https://fedorahosted.org/cloud/ticket/4 (mattdm, 17:04:18) * update on GCE legal and packaging things (samkottler, 17:05:03) * email shk(a)redhat.com if you want to get added to the trusted testers program or want to see the language associated with it (samkottler, 17:05:58) * LINK: http://fedorapeople.org/cgit/skottler/public_git/google-compute-engine-pack… (samkottler, 17:06:59) * Fedora.next product branding (samkottler, 17:16:33) * LINK: http://cloud-images.ubuntu.com/locator/ec2/ (jzb, 17:30:52) * LINK: https://aws.amazon.com/marketplace (jzb, 17:31:23) * AGREED: we'll produce a base image, with tools, and 2-4 images preconfigured for specific uses (samkottler, 17:43:44) * put together a team/plan to work on the PRD (samkottler, 17:53:38) * LINK: https://fedoraproject.org/wiki/Cloud_PRD (samkottler, 17:54:17) * open floor (samkottler, 18:02:49) * LINK: https://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-nov-26-… is a good write-up of that meeting (sgallagh, 18:07:03) Meeting ended at 18:23:52 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * samkottler (103) * jzb (52) * mattdm (49) * number80 (38) * frankieonuonga (29) * mrunge (27) * gholms (26) * rbergeron (25) * sgallagh (17) * geppetto (10) * juergh (8) * zodbot (5) 17:00:23 <samkottler> #startmeeting Cloud WG weekly meeting 17:00:23 <zodbot> Meeting started Wed Nov 27 17:00:23 2013 UTC. The chair is samkottler. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:37 <samkottler> #topic rollcall 17:00:42 * geppetto is here 17:00:44 <samkottler> \o 17:00:50 <rbergeron> heyooooo 17:00:59 <mrunge> heya! 17:00:59 <juergh> hi all 17:01:01 <samkottler> #chair geppetto mrunge number80 rbergeron mattdm frankieonuonga 17:01:01 <zodbot> Current chairs: frankieonuonga geppetto mattdm mrunge number80 rbergeron samkottler 17:01:27 <jzb> howdy 17:01:32 <samkottler> #chair jzb 17:01:32 <zodbot> Current chairs: frankieonuonga geppetto jzb mattdm mrunge number80 rbergeron samkottler 17:01:35 <mattdm> hi just a sec wrapping up Current Exciting Crisis 17:01:42 <gholms> Heh 17:03:49 * samkottler waits another minute for mattdm 17:03:58 <samkottler> we have a lot more people today than I was expecting :) 17:04:18 <mattdm> https://fedorahosted.org/cloud/ticket/4 17:04:27 <mattdm> just fyi :) 17:04:39 <rbergeron> samkottler: you haven't scared everyone off yet 17:04:47 <rbergeron> give it another minute or two :) 17:04:50 <samkottler> *yet* 17:05:03 <samkottler> #topic update on GCE legal and packaging things 17:05:26 <samkottler> so Fedora legal has said that people who wish to sign the google trusted tester document may do so individually 17:05:58 <samkottler> #info email shk(a)redhat.com if you want to get added to the trusted testers program or want to see the language associated with it 17:06:33 <number80> great 17:06:43 <samkottler> frankieonuonga, witlessb, and I started packaging the utlities we'll need 17:06:59 <samkottler> http://fedorapeople.org/cgit/skottler/public_git/google-compute-engine-pack… 17:07:15 <samkottler> help would be much appreciated 17:07:18 <samkottler> commit for everyone! 17:08:02 <mattdm> samkottler awesome thanks 17:08:06 <gholms> Great! How does that help us? 17:08:21 <mattdm> gholms fedora available in more public clouds 17:08:29 <samkottler> gholms: we'll need those tools to make fedora available in gce 17:08:35 <gholms> Wo's going to upload it? 17:08:42 <gholms> *Who's 17:08:54 <number80> samkottler: i could help 17:08:57 <gholms> Not rel-eng, I presume? 17:09:01 <mattdm> gholms eventually, release engineering. once we have it working. 17:09:13 <mattdm> rel-eng uploads ec2, and this is the same. 17:09:23 <gholms> I thought dgilmore wasn't going to do that. 17:09:50 <mattdm> gholms it could be someone working with him. dgilmore doesn't need more things piled on top of him, that's true. 17:09:50 <gholms> (the agreement thing, that is) 17:09:54 <number80> gholms: dgilmore needs moarr people to help him, so we need to get some people to join rel-eng 17:10:05 <gholms> Alrighty 17:10:10 <samkottler> frankieonuonga agreed to be the rel-eng rep a while back 17:10:18 <jzb> number80: what does that entail? 17:10:41 <samkottler> jzb: it'd mainly be scripting stuff to upload to public clouds 17:10:45 <samkottler> tools > humans 17:10:47 <gholms> I'm not trying to stop you or anything; I just want to have a clear picture. 17:11:31 <number80> jzb: plus improving general rel-eng process with more automation 17:11:43 <mattdm> yeah there is a plan to have image uploading be automatic. 17:11:50 <samkottler> it's also possible we could get dgilmore access without signing the document, but that's a whole other discussion 17:13:03 <number80> i'd say no, as it would force someone else to step up into rel-eng 17:13:30 <samkottler> well we should have someone else doing it regardless, but I was just putting that out on the table 17:15:15 <mrunge> esp. when thinking about release cycles, I'd love to see more automation 17:15:37 <rbergeron> automate all the things! 17:15:45 * rbergeron uses overused phrase 17:15:46 <samkottler> #topic +1 17:15:53 <samkottler> #undo 17:15:53 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x4c516d0> 17:15:55 <samkottler> +1 17:15:57 * rbergeron lulz 17:16:01 <gholms> Heh 17:16:02 <geppetto> :) 17:16:33 <samkottler> #topic Fedora.next product branding 17:16:35 <samkottler> :) 17:17:06 <samkottler> did people get a chance to read the thread on the list? 17:17:17 <mattdm> Yeah -- didn't respond but read it. 17:17:54 <jzb> I threw something out as a starter, I got one reply and I think we were largely saying the same things but slightly differently. 17:18:00 <mattdm> Are we generally in agreement with 17:18:02 <mattdm> Fedora Cloud provides a customizable base image and tools for developing 17:18:04 <mattdm> scale out applications on public and private clouds. 17:18:11 <mattdm> as our overall product? 17:18:14 <number80> yup 17:18:54 <number80> i wished that we added an emphasis on the devops side, but it's only a wording issue 17:19:11 <samkottler> the devops side in what respect? 17:19:18 <samkottler> ephemeralization of infrastructure? 17:19:43 <mattdm> I can get on board with that, although I'm also open to the idea of picking something more specific for the application scale-out approach and focusing around that 17:20:01 <mattdm> eg openshift and/or docker. 17:20:51 <samkottler> I think one thing that ubuntu has done really well in the cloud space is make their stuff extremely general purpose 17:21:06 <juergh> samkottler: +1 17:21:08 <number80> samkottler: not sure, i'm understanding that expression 17:21:31 <mattdm> whereas on the other hand, coreos goes the other way and basically comes batteries-included for a specific purpose. 17:22:01 <number80> It's more about providing tools from end to end of the process: the developer, the operator should use the same image 17:22:04 <mattdm> If I am alone in this, then we can just move on, because I think we can also do general purpose in a very succesful way. 17:22:10 <samkottler> number80: the ubuntu images can run docker, be ephemeral with the latest stuff, are a nice openstack guest standalone, etc. 17:22:20 <number80> samkottler: so we agree ;) 17:22:36 <samkottler> number80: yep, totally 17:23:35 <mattdm> overall, there's a tension between being able to do all of the things and being tailored to do one well. For example, normally one wouldn't want libvirt on a guest image, but that infrastructure will be necessary for selinux-protected docker, so we will want it for that... 17:23:53 <samkottler> mattdm: I don't mind aligning ourselves with certain other projects, but I thnink it's challenging to provide general, widespread value if we do 17:24:01 <mattdm> but it's a _big_ thing to add, so should probably be on the image itself for docker use, rather than installed with cloud-init or otherwise. 17:24:41 <samkottler> I almost feels like we need spins, but for cloud images 17:25:02 <mattdm> samkottler "library of cloud images". yes. 17:25:05 * rbergeron nods 17:25:15 <gholms> Thankfully lots of clouds make image customization a snap, too. 17:25:23 <jzb> samkottler: +1 17:26:29 <samkottler> so then we can produce a base, small image 17:26:36 <samkottler> and other stuff with the "value add" baked in 17:26:49 <samkottler> if you need a multi-tenant docker env, we've got that 17:26:50 <samkottler> etc. 17:26:57 <mrunge> well, I assume, that will confuse users to have a broad library of cloud images 17:27:16 <mrunge> so I'm -1 for (against) specialized images 17:27:27 <number80> the same 17:27:41 <samkottler> confuse users in what way? 17:27:45 <jzb> mrunge: they expect that, especially on AWS 17:27:45 <samkottler> they won't know which one to use? 17:27:57 <number80> i'd rather make it easy to build custom images and have a very bare one 17:28:15 <jzb> number80: we would, but also easy to use off-the-shelf images for specific things. 17:28:16 <mrunge> yeah, or if they see a list of 20 images, what do they do? 17:28:31 <mattdm> jzb +1 to off-the-shelf. 17:28:37 <jzb> mrunge: they pick the one that has the description that matches what they want 17:28:55 <mrunge> jzb, who reads docs? 17:28:55 <jzb> mrunge: this is not uniformed desktop users, this is developers who should be capable of reading a description and picking. 17:29:06 * gholms notes that we had this exact argument with the old spin download page 17:29:14 <samkottler> how many users are able to respin their own images without learning a significant amount of stuff 17:29:18 <jzb> mrunge: the people who choose from umpty-billion different AWS images based on Ubuntu? 17:29:23 <samkottler> remember that we're engineering for the 99% here :) 17:29:27 <gholms> samkottler: In AWS, all of them. 17:29:30 <samkottler> not the people who are in a working group :) 17:29:32 <gholms> Not sure about others. 17:29:40 <number80> jzb: from experience, specialized images always ends up with a lot of unused stuff for 90% of users 17:29:42 <geppetto> I think both extremes will be a bad idea â€¦ you don't want N people all "customizing" the same base into roughly the same baked in image. 17:29:48 <samkottler> gholms: that's not really true, though 17:29:53 <juergh> what about the effort to maintain a whole set of image vs. a bare image and some tools to customize it? 17:30:07 <samkottler> juergh: yep, that's basically what's being proposed 17:30:10 <juergh> think security updates and the likes. 17:30:12 <geppetto> Also the customizing can't be bugfree â€¦ which is a giant negative freeroll. 17:30:13 <samkottler> we'll keep the base image around 17:30:22 <jzb> number80: from experience with... images running in the cloud? 17:30:23 <samkottler> geppetto: mhm 17:30:50 <jzb> number80: this is our "competition" 17:30:51 <samkottler> number80: if the people don't need the stuff on top, then they just use the base image 17:30:52 <jzb> http://cloud-images.ubuntu.com/locator/ec2/ 17:31:23 <jzb> https://aws.amazon.com/marketplace 17:31:27 <number80> jzb: yup, at $dayjob, i'm doing a lot of SaaS migration :/ 17:31:31 <mattdm> So, thinking of the docker use case (just because that's what I'm working with), it's really awesome if there is a pre-made image that I can just launch or download+launch. 17:31:38 * mrunge needs to step out and will come back later 17:31:49 <number80> samkottler: +1 17:32:11 <mattdm> jzb but the cloud-images-locator is just the same as http://fedoraproject.org/en/get-fedora-options#clouds 17:32:36 <juergh> In my experience partners take a bare image, customize it, snapshot it and make that image available to their end users. There's alway some customization necesseray whether you start from a bare image or a specialized iamge. 17:32:59 <juergh> I'm not sold on customized images. 17:33:00 <geppetto> jzb: Is it obvious to other people how all those top 8 entries are different from each other? 17:33:05 <gholms> samkottler: You'vr seen how ridiculously easy EC2's console makes customizing an image, right? 17:33:17 <jzb> mattdm: similar, but my point is that people are capable of navigating things 17:33:41 <mattdm> gholms ridiculous in what sense? :) 17:34:07 <jzb> geppetto: I would hope if someone is doing app development and making some form of informed decision they are capable of reading a description and choosing. 17:34:19 <jzb> geppetto: also, this should not be a bare "the only thing they have is this page" situation 17:34:25 <samkottler> gholms: I wouldn't exactly say that 17:34:33 <jzb> geppetto: once we have soome customized images, we should be promoting them 17:34:34 <samkottler> most people don't build their own AMI's 17:34:54 <gholms> mattdm: Easy enough that I've got people from developers to graphic designers who figured it out on their own. ;) 17:34:56 <jzb> geppetto: e.g. "hey, wanna run docker on Fedora, use <link>" 17:35:16 <gholms> samkottler: From scratch, of course not. But customizi a base image is another story. 17:35:27 <jzb> geppetto: I think we'll put ourselves at a disadvantage having only a base image without any additional value-add images. 17:35:32 <samkottler> again, let's think about actual users 17:35:37 <samkottler> not us, but actual people :) 17:35:38 <jzb> though we should point loudly to the default 17:35:42 <geppetto> jzb: Sure. 17:35:45 <jzb> samkottler: hey, I think. 17:35:55 * jzb thought he was an actual people. 17:36:11 <number80> jzb: for our target, the barest image is itself a value 17:36:16 <gholms> samkottler: I really wish I could show you my data on this. :( 17:36:20 <mattdm> My viewpoint is that we have a pretty decent generic base image right now, and it's not getting very much traction. 17:36:21 * gholms cries 17:36:44 <gholms> mattdm: You know, that's a good point. 17:36:44 <jzb> mattdm: +1 17:36:46 <samkottler> gholms: I don't doubt that it's true, my point is that there are a lot of people who want to use an image without having to "rebake" it 17:37:04 <number80> mattdm: we lacks maintained application stacks :( 17:37:05 <gholms> samkottler: Makes sense 17:37:20 <mattdm> number80 +1 yes. 17:37:27 <number80> i'd rather rely on easily installable SCL than a bunch of images 17:37:41 <samkottler> telling users 'here, launch this AMI and you'll have docker/openshift/whatever' is huge 17:37:55 * gholms nods 17:38:01 <jzb> number80: let me see if I'm understanding this 17:38:05 <frankieonuonga> i am in guys 17:38:08 <frankieonuonga> sorry i am late 17:38:09 <mattdm> what if we kept the library small? three or four things in addition to the base, rather than 20? 17:38:13 <jzb> number80: you feel that offering 20 images is confusing 17:38:22 <jzb> number80: but offering one + shuttling them off to SCLs is not? 17:38:22 <number80> samkottler: we could add a script in user-data for that 17:38:29 <samkottler> 20 images is also insane to test 17:38:38 <samkottler> < 5 is perfect IMO 17:38:47 <number80> jzb: a base image and users are free to install any SCL they need 17:39:03 <jzb> number80: again, that's less confusing than offering it pre-baked? 17:39:07 <geppetto> samkottler: +1 â€¦ extremes of both cases will be pretty bad, IMO. 17:39:13 <jzb> when I can just spin up an Ubuntu image that has what I want? 17:39:43 <mattdm> so, proposal: base image, plus tools for extending (including application stack work), plus 2-4 images preconfigured for specific uses. 17:39:49 <samkottler> mattdm: +1 17:39:49 <jzb> geppetto, samkottler I am in agreement that 20 may be a bit much 17:39:56 <geppetto> mattdm: +1 17:40:00 <jzb> maybe 4 or 5 would be the ideal situation 17:40:26 <jzb> and if we start getting traction, perhaps the larger community will start building + offering more. 17:40:30 <gholms> Not to mention we'd have a lot easier time maintaining and testing just a few images. 17:40:33 <number80> jzb: yes, most of the time, your image will require frying anyway 17:40:43 <number80> n images = n times more QA 17:40:53 * rbergeron thinks there is a healthy balance between gholms's thoughts and samkottler's 17:41:17 <gholms> What if we start with just a few and see where that takes us? 17:41:21 <jzb> so, mattdm's proposal: ^^ 17:41:27 <geppetto> jzb: My guess is that it'd be a mistake to go above ~7 pre. baked images (roughly what people can remember, easily) 17:41:34 <samkottler> yeah, a few seems perfect for now 17:41:35 <frankieonuonga> i am +1 on gholms idea 17:41:40 <jzb> "base image, plus tools, plus 2-4 images preconfiguted for specific uses" 17:41:40 * rbergeron is also pretty sure that the number of folks that take a base image and then snapshot it after updating it in their own way is pretty large 17:41:48 <number80> if we have people to help maintaining more images, why not, but the main goal of fedora.next is to reduce the scope to get better products 17:41:54 <samkottler> if people like them then we can consider making more 17:41:55 <juergh> rbergeron: exactly 17:42:06 <geppetto> If everyone could stop re-proposing what mattdm said, and just +1 that'd be nice ;) 17:42:08 <number80> samkottler: +1 17:42:14 <jzb> so I'm +1 to mattdm / gholms 17:42:25 <jzb> geppetto: +1 17:42:35 * rbergeron just +1s the last 12 things said :) 17:42:37 <juergh> who/what's do decide what those additional images contain? 17:42:37 <frankieonuonga> i have already voted but just to clarigy gholms +1 17:42:48 * jzb +1's rbergeron 17:42:59 <jzb> (I think we have consensus) 17:43:18 * gholms +1s jzb just because :P 17:43:28 <mattdm> juergh all of us, and depending on who wants to work on what. 17:43:44 <samkottler> #agreed we'll produce a base image, with tools, and 2-4 images preconfigured for specific uses 17:43:49 * samkottler is excited about this 17:44:35 <mrunge> yeah, sounds good to me, the fewer, the better 17:45:06 <rbergeron> well - the worst that can happen is that we can find out that they're all wildly popular 17:45:21 <rbergeron> or that we were wrong about he popularity of one or another and ... figure out how to tune it / make it better / drop it 17:45:27 <rbergeron> learning ftw :) 17:45:42 <samkottler> agreed 17:45:56 <mattdm> rbergeron yes. and we need better metrics. we do not really have those right now. that might be a whole 'nuther issue. 17:46:06 <samkottler> next we need to figure out which ones we'll produce, but we can take that to the list 17:46:19 <number80> i suggest polls 17:46:24 * samkottler has a feeling some people will have opinions about that 17:47:07 <number80> i'd rather go ask actual users than relying on how own distorted perception :o) 17:47:13 <number80> well, mine is distorted 17:47:24 <samkottler> number80: well before we can poll we need some options, but yeah an end-user poll would be great 17:47:25 <mattdm> good polls are hard / expensive. 17:47:47 <frankieonuonga> totally agree with number80 but my only problem is how do we gather pols..do we let people vote as they download an image ? 17:47:48 <samkottler> also, remember that most of our target users currently aren't in the community :) 17:47:57 <mattdm> but could we bracket that for now and come back to it? there's more agenda to get through :) 17:48:03 <jzb> mattdm: +1 17:48:07 <frankieonuonga> mattdm: we could poll on the site and collect results on mysql 17:48:09 <mrunge> +1 17:48:12 <mattdm> the topic right now was product branding 17:48:15 <number80> +1 17:48:26 <mattdm> And this question was the big part of that that I felt was open 17:48:42 <mattdm> other than that, I think jzb's initial response was good except I would s/Docker/CoreOS/g 17:48:46 <samkottler> yeah, the PRD and branding docs will be much easier now 17:49:41 <jzb> mattdm: can we +CoreOS? 17:49:42 <samkottler> so should we take the branding document back to the list and move on? 17:49:56 <jzb> but I'm easy, s/Docker/CoreOS/g works too 17:50:24 <rbergeron> isn't coreOS like a ... whole different nut to crack from docker 17:51:10 <mattdm> Fedora happily includes Docker. CoreOS is a platform for Docker deployment + some other stuff, which is basically directly in competition. 17:51:19 <mattdm> friendly, open source competition :) 17:51:42 <number80> may the best win 17:52:04 <jzb> as long as it's us 17:52:08 <jzb> :-) 17:52:12 <frankieonuonga> :-) 17:53:09 * rbergeron looks back to samkottler's branding document question 17:53:24 <mattdm> yeah, +1 to back to the list and next item 17:53:38 <samkottler> #topic put together a team/plan to work on the PRD 17:54:03 <frankieonuonga> just as a reminder...what was PRD again ? 17:54:09 * rbergeron poked away some lsat week. 17:54:17 <samkottler> https://fedoraproject.org/wiki/Cloud_PRD 17:54:33 * samkottler is planning on working on it on friday and maybe tomorrow depending on how bored he gets 17:54:35 <rbergeron> but slowly. and having help would be teh awesomes so i am not feeling sad and lonely and wondering if i'm doing the right thing :) 17:55:13 * frankieonuonga offers to help samkottler 17:55:17 <jzb> rbergeron: will try to poke at it more this weekend 17:55:29 <jzb> rbergeron: will be doing the traditional gorging tomorrow and Friday 17:55:40 <rbergeron> jzb: TURKEEEEEEE 17:55:43 <samkottler> remember that we agreed to try and get it done by december 15th 17:55:47 <samkottler> which is kinda soon 17:56:02 <samkottler> rbergeron: don't remind me 17:56:04 <number80> rbergeron: i did some proof-reading this afternoon, and i plan to import openstack personas so we could grok our own personas 17:56:24 <frankieonuonga> we use cloud stack where i work so i can do that 17:56:39 <jzb> frankieonuonga: +1 17:56:47 * jzb says, wearing CloudStack PMC hat. 17:56:52 <samkottler> do we want individual personas for each private cloud impl? 17:57:06 <rbergeron> number80: cool, thanks 17:57:12 <rbergeron> samkottler: yeah. it's very soon :) 17:57:28 <number80> jzb: i prefer my yellow shiny eucalyptus t-shirt :P 17:57:37 <rbergeron> frankieonuonga: you just made jzb and ke4qqq smile, lol 17:57:46 <rbergeron> number80: that's because it's an epic shirt 17:57:51 <number80> \o/ 17:57:53 <rbergeron> samkottler: impl? 17:57:56 <frankieonuonga> :-) always a pleasure to ...plus ke4qqq is a huge help 17:58:03 <rbergeron> sorry, my head isn't right 17:58:08 <frankieonuonga> thanks mate 17:58:22 <jzb> samkottler: probably 17:58:58 <frankieonuonga> I would say 2 people in each 17:58:58 <number80> sorry, let's focus 17:59:04 <frankieonuonga> if possible 17:59:44 <samkottler> the PRD is just the kind of thing that requires hammering away on 17:59:44 <number80> (besides fesco meeting in one minute) 18:00:01 <number80> samkottler: +1 18:00:09 <samkottler> anyone have anything else to add on the PRD? 18:00:32 <samkottler> rbergeron: implementation 18:00:39 <rbergeron> samkottler: AHHHH 18:01:47 <samkottler> can we bump the release/lifecycle discussion to next week? 18:01:58 <number80> +1 18:02:02 <mrunge> +1 18:02:05 <mattdm> samkottler yes that's fine.. 18:02:08 <jzb> samkottler: maybe start on email? 18:02:08 <frankieonuonga> +1 18:02:10 <jzb> but +1 18:02:10 * mattdm has fesco meeting now 18:02:11 <number80> maybe kickstarting the discussion on the list 18:02:21 <samkottler> mattdm: can you kick that off on the list? 18:02:28 <mattdm> samkottler yep 18:02:41 <samkottler> mattdm: danke! 18:02:49 <samkottler> #topic open floor 18:03:09 <samkottler> anyone got anything else before we wrap up? 18:03:14 <frankieonuonga> yes 18:03:14 <sgallagh> Dangerous topic: dividing line of Server and Cloud? (Sorry if this was discussed earlier, just got here) 18:03:34 <frankieonuonga> I will wait for sgallagh to finish then i come in with mine 18:03:41 <mrunge> oh yes, good question 18:04:53 <mrunge> and sgallagh IMHO we had that very briefly on the cloud-ml, but didn't come to any conclusion 18:05:00 <frankieonuonga> I want to ask if we have some docs for the server side to find out what their limit is 18:05:02 <sgallagh> So it came up on yesterday's call that it's somewhat ambiguous 18:05:08 <mattdm> It's looking to me that there is going to be some overlap 18:05:12 <sgallagh> s/call/meeting/ 18:05:15 <mattdm> which is not necessarily bad. 18:05:17 <sgallagh> As there should be 18:05:23 <sgallagh> But how much? 18:05:59 <frankieonuonga> I personally think that we need to go in a few months before we know exactly what is happening 18:06:05 <frankieonuonga> but that is just me 18:06:20 <samkottler> sgallagh: it seems like we need to establish where we have the potential to overlap before we can figure out how much overlap is okay? 18:06:41 <mattdm> possibly a lot, at the core level. We're also going to focus on prebaked images for things like docker and openshift 18:06:45 <sgallagh> samkottler: We covered that somewhat in our Server WG meeting yesterday. 18:07:02 <samkottler> sgallagh: I'll re-read the log then, thanks 18:07:03 <sgallagh> https://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-nov-26-… is a good write-up of that meeting 18:07:10 <mattdm> also, I think that we will be somewhat concerned more with _language_ stacks and server maybe more with _application_ stacks? 18:07:12 * samkottler will make a point of attending those meetings 18:07:36 * frankieonuonga is lost but will figure it out 18:07:52 <sgallagh> mattdm: We're focusing our intentions pretty heavily around the ability to assign "roles" to a server 18:07:57 * number80 gotta go (office building is closing) 18:08:13 <sgallagh> At a high level "i.e. This machine is a domain controller", "This machine is a PostgreSQL server" 18:09:13 <frankieonuonga> by the way guys I am sorry . I know I had promised the packages for about 1 week ago but I have been badly busy at work. anyway happy to say that Samkottler has been a great help so i should be able to finish by end week. sorry again 18:09:43 <mrunge> and how fits e.g oVirt in this figure? 18:10:10 <mrunge> server based on small images 18:10:47 <mrunge> so, somehow oVirt is a classical data-center product 18:10:52 <mrunge> == a server product 18:11:24 <mrunge> but on one side totally based on small images (for compute nodes) 18:11:33 <mattdm> ovirt node vs. ovirt [whatever the not-node-part-is-called] 18:11:54 <mattdm> sgallagh Another differentiator might be image-based deployment vs. kickstart deployment. 18:11:55 * samkottler likes the idea of operating under the premise that server owns the hypervisor and we own the guest 18:12:05 <jzb> samkottler: +1 18:12:18 <frankieonuonga> +1 samkottler 18:12:30 <mrunge> samkottler, in the oVirt case, we would own both 18:12:40 <mrunge> and the same applies to server WG 18:12:42 <mattdm> who owns 'postgresql server' in that model? 18:12:51 <sgallagh> mattdm: I'm not sure if that differentiates the products really 18:13:13 <sgallagh> (Referring to kickstart vs. image) 18:13:26 <sgallagh> To me, the product is the result of that action 18:13:32 <samkottler> mrunge: no in the ovirt case we'd own neither 18:13:59 <samkottler> mattdm: the server WG would own the things that aren't cloud related 18:14:20 <samkottler> so we could own cloud-init, virtio stuff (maybe?) and they would own all the 'regular' packages 18:14:31 <frankieonuonga> i beg to differ...to some extent i think that our images in some cases are used as servers. 18:14:37 <gholms> Seems reasonable 18:14:38 <frankieonuonga> but i might be wrong 18:15:00 <sgallagh> samkottler: I generally agree on the hypervisor vs. guest thing 18:15:09 <sgallagh> Except of course for the tenancy case... 18:16:00 <sgallagh> i.e. virt-on-virt 18:16:22 <jzb> sgallagh: virt-on-virt? 18:16:34 <samkottler> frankieonuonga: oh yeah of course, we're mainly talking about where the server WG's role ends and ours begins 18:16:41 <samkottler> and I guess then where theirs starts again 18:16:44 <sgallagh> jzb: I set up a virtualized cloud and then rent you the ability to do virt inside my cloud 18:16:54 <samkottler> jzb: russia doll virt 18:16:58 <samkottler> russian doll** 18:17:11 <mrunge> jzb, e.g the undercloud-overcloud thing in OpenStack 18:17:19 <mrunge> jzb, named TripleO 18:17:32 <sgallagh> where virt may be one or more of "kvm, xen, lxc, docker..." 18:17:59 <samkottler> sgallagh: so basically you'd own the 'lowest' hypervisor 18:18:01 <jzb> ah 18:18:10 <mrunge> I'm not sure, if we can divide them at all 18:18:17 <samkottler> mrunge: tripleo is a whole other thing from russian doll virt 18:18:25 <mrunge> (I mean server and cloud) 18:19:13 <mrunge> samkottler, I don't think so. 18:19:31 <mrunge> nevertheless, this is nothing we can decide right now 18:19:49 <samkottler> mrunge: tripleo is using openstack to provision physical hardware 18:19:55 <samkottler> mrunge: and then install a hypervisor on top 18:20:17 <samkottler> vs. virtualizing on top of a hypervisor and then using that hypervisor to run another guest inside of it 18:21:21 <mrunge> samkottler, it's not necessarily the case 18:21:30 <samkottler> do we actually want to vote on something related to this? 18:21:32 <mrunge> but usually folks will implement it that way 18:22:35 <samkottler> frankieonuonga: you had something to bring up? 18:22:41 <frankieonuonga> yeah 18:22:55 <frankieonuonga> I am sorry . I know I had promised the packages for about 1 week ago but I have been badly busy at work. anyway happy to say that Samkottler has been a great help so i should be able to finish by end week. sorry again 18:23:17 <frankieonuonga> i thought it might be easier but there are some things i had over looked 18:23:21 <frankieonuonga> so i am doing what i can 18:23:40 <samkottler> no worries - let us know where/when you need help :) 18:23:52 <samkottler> #endmeeting

1 0

Reminder + topics for tomorrow's (11/27/2013) cloud WG meeting
by Sam Kottler 27 Nov '13

27 Nov '13

Following is the list of topics that will be discussed in the cloud WG meeting Wednesday at 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. I know tomorrow is a busy travel day in the US due to the Thanksgiving holiday on Thursday, but hopefully we'll have a solid group in attendance. Additionally, we're working on finding a better time going forward, but the meeting tomorrow is still at 17:00 UTC. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2013-11-27 17:00 UTC' = Followups = * GCE legal and packaging updates * Fedora.next product branding * Put together a team/plan to work on the PRD = New business = No new agenda items, but please bring up any topics you've got. If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/cloud, e-mail me directly, or bring it up at the end of the meeting during the open floor. I'll talk to you all tomorrow! -Sam

3 2

Reminder + topics for tomorrow's (11/20/2013) cloud WG meeting
by Sam Kottler 26 Nov '13

26 Nov '13

Following is the list of topics that will be discussed in the cloud WG meeting Wednesday at 17:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2013-11-13 17:00 UTC' = Followups = * Update on the status of packaging the tools needed to build images for GCE * Status of legal discussion around Google's trusted tester document = New business = * Fedora.next product branding for cloud (https://fedorahosted.org/cloud/ticket/3) If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/cloud, e-mail me directly, or bring it up at the end of the meeting, during the open floor. See you all tomorrow at 17:00 UTC! -Sam

4 6

cloud-initramfs-tools update for F20
by Juerg Haefliger 22 Nov '13

22 Nov '13

All, I realize it's late in the cycle but I just pushed an update to cloud-initramfs-tools: https://admin.fedoraproject.org/updates/cloud-initramfs-tools-0.20-2.fc20 The package contains fixes for: 1003153 - dracut growroot module leaves an empty directory around which breaks dracut 1016648 - ARM guest on x86_64 fails to boot, mount: special device /dev/vda3 does not exist 1009172 - dracut-modules-growroot does not enlarge /dev/mmcblk0 Karma is always welcome :-) Regards ...juerg

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud November 2013