15:00:13 <johnthetubaguy> #startmeeting XenAPI
15:00:14 <openstack> Meeting started Wed May 29 15:00:13 2013 UTC.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:17 <openstack> The meeting name has been set to 'xenapi'
15:00:24 <johnthetubaguy> hi
15:00:30 <johnthetubaguy> hands up for the XenAPI meeting?
15:01:22 <BobBall> o/
15:01:58 <BobBall> and matelakat too :)
15:01:58 <matelakat> hi
15:02:12 <johnthetubaguy> cool, hello
15:02:35 <johnthetubaguy> #topic actions from last meeting
15:02:44 <johnthetubaguy> matelakat: how did that documenting go?
15:03:12 <matelakat> As I said, it is a low priority, haven't even touched it.
15:03:24 <BobBall> *grin*
15:03:31 <johnthetubaguy> OK, lets leave that off the actions for next week, its got boring
15:03:37 <matelakat> focusing on quantum, and saying hello to smokestack
15:03:43 <johnthetubaguy> #topic blueprints
15:03:55 <johnthetubaguy> so I have made progress with xenapi-server-log
15:04:09 <johnthetubaguy> assuming someone configures the logging correctly
15:04:13 <johnthetubaguy> I can now read the logs
15:04:20 <BobBall> you mean with the xenstore key?
15:04:34 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/xenapi-server-log
15:04:42 <johnthetubaguy> well, its needs more than the xenstore key, but yes
15:05:06 <johnthetubaguy> #link https://review.openstack.org/#/c/30301/
15:05:28 <BobBall> Ah - this was WIP
15:05:29 <johnthetubaguy> got a few other bits till its finished, but the core proof of concept seems OK
15:05:31 <BobBall> is it still WIP?
15:05:42 <BobBall> or are you raedy for someone to look at it?
15:05:42 <johnthetubaguy> nope, its up for review
15:05:46 <BobBall> okay cool
15:05:51 <BobBall> I'll have a butchers :)
15:05:54 <johnthetubaguy> cool
15:06:13 <johnthetubaguy> its not that sophisticated, but its a step forward
15:06:22 <johnthetubaguy> I think we need to worry about deleting old logs too
15:06:41 <johnthetubaguy> that probably shouldn't be the job of logrotate, but I can't quite decide
15:06:57 <johnthetubaguy> anyhow, its baby steps forward
15:07:02 <BobBall> sounds good to me
15:07:26 <johnthetubaguy> so, next one I wanted to touch on was devstack refactor
15:07:35 <johnthetubaguy> #link https://blueprints.launchpad.net/devstack/+spec/xenapi-devstack-cleanup
15:07:40 <johnthetubaguy> matelakat: how is that going?
15:08:10 <matelakat> At the moment a quantum patch is waiting, after that, I would like to push the network cleanup.
15:08:20 <matelakat> We could discuss what we want in that.
15:08:33 <matelakat> remove internal xapi interface
15:08:41 <matelakat> sensible defaults
15:08:42 <johnthetubaguy> yes, I had some people talking about that inside rax
15:09:00 <matelakat> Oh, is someone using that if?
15:09:04 <johnthetubaguy> so, remove that guest install network thing, yes please
15:09:20 <matelakat> guest install network?
15:09:30 <johnthetubaguy> that internal xapi interface
15:09:32 <matelakat> I am not sure if we are speaking about the same stuff.
15:09:35 <johnthetubaguy> it has many names
15:09:52 <johnthetubaguy> current eth0 on bridge xapi
15:09:57 <matelakat> Another job would be to modify how the vm is built.
15:10:13 <johnthetubaguy> lets just get the network decided I think
15:10:16 <johnthetubaguy> first
15:10:18 <matelakat> y
15:10:24 <johnthetubaguy> so default config, what you thinking?
15:10:25 <matelakat> But that will be another change.
15:10:41 <matelakat> Default config - let's talk about that
15:10:52 <johnthetubaguy> I recon something like eth0 = management, eth1 = data, eth2 = public
15:10:58 <johnthetubaguy> that is the domU
15:11:01 <matelakat> Let's look at the doc.
15:11:08 <johnthetubaguy> doc?
15:11:22 <matelakat> my goal is to align devstack with the official docs
15:11:26 <matelakat> you know, the diagram.
15:11:43 <johnthetubaguy> we probably need to change that now though
15:11:50 <BobBall> IOW make devstack as close to what we'd recommend people deploying
15:11:52 <johnthetubaguy> anyways, let me find a link
15:11:59 <matelakat> #link http://docs.openstack.org/grizzly/openstack-compute/install/apt/content/introduction-to-xen.html#xenapi-deployment-architecture
15:12:10 <johnthetubaguy> BobBall: yes, but it needs to be simple no change for devs
15:12:12 <matelakat> what is IOW Bob?
15:12:31 <johnthetubaguy> matelakat: cool that looks good
15:12:44 <johnthetubaguy> I think managment network should be dhcp (i.e. home router)
15:12:49 <matelakat> yes.
15:12:59 <johnthetubaguy> then the tenant and public can default to host local private networks?
15:13:01 <BobBall> IOW = in other words
15:13:23 <johnthetubaguy> obviously you could create VLANS, etc, if you wish to do multi box setup
15:13:41 <johnthetubaguy> does that sound like what you were thinking?
15:13:50 <matelakat> I would leave it as an exercise for the user.
15:14:19 <matelakat> I meant the VLAN and the physical game.
15:14:21 <johnthetubaguy> erm, would be good to create the default host local networks auto-magically though?
15:14:22 <BobBall> I agree - don't add complexity to devstack... we can get it to install on whateverthehostisrunning
15:14:29 <BobBall> host-local sure, yes
15:14:30 <johnthetubaguy> ah right, absolutaly, no VLAN creation
15:14:48 <matelakat> The change that has been accepted is already doing this host local stuff.
15:15:01 <johnthetubaguy> the other Ubuntu installer stuff, that should probably default to eth0 dhcp to match the above
15:15:14 <matelakat> y
15:15:15 <johnthetubaguy> then autodetect the management ip address on eth0
15:15:21 <matelakat> y
15:15:38 <johnthetubaguy> I would just assume a default install of XS I guess (plus XD optimisations / EXT SR)
15:15:51 <matelakat> As documented.
15:15:53 <BobBall> idd
15:15:54 <johnthetubaguy> sounds like we agree on the network defaults?
15:16:13 <matelakat> Static IP could be another job.
15:16:32 <johnthetubaguy> what you mean? make it work with a static IP?
15:16:33 <matelakat> for now, let's assume dhcp on MGT network.
15:16:41 <johnthetubaguy> +1 for dhcp for now
15:16:44 <matelakat> yes, make it work without DHCP
15:17:02 <matelakat> Okay, so that's an agreement.
15:17:12 <johnthetubaguy> yeah, lets ignore that for now, we need to worry about proxies too in the complex case
15:17:13 <matelakat> Although the quantum case would need another diagram.
15:17:22 <johnthetubaguy> yes, that is worth doing
15:17:38 <johnthetubaguy> #action: need new doc diagram for quantum setup
15:17:50 <johnthetubaguy> matelakat: you mentioned ubuntu install changes?
15:18:20 <matelakat> I would like to see the snapshotted VM not connected to any networks.
15:18:36 <matelakat> Other than that: always update boot parameters
15:18:42 <johnthetubaguy> in what sense? for the install?
15:18:45 <matelakat> I meant kernel parameters.
15:19:08 <matelakat> At the moment, we are creating a VM with 4 interfaces, and preseed that VM
15:19:14 <matelakat> And than snap it.
15:19:16 <johnthetubaguy> OFFLINE=true gets close to that in localrc in the domU I think, for refresh
15:19:32 <matelakat> OFFLINE=true????
15:19:34 <johnthetubaguy> ah, hang on, not sure I get what you mean
15:19:52 <johnthetubaguy> OFFLINE=true stops the git pulls and apt-get updates, etc
15:19:53 <BobBall> I've not seen that one before :P
15:19:58 <BobBall> ahhh
15:20:16 <matelakat> create a VM with one interface, preseed it -> remove the interface from the VM -> snap it
15:20:56 <matelakat> Goal: You can change the network configuration without cleaning up the templates.
15:21:07 <matelakat> Makes sense?
15:21:09 <johnthetubaguy> ah, yes, good point
15:21:19 <BobBall> very much to me too
15:21:23 <matelakat> Okay.
15:21:28 <johnthetubaguy> that would really help the retry loop
15:21:32 <matelakat> I am not sure, if it is all one change.
15:21:43 <matelakat> We'll see how big it is.
15:21:59 <johnthetubaguy> I lost intrested half way through adding those snapshots after getting the test times down to something I could bare
15:22:18 <johnthetubaguy> cool, so that sounds like pleanty
15:22:32 <johnthetubaguy> and that should leave us in a good place for Havana I guess?
15:22:42 <matelakat> Now, file some actions please, I like to see the bot doing its job.
15:22:57 <johnthetubaguy> lol, probably best to update the blueprint though?
15:23:02 <matelakat> sure.
15:23:30 <matelakat> Let me check my trello board.
15:23:47 <matelakat> Oh, separate volume for cinder in devstack
15:23:59 <johnthetubaguy> I just updated the BP
15:24:03 <johnthetubaguy> #link √
15:24:05 <matelakat> Okay.
15:24:07 <johnthetubaguy> oops
15:24:12 <johnthetubaguy> #link https://blueprints.launchpad.net/devstack/+spec/xenapi-devstack-cleanup
15:24:30 <matelakat> So, one more thing that I have is: separate vhd for cinder volumes
15:24:33 <johnthetubaguy> Work items:
15:24:33 <johnthetubaguy> Get rid of VLAN configuration: DONE
15:24:33 <johnthetubaguy> Add proxy settings for Ubuntu install: DONE
15:24:33 <johnthetubaguy> Better network defaults: TODO
15:24:33 <johnthetubaguy> Reconfigure networking without Ubuntu VM re-install: TODO
15:24:34 <johnthetubaguy> Separate Hypervisor setup: TODO
15:24:56 <johnthetubaguy> matelakat: sure, but is that critical?
15:25:24 <matelakat> I would like to see that, because with the loopback device, you get kernel lockups.
15:25:38 <johnthetubaguy> ah, yes, that old fella
15:25:41 <matelakat> Which is not really a good experiment.
15:25:55 <matelakat> s/experiment/experience/g
15:26:25 <johnthetubaguy> cool
15:26:30 <johnthetubaguy> so lets move on to Quantum
15:26:34 <matelakat> Okay, move.
15:26:36 <johnthetubaguy> I saw L2 got into master
15:26:42 <johnthetubaguy> hows DHCP?
15:26:46 <matelakat> That's really good thing.
15:26:55 <johnthetubaguy> :)
15:27:00 <matelakat> We have issues with Quantum with oslo.config
15:27:19 <matelakat> That was a separate issue changing [OVS] -> [ovs]
15:27:36 <johnthetubaguy> oh, thats not specific to XenAPI, but yes
15:27:45 <matelakat> So that was sort of blocking me
15:28:04 <matelakat> Apart from that, a ci job is here:
15:28:20 <matelakat> #link https://github.com/citrix-openstack/qa/blob/master/xenserver-quantum-devstack.sh
15:28:37 <BobBall> Also blocked by a stupid commit I made :)
15:28:50 <matelakat> I didn't say that.
15:29:01 <BobBall> oh
15:29:03 <BobBall> but you thought it! :D
15:29:18 <matelakat> Bob's change just highlighted some other issues, but he likes to be punished by himself.
15:29:26 <johnthetubaguy> lol
15:29:39 <BobBall> Just to fill John in on the details...
15:29:40 <johnthetubaguy> OK, so you got DHCP working?
15:29:52 <matelakat> define "working"
15:30:05 <johnthetubaguy> instances get IP addresses from DHCP?
15:30:10 <matelakat> y
15:30:19 <johnthetubaguy> cool, whats broken?
15:30:31 <BobBall> devstack had some libvirt specific variables which were used in common code - I removed the libvirt specific variables and apparently committed it without testing it (although I know I tested something!) - so the upshot is that devstack is currently broken for XenServer and all non-libvirt hypervisors
15:30:43 <johnthetubaguy> oops
15:30:51 <matelakat> #link https://review.openstack.org/30703
15:30:58 <johnthetubaguy> I will not update my repo today then...
15:31:19 <matelakat> Update it.
15:32:04 <johnthetubaguy> so, I hear OVS plugin is getting deprecated
15:32:20 <johnthetubaguy> do we know what the plan is getting XCP working with the new one?
15:32:29 <matelakat> Which is the new one?
15:32:45 <matelakat> I need some details.
15:33:00 <matelakat> Was it on the ML ?
15:33:14 <johnthetubaguy> it was hinted to on the ML
15:33:19 <johnthetubaguy> let me check
15:33:38 <matelakat> I wouldn't care about the future plans.
15:33:41 <johnthetubaguy> its called ML2
15:33:44 <matelakat> At the moment.
15:34:03 <matelakat> ML2 is my second revision - It's not even born.
15:34:12 <johnthetubaguy> "However - do you have any idea about how this kind of feature will play with ML2 and deprecation of OVS plugin?"
15:34:23 <johnthetubaguy> was in a thread on VXLAN
15:34:56 <matelakat> Ah, how good is that. So that's why quantum folks accepted the L2 patch.
15:35:00 <matelakat> :-)
15:35:11 <johnthetubaguy> https://blueprints.launchpad.net/quantum/+spec/modular-l2
15:35:16 <BobBall> haha
15:36:04 <matelakat> Let's keep an eye on it.
15:36:08 <matelakat> Thanks John.
15:36:25 <matelakat> I need some time to parse that change.
15:36:35 <johnthetubaguy> well seems like its the new thing, I would ask salvatore
15:37:18 <johnthetubaguy> it may require almost zero changes
15:37:19 <johnthetubaguy> anyways
15:37:40 <johnthetubaguy> #topic Docs
15:37:47 <johnthetubaguy> any updated for Xen Doc Day yesterday?
15:37:51 <johnthetubaguy> nothing from me
15:38:11 <BobBall> not from me either
15:38:16 <matelakat> #link https://review.openstack.org/#/c/20105/9/quantum/plugins/ml2/README: It currently works with the existing openvswitch, linuxbridge, and hyperv L2
15:38:18 <BobBall> but what would you hope we could do for the xen doc day?
15:38:29 <matelakat> .. agents
15:38:44 <matelakat> So this ML2 seems to be higher up in the hierarchy.
15:38:46 <BobBall> so ML2 is on top of OVS?
15:38:52 <johnthetubaguy> ah, I keep meaning to join in that effort and work on XS OS docs
15:39:09 <johnthetubaguy> I think ML2 is the new things to configure OVS rather than the current OVS plugin
15:39:27 <matelakat> Okay, so as long as Agent stays, we don't care.
15:40:17 <johnthetubaguy> hopefully
15:41:20 <johnthetubaguy> #topic Bugs and QA
15:41:37 <matelakat> pass
15:41:58 <BobBall> So the biggest one is the devstack bug
15:42:25 <matelakat> Ah QA
15:42:48 <matelakat> I am trying to reproduce the Smoke things
15:42:56 <matelakat> And I am at around 80%
15:43:18 <matelakat> namely here: #link https://github.com/dprince/firestack/blob/master/example_xen.bash#L71
15:43:36 <matelakat> Who's gonna pick up the devstack one?
15:44:00 <BobBall> which devstack one?
15:44:03 <BobBall> the one that I introduced?
15:44:06 <matelakat> I would like to get quantum and smoke done this week.
15:44:25 <matelakat> Yes, let's call it Bob-Bug-2013/00000001
15:44:37 <BobBall> Wow - that's kind.  suggesting that it's the first bug.
15:44:40 <matelakat> So that we have enough digits for the year.
15:45:01 <BobBall> My issue with me looking at it is the next few days are likely to be busy
15:45:14 <BobBall> but I can say I'll take it
15:45:19 <BobBall> I'll see what I can do tomorrow
15:45:40 <matelakat> We can try to do some pair programming
15:46:18 <BobBall> Sure - although I might fix it tomorrow morning before you get in the office ;)
15:46:34 <johnthetubaguy> well, that sounds good
15:46:37 <matelakat> suggests Bob-Bug-2013/00000002
15:46:45 <johnthetubaguy> how is smokestack then?
15:47:46 <matelakat> Let's say environment setup phase.
15:48:22 <matelakat> learning - from my side.
15:48:44 <matelakat> All we need is to be able to fix any issues in puppet manifests at the moment.
15:49:09 <matelakat> And I would say we are not really far from being able to do that (hack -> test) cycle.
15:49:25 <matelakat> As I said, I would like to get it done this week.
15:49:39 <matelakat> Any other Q?
15:50:48 <BobBall> nope
15:51:18 <BobBall> are we done with the meeting now?
15:51:40 <matelakat> John has disappeared.
15:51:45 <matelakat> What a chairman!
15:51:54 <BobBall> and now we can't stop the meeting
15:52:00 <matelakat> Oh Bob
15:52:12 <BobBall> that means we have to keep going until John is back
15:52:16 <matelakat> It seems, that we have to stay here till the end of the time.
15:52:18 <johnthetubaguy> he is here
15:52:19 <johnthetubaguy> sorry
15:52:23 <matelakat> Oh.
15:52:36 <johnthetubaguy> one more thing
15:52:43 <johnthetubaguy> #topic open discussion
15:52:44 <matelakat> Good old SJ.
15:53:01 <johnthetubaguy> anything around diskimage-builder?
15:53:05 <johnthetubaguy> anyone looking at that
15:53:13 <matelakat> Not really.
15:53:14 <BobBall> fraid not
15:53:16 <johnthetubaguy> I noticed it was going for incubation / oslo inclusion
15:53:18 <johnthetubaguy> OK
15:53:28 <johnthetubaguy> I guess it doesn't do our style VHD
15:53:48 <matelakat> What is the exact use-case for that?
15:54:06 <zhiyan> hi, folks, how about https://etherpad.openstack.org/linked-template-image , any thoughts?
15:54:12 <BobBall> I've gotta run - sorry guys - was expecting us to be done by now! Mate, will be back on later if you want to email me.
15:54:47 <johnthetubaguy> matelakat: not sure
15:54:50 <zhiyan> DuncanT: around?
15:55:09 <matelakat> zhiyan, is it about XenAPI?
15:55:53 <johnthetubaguy> ok, so we are done with XenAPI I guess
15:55:57 <zhiyan> matelakat: no, just about cinder requirement/dependency: Attaching a volume to a host
15:56:00 <matelakat> johnthetubaguy: Is it some debootstrap thingie?
15:56:03 <johnthetubaguy> sorry got distracted at the end
15:56:07 <johnthetubaguy> matelakat: yep
15:56:18 <johnthetubaguy> I think its about bootstrapping OpenStack
15:56:23 <DuncanT> zhiyan: Give it 5 minutes, we aren't due to start yet!
15:56:25 <johnthetubaguy> so building images, and everything
15:56:29 <matelakat> zhiyan: I guess cinder meeting is the next, within few minutes.
15:56:38 <johnthetubaguy> yup, we almost done here
15:56:44 <johnthetubaguy> matelatat: any thing else?
15:56:45 <zhiyan> DuncanT: oh, sorry, :)
15:56:53 <matelakat> Okay, let's give the room to the cinder folks.
15:56:55 <johnthetubaguy> #endmeeting