16:00:21 <priteau> #startmeeting blazar
16:00:22 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:25 <openstack> The meeting name has been set to 'blazar'
16:00:47 <priteau> #topic Roll call
16:01:36 <priteau> Any Blazar folks around?
16:01:39 <tzumainn> hi!
16:02:26 <priteau> Hi tzumainn
16:04:38 <priteau> There should be at least one other person joining.
16:05:53 <geo_> count me in
16:05:57 <priteau> Hi geo_
16:06:53 <geo_> still working on the identities; I was turnerg last week
16:07:05 <priteau> I was going to ask about this
16:07:22 <geo_> yeh; old dog, new tricks ya' know
16:09:02 <priteau> I've put usage enforcement again on the agenda for today, as the conversation was quite lively
16:09:28 <priteau> #topic Usage enforcement
16:09:43 <priteau> Once question I was asking at the end of the meeting last week
16:09:45 <priteau> 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 <priteau> 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 <geo_> Yeh, you'd have to; speaking for us, it's doable
16:15:39 <priteau> diurnalist: Would an approach like this be of interest for Chameleon if it meant dropping usage enforcement from your fork?
16:16:40 <diurnalist> 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 <diurnalist> but i suppose enforcement is something that makes sense for a system like blazar to encapsulate
16:17:05 <diurnalist> regardless of how the inventory of resources is managed
16:18:10 <diurnalist> 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 <diurnalist> 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 <priteau> Yeah I said REST but I was thinking something over HTTP really
16:19:33 <diurnalist> ah, ok :+1:
16:21:33 <priteau> 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 <priteau> That's more work for the HTTP service of course.
16:23:06 <priteau> 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 <priteau> Let me explain in more details
16:24:24 <priteau> 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 <priteau> We could put a weight tag on each node to help Blazar with selecting the right resource.
16:28:07 <priteau> But any advanced policy and tracking against externally-stored allocations would have to be done via this HTTP service
16:28:47 <priteau> 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 <diurnalist> Yes, I guess the question is whether cost is important enough to be a concept in Blazar
16:31:07 <diurnalist> 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 <diurnalist> but this is more of a gut feeling
16:32:09 <priteau> It wouldn't strictly be related to cost, it could be an abstract weight. Like weighers in Nova scheduler.
16:32:09 <diurnalist> 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 <diurnalist> right
16:32:58 <diurnalist> 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 <diurnalist> 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 <diurnalist> 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 <priteau> 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 <diurnalist> 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 <diurnalist> yeah
16:35:35 <diurnalist> 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 <priteau> No problem. Thanks for your valuable input.
16:36:01 <diurnalist> 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 <priteau> #action Spec an external HTTP service that can compute reservation usage and accept/deny it
16:38:14 <priteau> #agreed Start with a simple external HTTP service without trying to make smart resource selection
16:38:46 <priteau> Hi jakecoll
16:39:11 <jakecoll> Hey, sry I'm late
16:42:15 <priteau> 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 <priteau> Anything else you would like to discuss on this topic?
16:46:45 <priteau> #topic AOB
16:47:47 <priteau> 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 <jakecoll> priteau: I'm working on adding the allocations api to the blazar-dashboard
16:50:13 <priteau> Nice! Is the API complete enough to implement it?
16:50:17 <jakecoll> this has involved adding more lease info in the allocations api in stein itself.
16:51:00 <jakecoll> In stein, there still isn't allocation api support for other resoures like networks for floating ips
16:51:33 <priteau> No, it's planned for Train
16:51:37 <jakecoll> Also, would be good to expose extra capabilities via an api call
16:51:48 <jakecoll> dashboard has to hit db for that info too
16:53:48 <priteau> Don't you get them if you GET /v1/os-hosts
16:56:05 <jakecoll> You might be right there
16:56:48 <priteau> 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 <priteau> It may be due to completely unoptimised DB queries
16:59:03 <priteau> I've checked, they are included in the host description
16:59:19 <priteau> Extra capabilities just show up as extra keys
16:59:37 <priteau> We're at the end of the meeting. Thanks for the update jakecoll!
16:59:48 <priteau> And thanks everyone for joining. Talk to you in two weeks!
17:00:00 <priteau> #endmeeting