15:00:39 <johnthetubaguy> #startmeeting XenAPI
15:00:40 <openstack> Meeting started Wed Sep 25 15:00:39 2013 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:43 <openstack> The meeting name has been set to 'xenapi'
15:00:44 <johnthetubaguy> hello all
15:00:50 <johnthetubaguy> hands up the for XenAPI meeting?
15:00:55 <BobBall> o/
15:01:51 <matel> hi
15:02:12 <BobBall> euanh is also here
15:02:26 <johnthetubaguy> #topic blueprints
15:02:47 <johnthetubaguy> hey, so any updates on drafting stuff for Icehouse, and filling out the XenAPI session, or other summit sessions?
15:03:13 <BobBall> nope - we've got a brainstorm tomorrow I hope (need to plan it) to see if we want to submit other summit session
15:03:19 <BobBall> or whether then xenapi stuff can fit in the xenapi session
15:03:31 <BobBall> I did say before that we needed to have a chat about the xenapi session
15:03:41 <BobBall> but I can't "fill it out" until there is an etherpad or something that I can contribute to
15:04:03 <johnthetubaguy> sure, I thought we said discuss it this week
15:04:04 <BobBall> and as for drafting stuff for icehouse, still focused on what needs to be done pre-summit ATM
15:04:09 <BobBall> fine by me :)
15:04:25 <matel> Let's start to throw in ideas.
15:04:31 <BobBall> although I'm not in the right mental state to remember the things I wanted to raise today!
15:04:35 <johnthetubaguy> https://etherpad.openstack.org/IcehouseXenAPIRoadmap
15:05:01 <matel> Let's re-visit the previous summit's roadmap first
15:05:44 <matel> compute driver events
15:06:06 <matel> https://blueprints.launchpad.net/nova/+spec/compute-driver-events
15:06:08 <johnthetubaguy> well, sounds like Bob wan't to do this next week
15:06:14 <BobBall> that's still something that we want to do
15:06:25 <BobBall> so hopefully we can get it done in icehouse
15:06:34 <matel> Okay, Let's put it there.
15:06:36 <BobBall> the problem is I can imagine it's lower priority than some of the other things we might be doing
15:06:49 <matel> Also I don't quite get its status from the blueprint.
15:07:51 <BobBall> that blueprint was the KVM version
15:07:56 <BobBall> we don't haev a XenAPI equivalent
15:08:12 <johnthetubaguy> we did have
15:08:16 <johnthetubaguy> but it got dropped
15:08:26 <BobBall> oh right
15:08:31 <BobBall> what's the link to that?
15:08:34 <matel> Okay, so that's one
15:08:37 <BobBall> so we can use that instead of the KVM blueprint as the ref?
15:08:43 <matel> https://blueprints.launchpad.net/nova/+spec/compute-driver-events
15:08:52 <johnthetubaguy> https://blueprints.launchpad.net/nova/+spec/xenapi-compute-driver-events
15:08:56 <matel> look at the dependency tree
15:09:08 <BobBall> duh - didn't scroll down, sorry.
15:09:11 <matel> Okay, we have one.
15:09:13 <BobBall> yup, so that should be on the roadmap
15:10:05 <matel> Who is editing the etherpad now?
15:10:09 <BobBall> me
15:10:31 <BobBall> I'm done though
15:10:33 <BobBall> for now
15:10:34 <matel> volume drivers
15:10:46 <BobBall> more details?
15:10:49 <matel> Should be an easy one.
15:10:57 <matel> A refactor mainly
15:11:10 <matel> So that you can plug in your volume driver to nova.
15:11:54 <BobBall> which volume driver?
15:12:00 <BobBall> maybe I'm being silly but I'm confused :)
15:12:21 <matel> The code that connects a volume to your hypervisor.
15:12:24 <johnthetubaguy> its the cinder stuff
15:12:28 <BobBall> yes
15:12:36 <johnthetubaguy> refactoring to match the libvirt code
15:12:45 <johnthetubaguy> so its easier to plug in additional stuff
15:12:50 <BobBall> a volume being provided by Cinder, using iSCSI? or are you talking about using a different XS SR?
15:13:15 <BobBall> perhaps it's the "additional stuff" that I'm not understanding :)
15:13:17 <matel> For example, say XS supports ceph
15:13:21 <johnthetubaguy> so whatever, you could lay a file SR over the top of some additional thing you attach, etc
15:13:23 <BobBall> ok
15:13:29 <matel> We would need a driver for that
15:13:41 <matel> In a nice separated class.
15:13:46 <johnthetubaguy> yup, ceph is the perfect example
15:13:51 <matel> you just drop it in, and off you go.
15:13:52 <BobBall> okies, understood
15:14:14 <BobBall> I guess that's medium priority for us
15:14:18 <matel> Okay, so that's something we want to do (this example is showing one usecase)
15:14:30 <matel> Okay, put medium to it for now.
15:14:32 <matel> next item.
15:14:43 <matel> gpu passthrough
15:14:55 <matel> https://blueprints.launchpad.net/nova/+spec/xenapi-gpu-passthrough
15:15:14 <johnthetubaguy> I think the priorities mean something different now
15:15:17 <BobBall> I'd say that's medium
15:15:21 <johnthetubaguy> russell will change those
15:15:25 <BobBall> sure
15:15:33 <BobBall> I'm talking about my/our priorities
15:15:36 <matel> I'd say, let's collect some random stuff for now.
15:15:37 <johnthetubaguy> we just need to communicate how important or not it is
15:15:38 <BobBall> as in Citrix
15:15:43 <johnthetubaguy> OK
15:15:46 <BobBall> as an input into the prioritsation of what we want to work on
15:15:54 <BobBall> OFC I expect RS to have their own priorities to feed into this
15:15:57 <johnthetubaguy> well did you want to do that, and come back with your list of ideas?
15:15:58 <matel> it's just a string.
15:16:11 <BobBall> which may influence what citrix implement etc
15:16:33 <johnthetubaguy> yep, I have a meeting on monday to chat about RS summit priorities
15:16:34 <BobBall> *confused*
15:16:37 <BobBall> great
15:16:58 <BobBall> I would very much love that to include input into the XenAPI roadmap
15:17:02 <matel> So, should we carry on with the gpu stuff?
15:17:02 <johnthetubaguy> Just thinking, better use of time, you can discuss at Citrix your prioirty list, then we can review it
15:17:07 <BobBall> yes
15:17:22 <BobBall> vGPU mate? or pci pass through?
15:17:35 <matel> https://blueprints.launchpad.net/nova/+spec/xenapi-gpu-passthrough
15:18:01 <johnthetubaguy> just to clarify, I see the XenAPI roadmap as what we agree at the summit, its not something we present as such
15:18:07 <BobBall> I think it's still very useful (although should be generic PCI pass through support on Xen) and only a little work
15:18:22 <BobBall> understood and agreed John - but I wanted to get lots down to discuss
15:18:31 <BobBall> perhaps the C priorities should be left out for now, yes
15:18:50 <johnthetubaguy> well, feel free to add some of those?
15:18:59 <BobBall> I'll add them to the etherpad yes
15:20:05 <johnthetubaguy> cool, so any more for blueprint / summit discussions?
15:20:22 <matel> Okay, so as John said, we should discuss these things at the summit, so let's collect ideas on etherpad.
15:20:23 <BobBall> do we want to go through the rest of the etherpad or just add actions to update it for next meeting?
15:20:38 <matel> Just an action.
15:20:56 <BobBall> ok
15:21:09 <matel> It doesn't make sense to discuss things now, and just present at the summit, as j said.
15:21:46 <matel> I guess we just need to make sure, we collect stuff on ether, and everyone understands what those things mean.
15:21:49 <BobBall> perhaps - but I'd rather not have surprises on either side too :)
15:22:57 <johnthetubaguy> Yeah
15:23:05 <johnthetubaguy> we can go through the list before the summit
15:23:16 <johnthetubaguy> but best to go through something that we have all contributed to in the mean time
15:23:19 <johnthetubaguy> if you see what I mean
15:23:51 <johnthetubaguy> #topic docs
15:23:57 <johnthetubaguy> so any updates on this stuff?
15:24:19 <matel> nope
15:24:25 <BobBall> we've hit a snag ... updates to docs are stalled ATM
15:24:25 <johnthetubaguy> OK
15:24:36 <johnthetubaguy> whys that?
15:25:19 <BobBall> technical problems that have sprung up with getting a reusable XVA
15:25:39 <johnthetubaguy> XVA of what? nova-compute VM?
15:25:42 <BobBall> which is an important Citrix goal for the summit
15:25:43 <BobBall> yup
15:26:03 <johnthetubaguy> whats up with it (can I remember how we may have fixed bits in olympus)
15:26:17 <BobBall> Mate's on the ball
15:26:21 <BobBall> it's a XS bug with networking
15:26:30 <johnthetubaguy> ah, fair enough
15:26:32 <BobBall> and the fact that we are passing the flat_network_bridge through as a kernel parameter
15:26:42 <BobBall> if you import an XVA it can screw up the networks
15:26:47 <matel> And I am working on to use hvc0 for stack.sh
15:26:59 <matel> So users can interact with the vm if needed.
15:27:02 <johnthetubaguy> OK, we used the pass the label rather than the names, which helped
15:27:16 <johnthetubaguy> but anyways, sounds good
15:27:26 <matel> Oh, does nova recognise labels as well?
15:27:27 <johnthetubaguy> anything to make getting starte easier
15:27:33 <johnthetubaguy> matel: yup
15:27:52 <matel> Ah, I didn't know that.
15:27:54 <johnthetubaguy> matel: we used that so you can create the xapi6 network, if you want, but just give it a standard name
15:28:20 <matel> xapi6 is a bridge name
15:28:27 <matel> not a networ name I guess.
15:28:36 <johnthetubaguy> yup, well, xapi-network names I was talking about
15:28:37 <matel> I will check the nova code.
15:28:46 <johnthetubaguy> sure, its in the vif drivers
15:29:10 <johnthetubaguy> looks up the network by bridge name and falls back to name-label, or something like that
15:29:13 <matel> So you say it could deal with something like "OpenStack VM Network"
15:29:28 <johnthetubaguy> I think so, but I don't remember adding spaces
15:29:41 <matel> Anyhow, it's a good tip.
15:29:52 <johnthetubaguy> #topic Bugs and QA
15:29:58 <johnthetubaguy> so, how is gating going?
15:30:41 <BobBall> eurgh... Giving up on xenserver-in-the-cloud for now.  Can't get an automatic way to install it in either RS or HP clouds which means it's not suitable for -infra
15:31:06 <BobBall> so the fallback is getting it working with xenserver-core
15:31:12 <BobBall> still with devstack in domu
15:31:32 <johnthetubaguy> OK
15:31:46 <johnthetubaguy> sounds like a good plan, in terms of ssh-ing into a box
15:32:00 <BobBall> very frustrating though
15:32:01 <johnthetubaguy> any major bugs people hitting
15:32:12 <BobBall> RS cloud has some missing things I need, HP cloud has other missing things
15:32:20 <BobBall> *shakes his head frustratingly*
15:32:28 <johnthetubaguy> yeah, no one really does hypervisors in the cloud yet
15:32:44 <johnthetubaguy> I would talk to us about adding an image for xenserver core
15:32:49 <BobBall> yup
15:32:50 <johnthetubaguy> it should be possible
15:32:51 <BobBall> that'd be great
15:32:57 <BobBall> well - just use centos
15:33:00 <BobBall> then we can install xs-c :)
15:33:04 <johnthetubaguy> exactly
15:33:05 <BobBall> I've got a funky script to do that
15:33:07 <BobBall> so that's fine for me
15:33:46 <johnthetubaguy> yeah, lets get an image sorted for that testing
15:34:03 <johnthetubaguy> also, let me know what region you need
15:34:32 <johnthetubaguy> any bugs people have?
15:34:48 <BobBall> I don't think so
15:35:04 <johnthetubaguy> having real issues running block base live-migration, will raise some launchpad bugs on that one, once we pin down the errors
15:35:08 <BobBall> johnthetubaguy: don't worry about the image - I'm doing initial testing based on CentOS 6.4 only, so that's what I'm spinning up in the RS cloud
15:35:20 <matel> full tempest is failing, but that's only because the good old iscsi issue.
15:35:34 <johnthetubaguy> joy
15:35:40 <matel> exactly
15:35:59 <johnthetubaguy> BobBall: OK, if you insist
15:36:43 <BobBall> I want us to skip the iscsi tests in full tempets when running XS
15:36:52 <BobBall> so we can prove the rest is working
15:36:57 <BobBall> and doesn't regress
15:37:11 <BobBall> we know why iscsi doesn't work - and it's not an OS bug
15:37:54 <johnthetubaguy> hmm, is that the kernel thing
15:38:16 <matel> johnthetubaguy: the refactors are still waiting for you: https://review.openstack.org/#/c/46056/ https://review.openstack.org/#/c/46057/
15:38:20 <BobBall> yes
15:38:31 <BobBall> well - actually not the kernel
15:38:46 <BobBall> the problem is because we're using netback/front and blkback/front for the same packets on the same machine
15:38:49 <BobBall> it's ugly
15:39:03 <BobBall> but it's not really an OS problem, or one you'd see in deployment
15:39:17 <BobBall> it only happens with devstack serving the iscsi volume from the same VM that is consuming it
15:39:24 <BobBall> (even for a short while)
15:39:27 <BobBall> -VM+host
15:40:03 <johnthetubaguy> oh I see
15:40:06 <johnthetubaguy> that makes sense
15:40:20 <johnthetubaguy> need the multi-machine tests to fix that
15:40:25 <johnthetubaguy> cool
15:40:28 <matel> bobball: https://github.com/openstack/nova/blob/master/nova/virt/xenapi/network_utils.py#L43
15:40:36 <BobBall> well, to be more realistic... or we need a workaround in Xen
15:40:39 <BobBall> which we're also working on
15:40:50 <BobBall> yay matel!
15:40:53 <BobBall> network name it is!
15:41:01 <johnthetubaguy> yup, its much easier that way!
15:41:29 <johnthetubaguy> cool, so
15:41:31 <matel> I will modify devstack, so we no longer depend on bridge names.
15:41:32 <BobBall> matel: but devstack should also fail earlier if we don't specify it... saves people from having a junk flat_network_bridge when it's not specified
15:41:34 <johnthetubaguy> #topic OpenDiscussion
15:41:49 <johnthetubaguy> devstack used to work with name_labels, I guess we lots that at some point
15:42:09 <BobBall> devstack will also work with name_labels I think
15:42:18 <matel> It works with labels.
15:42:36 <matel> cool stuff.
15:42:52 <matel> "OpenStack VM Network" -> osvmnet
15:43:07 <matel> "OpenStack Public Network" -> ospubnet
15:43:15 <johnthetubaguy> or "OpenStack_VM_Network"
15:43:31 <matel> is brctl happy with such long names?
15:43:39 <johnthetubaguy> it doesn't go there
15:43:43 <BobBall> why does brctl get involved?
15:43:49 <matel> nova-network.
15:44:04 <BobBall> *confused*
15:44:05 <johnthetubaguy> yeah, not sure it gets used there either
15:44:17 <BobBall> if we find the bridge then we're happy
15:44:18 <BobBall> ohhhhh
15:44:19 <BobBall> hmmmm
15:44:27 <BobBall> we might rely on the name matching
15:44:34 <BobBall> I think thjat's mate's point?
15:44:41 <johnthetubaguy> not really
15:44:49 <johnthetubaguy> nova-network will create the bridges on the fly
15:45:12 <johnthetubaguy> I can't remember quite where it gets those from now, it might be translated to xapi by that point
15:45:20 <matel> in domU u have a xapi1 bridge
15:45:33 <johnthetubaguy> yeah
15:45:46 <johnthetubaguy> but its that converted to a bridge name and saved int he db
15:45:54 <johnthetubaguy> or does the db get the name_lable
15:45:57 <matel> so it's replicating the same as it gets from /proc/cmdline
15:46:01 <matel> flat_network_bridge=xapi1
15:46:01 <johnthetubaguy> I guess its the name label
15:46:30 <johnthetubaguy> the code path isn't that simple I don't think, its the network entry in the db
15:46:32 <matel> brct show
15:46:42 <johnthetubaguy> which might be the same thing
15:46:45 <matel> brctl show
15:46:45 <matel> bridge name     bridge id               STP enabled     interfaces
15:46:45 <matel> xapi1           8000.8e3528b79d15       no              eth1
15:47:21 <johnthetubaguy> sure, I just not sure if it "name_lavbel_foo" will go to xapiN
15:48:19 <johnthetubaguy> Seems like the max length is 15
15:48:21 <matel> And I don't understand what you are saying.
15:48:24 <BobBall> perhaps it's easiest just to test it and see where it breaks :)
15:48:28 <johnthetubaguy> yeah
15:48:37 <johnthetubaguy> the config defines the look up in xapi
15:48:44 <johnthetubaguy> that goes into the DB in the network table
15:48:53 <johnthetubaguy> that is then read by nova-network when creating the bridge
15:49:01 <johnthetubaguy> can't remember if it gets changed en-route
15:49:04 <johnthetubaguy> probably not I guess
15:49:27 <johnthetubaguy> anyways, will leave that with you
15:49:32 <johnthetubaguy> anything more?
15:49:48 <matel> mysql> select bridge from networks;
15:49:48 <matel> +--------+
15:49:48 <matel> | bridge |
15:49:48 <matel> +--------+
15:49:48 <matel> | xapi1  |
15:49:49 <matel> +--------+
15:49:50 <matel> 1 row in set (0.00 sec)
15:49:58 <johnthetubaguy> yeah, thats the one
15:50:10 <johnthetubaguy> I would expect xapi1 to be there
15:50:22 <johnthetubaguy> the question is, if you have its name_label in the config
15:50:28 <johnthetubaguy> do you still get xapi one in the DB
15:50:28 <matel> yes
15:50:36 <johnthetubaguy> probably not, but its worth checking
15:50:53 <johnthetubaguy> there is always the description field
15:51:02 <matel> Okay so, the question is: db_entry = lookup_bridge_name(something)
15:51:11 <johnthetubaguy> yeah
15:51:17 <matel> Okay, will check it.
15:51:22 <johnthetubaguy> I guess not
15:51:25 <johnthetubaguy> I would just test it
15:51:37 <matel> Probably not.
15:51:53 <matel> Sure, just kicking off a build after the meeting.
15:51:59 <johnthetubaguy> sweet
15:52:10 <johnthetubaguy> we all done now?
15:53:03 <johnthetubaguy> … tumble weed goes past
15:53:13 <johnthetubaguy> #endmeeting