Vagrant in Fedora
by Alex Drahon
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
9 years, 11 months
Feedback: Cloud image F20 TC2
by Juerg Haefliger
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
10 years
Fedora.next Product Branding for Cloud
by Máirín Duffy
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
10 years
lifespan and lifecycle
by Matthew Miller
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>
10 years
Fedora 20 TC3 AMIs
by Dennis Gilmore
-----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-Image...
http://dl.fedoraproject.org/pub/alt/stage/20-TC3/Images/x86_64/Fedora-Ima...
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-----
10 years
Minutes from today's (11/27/2013) cloud WG meeting
by Sam Kottler
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-meeti...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeti...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeti...
Log (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeti...
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-meeti...
.
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-pa...
(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-2...
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-pa...
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-2... 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
10 years
Reminder + topics for tomorrow's (11/27/2013) cloud WG meeting
by Sam Kottler
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
10 years
