[14:01] <smoser> hey all.
[14:01] <smoser> we're waiting on roaksoax to join fishbowl
[14:01] <smoser> then... should be starting very shortly.
[14:03] <med_> good morning
[14:04] <Daviey> hey
[14:05] <lynxman> med_: morning o/
[14:05] <chiluk_> will there be a first-boot concept?
[14:05] <med_> chiluk_, you should be skiing.
[14:05] <chiluk_> I should be.
[14:06] <med_> Lot's of TODOs in the BP still.
[14:06] <smoser> https://help.ubuntu.com/community/CloudInit
[14:07] <smoser> there are lots of blueprint items, yes.
[14:07] <roadmr> question, I remember the server install images moved to using a squashfs rather than a pool of .deb packages, this sped them up considerably. So here we're looking at something even faster?
[14:07] <chiluk_> thanks for the wiki link smoser
[14:07] <med_> so thin install plus the cloud-init package to "customise" the thin install
[14:08] <Daviey> roadmr: yes, rather than using squasfs.. talking of re-using cloud images, so dd like experience
[14:08] <roadmr> I see, thanks
[14:09]  * med_ nods his head furiously and realizes he's off camera
[14:10] <jtaylor> are you using eatmydata to speed up dpkg?
[14:12] <shirgall> A reminder, if someone watches the session later they can't see the questions, so it may help to summarize the question concisely for the recording.
[14:12] <jtaylor> in my experience force-unsfae-io is not as good as eatmydata
[14:13] <smoser> shirgall, thanks.
[14:13] <Daviey> shirgall: i think we are trying to do that.. if we are not, please shout.
[14:13] <jtaylor> its been a while since i compared though
[14:14] <med_> Yes how do we test.
[14:14] <med_> ROAKSOAX
[14:14] <roaksoax> o/
[14:14] <Daviey> rock socks?
[14:14] <rbasak> smoser: you pronounced smoser wrong :-P
[14:14] <med_> is there any hardware limitations on target hosts?
[14:15] <med_> which maas do we need to use?
[14:15] <med_> did MAAS get SRUd into Precise?
[14:15] <Daviey> med_: do you want to join the inner circle?
[14:15] <Daviey> (or anyone else?)
[14:15] <roaksoax> med_: no.. waiting on an upstream bug fix before oing so
[14:16] <med_> ARM
[14:16] <med_> :)
[14:17] <med_> PPA works.
[14:17] <med_> :)
[14:17] <med_> How can we help?
[14:19] <med_> Daviey, Do you mean something like juju deploy ubuntu, destroy-service ubuntu; juju deploy something else
[14:20] <rbasak> sfdisk or gsfdisk input format?
[14:21] <Daviey> i've never used gsfdisk
[14:21] <Daviey> is it compatible ?
[14:21] <rbasak> No, it's different. gsfdisk for GPT
[14:21] <rbasak> fstab format for filesystems
[14:21] <rbasak> We have a standard way of referring to partitions on a disk :)
[14:22] <rbasak> I use sfdisk format a lot by hand
[14:22] <rbasak> But I may not be normal
[14:22] <rbasak> It's concise
[14:22] <smoser> echo "1,1" | sfidisk /dev/sda
[14:22] <med_> that formats the whole disk as 1 ptn?
[14:23]  * med_ will try that in a VM.
[14:23] <rbasak> Yes but you can miss most stuff out and it'll do a sensible default
[14:23] <rbasak> Eg. fill to avaiable space
[14:23] <med_> on /dev/scotsssda
[14:23] <Daviey> oh neat
[14:24] <rbasak> We will need to think a little bit about GPT
[14:24] <Daviey> rbasak: want to join the hangout?
[14:24] <rbasak> This is just an aside, right?
[14:25] <med_> Isn't GPT required for some archs.
[14:25] <med_> (IA64 used to require it as it was EFI based.)
[14:25] <med_> well, still does, but is kind of irrelevant.
[14:27] <med_> smoser, are you using ACTUAL hardware or VMs to devel/test?
[14:29] <med_> thanks.
[14:29] <med_> Daviey, can you elaborate?
[14:30] <med_> or smoser is
[14:31] <med_> we'll have more info next UDS on poking/playing?
[14:32] <roadmr> thanks!
[14:32] <shirgall> Thanks!
[14:46] <psusi> shoot, did I miss the meeting?
[14:47] <Daviey> psusi: sadly.
[14:48] <psusi> smoser: I wanted to pipe up on this to ask if anyone had considered rather than coming up with an alternate installer, workign to fix d-i so it isn't so slow?  I worked up some patches recently to make debootstrap much faster
[14:50] <smoser> psusi, oh? thats neat.
[14:51] <smoser> and clearly a more general solution.
[14:52] <smoser> i tink that having a filesystem ready and easily written to a filesystem though is still nice.  and just about guaranteed to be faster than dpkg.
[14:52] <psusi> ideally I'd like dpkg to be at least say, 80% as fast as that, preferably 90%+
[14:53] <psusi> it seems to me that it is slowness is due to a lot of fsyncs that aren't needed especially on first install, so I patched debootstrap to pull in and activate libeatmydata to defeat that junk and it made it MUCH faster
[14:54] <psusi> like 5x faster or something iirc
[14:55] <smoser> psusi, that is very interesting.  i konw that the installer uses unsafe-io
[14:55] <smoser> but didn't realize that eatmydata was *that* much faster.
[14:55] <psusi> yea, that does very little
[14:56] <psusi> it only gets rid of something like 10% of the syncs
[14:56] <smoser> any way you look at it, installation of packages and execution of pre/post installs cripts is going to be slower though.
[14:56] <smoser> than tar, which is just writing to disk.
[14:57] <smoser> but that is solved/addressed by the squashfs images to some extent.
[14:57] <smoser> tanks psusi we should move out of this channel though.
[14:57] <smoser> :)
[14:57] <psusi> aye ;)
[14:59] <Daviey> jamespage: are you joining us?
[14:59] <Daviey> anyone else want to be in the inner circle?
[15:01] <med_> Grrrrr
[15:01] <Daviey> Starting shortly.
[15:02] <smoser> HIT RELOAD NOW!
[15:02] <nordm> Is the stream up n running?
[15:03] <med_> http://www.youtube.com/watch?v=ZqV6PW4e_90&feature=player_embedded
[15:03] <med_> live
[15:03] <med_> nice housefull
[15:03] <med_> zul?
[15:06] <med_> no longer
[15:06] <med_> only cinder
[15:08] <ivoks> i guess we could test that
[15:08] <ivoks> updates
[15:10] <med_> Any other new packages/services? OSLO? Ceilometer? etc
[15:10] <med_> Heat?
[15:14] <hlh> OATs?
[15:14] <med_> How do rolling releases impact OpenStack?
[15:15] <Daviey> med_: for cloud archive, they don't :)
[15:16] <nordm> MIR?
[15:16] <jamespage> Main Include Request
[15:16] <jamespage> Inclusion rather
[15:16] <nordm> thx
[15:17] <med_> RCs make sense.
[15:20] <med_> I guess "rolling releases" was really a question for the OpenStack Havana session we haven't yet scheduled in this UDS.
[15:22] <med_> so no testing, no recommendation... etc.
[15:22] <med_> so unknown but possible>?
[15:22] <med_> ^ w/r/t ZeroMQ
[15:23] <Daviey> yes
[15:24] <med_> Haven't looked
[15:24] <med_> has webops looked?
[15:24] <med_> wedgwood, ^
[15:24] <med_> at NRPE plugin
[15:24] <med_> (for Grizzly)
[15:24] <dweaver> Landscape API integrates with Nagios
[15:26] <dweaver> http://blog.landscape.canonical.com/2012/09/13/landscape-with-nagios/
[15:27] <Daviey> dweaver: thanks, looks useful
[15:28] <Daviey> dweaver: we should talk to landscape about this
[15:29] <hlh> is OATs a candidate for MIR?
[15:30] <dweaver> Daviey, We use it in our demo lab to demonstrate to customers management of an openstack deployment, works pretty well.  Federico would be the one to talk to.
[15:30] <yolanda_> hi, i don't have any sound or mike sorry
[15:31] <Daviey> hlh: not sure how much value MIR adds to it?
[15:32] <roaksoax>  /win 13
[15:32] <jamespage> hlh: OAT  open attestation?
[15:32] <hlh> Open Attestation
[15:32] <zul> oats?
[15:35] <med_> hlh is US.
[15:35] <med_> erm, Canonical.
[15:35] <jamespage> med_, so I understand
[15:35] <hlh> sure, for now :)
[15:35] <jamespage> sorry hlh :-)
[15:35] <hlh> I'm good for now
[15:37] <hlh> thank you
[16:00] <Daviey> starting shortly
[16:01] <Daviey> rbasak: are you joining this?
[16:01] <rbasak> Sure
[16:01] <Daviey> Machine readable cloud image data
[16:02] <med_> not live yet
[16:03] <smoser> HIT RELOAD NOW
[16:03] <med_> not live yet
[16:03] <smoser> well, NOW
[16:03] <med_> http://www.youtube.com/watch?v=w1rsjo2WmyM&feature=player_embedded
[16:03] <med_> live
[16:05] <smoser> collection format:  http://cloud-images.ubuntu.com/eightprotons/
[16:05] <Daviey> Who do we have in the audience ?
[16:06] <med_> \o/
[16:06] <med_> easy
[16:06] <med_> easy to share
[16:06] <med_> daviey set focus on his screen so focus doesn't follow voice
[16:06] <med_> it keeps jumping to others
[16:07] <Daviey> is that ok?
[16:07] <med_> yeppers
[16:07] <med_> and very readable.
[16:08] <med_> can someone dump that URL in here?
[16:09] <med_> if it is publicly reachable
[16:10] <smoser> http://cloud-images.ubuntu.com/eightprotons/images/streams/v1/
[16:10] <med_> thanks
[16:11] <niemeyer> +1 for json
[16:12] <niemeyer> yaml is interesting when human readability is key
[16:12] <niemeyer> For a case like this, data availability sounds like the key.. the simplicity of json wins
[16:12] <niemeyer> (and ubiquity)
[16:12] <smoser> http://cloud-images.ubuntu.com/eightprotons/cloud/
[16:15] <med_> Will this be provided for all public clouds? Does this work (this generalization) for other public clouds?
[16:16] <med_> so Juju providers will embed this knowledge?
[16:16] <med_> or something in the juju ecosystem will?
[16:19] <med_> yep, image_id/something else
[16:21] <med_> (didn't mean to derail meeting)
[16:22] <niemeyer> I have step out, but I will watch the whole video later
[16:22] <niemeyer> smoser: One last point.. it doesn't feel like splitting up per arch is necessary
[16:23] <niemeyer> smoser: I'd take one depth level out of that directory structure, and merge amd64 and i386.js into a single file
[16:23] <rbasak> niemeyer: not sure I follow?
[16:23] <med_> me either. How can you drop an arch?
[16:23] <rbasak> niemeyer: ok, so a data format thing, rather than the information presented?
[16:23] <niemeyer> smoser: and have lucid.js instead
[16:23] <niemeyer> rbasak: Right
[16:24] <niemeyer> That cuts the round trips by half, and simplifies slightly the model, without any major impact I believe
[16:25] <rbasak> Yes - after all instance store and ebs are separate too.
[16:25] <rbasak> But we're tying them together
[16:25] <niemeyer> There are several axis,as rbasak points out
[16:25] <rbasak> I think the core data format allows flexibility here, right?
[16:25] <Daviey> Considering code names were technically only supposed to be used during development, it should probbaly be 10.04.js
[16:26] <rbasak> Daviey: so what about raring?
[16:26] <med_> arm64 arch
[16:26] <rbasak> It would need to change on release
[16:26] <Daviey> rbasak: Good question !
[16:26] <niemeyer> smoser: I don't think I get it.. there are several axis there
[16:26] <niemeyer> smoser: i386/amd64.. ebs/instance..
[16:28] <niemeyer> Sure, but that doesn't justify the fact they can't be together.. people have to cherry-pick the right item inside that file anyway
[16:29] <med_> I thought the idea was that you'd get the latest/freshest/right item by default....
[16:31] <niemeyer> It's kind of the opposite of what would be an issue.. the *common* axis are out of the data format.. these are the axis that *can* be in the format because they are standardized across providers.
[16:31] <Daviey> med_ / niemeyer: Wnat to join the fishbowl?
[16:31] <niemeyer> Daviey: I can't, I really have to step out.. :(
[16:31] <Daviey> :(
[16:31] <niemeyer> But I'll watch out the full video
[16:31] <niemeyer> s/out//
[16:31] <Daviey> niemeyer: Shame, sounds like you have some good points.
[16:31] <niemeyer> and provide feedback
[16:32] <niemeyer> Ultimately, each provider could be an independent file..
[16:32] <niemeyer> aws.js
[16:32] <niemeyer> etc
[16:33] <rbasak> niemeyer: yes - and the format allows us to break it down by provider, AIUI
[16:33] <niemeyer> With less field duplication inside the format itself
[16:33] <niemeyer> This reduces the burden when using that data
[16:33] <niemeyer> (for an app developer)
[16:33] <niemeyer> I'll organize those thoughts and provide a suggestion
[16:34] <rbasak> niemeyer: thanks! Appreciate your input.
[16:34]  * niemeyer steps aside
[16:35] <rbasak> smoser: also MAAS for ephemeral images?
[16:35] <rbasak> And d-i netinst images perhaps?
[16:35] <rbasak> Or is that out of scope?
[16:41] <rbasak> Didn't want to interrupt :)
[16:41] <med_> too polite...
[16:41]  * med_ lost his entire train of thought while joining.
[16:42] <med_> short train though, one car.
[16:42] <Daviey> rbasak: sorry. :)
[16:48] <med_> Jump in if you have questions--we'll proxy them...
[16:53] <med_> lightning talks are next so probably no reason to curtail discussion here unless folks are presenting there
[16:53] <med_> some of us have other conflicts though
[16:54] <med_> utlemming, patches are welcome.... :^)
[16:57] <med_> so is IQN akin to a UUID?
[16:57] <med_> GUID?
[16:57] <med_> smoser, ^
[16:57] <med_> okay
[16:57] <utlemming> I have to run to the next meeting
[16:57] <med_> ditto.
[17:03] <Daviey> med_: erm, sort of
[17:03] <med_> nod. he said "stream" just as I typed that in real time.
[18:17] <smoser> 10..9..8...
[18:17] <smoser> starting in
[18:17] <smoser> 3.
[18:17] <smoser> 2.
[18:17] <smoser> 1
[18:17] <smoser> RELOAD NOW!
[18:18] <jamespage> o/
[18:18] <smoser> technical difficulties
[18:18] <jcastro> \o
[18:18] <smoser> please stand by
[18:18] <jamespage> smooootthhh!
[18:18]  * jcastro slow claps
[18:18] <roaksoax> argh sorry my computer with video crashed
[18:18] <smoser> this is a test of your emergency broadcasting system.
[18:19] <dweaver> Meanwhile here's some music.......
[18:19] <smoser> <jeopardy themesong plays>
[18:25] <Daviey> anyone else want to join the inner circle?
[18:25] <jamespage> Daviey, not for this one ta
[18:31] <marrusl-uds> When do we think the SRU will go through?
[18:33] <dweaver> +1 on timescales for the SRU? ^^^
[18:35] <marrusl-uds> \o/
[18:36] <dweaver> Of course!
[18:36] <dweaver> I'll be deploying it to the SE Demo Lab.
[18:36] <marrusl-uds> would love to!
[18:40] <smoser> https://code.launchpad.net/~virtual-maasers/charms/precise/virtual-maas/trunk
[18:40] <jcastro> Daviey: yeah I would like to get clarification on exactly how many machines it needs
[18:40] <jamespage> hey smoser!
[18:41] <jamespage> want me to join now?
[18:41] <Daviey> jamespage: sure
[18:41] <Daviey> and anyone else?
[18:41] <Daviey> jcastro: ?
[18:41] <jcastro> Daviey: nm, he's answering my question
[18:41] <nuclearbob> awesome, I'd use that
[18:41] <jcastro> with virtual maas I don't really care anymore, heh
[18:42] <jcastro> smoser: when would you guys consider the virtual maas charms to be ready to use by people like me?
[18:42] <nxvl> forget about "trying it" that's great for "development" environment where i want to test that before i decided to deploy
[18:42] <nxvl> or to play with some configurations
[18:42] <Daviey> jcastro: "like you" .. much longer than everyone else. :)
[18:42] <jcastro> well played sir
[18:43] <Daviey> >:)
[18:43] <dweaver> Agreeed. Standalone makes a lot more sense than a charm.
[18:43] <nxvl> How many TL does the server team has?
[18:43] <Daviey> 18
[18:44] <nxvl> awesome!
[18:44] <roaksoax> smoser: you are the hot standby?
[18:44] <rbasak> HA tech leads!
[18:44] <nxvl> smoser: sure, you are stealing the credits!
[18:44] <zul> everyone is tl in their own special way
[18:44] <jcastro> nxvl: one more and they can RAID5
[18:45] <nxvl> zul: ok, i won't even comment on that one...
[18:45] <Daviey> nxvl: The server team used to have one tech lead, but when he moved.. he had to be replaced by two people.. as the original one was of that calibre
[18:45] <nxvl> Daviey: who was he?
[18:46] <rbasak> "Ubuntu Server Technical Lead" or "Technical Lead, Ubuntu Server Team"? "People's Front of Judea" or the "Judean People's Front"?
[18:46] <jcastro> Daviey: I don't suppose you know the status of the maas provider for juju offhand?
[18:46] <smoser> :)
[18:48] <jcastro> roaksoax: that answers my question, thanks.
[18:49] <jcastro> \o/
[18:49] <marrusl-uds> thanks!
[19:01] <Daviey> Anyone else want to be in the inner circle?
[19:05] <jamespage> refresh in 10
[19:05] <jamespage> 9
[19:05] <jamespage> 8
[19:05] <jamespage> 7
[19:05] <jamespage> 6
[19:05] <jamespage> 5
[19:05] <jamespage> 4
[19:05] <jamespage> 3
[19:05] <jamespage> 2
[19:05] <jamespage> 1
[19:05] <jamespage> ....
[19:05] <jamespage> refresh!
[19:06] <arosales> up and working
[19:06] <jamespage> ping me if you want attention in the inner circle
[19:14] <arosales> adam_g: along the lines of Go Juju can you update on your plans for testing there?
[19:14] <jamespage> arosales, nothing until maas provider exists?
[19:15] <arosales> jamespage: ah, that makes perfect sense
[19:15] <dweaver> Are there any plans to add VNC support for connecting to instances from horizon to the openstack deployment charms?
[19:15] <Daviey> dweaver: isn't that working now?
[19:16] <melmoth> works
[19:16] <melmoth> (foslom and essex)
[19:16] <Daviey> (if it's not, it's a bug.. not lacking support)
[19:16] <adam_g> arosales, i did a quick test of keystone, mysql + a few core services on EC2 using go juju, seemed to work fine
[19:17] <melmoth> i meant, it s working, but there s no charm for it.
[19:17] <Daviey> melmoth / dweaver: wanna join the inner circle, to explain?
[19:18] <melmoth> url ?
[19:18] <dweaver> Daviey, not on my deployments on essex, but I have yet to try Folsom yet.
[19:19] <arosales> adam_g: good to hear
[19:20] <arosales> re go-juju testing on ec2
[19:20] <Daviey> zul: come baaaaaaack
[19:20] <Daviey> arosales: wanna join?
[19:20] <arosales> Daviey: nah. Just had that quick go-juju question.
[19:21] <zul> sorry press the wrong button
[19:21] <dweaver> Daviey, url?
[19:21] <arosales> jamespage: is it a party since it s the last session?
[19:21] <Daviey> dweaver: pm
[19:27] <smoser> if performance of shell is an issue, should you just skip python and write charms in go?
[19:35] <adam_g> melmoth, lp:juju-deployer
[19:43] <melmoth> ok
[19:53] <arosales> thanks!
[20:17] <danwest> when is the requirement for a dedicated juju node for the juju maas provider going away?
[20:19] <danwest> yup, running/installing it outside the charm