16:00:21 #startmeeting blazar 16:00:22 Meeting started Thu May 23 16:00:21 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:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:25 The meeting name has been set to 'blazar' 16:00:47 #topic Roll call 16:01:36 Any Blazar folks around? 16:01:39 hi! 16:02:26 Hi tzumainn 16:04:38 There should be at least one other person joining. 16:05:53 count me in 16:05:57 Hi geo_ 16:06:53 still working on the identities; I was turnerg last week 16:07:05 I was going to ask about this 16:07:22 yeh; old dog, new tricks ya' know 16:09:02 I've put usage enforcement again on the agenda for today, as the conversation was quite lively 16:09:28 #topic Usage enforcement 16:09:43 Once question I was asking at the end of the meeting last week 16:09:45 If Blazar was making REST requests to a customisable endpoint on reservation creation / update, expecting to get a simple yes/no answer (with some details, like how much SUs are left compared to how much would be used), would people be motivated to write a small REST service making the link between Blazar and any custom allocation backend? 16:11:43 That's really because each deployment appears to be using some different system for tracking usage against allocations, as there's no standard solution in this space. 16:13:12 Yeh, you'd have to; speaking for us, it's doable 16:15:39 diurnalist: Would an approach like this be of interest for Chameleon if it meant dropping usage enforcement from your fork? 16:16:40 priteau: yes, i'm just thinking about what assumptions it introduces in to the data model, as i know there is a lot of discussion about which system's responsibility it really is to manage inventory/reservations 16:16:54 but i suppose enforcement is something that makes sense for a system like blazar to encapsulate 16:17:05 regardless of how the inventory of resources is managed 16:18:10 priteau: how do you imagine tagging resources in blazar with cost models? is this something the custom REST service would also have to deal with? 16:18:50 i guess it also depends on how complex of a service you're thinking. a full REST service is actually a bit hard to get right. it would be easier if it was just one endpoint (more RPC), like how the Nova custom vendordata service works. 16:19:25 Yeah I said REST but I was thinking something over HTTP really 16:19:33 ah, ok :+1: 16:21:33 That's a very good question about the cost model. If Blazar forwards the list of allocated resources to the HTTP service (or customisable tags associated with them), it could remain completely ignorant of the cost of each resource. 16:21:44 That's more work for the HTTP service of course. 16:23:06 However I can see how teaching Blazar to know a bit about resource cost could be useful to improve resource allocation, e.g. by selecting the cheapest resources. 16:23:14 Let me explain in more details 16:24:24 If you've got a cloud of regular compute nodes and expensive GPU nodes, and users ask to reserve any resource without filtering by node type, Blazar could allocate a GPU node when a regular compute node would have been enough. 16:25:22 We could put a weight tag on each node to help Blazar with selecting the right resource. 16:28:07 But any advanced policy and tracking against externally-stored allocations would have to be done via this HTTP service 16:28:47 That is, unless we go via a Python plugin approach, like vendordata v1 in Nova. But it seems like people are generally moving away from this. 16:30:14 Yes, I guess the question is whether cost is important enough to be a concept in Blazar 16:31:07 I think that module plugins are indeed going away, and I think that makes sense especially given the popularity of solutions like Kolla, where it becomes a bit harder to inject code like that 16:31:21 but this is more of a gut feeling 16:32:09 It wouldn't strictly be related to cost, it could be an abstract weight. Like weighers in Nova scheduler. 16:32:09 i'm not 100% on whether blazar should know about cost. rather, the operators could tag resources arbitrarily and pass the resources/tags in to this custom service and deal with them however they want 16:32:17 right 16:32:58 i wonder if it instead makes sense to just allow this external usage service to return how much usage such and such a reservation will take 16:33:23 this could allow flows where users are given feedback on the cost/feasibility of their reservation and make adjustments (as you said, perhaps adding filters to not use GPU nodes?) 16:34:03 so, the question being if the blazar resource selection should be smart about some defaults, or whether we just kick the can to the operator's environment 16:34:29 That's simpler and probably better to start with. I get the feeling that if we make this external service take too much responsibility, we will end up just replicating the whole placement <-> nova interaction 16:34:31 jay pipes said something in a thread like "don't attempt to deal with quota. there are too many use cases and it will haunt you. forever and ever" or something to that effect ;) 16:34:55 yeah 16:35:35 priteau: i'm afraid i have to leave the meeting a bit early today. i'll review the notes when i get back! thanks again for organizing. 16:35:52 No problem. Thanks for your valuable input. 16:36:01 overall i think this external HTTP service is a good idea, and i'm happy that it will reduce some of our patch burden of course :) 16:36:54 #action Spec an external HTTP service that can compute reservation usage and accept/deny it 16:38:14 #agreed Start with a simple external HTTP service without trying to make smart resource selection 16:38:46 Hi jakecoll 16:39:11 Hey, sry I'm late 16:42:15 I'll try to start work on this spec, would be nice to get help from jakecoll and diurnalist to cover requirements from Chameleon 16:44:39 Anything else you would like to discuss on this topic? 16:46:45 #topic AOB 16:47:47 jakecoll: I haven't followed closely how Blazar has evolved in Chameleon in the last couple of months. Do you have new features or bug fixes that would make sense for upstream? 16:49:50 priteau: I'm working on adding the allocations api to the blazar-dashboard 16:50:13 Nice! Is the API complete enough to implement it? 16:50:17 this has involved adding more lease info in the allocations api in stein itself. 16:51:00 In stein, there still isn't allocation api support for other resoures like networks for floating ips 16:51:33 No, it's planned for Train 16:51:37 Also, would be good to expose extra capabilities via an api call 16:51:48 dashboard has to hit db for that info too 16:53:48 Don't you get them if you GET /v1/os-hosts 16:56:05 You might be right there 16:56:48 Note that it's a bit slow to run on Chameleon. 10 seconds to get all hosts at UC. Could be more at TACC. If you can figure out why :-) 16:57:02 It may be due to completely unoptimised DB queries 16:59:03 I've checked, they are included in the host description 16:59:19 Extra capabilities just show up as extra keys 16:59:37 We're at the end of the meeting. Thanks for the update jakecoll! 16:59:48 And thanks everyone for joining. Talk to you in two weeks! 17:00:00 #endmeeting