13:03:21 <alexpilotti> #startmeeting hyper-v
13:03:21 <itxaka> o/
13:03:22 <openstack> Meeting started Wed Dec  9 13:03:21 2015 UTC and is due to finish in 60 minutes.  The chair is alexpilotti. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:25 <openstack> The meeting name has been set to 'hyper_v'
13:03:40 <alexpilotti> morning folks
13:03:43 <claudiub> o/
13:03:44 <sagar_nikam> Hi Everybody
13:03:49 <lpetrut> Hi
13:03:53 <abalutoiu> Hello
13:03:58 <Sonu> Hello everyone
13:04:28 <atuvenie> o/
13:04:40 <kvinod> hi
13:04:59 <alexpilotti> sagar_nikam: anybody that we are waiting on the HP side?
13:05:17 <sagar_nikam> no, everybody is present
13:05:21 <sagar_nikam> we can start
13:05:47 <alexpilotti> cool, primeministerp is a bit late, everybody else is here
13:05:53 <alexpilotti> so
13:06:00 <alexpilotti> #topic mitaka patches
13:06:42 <alexpilotti> #link https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
13:06:45 <alexpilotti> based on ^
13:07:05 <alexpilotti> the current 3 top patches are
13:07:08 <alexpilotti> #link https://review.openstack.org/#/c/237593/
13:07:16 <alexpilotti> #link https://review.openstack.org/#/c/175479/
13:07:24 <alexpilotti> #link https://review.openstack.org/#/c/246298/
13:07:49 <alexpilotti> sagar_nikam: you asked me about OVS, the 3rd one is one of them
13:08:29 <sagar_nikam> this one ? https://review.openstack.org/#/c/246298/
13:08:33 <alexpilotti> got a review yesterday from Nithin, which works with us on the OVS Hyper-V driver community
13:08:40 <sagar_nikam> that's not networking
13:08:55 <Sonu> https://review.openstack.org/#/c/140045/
13:09:10 <alexpilotti> #link https://review.openstack.org/#/c/179727/
13:09:14 <alexpilotti> this one
13:09:43 <alexpilotti> my bad, I copied the next 3 patches :)
13:09:44 <sagar_nikam> yes
13:09:50 <sagar_nikam> that is the correct one
13:10:04 <alexpilotti> so, again, the 3 patches are:
13:10:15 <alexpilotti> #link https://review.openstack.org/#/c/237593/
13:10:21 <sagar_nikam> sonu: this is of higher priority, can you give details
13:10:23 <alexpilotti> #link https://review.openstack.org/#/c/184038/
13:10:36 <alexpilotti> #link https://review.openstack.org/#/c/179727/
13:11:09 <Sonu> networking related is only #link https://review.openstack.org/#/c/179727/
13:11:22 <Sonu> what about https://review.openstack.org/#/c/140045/
13:11:26 <alexpilotti> this is a priority for us too. Since this code is not in the driver, either we get it in Nova or we need to cherry-pick it in a fork
13:12:03 <alexpilotti> so the whole OVS thing is something we want to get in ASAP, based on Nova's review bandwidth
13:12:09 <Sonu> Sagar for us to consume, we need it in Nova.
13:12:42 <atuvenie_> I can add some details about the patch that snonu is refering to
13:12:47 <alexpilotti> Sonu: those are the 3 top patches, there's only one for OVS, as stated above
13:12:48 <sagar_nikam> Sonu: fine, got it
13:13:12 <alexpilotti> atuvenie_: please go ahead
13:13:32 <atuvenie_> so, it's work in progress. It doesn't account for live migration
13:13:43 <atuvenie_> by the end of the day there is going to be a new patchset
13:14:06 <atuvenie_> it's tested on compute-hyperv and I will cherry pick it and test it on nova as well
13:14:16 <alexpilotti> atuvenie_: there was some refactoring from Kilo / Liberty related to Live migration if I well recall
13:15:14 <alexpilotti> sagar_nikam Sonu: anything you'd like to add on this patch?
13:15:31 <Sonu> where will HP consume the content of this patch from?
13:15:36 <sagar_nikam> yes, when is live migration support planned
13:15:40 <Sonu> from openstack/nova or compute-hyperv
13:16:34 <sagar_nikam> sonu: if it does not get merged in nova, we cherry-pick the patch in review
13:16:42 <Sonu> fine
13:17:10 <alexpilotti> Sonu: we dont get your comment in the review
13:17:11 <sagar_nikam> alexpilotti:my question on live migration
13:17:27 <alexpilotti> sagar_nikam: atuvenie_ said she's uploading a new patch
13:17:29 <Sonu> regarding live migration, if we apply OVS flow rules in br-int bridge, will live migration work as expected
13:17:49 <sagar_nikam> ok, that supports live migration. got it
13:17:54 <alexpilotti> Sonu: of course
13:18:11 <alexpilotti> Sonu: I saw you left a -1 on the patch, but all you have is a question
13:18:26 <Sonu> nope
13:18:27 <alexpilotti> Sonu: in general, if you have questions please leave a neutral comment.
13:18:37 <Sonu> I have given code comment
13:19:15 <alexpilotti> atuvenie_: did you see Sonu's comment?
13:19:58 <alexpilotti> Sonu: I totally dont get what you mean
13:20:08 <atuvenie_> yes, I don't think the cache should be moved but investigating options before answering
13:20:12 <alexpilotti> with "Not a good idea to put the caching requirement on client. If the implementation demands a single instance, it must be handled in this function."
13:20:44 <alexpilotti> this is a cache of classes implementing the behaviours by vif type
13:20:53 <Sonu> vif driver instance need not be maintained in cache in vmops.
13:21:24 <alexpilotti> could you explain why not? :)
13:21:50 <Sonu> _get_vif_driver() is a form of factory methiod
13:22:06 <alexpilotti> this just to avoid loading the same class over and over all the time
13:22:11 <Sonu> and a factory method generally defines when to create a new instance etc.
13:22:27 <alexpilotti> not necessarily
13:22:35 <Sonu> calling a factory method can still return a single instance, provided factory caches it.
13:22:39 <alexpilotti> those drivers are stateless
13:23:06 <alexpilotti> there's no reason to create new instances all the time
13:23:41 <alexpilotti> said that, it's a relatively minor performance improvement
13:23:45 <alexpilotti> there's a comment:
13:23:49 <alexpilotti> # with instantiated classes will cause tests to fail on
13:23:56 <alexpilotti> # non windows platforms
13:25:06 <Sonu> Please do comment on my review comment, and I shall take appropriate action.
13:25:08 <atuvenie_> my main reason for not moving the cache would be that for live migration I have to call the driver post_start method. That would imply importing the vif which would mean I have to copies of the cache
13:25:13 <alexpilotti> hmm looks like adelina dropped off, waiting for her to join back
13:26:08 <atuvenie_> I'm back. comment above
13:26:33 <Sonu> hmm please do put the same comment in the review, I shall take a look at it.
13:26:39 <atuvenie_> ok
13:26:51 <sagar_nikam> alexpilloti:on the earlier question by Sonu: OVS Flow on br-int, will it work in cluster driver as well,
13:26:56 <alexpilotti> Sonu: did you ever run this code?
13:27:13 <Sonu> I am running OVS and Hyper-V with VLAN and security group enabled
13:27:42 <alexpilotti> sagar_nikam: we already said that whatever we do in this area will support the current and planned features sets
13:27:49 <sagar_nikam> basically we are trying to check how it works with live migration triggered by Nova as well as triggered by failover cluster manager
13:27:53 <alexpilotti> this includes live migration and clusters of course
13:27:58 <sagar_nikam> o, good
13:28:00 <sagar_nikam> ok
13:28:07 <Sonu> thats great. I will try that and let you know.
13:28:28 <sagar_nikam> Sonu:you had a question of security groups
13:28:38 <sagar_nikam> is that answered ?
13:28:43 <alexpilotti> Sonu sagar_nikam: you saw that we are rebasing the cluster BP patches?
13:29:07 <Sonu> yes. br-int will host all the security group rules for Hyper-V using ovs firewall driver
13:29:10 <sagar_nikam> alexpilotti: we added review comments on it yesterday
13:29:44 <Sonu> and as per alexpilotti live migration will migrate these rules as well as it was the case with native HV Vswtich
13:29:55 <alexpilotti> Sonu: what ovs firewall driver? the conntrack based one?
13:30:13 <Sonu> live migration will be done by the Failover Cluster Manager.
13:30:13 <sagar_nikam> you mean liver migration triggered by failover cluster ?
13:30:23 <sagar_nikam> will also migrate these rules
13:31:11 <Sonu> For ESX based solution, we have OVS firewall driver with connection tracking using learn flows. We are evaluating the driver with OVS hyper-V
13:31:50 <alexpilotti> Sonu: you might want to wait for conntrack to be implemented in Hyper-V for this :)
13:32:35 <sagar_nikam> alexpilotti:this is the patch we reviewed and gave some comments https://review.openstack.org/#/c/199037/
13:33:13 <sagar_nikam> dont yet see any rebase of it,
13:33:41 <sagar_nikam> were you refering to some other patch, when you mentioned cluster patch is rebased
13:34:27 * alexpilotti checking
13:35:07 <alexpilotti> you colleague put a -1 asking questions
13:35:54 <alexpilotti> as a general rule, if you dont want to add further delays on reviews, it's better to put neutral reviews when you dont understandhow things work :)
13:36:30 <alexpilotti> is snraju taking part of the meeting by any chance?
13:36:38 <sagar_nikam> no, i think what he meant was how will DB update work and also if the glance image gets downloaded to CVS and concurrent downloads happen on 2 hosts in a cluster for same image, things will nto work
13:37:02 <claudiub_> i'm going to answer the comments today. as for the rebase, the cluster utils will have to be submitted to os-win
13:37:17 <claudiub_> sagar_nikam: yeah, it won't be a problem
13:37:33 <sagar_nikam> claudiub_: thanks
13:37:53 <sagar_nikam> also any plans of supporting multiple CSVs ?
13:37:53 <claudiub_> sagar_nikam: there is a lock for the image path, so the same image won't be downloaded twice
13:37:58 <alexpilotti> sagar_nikam: CSV itself, being a shared resource, is not handled properly by Nova ATM
13:38:05 <alexpilotti> we already talked about this
13:38:40 <sagar_nikam> ok, lock makes sense
13:38:50 <alexpilotti> last time I synced with claudiub_ about this, jaypipes AFAIK said he;d like to implement support for similar cases
13:38:57 <sagar_nikam> support for multiple CSV ?
13:39:15 <sagar_nikam> is that planned ?
13:39:17 <alexpilotti> the idea is that the CSV storage will be seen as a single storage by all Nova nodes in the cluster
13:39:30 <sagar_nikam> agree
13:39:42 <alexpilotti> say that you have 1000GB on the CSV volume and that we have 4 hosts
13:39:43 <sagar_nikam> but the host can also have multiple CVS
13:39:51 <alexpilotti> each of them will report 1000GB
13:40:15 <alexpilotti> sagar_nikam: the multiple CSV for now is just a secondary extension
13:40:16 <sagar_nikam> which i think is fine. any issue with it
13:40:45 <alexpilotti> sagar_nikam: of course: the scheduler thinks that there's 4 * 1000 GB space
13:41:37 <alexpilotti> atthe same time, when we deploy an instance with, say 100GB disk flavor
13:41:43 <sagar_nikam> ok
13:41:45 <sagar_nikam> agree
13:41:56 <alexpilotti> all nodes will see 900GB free after allocating the space
13:42:17 <alexpilotti> let's now get to the point were the cluster has 50GB
13:42:34 <alexpilotti> Nova sees 4 * 50 GB
13:42:54 <alexpilotti> but if we try to spin 4 instances with 40GB hdd it will fail
13:43:10 <alexpilotti> although the scheduler will think it's perfectly fine :)
13:43:31 <alexpilotti> makes sense?
13:43:43 <sagar_nikam> the  vmware cluster driver also has the same issue, though it is for CPU and memory
13:43:58 <sagar_nikam> got it. so what is the fix planned
13:44:15 <alexpilotti> you are asking me like we own Nova :)
13:44:33 <alexpilotti> this is a Nova problem, not a driver problem
13:44:46 <sagar_nikam> ok, you mean fix is outside of driver ?
13:44:48 <alexpilotti> we need a BP at the Nova resourse tracker level
13:44:53 <sagar_nikam> ok
13:45:01 <alexpilotti> sagar_nikam: lolz
13:45:28 <alexpilotti> sagar_nikam: as written above:
13:45:45 <sagar_nikam> ok
13:45:59 <alexpilotti> jaypipes said he wanted to take a stab at it
13:46:08 <alexpilotti> but that was at the last midcycle meeting
13:46:14 <jaypipes> alexpilotti: https://review.openstack.org/#/c/225546/1
13:46:15 <alexpilotti> we dont have updates
13:46:41 <sagar_nikam> will it stop from the cluster patch getting merged ?
13:46:46 <jaypipes> alexpilotti: I am in the process of pushing a decomposition of that spec into three smaller chunks.
13:46:47 <alexpilotti> jaypipes: sweet tx!!
13:47:18 <jaypipes> alexpilotti: here is the one most relevant to you: https://review.openstack.org/#/c/253187/2/specs/mitaka/approved/generic-resource-pools.rst
13:47:29 <alexpilotti> sagar_nikam: no it wont, it will be just be a note
13:47:45 <sagar_nikam> jayppipes: Hi, nice to see you
13:48:07 <alexpilotti> sagar_nikam: the patch that jaypipes just linked will help us in a ton of situations
13:48:24 <sagar_nikam> jaypipes:thank you
13:48:36 <jaypipes> np guys
13:48:41 <alexpilotti> including Gen2 VMs, remotefx and in general all the compute resources that the driver exposes
13:48:47 <sagar_nikam> jaypipes:thank you
13:48:54 <alexpilotti> jaypipes: do you have a timeline for this to merge?
13:49:13 <alexpilotti> jaypipes: as in N, O...
13:49:29 <alexpilotti> I guess Mitaka is quite impossible
13:49:38 <jaypipes> alexpilotti: sorry, I do not know the answer for that. we will work on it in Mitaka. no idea when it would merge though
13:50:15 <alexpilotti> jaypipes: fair enough, please let me know if you need resources to work on it / review / etc
13:50:53 <alexpilotti> jaypipes: among the features outside of the driver, it's possibly our main pain point
13:51:26 <alexpilotti> sagar_nikam: any other questions on this?
13:51:40 <sagar_nikam> no
13:51:49 <alexpilotti> ok, changing topic
13:51:53 <alexpilotti> #topic FC
13:52:17 <alexpilotti> things are progressing very well
13:52:24 <alexpilotti> lpetrut: want to add something?
13:53:33 <lpetrut> alexpilotti: sure, the implementation for passthrough attached FC disks is almost ready
13:54:23 <sagar_nikam> the issue which we discussed last time, which required help from MS Storage team, is it resolved ?
13:55:00 <lpetrut> do you mean the issue we had in retrieving the physical disk path for a specific volume?
13:55:17 <sagar_nikam> yes
13:55:40 <alexpilotti> that got solved by using native APIs instead of WMI
13:55:57 <lpetrut> yes, there seemed to be an issue with the WMI API, so I've rewritten that using the hbaapi functions. The only issue with that is that it did not work remotely, so I had to do a small refactoring on live migration
13:56:01 <lpetrut> so that we don't break that
13:56:26 <sagar_nikam> ok
13:57:01 <sagar_nikam> one more point made by Kurt, on using os-brick
13:57:10 <lpetrut> next, I'll take care of the other scenario, when we expose virtual HBA ports to the instance directly, that should be the last step
13:57:32 <alexpilotti> time is almost up
13:57:44 <alexpilotti> #topic open discussion
13:57:47 <lpetrut> sure, but for the beginning, I was considering merging this in Nova, next to the other volume drivers we currently have, and move those out as a later effor
13:58:13 <Sonu> alexpilotti: Regarding Microsoft official support statement for OVS Ext in Hyper-V, I did not get any response from MSFT. Can this be done for OVS 2.4?
13:58:29 <Sonu> Just checking.
13:58:47 <alexpilotti> primeministerp: would you like to answer this one?
13:59:26 <alexpilotti> Sonu: I won't make official statements on behalf of MSFT :-)
13:59:37 <Sonu> sure. Not a problem.
13:59:56 <sagar_nikam> Sonu: your question on building OVS on windows
14:00:02 <alexpilotti> Sonu: what I can tell you is that the current plan is to submit 2.5 to WHQL
14:00:06 <sagar_nikam> can you check that
14:00:12 <alexpilotti> this does not mean any support from MSFT
14:00:52 <alexpilotti> Cloudbase supports and will support commercially OVS on Hyper-V
14:01:04 <Sonu> I get that. And when is OVS 2.5?
14:01:11 <Sonu> tentatively? FY16?
14:01:20 <alexpilotti> for the rest, the upstream code is OSS so anybody can take it and compile it
14:01:36 <Sonu> I get it.
14:01:59 <alexpilotti> Sonu: we're waiting for the OVS TPL to branch
14:02:16 <alexpilotti> so it will happen very soon
14:02:28 <Sonu> Thanks.
14:02:35 <alexpilotti> more details on the OVS community, we have a weekly meeting on Tue there
14:02:42 <ajo> we need to start the neutron_qos meeting guys :)
14:02:45 <vikram> hi
14:02:53 <Sonu> bye everyone.
14:02:53 <alexpilotti> #endmeeting