13:00:21 #startmeeting hyper-v 13:00:23 Meeting started Wed Jul 27 13:00:21 2016 UTC and is due to finish in 60 minutes. The chair is claudiub|2. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:27 The meeting name has been set to 'hyper_v' 13:00:45 Hi 13:00:48 damn, I have a bad nickname 13:00:52 hello. :) 13:01:19 how was the mid cycle meetup ? 13:01:42 well, tirering. :) 13:01:54 we'll get to the details shortly. :) 13:02:06 ok 13:02:15 anyone else joining us today? 13:02:34 lpetrut won't be with us today, as he's on vacation 13:02:42 anyways, let's get started 13:02:51 #topic os-brick status 13:03:03 sooo, we have a voting CI on os-brick 13:03:06 yeay. :) 13:03:12 good ... 13:03:37 buut, currently, it only tests iscsi and smb. fibre channel will be added soon, probably by next week. 13:03:55 hi guys! 13:03:56 lpetrut has worked diligently on it. :) 13:04:04 atuvenie_: hi. :) 13:04:05 hello guys 13:04:26 thanks lpetrut: 13:04:53 hi 13:04:53 for now, I'll bug hemna and smcginnis to review the smb patch on os-brick for now. 13:05:03 hi atuvenie_: abalutoiu: 13:05:13 ok 13:05:17 that's mergeable, and they shouldn't have any more complains regarding ci for it 13:05:28 i will also try to get hemna's review 13:05:39 sagar_nikam: cool, thanks. :) 13:05:51 #topic designate status 13:06:16 abalutoiu: the patch didn't merge yet. abalutoiu has been addressing comments 13:06:54 hopefully it'll get merged soon. 13:07:28 #topic shielded VMs 13:08:05 sooo, we've said this in the past meetings: Hyper-V 2016 comes with a new feature called shielded vms 13:08:32 it's a pretty neat feature, the instance is fully encrypted and safe 13:08:49 it is merged at the moment in compute-hyperv 13:09:04 planned for "o" ? upstream 13:09:11 BP approved ? 13:09:22 if you guys are planning to use it, that would be great. :) 13:09:38 we will try it .... 13:09:43 nice feature to have 13:10:19 sagar_nikam: the blueprint was approved in the past, but it wasn't approved in newton, since there were some changes in how shielded vms were implemented, so we had to rewrite some parts of the spec. 13:10:32 ok 13:11:08 itoader: can you share some links on this topic? 13:11:22 on how to use them / how to create the env for it? 13:11:43 Here is explained the concept and how to do the setup https://cloudbase.it/hyperv-shielded-vms-part-1/ 13:12:22 And this is the link on shielded vms in openstack https://cloudbase.it/hyper-v-shielded-vms-part-2/ 13:12:54 cool, thanks. :) 13:13:18 I consider that everything needed it's explained in the blog posts, but if you have any questions, I'll gladly answer them :) 13:13:42 we will check 13:13:54 was reading the blog now... sounds very intresting 13:14:28 cool, moving on. :) 13:14:42 #topic OpenStack Summit presentations 13:14:53 claudiub: Can you give reference to use cases of using shielded vms with openstack? 13:15:26 soo, just a short topic, the voting for presentations in barcelona are open. 13:15:30 #link https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/presentation/16466 13:15:43 sonu: just a sec. 13:15:51 Is it Telco use case. 13:16:33 soo, there are a few presentations regarding windows and hyper-v that would be nice to have them there. for that, they need voting. 13:17:09 unfortunately, the vote-for-presentations link is a bit... bad, and I cannot link the exact presentations directly 13:17:26 ok 13:18:07 but, a quick seach for Alessandro, Samfira, Vladu, and Sonu will reveal those presentations. :) 13:19:09 so, if you could, please vote on those presentations. :) 13:19:32 sure 13:20:00 sonu: ok, so now answering your question: the usecase is whenever security is a huge concern 13:20:14 sonu: and the VMs and their data needs to be protected 13:20:24 I got my answer Claudiu Thanks 13:20:52 e.g.: vms related to banks, financial transactions, personal data / info, etc. 13:20:57 Yes 13:21:15 k 13:21:33 #topic nova midcycle meeting status 13:21:48 ok, so this is going to take a while 13:22:18 it'll be hard to compress 3 days worth of discussions into 35 mins. 13:22:53 ok 13:23:06 for a comprehensive view on the topics discussed at the midcycle, there's an etherpad 13:23:09 #link https://etherpad.openstack.org/p/nova-newton-midcycle 13:23:11 how was the discussion on clusterdriver 13:24:15 soo, on the cluster driver, the nova folks reaaaallly don't like the fact that failover migration can occur without nova's consent 13:24:56 they say that ideally, the hyper-v cluster driver should call nova's api to actually do the failover 13:25:14 oh .... 13:25:23 driverf calling api ? 13:25:30 so that the claims, affinity, and other scheduling rules will be applied to the failover 13:25:33 driver calling api ? 13:25:53 yeah, don't like it either. :) 13:26:18 but the thing is, the whole scheduler / claiming / placement logic is being heavely refactored. 13:26:33 right now, the claims are being made locally, on each compute-node 13:26:50 and for now, the claims are correct with the cluster driver 13:27:05 but all the claims and all its logic are going to be moved to the scheduler 13:28:01 so, unless we do the failover "via the api" as they say, the resource claims won't be correct when a failover occurs. 13:28:37 right now, I'm thinking how we can manually do the failover... 13:28:37 but ... driver calling api ... may not be good 13:29:58 so, there's a field on the MSCluster_Resource object, that says how many times can it failover. wondering if we can set it to 0, detect whenever a failover needs to happen, and then call the api for it 13:30:21 that's going to require some experiments. 13:30:55 you mean nova driver detects when the failover has to happen ? 13:31:07 yep 13:31:20 claudiub|2 but: but that kind of defeats the purpose of failover 13:31:23 so, unless we can do something like this, they won't say yes to the spec. 13:31:31 atuvenie_: i know 13:31:47 atuvenie_: it is going to slow the failover a lot. :) 13:31:54 how will hardware failures on another node be detected ? 13:32:17 claudiub|2: also, if we set that field to 0, it will not failover to another node ever. That means, how many times the vm can be moved around 13:32:32 claudiub|2: that field I mean 13:32:58 i think setting the field to 0 defeats the purpose of HA 13:33:18 sagar_nikam: so, cluster resources are available at the cluster level. the cluster service detects whenever a failover needs to occur and does it. at the moment, in the compute-hyperv we have a wmi listener, which detects whenever a cluster resource changes its host. 13:34:10 atuvenie_: i know, that's the point. basically to disable the automatic hyper-v failover, so we can attempt to do it manually. 13:34:10 and where is the wmi listener running ? 13:34:41 sagar_nikam: on all nodes. they all listen to the event "when a cluster resource changes the its host to me" 13:34:46 doing it manually can mean the VM can get powered off... which may not be a good solution 13:34:57 oh... 13:35:17 atuvenie_: yeah, wait, if that value is 0 and the system needs triggers a failover, then the vm will be in error state 13:35:41 claudiub|2: so you mean we should detect this and move it manually then? 13:35:44 you mean nova-compute running on all the nodes in the cluster will listen to this wmi listener ? 13:36:10 atuvenie_: pretty much, yeah. 13:36:12 claudiub|2: error state in hyperv, not in nova I mean 13:36:46 atuvenie_: not sure it is going to be explicitly in error state 13:36:58 claudiub|2: then how is this different than a cold migration? I don't even know if we can recover it from that state 13:37:01 we'll have to see what exactly happens if failover count is 0 13:37:13 claudiub|2: I think we can actually, but what about hardware failure? 13:37:48 atuvenie_: if there's a hw failure, the vm will be in off state anyways 13:37:59 claudiub|2: no it will not 13:38:10 agree with atuvenie_: we need to handle hardware failures 13:38:13 claudiub|2: it will be restarted on another node pretty fast 13:38:21 the hyper-v cluster documentation says that it will not guarantee that the failover vms will have the same state as before failover 13:38:22 claudiub|2: from a saved state 13:38:24 currently ... the mscluster handles it 13:38:47 claudiub|2: it's not the exact same state, but pretty close, and certainly not from off state 13:39:17 claudiub|2: it's the closest saved state the hyper-v cluster has 13:39:57 if there is such a saved state, we can restore that state on another host then. 13:40:37 claudiub|2: also, if we do this, this is not taking advantage of any of the clustering features in hyper-v, we can just make our own cluster manually and be done with it, cause this way, we use the hyper-v cluster for nothing if we don't use any of it's features 13:40:52 claudiub|2: I don't think we can access that state 13:41:52 why not? why don't we have access to it, but the cluster service magically has access to it? 13:42:40 claudiub|2: it's how the hyper-v cluster works. I assume we don't have access there, but we can check 13:43:37 claudiub|2: still, this sounds like a pretty nasty hack to be honest. 13:44:37 well, nova core didn't offer any other solution 13:45:32 anyways. 13:45:42 remains to be seen how we can address this 13:46:01 as for other news, there are a couple of them 13:46:09 live-resize is going to be a thing, finally 13:46:13 yeay 13:46:31 but I'll have to do a blueprint beforehand, for a new api 13:46:59 ok 13:46:59 which can basically tell you "what you can do", given your permissions as a user and the capabilities of your cloud. 13:47:41 the live-resize will be implemented for all drivers, there are volunteers for each of the drivers. 13:47:59 as for host capabilities, there's going to be a new project called os-capabilities 13:48:34 and there will be all sorts of capabilities, for cinder and neutron, not only for nova. 13:49:05 so, we'll have to handle the hyper-v related capabilities in the near future on that project. 13:49:11 ok 13:49:40 multiple ephemerals, nova does them, but they have no idea why they were introduced in the first place 13:49:50 and they might be deprecated in the future. 13:50:22 then there's the new placement api 13:50:34 which will be the next step for the scheduler 13:50:54 and which will be outside of nova, as it will also be used by nova, neutron, cinder. 13:51:21 so where is this new API coming ? 13:51:24 if not nova 13:51:36 although there's still plenty of work to be done on that, plus, they want to make sure the host capabilities fits very well in it. 13:51:59 sagar_nikam: it is going to be a separate project 13:52:11 ok 13:52:16 os-capabilities ? 13:52:33 no, another 13:52:39 no name yet 13:53:18 ok 13:53:45 and yeah, there were a lot of talks about how to evolve the nova api in the future 13:53:59 as they want to get rid of most of the api extensions 13:54:14 as you know, they already removed the legacy v2.0 api 13:54:33 and how to finally get rid of nova-network 13:54:55 by constantly breaking bits of it, until people finally move to neutron. 13:55:28 anyways. 13:56:32 there were other topics as well, you can read them in the etherpad 13:56:52 but those were the major things, and things that we had an interest in. 13:57:02 #topic open discussion 13:57:20 anything here? 13:57:49 back to cluster driver in compute-hyperv... any further discussion on iscsi support ? 13:58:34 atuvenie_: ^ 14:00:42 hm, she got disconnected 14:00:43 sagar_nikam: if you want to go ahead with the idea of having each node login all targets you can propose a patch 14:01:02 hm, i was wrong. :) 14:01:11 ok 14:01:15 anyways... need to end the meeting 14:01:27 thanks 14:01:27 thanks folks for joining, see you next week! 14:01:30 #endmeeting