12:59:56 <claudiub> #startmeeting hyper-v
12:59:57 <openstack> Meeting started Wed Jul  6 12:59:56 2016 UTC and is due to finish in 60 minutes.  The chair is claudiub. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:59:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:00 <openstack> The meeting name has been set to 'hyper_v'
13:00:03 <Guest38015> hi all
13:00:06 <claudiub> hello
13:00:08 <abalutoiu> hi
13:00:11 <itoader> hi
13:00:12 <sagar_nikam> Hi
13:00:38 <claudiub> anyone else joining today?
13:00:54 <atuvenie> \o
13:01:21 <sagar_nikam> not sure.. today is a holiday in india...
13:01:27 <claudiub> oh, I see.
13:01:28 <sagar_nikam> we can start
13:01:42 <claudiub> #topic os-brick patches status
13:02:00 <claudiub> sooo... the iSCSI connector patch is merged
13:02:23 <sagar_nikam> good.... so that leaves only the nova patch ?
13:02:25 <claudiub> the fibre channel and smb ones are still pending. they got a review from hemna, to include a release note
13:02:35 <sagar_nikam> ok
13:03:04 <sagar_nikam> those 2 would also get merged soon ? what are the chances
13:03:12 <claudiub> so, other than that, I hope they get in soon.
13:03:24 <claudiub> but it's not really up to me. :)
13:03:31 <claudiub> will ping hemna again later today,
13:03:46 <sagar_nikam> ok
13:04:18 <claudiub> #topic networking-hyperv patches status
13:04:24 <sagar_nikam> one point
13:04:37 <sagar_nikam> before we go to next topic
13:05:01 <sagar_nikam> we started testing this https://review.openstack.org/#/c/301233/
13:05:12 <sagar_nikam> works well atleast for nova operations... nice work
13:05:16 <sagar_nikam> now my question
13:05:27 <sagar_nikam> since the topic is on cinder
13:05:41 <sagar_nikam> for us to test cinder attach in mitaka
13:05:49 <sagar_nikam> with cluster driver
13:05:52 <claudiub> #undo
13:05:52 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f2b35e4a110>
13:06:12 <sagar_nikam> are all patches that are required already merged in mitaka ?
13:06:35 <atuvenie> the cluster driver atm works only with the cinder smb driver
13:06:40 <claudiub> sagar_nikam: hm, not really sure what you mean. what other patches?
13:07:22 <sagar_nikam> claudiub: i meant ... any patches required in nova or os-brick
13:07:41 <sagar_nikam> that are required for testing cluster driver for attaching volumes
13:08:06 <sagar_nikam> atuvenie: only smb volumes ? what about iscsi... we use iscsi only
13:08:13 <claudiub> hm, as far as I know, there aren't any other patches, other than that.
13:08:34 <atuvenie> sagar_nikam: yes, atm only smb
13:08:48 <atuvenie> sagar_nikam: we are looking into iscsi as well, but it's a little more complicated
13:09:10 <sagar_nikam> atuvenie: oh... we dont have smb as of now... nor planned in near future
13:09:18 <sagar_nikam> we only have iscsi
13:09:46 <atuvenie> sagar_nikam: since we can't predict where a machine will failover to, it's complicated to ensure that the target in loged in on that particular host
13:10:03 <sagar_nikam> but... when i last discussed this topic many months back.. alexpilotti: mentioned that iscsi, fc and smb will all work and will be supporrted
13:10:39 <sagar_nikam> atuvenie: why dont we present the iscsi volumes to all hosts in the cluster
13:10:51 <sagar_nikam> ?
13:10:53 <lpetrut> Hi guys
13:11:01 <sagar_nikam> as part of attach volumes
13:11:08 <atuvenie> sagar_nikam: That is one option we thought about, but it can get complicated pretty fast
13:11:16 <sagar_nikam> lpetrut: hi.... nice time to join... the cinder expert is here
13:11:36 <sagar_nikam> what issues ?
13:11:48 <atuvenie> sagar_nikam: another thing we were considering is building a custom provider for the cluster service in hyperv that does this
13:14:01 <atuvenie> sagar_nikam: I think it's a little bit overkill to all the targets exposed to every host in the cluster
13:14:52 <sagar_nikam> only presented... not attached
13:15:10 <sagar_nikam> as and when the vm moves to a new host in a cluster due to host failure
13:15:31 <sagar_nikam> mscluster will automatically attach the volume agaon
13:15:35 <sagar_nikam> again
13:16:29 <lpetrut> well, for iSCSI/FC we do passthru, so for this to happen, the volume would have to be attached to all of the hosts
13:16:44 <sagar_nikam> it is a iscsi connection... should be fine i think
13:16:59 <sagar_nikam> lpetrut: yes that is the suggestion
13:17:15 <sagar_nikam> presented to als the hosts
13:17:57 <lpetrut> there is another reason why simply exposing the disk to all the hosts of the cluster wouldn't solve the issue. Hyper-V identifies the disks attached to instances by the drive number, which may differ among hosts for the same shared volume
13:18:56 <lpetrut> so, as atuvenie mentioned, the only feasible way of doing this would involve a custom cluster service provider
13:19:18 <sagar_nikam> lpetrut: let me get back to you on this... my team mate bharath has done some checks on this
13:19:41 <sagar_nikam> what is the custom cluster service provider ?
13:20:57 <lpetrut> the idea would be to have our own hooks, controlling what happens  when an instance is failed over, before being started
13:21:24 <lpetrut> still, there may be another approach
13:22:07 <atuvenie> sagar_nikam: basically a custom provider that would be do exactly what the hyper-v one does, just that it also deals with the volumes when the machine is failed over to the host new host
13:22:20 <lpetrut> if an instance having iSCSI/FC attached is failed over, it will enter an error state after being moved, as the disks are not accessible. We could just this error-state instance, attach all the disks at this stage, and then power it back on
13:23:10 <atuvenie> lpetrut: yeah, but that defeats the purpose of the cluster. The way it works we have minimum downtime at a failover
13:23:10 <lpetrut> s/just this/just take this
13:23:37 <lpetrut> that may just add a few seconds, but I think that's reasonable
13:23:45 <claudiub> atuvenie: it would still be pretty minimal, imo. you'd have a few seconds downtime.
13:24:14 <lpetrut> sagar_nikam: what's your view on this?
13:24:35 <sagar_nikam> i thought the connection_info got from cinder
13:24:44 <sagar_nikam> will have the disk number
13:24:57 <atuvenie> lpetrut, claudiub: I don't know, this should be investigated, but I feel that that downtime may be more than that.
13:25:07 <sagar_nikam> and all the details which can help us to attach the volumes
13:25:40 <sagar_nikam> also presenting the volumes as a clustered disk.. means it gets presented to all hosts
13:26:20 <lpetrut> that's the target side LUN, but hyper-v cares about the client side disk number
13:26:21 <atuvenie> lpetrut, claudiub: also, we are dealing with a cluster resource not a virtual machine, so when it gets in error state it may not be recoverable like a normal vm. Again, this should be investigated
13:26:53 <lpetrut> atuvenie: yep, I agree, just saying that this is one possible approach
13:26:53 <sagar_nikam> cluster driver not having iscsi/fc support is a major drawback
13:27:07 <claudiub> atuvenie: from my experience, you could simply reattach the disks and restart it.
13:27:13 <sagar_nikam> most cloud instances will have volumes
13:28:09 <sagar_nikam> we need to find a way to solve this issue
13:28:17 <lpetrut> sagar_nikam: sure, that's why we thought that for the beginning, we'd support only SMB backed volumes, while investigating for a proper solution for iSCSI/FC volumes
13:28:35 <sagar_nikam> lpetrut: ok
13:28:37 <atuvenie> claudiub: restarting it is a no no in my oppinion. If it's in a saved state, then yes, it may be ok to start it again, but restarting it is really a no no.
13:29:16 <sagar_nikam> claudiub: you mean restart the instance after failover
13:29:26 <sagar_nikam> ?
13:29:47 <sagar_nikam> but ... failover should be transparent to the user
13:29:53 <atuvenie> ^ exactly
13:30:02 <claudiub> atuvenie: i don't remember exactly, but if the vm couldn't start after failover, it was ending up in stopped state
13:30:16 <sagar_nikam> restarting may not be fine for tenant users
13:30:29 <atuvenie> claudiub: then that is not a solution.
13:30:31 <sagar_nikam> claudiub: how is it done in nova.. other drivers ?
13:30:39 <sagar_nikam> libvirt driver
13:30:49 <sagar_nikam> does it restart the instances ?
13:30:51 <lpetrut> I think that the only way in which a reboot may be avoided is using Hyper-V replicas (which we may have to consider)
13:31:07 <claudiub> sagar_nikam: as far as i know, there's only vmware that has a cluster driver.
13:31:15 <atuvenie> sagar_nikam: how does libvirt do what?
13:31:37 <sagar_nikam> i have worked on vmware driver... the volume is a vm disk there
13:32:09 <atuvenie> sagar_nikam: are you talking about a vmware cluster driver?
13:32:15 <sagar_nikam> claudiub: atuvenie: i meant migration trigered from nova api
13:32:45 <sagar_nikam> atuvenie: vmware driver only supprts vcenter cluster
13:32:55 <atuvenie> sagar_nikam: I see
13:33:14 <sagar_nikam> when migration is triggered from nova api... does it end up in rebooting the vm ?
13:33:17 <claudiub> sagar_nikam: you mean cold / live migration triggered from nova api? the volumes are mounted on both source and destinaton nodes before starting the migration.
13:33:51 <atuvenie> sagar_nikam: claudiub: but again, in that case we know the destination beforehand
13:33:54 <claudiub> but in the case of failover, the mscluster chooses the destination node.
13:33:57 <sagar_nikam> yes... live and cold migration
13:34:31 <sagar_nikam> since we are waiting for cluster events for us to identify the vm has moved
13:34:41 <claudiub> yep
13:34:48 <sagar_nikam> we use those events and update nova db
13:34:52 <sagar_nikam> with the new hostname
13:35:12 <sagar_nikam> cant we do something similar here... present that volume to the moved host
13:35:23 <sagar_nikam> on getting the event from mscluster
13:35:46 <lpetrut> you get the event that the instance was moved, but meanwhile it gets into an error state as it does not have the disks
13:35:52 <atuvenie> yes, but by the time we get the event from mscluster, the machine is on the new host and started, which without the volumes will be in error state
13:36:31 <claudiub> sagar_nikam: yeah, we basically get the event that the failover already happened, not that it will happen.
13:36:50 <sagar_nikam> ok.. got it... then the only possibly solution.. we need to present the lun to all hosts... and find a way to get the correct disk number
13:37:49 <atuvenie> sagar_nikam: I'm not a fan of that solution, we considered it
13:38:23 <sagar_nikam> atuvenie: ok .. but we need some way to support iscsi and fc volumes with cluster driver
13:40:58 <claudiub> yeah, there has to be anyways.
13:41:52 <claudiub> speaking of hyper-v cluster..
13:42:05 <claudiub> #topic hyper-v cluster status
13:42:26 <claudiub> well, it seems that nova-core has some more concerns about this feature and how it works
13:42:37 <sagar_nikam> can the patch be moved up the priority for core reviewers ?
13:42:43 <sagar_nikam> oh ...ok
13:42:47 <claudiub> and potential race conditions
13:43:09 <claudiub> which is why they've decided for it to be a topic for the next nova midcycle meetup
13:43:14 <claudiub> which will happen in 2 weeks
13:43:20 <sagar_nikam> ok
13:43:30 <claudiub> I will be attending, armed to the teeth with answers. :)
13:43:56 <sagar_nikam> nice... as far as the code goes... it works as seen in our tests
13:44:19 <sagar_nikam> so hopefully claudiub: has all the answers and ir gets merged soon
13:44:28 <claudiub> yeah, but there might be a few race conditions that we didn't / couldn't take into account
13:44:39 <sagar_nikam> like ...
13:44:53 <sagar_nikam> can you let me know where it can fail ?
13:45:08 <claudiub> for example, if an instance is scheduled to start on a host A, and it would fit, if a vm failovers to host A faster, the scheduled instance might not fit anymore.
13:45:51 <sagar_nikam> ok
13:46:34 <claudiub> plus, we have to make sure that the resource claims are also moved to the new host, in order to ensure that the scheduler has a proper resource view on the nodes.
13:47:03 <sagar_nikam> ok....
13:47:16 <sagar_nikam> in vmware driver
13:47:25 <sagar_nikam> we dont hit such issues
13:47:38 <sagar_nikam> since one compute -- one cluster
13:47:45 <claudiub> anyways, until then, we'll have to get this in: https://review.openstack.org/#/c/335114/
13:47:50 <sagar_nikam> here we have n computes for n hosts in a cluster
13:48:40 <claudiub> it improves host the driver handles shared storage, which is a must for the cluster driver anyways.
13:48:51 <sagar_nikam> ok
13:49:10 <claudiub> sagar_nikam: yeah, that's true, but on the vmware there are other issues regarding this
13:49:21 <sagar_nikam> claudiub: any thoughts on having a single nova-compute for a cluster ?
13:49:37 <sagar_nikam> i meant mscluster
13:49:51 <sagar_nikam> one main question... where do we run it
13:50:22 <claudiub> sagar_nikam: for example, on a vmware cluster, the scheduler might see that the cluster has 128 GB memory free, but that doesn't mean you can spawn an isntance with 128 gb memory there
13:50:50 <claudiub> as that 128 gb free is spread across the whole cluster.
13:50:54 <sagar_nikam> agree.... i have seen this issue in vmware driver
13:51:16 <sagar_nikam> not just memory, same problem for disk as well
13:51:17 <claudiub> sagar_nikam: the mscluster is a clustered service, meaning it will run in the cluster. anywhere / everywhere.
13:51:45 <claudiub> sagar_nikam: if at one point it is on host A, if host A goes down, it restarts on host B.
13:51:57 <claudiub> sagar_nikam: same as any other clustered service / resouce.
13:52:12 <sagar_nikam> no ... i meant where do we run nova-compute
13:52:28 <claudiub> sagar_nikam: ah, gotcha. on each compute node.
13:52:33 <sagar_nikam> if we go with the option of one novacompute per mscluster
13:53:08 <sagar_nikam> just got a idea... but too many issues... may not be a good option
13:53:13 <claudiub> sagar_nikam: there was a discussion about this before this spec was approved in the first place. and having a nova-compute on each node was the most favorable one
13:53:24 <sagar_nikam> ok
13:53:55 <claudiub> moving on, as we are short on time.
13:54:04 <claudiub> #topic networking-hyperv patches status
13:54:14 <claudiub> #link https://review.openstack.org/#/c/332715/
13:54:18 <claudiub> ^ this merged on master
13:54:22 <sagar_nikam> we have almost used most time of this meeting for cluster driver. nice discussion... we need to find a way to slve iscis spport
13:54:34 <claudiub> it fixes the issue when the security group is changed on a port.
13:54:39 <claudiub> backported it to mitaka.
13:54:50 <sagar_nikam> ok nice
13:55:09 <sagar_nikam> will let vinod know about it
13:55:23 <sagar_nikam> 5 mins only
13:55:24 <claudiub> during last week's meeting, vinod said that he couldn't replicate the bug on liberty.
13:55:34 <sagar_nikam> ok
13:55:40 <claudiub> so, it seems it doesn't affect liberty.
13:55:57 <claudiub> #link https://review.openstack.org/#/c/328210/
13:55:57 <sagar_nikam> we are slowly moving to mitaka
13:56:08 <claudiub> this has a few comments, but hyper-v ci is passing, which is good.
13:56:10 <sagar_nikam> we will check this patch
13:56:25 <claudiub> sagar_nikam: cool, sounds good. :)
13:56:31 <sagar_nikam> last topic.. before time ends
13:56:39 <sagar_nikam> what's happening on freerdp
13:56:40 <claudiub> so, if the comments are addressed, +2 from my part.
13:56:44 <claudiub> #topic open discussion
13:56:53 <sagar_nikam> we raised a defect
13:57:19 <sagar_nikam> freerdp does not support tls enabled keystone endpoint
13:58:19 <claudiub> c64cosmin: ohai
13:58:29 <c64cosmin> hi
13:58:49 <sagar_nikam> hi
13:58:59 <sagar_nikam> how is freerdp work ?
13:59:18 <sagar_nikam> any new solution for the issue we found ?
13:59:30 <c64cosmin> well, this are going well, just that I must delay that work for a bit
13:59:43 <c64cosmin> I've been asigned a new project
13:59:44 <sagar_nikam> ok
13:59:54 <c64cosmin> but it seems that the problem you have is solvable
13:59:54 <sagar_nikam> ok
14:00:01 <c64cosmin> the https keystone I suppose
14:00:44 <sagar_nikam> almost end of time
14:00:49 <claudiub> yeah..
14:00:53 <sagar_nikam> we can discuss offline
14:00:55 <claudiub> i'll have to end it here
14:00:56 <sagar_nikam> thanks all
14:01:07 <claudiub> thanks folks for joining, see you next week!
14:01:09 <claudiub> #endmeeting