16:00:52 #startmeeting blazar 16:00:53 Meeting started Thu Aug 15 16:00:52 2019 UTC and is due to finish in 60 minutes. The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:56 The meeting name has been set to 'blazar' 16:01:46 #topic Roll call 16:02:29 Hi jakecoll 16:02:44 hello 16:03:37 Is Jason planning to join? If not we can start now. 16:04:00 not sure 16:04:10 Hi diurnalist 16:04:13 o/ 16:04:40 #topic Upstream contributions 16:05:31 Thanks jakecoll for submitting a spec for network reservation. I just reviewed it earlier today. 16:05:34 #link https://review.opendev.org/#/c/674089/ 16:06:14 It was a good exercise indeed as some comments may trigger code changes 16:06:35 Thanks. Just now looking at some of the comments 16:08:15 If you could update the code implementation accordingly, that would be great. For example I suggested that the vfc_resources DB row is removed, if there is any related code it should go as well. 16:09:13 I should be able to jump back on a lot of this next week. Had a bunch of stuff on my docket this week at work. 16:10:24 We should think about how the vfc stuff can be most efficiently maintained in Chameleon 16:11:12 I'm not all that aware of the vfc stuff 16:12:43 It's something specific to some network hardware in use on Chameleon, which means that even though X VLANs may be available, only Y can be configured at the same time. 16:13:06 Maybe it could be another use case for the policy enforcement API we discussed some time ago. 16:13:50 i.e. not just enforce resource usage policy, but also restrict reservation to technical limitations that may not be easy to describe within Blazar 16:14:40 #action Update usage enforcement spec to add VFC allocation use case, if relevant 16:16:12 Worth discussing while we're online: my comment about the UI for blazarclient to show/list allocations 16:16:23 https://review.opendev.org/#/c/673106/ 16:16:33 Will we eventually have: 16:16:36 blazar host-allocation-list 16:16:36 blazar floatingip-allocation-list 16:16:36 blazar networksegment-allocation-list 16:16:41 or just: 16:16:45 blazar allocation-list [--host | --floatingip | --networksegment] 16:17:08 Replace networksegment by network, I will we will settle on this name 16:17:34 Yea, I like the functionality of that better 16:17:43 that = the second one? 16:18:38 No. The allocation-list --host etc... 16:18:48 ...or, yes, the second one 16:18:55 Yes, OK :) 16:19:13 I like it better too 16:20:28 I look forward to your updated patch 16:21:11 That's all for me review-wise, I haven't managed to look at your other patches yet 16:22:26 Do you have anything else in the pipeline? 16:23:37 Yes, potentially 16:24:13 We're adding an API call that would reallocate a host. It's basically exposes the _reallocate functionality used in heal reservations to the admin api. 16:24:55 Hea reservations is pretty useless on a baremetal setup so this just makes life easier for us. 16:25:23 Health monitoring doesn't work well with Ironic? 16:25:58 Nope. It just queries Nova for the hypervisor status 16:26:00 I think you were trying it out at some point 16:26:31 Do you know if it mirrors the maintenance state from ironic? 16:26:37 And anecdotal evidence on Chameleon seems to suggest that rarely if ever happens 16:27:28 I've never verified, but I assume since an ironic node in maintenance mode can still end up in a user's lease then no, I don't believe it does 16:28:24 That's good to know. Maybe we can make improvements to the monitoring 16:28:28 my understanding is that the hypervisor is only down if the nova-compute-ironic service is down. when it restarts it processes each ironic node and i think even the ones in an error state show up as UP. 16:29:38 improvements to the monitoring will be necessary, either from this end or from nova's end. unclear how much nova should know about this. my understanding is that blazar has no idea ironic exists at the moment. 16:29:47 I'll look at your reallocate code, is this it? https://github.com/ChameleonCloud/blazar/pull/19 16:30:03 yep 16:31:13 Have you considered using a property on the host itself rather than introducing a new API call? 16:31:52 No. What would that look like? 16:32:05 priteau: not sure what you mean? the main thing is a means to trigger the mechanism that finds a replacement 16:32:49 So just set the hypervisor status to down? 16:33:05 There is an existing property called `reservable` on the Blazar host. What if turning it from false to true triggered the reallocation? 16:33:21 Sorry, from true to false 16:34:05 I believe that's used by the health monitoring so we would have to check how it interacts with it 16:34:09 Yea, that could work. We didn't think of that 16:34:44 Although we have to consider if there is a situation where reservable is already set to false and you still want to reallocate 16:35:28 could work. is it valid for a non-reservable node to be in an allocation? 16:35:45 That would mess up all of our maintenance leases, I imagine 16:36:08 indeed :D - due to how the blazarnova filter works, a reservation is always required to test anything. 16:36:16 but... with this property, maintenance leases become less important. 16:36:41 it definitely changes the workflow. i think ironic people are also having issues with how to handle this type of thing (taking node out of commision, but needing to work on it) 16:36:58 http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006430.html 16:37:27 Good point about the maintenance leases. As diurnalist say, they would not be required to prevent users from allocating the node (since reservable would be false), but could be useful for testing 16:38:02 Have you tried specifying the host to use to launch an instance? It may bypass BlazarFilter 16:38:57 how does that work? instead of sending a reservation_id you can send some special param? 16:39:11 i would hope you couldn't bypass that filter so easily! 16:39:37 It works well on a virtualised cloud, you do something like this: openstack server create [...] --availability-zone nova:hostname 16:40:51 For Ironic the syntax may be: :: 16:43:04 Hopefully admin only 16:43:54 I'll look at the health monitoring code and provide feedback 16:44:40 :+1: 16:44:50 interesting, will have to try that out 16:46:11 Anything else to discuss today? 16:47:43 not on my end 16:48:19 Thanks a lot for joining, this was a good discussion 16:48:32 No AOB from me either 16:48:38 Have a good fortnight! 16:48:48 #endmeeting