09:30:58 <BobBall> #startmeeting XenAPI
09:30:59 <openstack> Meeting started Wed May 25 09:30:58 2016 UTC and is due to finish in 60 minutes.  The chair is BobBall. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:31:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:31:03 <openstack> The meeting name has been set to 'xenapi'
09:31:13 <BobBall> Good morning / afternoon / evening all
09:31:21 <BobBall> johnthetubaguy: pingity ping :)
09:31:41 * johnthetubaguy is lurking with intent to read
09:31:50 <BobBall> Good intent
09:31:52 <jianghuaw> Good morning Bob&johnthetubaguy.
09:31:56 <BobBall> Well - we need you for the first bit johnthetubaguy :)
09:32:05 <BobBall> #topic Blueprints / Reviews
09:32:16 <BobBall> We're rapidly approaching non-priority blueprint freeze
09:32:31 <BobBall> The three blueprints in https://etherpad.openstack.org/p/newton-nova-priorities-tracking are still pending core reviewers
09:32:45 <BobBall> Sorry, four
09:32:48 <BobBall> https://review.openstack.org/#/c/280099/7 - XenAPI: support VGPU via passthrough PCI
09:32:51 <BobBall> https://review.openstack.org/#/c/277452/ - XenAPI independent hypervisor (fixing interaction layer between Nova + Hypervisor)
09:32:54 <BobBall> https://review.openstack.org/#/c/274045/5 - Xenapi: a new VDI store via streaming
09:32:57 <BobBall> https://review.openstack.org/#/c/304377/ - Xenerver compute driver support neutron security group
09:33:03 <BobBall> Let's go through them one at a time?
09:33:13 <BobBall> johnthetubaguy: Any further thoughts on https://review.openstack.org/#/c/280099 ?
09:33:13 <huanxie> hi all
09:33:20 <BobBall> That's the VGPU spec
09:33:41 <BobBall> oh
09:33:42 <BobBall> haha
09:33:45 <johnthetubaguy> I just added a comment, I think we need to point to the code
09:33:48 <BobBall> Comment 1 minute ago :D
09:33:50 <johnthetubaguy> yeah
09:34:05 <BobBall> Oh - against sdagues comment?
09:34:10 <BobBall> Do you want the reference in the spec?
09:34:36 <johnthetubaguy> more just in the comments
09:34:45 <johnthetubaguy> we don't have any decent docs on this stuff
09:34:52 <BobBall> OK; jianghuaw can you add an update there?
09:34:53 <johnthetubaguy> so its hard to tell when the API is changing
09:35:06 <BobBall> Ah - Moshe Levi added the reference to the code
09:35:20 <johnthetubaguy> ah, I was just going to double check devref
09:35:27 <jianghuaw> I didn't get much reference on that.
09:35:30 <BobBall> clearly someone is watching the spec :)
09:35:50 <BobBall> Do you have any other comments johnthetubaguy? Or are you close to a +2? :)
09:35:56 <jianghuaw> But that's the way I know how pci pass-through can work.
09:36:42 <BobBall> jianghuaw: It's OK - the reference to the code has been added
09:37:11 <jianghuaw> ah, yes. I see it.
09:37:12 <jianghuaw> thanks.
09:37:36 <johnthetubaguy> not sure I am close to a +2 yet, just getting my head around it all really
09:38:00 <BobBall> fair enough - if we could request a re-review then that would be appreciated
09:38:01 <johnthetubaguy> so follow on question
09:38:08 <johnthetubaguy> "vgpu1:1"
09:38:14 <johnthetubaguy> what is the ":1" bit for?
09:38:24 <BobBall> It's the number of instances you are requesting
09:38:35 <BobBall> See the comment above https://github.com/openstack/nova/blob/master/nova/pci/request.py#L181-L185
09:38:35 <jianghuaw> yes.
09:38:46 <BobBall> The pci_passthrough:alias scope in flavor extra_specs
09:38:46 <BobBall> describes the flavor's pci requests, the key is
09:38:46 <BobBall> 'pci_passthrough:alias' and the value has format
09:38:46 <BobBall> 'alias_name_x:count, alias_name_y:count, ... '. The alias_name is
09:38:47 <BobBall> defined in 'pci_alias' configurations.
09:39:05 <johnthetubaguy> hmm, I se this bit now: https://github.com/openstack/nova/blob/master/nova/pci/request.py#L134
09:39:48 <BobBall> It's almost always going to be 1 (IMO it would have been better if the original PCI spec had said that if the :<count> was missing it would default to 1)
09:41:03 <johnthetubaguy> so the problem here, is we are modifying a bit of code that has few docs, and few folks who understand it, so it takes time to agree things, sadly
09:41:22 <johnthetubaguy> anyways, getting there
09:41:59 <BobBall> I just hope we can get there fast enough.  Just 1 week to no priority feature freeze
09:42:06 <BobBall> hence us pushing quite hard now :)
09:42:11 <johnthetubaguy> oh wait, the alternatives sections...
09:42:32 <johnthetubaguy> did we decide to only expose one type per host
09:42:45 <BobBall> Yes
09:42:55 <johnthetubaguy> we should cover the alternative, in that alternatives section
09:43:05 <johnthetubaguy> so we remember why we are not doing that
09:43:09 <BobBall> Good point
09:43:42 <jianghuaw> sure, I will update it.
09:43:48 <BobBall> Awesome
09:43:53 <BobBall> Let's move on to the next spec
09:43:59 <BobBall> https://review.openstack.org/#/c/277452/ - XenAPI independent hypervisor (fixing interaction layer between Nova + Hypervisor)
09:44:17 <BobBall> I've addressed your comments and removed the link to the new VDI store via streaming BP
09:44:41 <BobBall> So I think the next step is if you could re-review it and let me know what your thoughts are?
09:45:23 <johnthetubaguy> yeah, did you get my concerns on the functional tests
09:45:31 <johnthetubaguy> I just worry if we add more code branches
09:45:49 <johnthetubaguy> if its just checks about not being able to do certain things, then that doesn't feel as bad, for sure
09:46:16 <johnthetubaguy> I guess we will need to always stream config drive to the hypervisor?
09:46:25 <johnthetubaguy> to take that approach
09:46:28 <BobBall> I do understand the concerns, yes.  I hoped that my comments would reassure you :)
09:46:31 <BobBall> Yes
09:46:49 <BobBall> No reason not to.  It's a small enough drive to just create in-guest and then stream to the hypervisor in a 'supported' way
09:47:07 <BobBall> Wrong use of ''s there... Supported + potentially isolated way
09:47:07 <BobBall> :)
09:47:26 <johnthetubaguy> yeah, thats all fine
09:48:01 <johnthetubaguy> oh, one thing comes to mind about partition_utils
09:48:08 <johnthetubaguy> do you know what the load will be on Dom0?
09:48:17 <BobBall> It should be very low
09:48:45 <BobBall> We're not planning to do anything big in there iirc?
09:49:01 <johnthetubaguy> I thought we created ext3 filesystems
09:49:05 <BobBall> do you know the load of resizing the partition in domU?
09:49:11 <johnthetubaguy> for ephemeral disks
09:49:26 <BobBall> Yeah - but that's quite quick even for large disks
09:49:32 <johnthetubaguy> I got the impression the load isn't minimal
09:49:44 <johnthetubaguy> ext4 would be quick, but ext3 has to do a lot more work, I believe
09:50:02 <johnthetubaguy> I had forgot about that until now
09:50:14 <BobBall> What level of 'load' do you think would be concerning?
09:50:37 <johnthetubaguy> honestly, this is based more on my laptop fan getting excited when doing this inside a VM running XenServer
09:50:38 <BobBall> And what load are you thinking of? bytes written to disk? CPU load?
09:50:50 <johnthetubaguy> more CPU load, honestly
09:51:03 <johnthetubaguy> disk load will kinda be the same, I am guessing
09:51:26 <BobBall> They will both be the same; but in a different place (i.e. dom0 vs the scheduled domU)
09:51:30 <johnthetubaguy> I suspect I am overthinking it, its just something thats worth checking
09:51:42 <johnthetubaguy> right, but the compute node has throttled CPU, dom0 less so
09:52:06 <johnthetubaguy> it would be bad if other guests saw issues during a resize, etc
09:52:18 <BobBall> Well - while it does have access to it's CPUs, it still has Dom0 has a fixed number of them
09:52:31 <johnthetubaguy> well, thats the problem
09:52:40 <johnthetubaguy> the CPUs in Dom0 are needed to keep the guests responsive
09:52:46 <johnthetubaguy> not so for the compute node VM CPUs
09:53:02 <BobBall> Yes; so how many CPUs for how long would be worrying?
09:53:25 <BobBall> i.e. if it had the potential to use up to 100% of one CPU (single threaded task, obviously) for 30 seconds, would that be worrying?
09:53:36 <johnthetubaguy> yeah, that would be a worry
09:53:37 <BobBall> Clearly we can nice it if you like
09:53:50 <johnthetubaguy> nice is probably a good iea
09:53:54 <johnthetubaguy> idea
09:54:30 <johnthetubaguy> its more, I would like to know the rough impact, on a good size VM
09:54:36 <BobBall> OK; so I'll update the spec to say we will use nice to lower the priority of the intensive tasks such as mkfs.ext3
09:54:41 <johnthetubaguy> lets just double check if its terrible
09:54:48 <johnthetubaguy> yeah, that works
09:54:50 <BobBall> Good size = how much disk?
09:55:54 <johnthetubaguy> hmm, 200GB or something like that?
09:56:01 <BobBall> I will check.
09:56:07 <BobBall> OK, next spec.. :)
09:56:13 <BobBall> https://review.openstack.org/#/c/304377/ - Xenerver compute driver support neutron security group
09:56:18 <BobBall> Hopefully this is a very simple one :)
09:56:32 <BobBall> The nutshell is that we want to do the same thing as libvirt to get security groups working in Neutron
09:56:46 <BobBall> libvirt sets up a Linux Bridge that it can apply iptables rules to
09:56:51 <BobBall> and we want to do the same thing
09:56:55 <huanxie> yes, main part is creating linux bridge
09:57:21 <BobBall> It hasn't had a review yet, but if you remember this is the change that you reviewed a while ago and requested a simple spec to make it clear what we were doing
09:57:30 <johnthetubaguy> so the linux bridge is created inside the compute VM?
09:57:37 <BobBall> No - Dom0
09:57:39 <huanxie> No
09:57:43 <huanxie> yes, Dom0
09:57:49 <johnthetubaguy> so you are running both linux bridge and ovs in Dom0?
09:57:56 <huanxie> yes
09:58:08 <BobBall> yes; which is also what libvirt does (ovs+bridge)
09:58:55 <BobBall> *but* clearly we only want to add a linux bridge if security groups are applied and you're using the appropriate firewall driver
09:59:17 <BobBall> So if you don't select a firewall driver (or you use a different one, which I guess you do at RAX) then it doesn't affect you
09:59:47 <BobBall> But it is clearly critical to getting neutron support as it's the only way we can get security groups with the upstreamed drivers
09:59:52 <johnthetubaguy> so the spec doesn't mention about this being in a firewall driver
10:00:01 <johnthetubaguy> and that it needs to be configured
10:00:04 <johnthetubaguy> i.e. its optional
10:00:10 <huanxie> I will update that
10:00:37 <BobBall> Yes; we will make it clear; i.e. it will not affect Rackspace as I understand your deployment
10:01:06 <johnthetubaguy> thats not my main concern here, just trying to work out what the impact is
10:01:18 <BobBall> Understood
10:01:28 <BobBall> Finally https://review.openstack.org/#/c/274045/ - you said you would have a closer look at this spec :)
10:01:53 <johnthetubaguy> so just to be clear
10:02:01 <johnthetubaguy> Nova is doing the security groups, and not neutron?
10:02:16 <johnthetubaguy> or does Nova just put in place the bridge, that neutron detects and updates?
10:02:36 <huanxie> neutron will write security group rules
10:02:47 <huanxie> but the rules are applied on linux bridge
10:03:04 <BobBall> My understanding is that Neutron requires security groups to be enabled (e.g. some Neutron tempest tests depend on security groups)
10:03:21 <huanxie> And the linux bridge should be created during booting VM, so we mainly do the creating linux bridge work
10:03:51 <johnthetubaguy> yeah, its just some neutron things actually make nova add the rules
10:03:59 <BobBall> Yes
10:03:59 <johnthetubaguy> its a bit odd, so glad thats not the case here
10:04:38 <BobBall> Indeed; this is just 'standard' Nova; just a part that is expected to work :/
10:04:40 <huanxie> yes, neutron does most of the rules on the linux bridge, and nova create the linux bridge
10:05:46 <johnthetubaguy> OK, added comments on the spec, I think thats close
10:05:54 <huanxie> thanks a lot
10:06:07 <BobBall> So, finally https://review.openstack.org/#/c/274045/ - you said you would have a closer look at this spec :)
10:06:33 <johnthetubaguy> yeah, and another 20/30 of them, but its not happened
10:06:45 <BobBall> I can totally understand
10:07:20 <johnthetubaguy> I think my existing comments still stand
10:07:33 <johnthetubaguy> ah, wait, I am looking at the old version
10:07:58 <BobBall> :)
10:08:34 <johnthetubaguy> so testing is the issue here
10:08:40 <johnthetubaguy> if we start testing this by default
10:08:45 <johnthetubaguy> the old system will break
10:09:20 <johnthetubaguy> maybe we keep the neutron CI on the new one, and the old CI on the old one?
10:09:32 <BobBall> Yeah; can do
10:09:53 <BobBall> (Also, we could do the same for the isolated compute change)
10:10:27 <jianghuaw> But please note: the purpose is to make this new store as default.
10:10:33 <johnthetubaguy> yeah, I figured that one is harder, as it forces us towards multi-node
10:11:27 <johnthetubaguy> yeah, we should probably get the CI running, before we switch over the default
10:11:33 <BobBall> Isolated compute can be tested even if the compute is embedded - just set the flag
10:12:17 <johnthetubaguy> yeah, but you don't stop people "doing things they shouldn't", which is probably quite useful
10:12:17 <BobBall> I'm sure we can stop the host from attaching any disks to the guest; which is the main problem
10:12:28 <johnthetubaguy> yeah, that could work
10:12:53 <BobBall> OK.  Well, I think we've reached time.
10:13:11 <BobBall> So - is there anything else we should cover?
10:13:24 <jianghuaw> #link: https://review.openstack.org/#/c/242846/
10:13:34 <BobBall> We'll work on updating those specs by tomorrow
10:14:02 <BobBall> and then, johnthetubaguy, do you mind if I nag you again on Friday, given how close we are to non-priority feature freeze?
10:14:10 <huanxie> Hi, I hope this patchset can be reviewed again https://review.openstack.org/#/c/213112/
10:14:10 <johnthetubaguy> totally keep bugging me
10:14:28 <jianghuaw> John, if you have time could you help to re-review this patch set?
10:14:29 <jianghuaw> https://review.openstack.org/#/c/242846/
10:14:32 <BobBall> jianghuaw: Could we cover that bug next time?
10:14:44 <jianghuaw> sure.
10:14:46 <jianghuaw> thank.
10:14:51 <jianghuaw> thanks.
10:14:59 <BobBall> huanxie: Same; I think we should focus on BPs
10:15:09 <huanxie> sure, thanks
10:15:35 <BobBall> The deadline for non-priority blueprints is in 1 week's time, so if we can grab any of johnthetubaguy's time I'd personally rather it was looking at specs than those bug fixes - which we have more time for
10:15:58 <johnthetubaguy> yeah, specs should be the focus for the moment
10:16:02 <jianghuaw> Bob: Got it. Thanks.
10:16:15 <BobBall> OK - then let's close the meeting there.
10:16:19 <BobBall> Thanks for the feedback johnthetubaguy!
10:16:22 <BobBall> #endmeeting