[14:54] <arosales> Hello folks, we'll be getting http://summit.ubuntu.com/uds-1305/meeting/21815/servercloud-s-cloud-images-lts-enablement/ underway in a minute here
[14:57] <arosales> Any folks interested in being in the G+ hangout?
[14:58] <arosales> specifically for http://summit.ubuntu.com/uds-1305/meeting/21815/servercloud-s-cloud-images-lts-enablement/
[15:02] <arosales> Hello getting kicked off for the 12.04.x images with LTS Enablement Kernel session
[15:05] <smoser> http://cloud-images.ubuntu.com/releases/13.04/release/
[15:07] <bjf> can you clearly state what you think the policy is today and what the difference is with your new plan?
[15:07] <smoser> can you clarify "policy"?
[15:08] <smoser> suggesting that there is a
[15:08] <smoser>  http://cloud-images.ubuntu.com/releases/13.04/release/
[15:08] <smoser> and a
[15:08] <smoser> err..
[15:08] <smoser> http://cloud-images.ubuntu.com/releases/12.04/release/
[15:08] <smoser> and
[15:08] <smoser> http://cloud-images.ubuntu.com/releases/12.04-lts/release/
[15:08] <xnox> Well - the desktop .X releases have only the lts-backports kernel. Thus to "get older" kernel, one installs using older .0 image.
[15:08] <xnox> ...
[15:09] <xnox> but raring-lts kernel is support for the lifetime of the LTS.
[15:09] <bjf> the default for 12.04.2 is the Quantal kernel
[15:09] <bjf> the default for 12.04.3 will be raring
[15:09] <xnox> that's on the desktop images, but i don't think that was the case on the server images.
[15:09] <xnox> would be interesting if server ISOs follow same as the Cloud images.
[15:09] <smoser> xnox, personally, thats completely unacceptable.
[15:09] <bjf> xnox, i thought that was supposed to be the default for all
[15:10] <smb> The only pressing reason to ship the newer kernel would be if the cloud-image is run on hardware that would not run on the older kernel. OTherwise it should be simple to pull in the meta package for lts to switch over
[15:10] <chiluk> no upgrade step is a big problem.  because most people see lts = 5 years of support ..  whereas lts+raring backport would have a 9 month support window.
[15:10] <xnox> smoser: sure. that's just what the current state is on the desktop cds.... =(
[15:11] <xnox> bjf: let me double check quickly.
[15:11] <bjf> chiluk, lts+raring is more than 9 months
[15:11] <bjf> chiluk, lts+raring is until 14.04.1
[15:11] <bjf> chiluk, that's lts-backport-raring
[15:14] <timrc> g+ hangout keeps dying on me… is this happening for anyone else?
[15:14] <marcoceppi> timrc: not here, it's been going strong since start
[15:14] <bjf> timrc, working fine here
[15:14] <arosales> chiluk, there were always be the LTS (percise ) kernel where the 5 years of support lies.  The latter interim release kernels will have the 9 months of support
[15:14] <xnox> timrc: refresh the page. It works ok for me, but I am on a good wifi.
[15:14] <chiluk> I'm more worried about the confusion it will generate.
[15:14] <timrc> bjf: argh, okay.  Thanks!
[15:14] <bjf> arosales, that is not correct for lts-backport kernels
[15:15] <xnox> arosales: lts-backport kernels have support from when they become part of the 12.04.X release up until throughout the rest LTS support cycle.
[15:16] <bjf> arosales, lts-backport kernels for precise will be supported until 14.04.1
[15:16] <xnox> including security fixes. See, the USN against all of them.
[15:16] <arosales> bjf, xnox: would you be interested in joining the hangout to provide additional info on backports?
[15:16] <xnox> nah =)
[15:16]  * xnox thought this is more about server.iso but it seems like it's all about the cloud-images.
[15:17] <bjf> arosales, sure
[15:18] <bjf> xnox, did you figure out what the default kernel is for 12.04.2?
[15:19] <smb> utlemming, For mass rollout could one not just change the seed to include the lts kernel meta package
[15:19] <smoser> utlemming, right.
[15:19] <smoser> that is the suggestion of re-bundling images
[15:19] <smoser> user can do this already
[15:22] <smoser> smb, do you know do the 12.04.X isos install the backports kernels?
[15:22] <smb> smoser, Not 100% but I would expect them to
[15:22] <smb> Cause of size restrictions on the iso
[15:23] <smoser> right. so i know it doens't hav 2 kernels.
[15:25] <smb> smoser, It _is_ 3.5 (Quantal)
[15:26] <smoser> gracias.
[15:27] <smb> utlemming, So they VM would not initially boot with the old kernel?
[15:27] <utlemming> smb: that depends
[15:28] <chiluk> hongout on air failing..
[15:28] <smb> chiluk, running for me
[15:32] <arosales> quick bottom of the hour check
[15:32] <arosales> Any question still outstanding that haven't been answered in the hangout?
[15:34] <rtg_> bjf, remember that quantal  is special 'cause we promised 18 months, but saucy and other interim releases only get 9 months.
[15:36] <bjf> rtg, true
[15:37] <bjf> rtg_, we said all lts-hwe kernels get until the first point release of the next lts
[15:37] <bjf> https://wiki.ubuntu.com/BradFigg/SupportSchedule
[15:37] <bjf> rtg_, ^
[15:37] <bjf> rtg, so, not true
[15:37] <bjf> ogasawara, ^
[15:37] <rtg_> bjf, ogasawara - we gotta discuss this on mumble after the session
[15:38] <ogasawara> rtg_: ack
[15:38] <ogasawara> rtg_: but I agree with bjf, we agreed to special case support for some of the release until the 14.04.1 time frame
[15:38] <ogasawara> else we'd leave users unsupported
[15:39] <ogasawara> rtg_: I think we need to update some of the schedules and policies per discussions coming out of the sprint
[15:39] <ogasawara> bjf et al, lets follow up in our kernel misc session later today
[15:40] <ogasawara> smoser, arosales ^^
[15:40] <bjf> ogasawara, ack
[15:40] <ogasawara> I'd planned on talking about HWE kernels there anyways
[15:40] <arosales> ogasawara, thanks, will do.
[15:40] <smoser> ogasawara, ack
[15:42] <smb> arosales, utlemming last session toda
[15:42] <utlemming> smb: I'll be there
[15:44] <arosales> smb, ogasawara the session is http://summit.ubuntu.com/uds-1305/meeting/21777/foundations-1305-kernel/ correct?
[15:44] <ogasawara> arosales: correct
[15:44] <ogasawara> arosales: let me know if you or someone from you team want to be in the actual hangout for that
[15:44] <bjf> arosales, ok, we'll cover this again in the afternoon session but the kernel team has agreed to the support as i stated it, until the next lts .1 release
[15:45] <arosales> ogasawara, thanks. I think utlemming will want to be there
[15:45] <ogasawara> arosales: ack
[15:45] <xnox> Precise is that good =)
[15:45] <xnox> i wonder if any of them will upgrade to 14.04.....
[15:45] <smb> Usually VMs are more stable about hw emulation.
[15:46] <smb> Except probably the case utlemming mentioned
[15:47] <smoser> its interesting actually.
[15:47] <smoser> you just have an immature hypervisor
[15:47] <smoser> which is the same as having immature hardware
[15:47] <smoser> only it can actually change *faster* than hardware could.
[15:47] <smoser> xen and kvm were immature at osme point. as was vmware.
[15:48] <utlemming> which is the reason why HyperV and HWE kernels are interesting
[15:48] <utlemming> HyperV moves fast
[15:48] <smoser> immature things move fast
[15:48] <arosales> Any other questions?
[15:48] <smoser> 18 year olds too.
[15:48] <arosales> to specifically address in the hangout?
[15:49] <arosales> [QUESTIONS]
[15:55] <arosales> 12.04.x Images sessions has concluded
[15:55] <arosales> Next session up: Cloud-Init for Vagrant @ 16:05 UTC
[15:55] <arosales> ref link = http://summit.ubuntu.com/uds-1305/meeting/21790/servercloud-s-cloud-vagrant/
[16:00] <zyga> hi
[16:03] <smoser> hello everyone
[16:04] <smoser> http://summit.ubuntu.com/uds-1305/meeting/21790/servercloud-s-cloud-vagrant/
[16:04] <smoser> 10
[16:04] <smoser> 9
[16:04] <smoser> 8
[16:05] <smoser> ...
[16:05] <smoser> should be live now
[16:05] <smoser> do we have a vagrant developer here ?
[16:05] <smoser> if so, you can come into the hangout discussion
[16:06] <arosales> Starting http://summit.ubuntu.com/uds-1305/meeting/21790/servercloud-s-cloud-vagrant/ session
[16:06] <zyga> hi
[16:06] <arosales> zyga, hello
[16:07] <arosales> ping me if any folks would like to join the hangout
[16:07] <geofft> I can hear you after reloading my YouTube page.
[16:07] <arosales> Please pre-sed questions with "[QUESTION]"  so we can be sure we don't miss them.
[16:07] <geofft> er, wrong channel
[16:07] <zyga> I don't know if this is the session but I'd like to see more support for vagrant images in general: in particular, desktop images
[16:08] <zyga> as a generic platform for testing
[16:08] <arosales> zyga, this is mainly for cloud images, but the idea is to use that in a desktop platform.
[16:08] <arosales> ie make it easier for a Ubuntu deploys in vagrant
[16:09] <arosales> so while this is not specifically for desktop images, it would be applicable for desktop vagrant workflows
[16:11] <arosales> jcastro asks, "what about virtualbox itself?
[16:11] <arosales> would we need to mainline that too?"
[16:11] <arosales> hello jcastro. I just asked your question, "what about virtualbox itself? Would we need to mainline that too?"
[16:13] <zyga> arosales: existence of official vagrant desktop images would allow for a lot of testing that is currently splintered across various tools, to happen. I don't know if that is doable easily with the current infrastructure. I don't want to talk about this during the session too much but I would like to point out the usefulness
[16:13] <jcastro> so what work is hardest, mainlining vbox or getting vagrant working on kvm?
[16:13] <utlemming> jcastro: mainlining vbox
[16:13] <jcastro> bummer. :)
[16:13] <zyga> jcastro: vagrant upstream is very interested in additional backends and there are existing talks about kvm
[16:13]  * jcastro nods
[16:15] <jcastro> ok so vbox to get it out and working, and then kvm-long term for linux users
[16:15] <arosales> vbox also is a good platform for other devs such as OSX users developing for Ubuntu
[16:15] <arosales> kvick, hello
[16:15] <kvick> Please keep in mind that the vagrant author thinks vbox is terrible
[16:15] <jcastro> heh
[16:16] <zyga> one thing you may need to remember about is vagrant likes to use guest filesystem sharing (which is useful for development targetting ubuntu, eg webapps work) and this has no direct replacement in kvm. There is a mode to use nfs but it's not the default
[16:16] <zyga> er
[16:16] <zyga> host filesystem
[16:16] <smoser> zyga, plan9 is that.
[16:20] <arosales> kvick, do you have any pain points for the current vagrant/ubuntu workflow?
[16:20] <utlemming> zyga: plan9 is the shared fs...and that works really well.
[16:21] <kvick> besides chef not being already installed in 12.04 :)  I know it's a licence issue that is resolved in later versions
[16:22] <zyga> utlemming: are you really proposing to use plan9?
[16:22] <zyga> utlemming: I know about what plan9 is but I have no experience with it
[16:23] <jcastro> man I didn't even know people used plan9, hah
[16:26] <kvick> thanks for the explanation.  makes sense
[16:27] <arosales> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-chef also for reference for the work done to get chef updated
[16:29] <arosales> kvick, I think utlemming does have some thoughts on using backports for a way for betting the story on 12.04 though
[16:29] <arosales> the 12.04 vagrant story that is.
[16:34] <jcastro> it is certainly an awesome local dev story
[16:35] <utlemming> I can't hear Mims
[16:35] <arosales> m_3, coming through ok for me.
[16:36] <jcastro> m_3: +50!
[16:36] <utlemming> can I get a repeat?
[16:36] <utlemming> I can't hear m_3
[16:37] <jcastro> maybe yes! :)
[16:39] <arosales> any other questions for this session?
[16:39] <arosales> jcastro, assigned you the work items to get juju working against vagrant :-)
[16:39] <jcastro> all good here
[16:39] <jcastro> arosales: yeah I see what you did there
[16:43] <arosales> Cloud-Init for Vagrant session has ended
[16:43] <arosales> We'll start the next session, http://summit.ubuntu.com/uds-1305/meeting/21789/servercloud-s-cloud-init/
[16:44] <arosales> @ 5 minuts  past the top of the hour (18:05 UTC)
[16:45] <smoser> arosales, that is the *next* hour
[16:46] <smoser> (its currently 16:45 UTC, cloud-init discussion here starts 18:05 UTC)
[16:46] <arosales> smoser, ah yes at the top of the next hour :-)
[16:46] <arosales> smoser, thank you
[16:46] <arosales> lunch/break is up next
[18:04] <arosales> we'll be starting the http://summit.ubuntu.com/uds-1305/meeting/21789/servercloud-s-cloud-init/ session shortly
[18:05] <smoser> 3 seconds
[18:05] <smoser> reload now. we are live
[18:06] <arosales> ether pad is at http://pad.ubuntu.com/uds-1305-servercloud-s-cloud-init
[18:07] <arosales> please feel pre-sed any qeustions with [QUESTION] so we can make sure we don't miss them here.
[18:13] <utlemming> http://paste.ubuntu.com/5665285/
[18:31] <smoser> any questions
[18:31] <smoser> ?
[18:49] <rbasak> I wonder how many people start cloud instances today without writing or knowing how to write cloud-init userdata?
[18:50] <rbasak> Thus I think the defaults matter
[18:50] <rbasak> How about a "fast" option in userdata instead, which drops all the slow stuff? Then the default will still be good.
[18:50] <rbasak> Sorry I think my stream is lagging.
[18:52] <arosales>  cloud-init session wrapped up
[18:53] <arosales> utlemming, smoser do you guys want to work off of https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-cloud-init
[18:53] <rbasak> smoser, utlemming: I meant in relation to dropping things like universe and backports by default from the images.
[18:54] <utlemming> rbasak: actually it would be adding them to the inmages by default. Right now, neither are there
[18:54] <rbasak> Oh, OK
[18:54] <rbasak> +1 to making the images easier to use by default
[18:55] <rbasak> Then we can blog about how to make the cloud images more streamlined via userdata after adding that option. I think it fits Ubuntu better by preferring to make the images more useful with less intervention to more people.
[18:55] <smoser> rbasak, some smart person decided not to jump on the "throw everything in apt sources list" band wagon
[18:56] <smoser> i disagree.
[18:56] <smoser> i htink the *are* usable by more people by default by having less garbage.
[18:56] <rbasak> Hmm, OK.
[18:56] <rbasak> I don't feel too strongly about it, and we don't seem to have any other feedback.
[18:57] <smoser> in reality, the change if we included backports, mulitiverse, partner , the download and apt-decompression time makes 'apt-get update' take like twice as long.
[18:58] <smoser> i think a general tool for manipulating the common repositories would be nice... and cloud-init then just interacting with it.
[18:58] <smoser> basically like apt-add-repository
[18:58] <smoser> but have that support 'multiverse' , 'universe'
[18:58] <smoser> and have 'apt-remove-repository'
[18:58] <rbasak> I have a really horrible thought
[18:58] <smoser> you have 1 minute.
[18:58] <rbasak> Special userdata "keywords" like "fast" and "full-featured" (and nothing else) that cloud-init automatically interprets with pre-set defaults.
[18:59] <smoser> :)
[18:59] <smoser> "ha"
[18:59] <smoser> and "money making"
[18:59] <smoser> also
[18:59] <smoser> :)
[19:00] <rbasak> Could just be a pointer to a preset userdata file supplied by the package.
[19:03] <rbasak> Has this started? I don't see the stream.
[19:05] <chilicuil> I don't see it neither, let's hope it hasn't started =)
[19:05] <arosales> just started
[19:05] <marcoceppi> rbasak: chilicuil just started
[19:06] <arosales> refresh should show
[19:06] <arosales> actually refresh once more.
[19:06] <rbasak> It seemed to take a couple of minutes after you said but got it now.
[19:32] <arosales> Any questions for Juju Core development here?
[19:32] <avoine> Question: Do you plan to make juju-core to be install on machine via the ubuntu archive instead of uploading tools?  i.e enable cross arch bootstrapping
[19:32] <arosales> avoine, ok, queued up next
[19:36] <avoine> ok, got it
[19:36] <avoine> thanks
[19:44] <arosales> avoine, thanks for the question
[19:47] <arosales> Any other questions?
[19:48] <jcastro> DAY ONE DONE!
[19:49] <avoine> lot of cool stuff coming!
[19:49] <gary_poster> :-) definitely