13:00:59 <alexpilotti> #startmeeting hyper-v
13:01:00 <openstack> Meeting started Wed Apr 20 13:00:59 2016 UTC and is due to finish in 60 minutes.  The chair is alexpilotti. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:03 <openstack> The meeting name has been set to 'hyper_v'
13:01:19 <alexpilotti> hi folks
13:01:21 <sagar_nikam> Hi
13:01:30 <atuvenie> hi all
13:01:35 <domi007> hi
13:01:43 <ajo> hmm, isn't neutron_qos meeting here at this time?
13:02:08 <alexpilotti> To begin a quick announcement: we'll skip the meeting next week as most of us are going to be at the Austin summit
13:02:30 <slaweq_> hello
13:02:37 <slaweq_> ajo: I also thought that :)
13:02:55 <alexpilotti> ajo: looks like there's some timezone issue here :)
13:02:56 <ajo> slaweq_, ours is later: http://time.is/es/UTC
13:02:58 <ajo> sorry :)
13:03:02 <slaweq_> aha
13:03:03 <slaweq_> ok
13:03:14 <ajo> DST
13:03:46 <alexpilotti> ajo slaweq_: the beauty of having meetings in UTC is that around this time of the year it becomes a mess :)
13:04:00 <ajo> hehehehe alexpilotti yes ':)
13:04:40 <slaweq_> yep
13:04:46 <slaweq_> sorry for disturb You :)
13:05:12 <alexpilotti> slaweq_: np! :)
13:05:41 <alexpilotti> #topic tpool for mixed threads / greenlets
13:06:12 <alexpilotti> We identified some race conditions around WMI events which are handled in native threads
13:06:47 <alexpilotti> there's a new patch that merged now in os-win for master and Mitaka
13:07:01 <domi007> what symptoms can be observed? random WMI operation failing?
13:07:10 <lpetrut> basically, we have to avoid using eventlet primitives (or monkey patched ones, such as locks, events, etc) when running code in a different native thread
13:07:38 <alexpilotti> lpetrut: do you have a trace at hand or even better the link to the bug?
13:07:44 <lpetrut> the event listener was dying unexpectedly with a greenlet error, complaining that it cannot switch to a different thread
13:07:48 <lpetrut> sure
13:08:43 <lpetrut> https://bugs.launchpad.net/os-win/+bug/1568824
13:08:43 <openstack> Launchpad bug 1568824 in os-win "Event listeners die unexpectedly" [Undecided,Fix released]
13:08:46 <domi007> thanks
13:10:01 <alexpilotti> I just noticed that it was unprioritized, added it now
13:11:40 <alexpilotti> talking about MI and WMI, it's important to note that the Hyper-V WMI v2 provider in Windows Server 2012 has some issues
13:11:50 <lpetrut> just added a trace to the bug report as well
13:12:04 <alexpilotti> so for 2012 we revert to the old WMI when needed
13:12:50 <alexpilotti> this means that since the old WMI is not supporting parallel operations, we limit the workers to 1 in networking-hyperv
13:13:10 <alexpilotti> important: this DOES not apply to 2012 R2, only 2012
13:13:21 <sagar_nikam> alexpilotti: if using 2012, we need to use WMI instead of pyMI ?
13:13:44 <domi007> I think this is all PyMI's internal magic, isn't it?
13:13:45 <alexpilotti> just for some operations, os-win takes care of that
13:13:54 <domi007> I meant os-win :)
13:14:23 <alexpilotti> basically os-win selects the proper WMI module based on the OS
13:14:48 <sagar_nikam> ok
13:14:52 <alexpilotti> what is annoying, is that we still need to ship pywin32 for supporting 2012
13:15:12 <alexpilotti> as the old WMI depends on it
13:15:31 <domi007> that's indeed annoying, but at least everything works everywhere
13:15:38 <alexpilotti> nothing critical but it's important to note it
13:16:18 <alexpilotti> #topic Mitaka release
13:16:58 <alexpilotti> today we're done with all bugs and backports
13:17:39 <alexpilotti> a new PyMI 1.0.2 release is under test and will be released later today if nothing new shows up on the radar
13:18:18 <alexpilotti> which means that final tests for our MSI will start as well immediately afterwards
13:18:39 <sagar_nikam> what are the fixes in 1.0.2 as compared to the previous version ?
13:18:57 <domi007> alexpilotti: once the MSI tests are done it is safe to say that upgrading to Mitaka should be painless?
13:19:35 <alexpilotti> sagar_nikam: mostly minor things: https://github.com/cloudbase/PyMI/commits/master
13:19:56 <sagar_nikam> ok
13:20:28 <alexpilotti> the main "feature" is adding a field to the previous WMI instance object during events
13:20:33 <alexpilotti> this is needed for clustering
13:20:47 <sagar_nikam> ok
13:21:26 <alexpilotti> beside this, better error reporting when trying to retrieve a non-existing WMI instance property / method
13:23:33 <alexpilotti> current version is 1.0.2.dev2, which will be a signed 1.0.2 release after tests (unless regressions show up of course)
13:24:05 <alexpilotti> next
13:24:28 <alexpilotti> #topic console support specs
13:24:47 <alexpilotti> after the millionth rebase we have been asked to add a spec for this BP
13:25:17 <sagar_nikam> bp link ?
13:25:22 <alexpilotti> reason is that we are also working on objects, so it's not a so called trivial BP anymore
13:25:36 <alexpilotti> lpetrut: do you have a link at hand?
13:25:39 <lpetrut> basically, the serial console implementation can go in, they need a spec just for adding the the image props
13:25:47 <lpetrut> sure
13:26:24 <lpetrut> here's the BP: https://blueprints.launchpad.net/nova/+spec/hyperv-serial-ports
13:26:44 <lpetrut> but for the image props, we'll need a spec, which I have not submitted yet
13:27:01 <alexpilotti> thanks lpetrut
13:27:41 <alexpilotti> to be clear console support is part of compute-hyperv since ages, but since it needs to merge in nova eventually, this is the status
13:28:25 <alexpilotti> those were also the first patches in the Newton review queue, so we are now bumping up the next in line
13:29:29 <alexpilotti> #topic OVS 2.5
13:30:15 <alexpilotti> we have a release-blocker bug for 2.5, when using LACP, the switch is dropping packets in some conditions
13:30:30 <domi007> oh I see
13:30:38 <alexpilotti> ATM this is the last blocker before release
13:30:53 <alexpilotti> this can be worked around using NetLBFO
13:31:22 <alexpilotti> but it's obviously much better if LACP can be handled directly by the vmswitch + OVS
13:31:48 <alexpilotti> especially considering that the user can just apply the same openflow rules on Linux and Windows
13:32:12 <alexpilotti> sagar_nikam: did you guys did tests with the OVS 2.5 beta?
13:32:57 <sagar_nikam> i think not yet. sonu: team was planning, but as per my understanding it is not yet done
13:33:01 <sagar_nikam> it is planned
13:33:06 <alexpilotti> ok thanks
13:33:30 <alexpilotti> #topic Cinder SMB3 / iSCSI driver release
13:33:44 <domi007> we would do testing, but without documentation we are not sure what to do...should we try to do it based on your previous write up?
13:34:09 <domi007> oops, sorry, got caught up in the middle of topic change :) I'll leave my questions to the end
13:34:11 <alexpilotti> domi007: good point, we're still writing the updated docs, let me ping a colleague
13:34:23 <domi007> thanks :)
13:36:17 <alexpilotti> domi007: I'm starting an email thread
13:36:40 <domi007> all right, looking forward to it :)
13:37:02 <alexpilotti> so you dont have to wait for the public docs to be available
13:37:21 <domi007> good, I'm grateful
13:37:39 <alexpilotti> so getting back to the Cinder driver, it's aslo getting released
13:38:32 <alexpilotti> nothing major to signal, there are various bug fixes but core functionality is retained from Liberty
13:38:55 <alexpilotti> #topic open discussion
13:39:51 <sagar_nikam> alexpilotti: have you tried Windows NLB ?
13:39:52 <alexpilotti> Most topics today were clearly focused around the Mitaka release as that's where most of the focus was in the last days
13:39:57 <sagar_nikam> network load balancer
13:40:04 <alexpilotti> sagar_nikam: in what context?
13:40:18 <sagar_nikam> i am thinking of using it for freerdp
13:40:29 <sagar_nikam> run freerdp on 3 machines
13:40:40 <sagar_nikam> have a cluster IP using NLB
13:41:07 <alexpilotti> any load balancer that can preserve client affinity and supports websockets is good
13:41:10 <sagar_nikam> and then provide that Cluster IP in nova.conf
13:41:34 <domi007> so we have this weird issue I already put up on ask and Alin was nice and started looking into it - basically if a network security group is applied to a VM and the group is modified the modification isn't applied to the VM somehow. I couldn't get any traces of it yet, but as far as I know the issue still exists
13:42:24 <domi007> sagar_nikam: haproxy could be used maybe, we will need some kind of freeRDP clustering as well good that you mentioned this
13:42:26 <sagar_nikam> alexpilotti: i had some questions on NLB, anybody from your team has knowledge on it ?
13:42:49 <alexpilotti> sagar_nikam: we are using haproxy as well much more than NLB
13:43:04 <sagar_nikam> domi007: haproxy for windows ? i think it is not available, hence i am thinking of using NLB
13:43:29 <domi007> oh I see, I thought of it because we already have one in our system that balances openstack management apis :)
13:43:32 <sagar_nikam> alexpilotti: haproxy on windows ? how does it work
13:43:46 <alexpilotti> we use NLB as well, but not being that popular we dont use it as a load balancer in test deployments
13:43:53 <alexpilotti> sagar_nikam: linux
13:44:18 <alexpilotti> it's just sitting in front of the Windows cluster
13:44:26 <alexpilotti> also, IIS has a nice LB feature
13:44:33 <alexpilotti> as an alternative
13:44:49 <sagar_nikam> alexpilotti: since i am running freerdp on windows machines, i thought NLB was the only option
13:44:51 <alexpilotti> it's called ARS
13:45:28 <sagar_nikam> alexpilotti: can you/your team help me with using haproxy and windows cluster
13:45:49 <alexpilotti> If you want a pure Windows deployment, NLB or ARS are the only choices
13:46:14 <alexpilotti> if not, any LB frontend with the above limits can do
13:46:56 <alexpilotti> domi007: abalutoiu says he tested on Mitaka and all is good, he's switching to Liberty now
13:47:02 <sagar_nikam> in your environments you use haproxy on linux and it balancing windows cluster ?
13:47:16 <domi007> do you also have the issue of wsgate sometimes simply not working, but a restart of the service fixes it?
13:47:33 <alexpilotti> sagar_nikam: the FreeRDP hosts, not the Windows cluster itself
13:48:01 <domi007> sagar_nikam: in our env we have all linux VMs running openstack's management machines, and between them all API calls are routed through haproxy
13:48:04 <sagar_nikam> alexpilotti: right i meant freerdp hosts
13:48:40 <sagar_nikam> alexpilotti: and what IP is given in nova.conf for freerdp on hyperv hosts ?
13:49:17 <alexpilotti> domi007: it happened for us on previous versions due to a lock, do you have a dump that we can analyze?
13:49:54 <domi007> alexpilotti: by dump you mean a log file? does wsgate keep logs at all? haven't really checked this
13:49:56 <alexpilotti> domi007: if not, if happens again, get in touch with cmunteanu in our team
13:50:15 <domi007> oh, okay, that's good
13:50:31 <alexpilotti> domi007: no, a Windows memory dump. You can generate one when the service becomes unresponsive
13:50:58 <domi007> oh, all right...but there is a newer version available if I understood correctly?
13:51:03 <alexpilotti> domi007: Windows can generate dumps on BSODs and application crashes, but you can also dump one anytime
13:51:14 <domi007> makes sense, sure
13:51:28 <alexpilotti> domi007: last one was in december AFAIK
13:51:57 <domi007> okay, I think our installation is newer then that, so we will cluster and dump as well
13:52:03 <domi007> :)
13:52:36 <sagar_nikam> alexpilotti: haproxy VIP is given in nova.conf on hyperv hosts ?
13:53:21 <alexpilotti> sagar_nikam: yes correct
13:53:30 <sagar_nikam> ok
13:53:35 <sagar_nikam> will try that
13:53:39 <alexpilotti> since that's what horizon passes to the user
13:54:00 <domi007> proxies to the user :)
13:54:22 <alexpilotti> then the LB connects to the FreeRDP farm
13:54:35 <sagar_nikam> ok
13:54:41 <sagar_nikam> and it works well ?
13:54:42 <alexpilotti> and those connect to the individual Hyper-V hosts based on the Nova token
13:55:01 <alexpilotti> sagar_nikam: only issues we had are for websocket affinity
13:55:04 <sagar_nikam> never tried using haproxy running on linux connecting windows machines
13:55:28 <alexpilotti> we do it all the time, mostly for web apps
13:55:36 <sagar_nikam> ok
13:55:52 <alexpilotti> it's a very simple and lightweight solution
13:55:56 <sagar_nikam> alexpilotti: will mail you if i need any help
13:55:59 <domi007> since HTTP is universal, haproxy simply pings based on http
13:56:09 <sagar_nikam> this seems much simpler than using NLB
13:56:19 <domi007> so it should work...we will try this as well, so if you need help sagar_nikam email us
13:56:22 <alexpilotti> sure, but yeah as domi007 says it's just HTTP :)
13:56:25 <domi007> as well
13:56:37 <sagar_nikam> sure domi007:
13:57:08 <alexpilotti> NLB is not limited to HTTP only, but in this case that's all you need
13:57:26 <alexpilotti> -3'
13:57:31 <sagar_nikam> alexpilotti: agree
13:57:35 <alexpilotti> any other topic?
13:58:17 <alexpilotti> Timing out... :)
13:58:24 <sagar_nikam> alexpilotti: 4 meetings scheduled in summit. freezer, monasca, magnum and designate, let me know if you need any help
13:58:46 <domi007> Good luck in Austin guys, see you in two weeks! Hopefully Mitaka MSIs will be done with testing and out for the public :)
13:59:13 <domi007> alexpilotti: till then we'll look into OVS
13:59:36 <alexpilotti> sagar_nikam: thanks for all your help there, we're still waiting for an answer from the Magnum TPL AFAIK, but all the rest of the meetings are planned
13:59:57 <alexpilotti> thanks guys!
14:00:01 <alexpilotti> #endmeeting