09:28:41 <jianghuaw> #startmeeting XenAPI
09:28:42 <openstack> Meeting started Wed Mar 30 09:28:41 2016 UTC and is due to finish in 60 minutes.  The chair is jianghuaw. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:28:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:28:45 <openstack> The meeting name has been set to 'xenapi'
09:28:58 <jianghuaw> Morning all.
09:29:06 <huanxie> Hello johnthetubaguy and jianghuaw
09:29:32 <jianghuaw> Hello Huan.
09:29:45 <johnthetubaguy> hello
09:29:55 <jianghuaw> morning johnthetubaguy
09:30:07 <johnthetubaguy> good afternoon to you both (I think?)
09:30:13 <jianghuaw> Bob is on vocation. So I'm hosting this meeting today.
09:30:24 <jianghuaw> yes. thanks.
09:30:28 <huanxie> yes, thanks johnthetubaguy
09:30:54 <jianghuaw> JohnHua is on vacation also. I think we can start now.
09:30:56 <jianghuaw> #topic Blueprints
09:31:12 <jianghuaw> #link: https://blueprints.launchpad.net/nova/+spec/bare-vhd-image
09:31:32 <jianghuaw> this BP is from JohnHua.
09:32:05 <jianghuaw> I think we agreed that it's a spec-less BP in last meeting.
09:32:46 <johnthetubaguy> yes, I think that makes sense
09:33:07 <johnthetubaguy> is the idea to support gzipping the VHD as well? or just raw VHD at first?
09:33:23 <jianghuaw> Per johnthetubaguy's comment, more information was needed in the BP. I think JohnHua has added some details in it.
09:33:42 <jianghuaw> raw VHD.
09:33:53 <johnthetubaguy> OK, that seems like a good place to start
09:34:05 <johnthetubaguy> thanks for the extra info in there, that looks better
09:34:34 <jianghuaw> great.
09:34:34 <johnthetubaguy> so there is one problem, current Nova is not allowing any new blueprints, we are focusing on stuff that was already approved last cycle
09:35:26 <huanxie> Do you mean Mitaka @johnthetubaguy?
09:35:47 <johnthetubaguy> yeah, things from mitaka, and before
09:35:48 <jianghuaw> I think we are targeting to Newton.
09:36:13 <johnthetubaguy> yes, basically we are not allowing things into Newton, unless they were approved during mitaka or before
09:36:19 <johnthetubaguy> at least until the summit
09:36:33 <johnthetubaguy> the idea is at the design summit we will work out a way to get the new things approved
09:36:56 <johnthetubaguy> basically the process is going to be changing a little bit
09:36:56 <huanxie> Got it, thanks
09:37:17 <jianghuaw> ok. So we need wait until to the summit.
09:37:48 <johnthetubaguy> having said that, you are doing all the right things here, its good to agree as a sub team on the details of the new things, so once we start adding new things to Newton, we should be ready to go very quickly
09:38:17 <jianghuaw> fair enough.
09:38:42 <jianghuaw> the next BP:
09:38:43 <jianghuaw> #link: https://review.openstack.org/#/c/280099/
09:39:11 <jianghuaw> my BP for: fake VGPU devices to SR-IOV PCI, so that we can enable VGPU on XenServer via pass-through PCI
09:39:54 <jianghuaw> johnthetubaguy: it will be great if you can have a look and give some input.
09:40:35 <jianghuaw> It's to fake the vgpu resources as SR-IOV.
09:41:00 <johnthetubaguy> yeah, I should read that, it sounds like it was matching the approve libvirt was taking
09:41:12 <johnthetubaguy> now sure how it maps to the stuff hyper-v are doing
09:41:17 <johnthetubaguy> s/now/not/
09:42:28 <jianghuaw> all right. We hope this spec can go into Newton.
09:43:30 <jianghuaw> my another BP:
09:43:33 <jianghuaw> #link: https://review.openstack.org/#/c/274045/
09:43:48 <jianghuaw> this BP is for: Introduce a new VDI store to upload and download images using streaming through the Compute node.
09:44:32 <johnthetubaguy> I remember bobball talking about that one
09:45:47 <johnthetubaguy> I think you might want to include about how that streaming method avoids problems with VHD chains growing too long when taking a snapshot
09:46:49 <johnthetubaguy> anyways, need a review, but the general approach seems good
09:48:06 <jianghuaw> I think the snapshot is done in xapi. And it's only one vhd file expose to Nova.
09:48:34 <johnthetubaguy> yes, the new method looks good
09:48:53 <johnthetubaguy> the old method has issues with the chain growing quite long, in certain cases
09:49:34 <jianghuaw> glad to see another benefit added by this new method:-)
09:50:02 <jianghuaw> I'm done with my BPs.
09:50:14 <jianghuaw> Huan: do you have any BP?
09:50:34 <huanxie> I have a spec less BP for supporting neutron security group #link https://blueprints.launchpad.net/nova/+spec/xenserver-give-support-on-neutron-security-group
09:51:38 <huanxie> @johnthetubaguy, hope you can have a look about whether the decription in the BP is enough and also want this can be approved in newton
09:51:50 <jianghuaw> johnthetubaguy: could you help confirm if we can keep this BP as spec-less?
09:52:28 <johnthetubaguy> honestly, I suspect we will want a spec for that, as its quite complicated how that actually works
09:53:14 <johnthetubaguy> its more to make sure, in a few years time, we recorded why we took this particular approach
09:53:24 <jianghuaw> johnthetubaguy: hmm, it's complicated but follows the existing mechanism in libvirt.
09:54:13 <johnthetubaguy> qbrxxx bit seems different though
09:54:25 <huanxie> @johnthetubaguy, long time ago when we discussing this, we seems agreed on a spec-less BP, but if it's needed, I can add a spec
09:54:53 <johnthetubaguy> yeah, it just seems more complicated than I remember
09:55:05 <johnthetubaguy> other folks may disagree with me on the need for a spec though
09:55:16 <johnthetubaguy> it doesn't need to be a long spec
09:55:21 <johnthetubaguy> the shorter the spec, the better, really
09:55:30 <johnthetubaguy> thats a general statement
09:55:43 <huanxie> got it, then I will add one
09:55:59 <johnthetubaguy> huanxie: does this only work with linux bridge, or does it work with ovs?
09:56:04 <huanxie> Then need I point out all the bridges and ports that we plan to add?
09:56:24 <johnthetubaguy> yes, ideally it should say what the system will look like
09:57:13 <huanxie> johnthetubaguy, we only tested on ovs bridge, so for linux bridge, need to tested, and now I cannot confirm whether it works well with linux bridge
09:58:50 <jianghuaw> OVS is the default on xenserver.
09:59:19 <johnthetubaguy> so the bp was talking about bridges, so I assumed it was linux bridge, which seemed odd given OVS is the default
09:59:55 <johnthetubaguy> it makes sense to only do this for OVS, I just worry about talking about it in terms of the bridge compatibility mode, it seems a little strange somehow
10:00:03 <johnthetubaguy> but lets cover that in the spec
10:00:10 <johnthetubaguy> its probably clearer in context
10:00:17 <jianghuaw> at here, linux bridge is added between the VIF OVS and integration ovs.
10:00:37 <jianghuaw> as linux bridge is needed for iptable.
10:01:28 <jianghuaw> So vif by default uses ovs, but this method will add a Linux bridge in the chain. Huan, is it right?
10:01:46 <johnthetubaguy> oh... so its using both
10:02:12 <johnthetubaguy> hmm, yeah, this needs a spec to make these details obvious
10:02:17 <huanxie> johnthetubaguy: yes, we should use both linux bridge and ovs
10:02:40 <johnthetubaguy> it seems very surprising to use both, so its good to describe why
10:02:43 <huanxie> Linux bridge is targeted for iptables rules
10:03:12 <johnthetubaguy> so neutron can generate rules of ovs, so it seems odd we don't use OVS for both bits, but I guess there is a good reason why, I just don't see it
10:03:48 <johnthetubaguy> I do wonder how much of the detail needs to be known by Nova, its possible this might end up in os-vif, but lets get a spec written out, then see where we go from there
10:03:53 <huanxie> Current OVS is not compatiable with iptables, so linux bridge and ovs bridge all need
10:04:38 <huanxie> Neutron will add iptables rule at the linux bridge side for security group, so linux bridge is added in this BP
10:05:25 <jianghuaw> the latest OVS may support iptables already, but presently the ovs running on XS dom0 can't support that.
10:06:08 <huanxie> Linux bridge qbr and tap device are all used for neutron, but it should be added when booting an instance
10:06:36 <johnthetubaguy> as I understand it, we don't need to use iptables
10:06:40 <johnthetubaguy> we can use ovs rules directly
10:06:58 <johnthetubaguy> if you use neutrons OVS drivers to do all the rule configurations
10:07:00 <huanxie> OVS rules currently are only used for L2
10:07:29 <johnthetubaguy> hmm, so how does neutron do this? does it add a linux bridge and configure things via IPtables?
10:07:36 <huanxie> for now we will also use ovs flow rules, to do the tag and untag job
10:08:26 <huanxie> when we add security group rules, such as ssh, then neutron will add iptables rules at the tap device
10:09:12 <johnthetubaguy> hmm, so I don't really understand how this works for libvirt I guess, I would need to understand that better before I can review this plan
10:09:23 <johnthetubaguy> anyways, I have a feeling we are out of time?
10:09:47 <huanxie> yes, sorry for forgetting the time
10:10:32 <huanxie> Maybe in my spec, I add some link for clarify why linux bridge are needed at neutron side?
10:11:08 <johnthetubaguy> huanxie: sounds good to include that in the spec
10:11:24 <huanxie> sure, will add that part
10:11:33 <jianghuaw> Ok. we've done for the BPs. thanks.
10:11:50 <jianghuaw> sorry for out of time.
10:12:15 <jianghuaw> may have a quick sync-up on the bugs fix.
10:12:19 <jianghuaw> #topic Bugs & QA
10:12:30 <jianghuaw> #link: https://review.openstack.org/#/c/242846/
10:12:39 <johnthetubaguy> we merged the nasty bug for RC1
10:13:14 <jianghuaw> johnthetubaguy: this is a long fix.
10:13:21 <jianghuaw> It's for: Add an interim OVS bridge to fix the port configure issue. And the neutron security group feature depends on this patch set also.)
10:13:33 <johnthetubaguy> so we need to get the important spec and code patches added into the new etherpad: https://etherpad.openstack.org/p/newton-nova-priorities-tracking
10:13:39 <johnthetubaguy> under the xenapi subteam section
10:13:52 <jianghuaw> yes, has added it.
10:13:54 <johnthetubaguy> once you have had other folks in the subteam give you a +1 that is
10:14:00 <johnthetubaguy> it looks empty right now
10:14:36 <huanxie> johnthetubaguy: sorry that it's empty now
10:14:54 <johnthetubaguy> it was cleaned out last week sometime, to get rid of the stale stuff
10:15:07 <jianghuaw> Sorry, I remember that I added that this morning.
10:15:17 <johnthetubaguy> so its a new link for this release
10:15:28 <johnthetubaguy> thats the newton one, not the mitaka one
10:15:33 <jianghuaw> Anyway, we will add those ready ones.
10:15:43 <jianghuaw> ok. got it.
10:15:55 <jianghuaw> I must added into the wrong page.
10:16:18 <jianghuaw> we will do that soon. Thanks.
10:16:40 <jianghuaw> Anything else?
10:16:59 <huanxie> no for me
10:17:32 <jianghuaw> I think we've done.
10:17:34 <jianghuaw> thanks all.
10:17:37 <jianghuaw> #endmeeting