16:04:44 <priteau> #startmeeting blazar
16:04:45 <openstack> Meeting started Thu Jan 30 16:04:44 2020 UTC and is due to finish in 60 minutes.  The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:48 <openstack> The meeting name has been set to 'blazar'
16:05:13 <priteau> #topic Roll call
16:05:57 <diurnalist> o/
16:06:01 <jakecoll> o/
16:06:02 <priteau> Hi diurnalist, jakecoll
16:06:09 <jakecoll> good monring
16:06:10 <diurnalist> hey
16:06:22 <priteau> Agenda for today:
16:06:26 <priteau> * Ussuri planning and priorities
16:06:33 <priteau> * Upstream contributions
16:06:36 <priteau> * AOB
16:06:41 <priteau> #topic Ussuri planning and priorities
16:07:00 <priteau> Our initial post-PTG planning is at https://etherpad.openstack.org/p/blazar-ptg-ussuri
16:07:26 <priteau> I am afraid we're already quite late compared to the tentative schedule I had proposed
16:07:44 <priteau> I've focused on the preemtible spec as that's the main priority for us
16:08:52 <jakecoll> Really? Pre-emptible is a priority now?
16:09:23 <priteau> I mean for us = for my employer
16:09:35 <priteau> Not for us = Blazar project
16:09:53 <jakecoll> OVH involved in that at all?
16:10:24 <priteau> I've heard they were interested by the idea but they're not involved.
16:10:41 <priteau> diurnalist: a few weeks ago jakecoll was telling me that time to contribute to upstream Blazar was very limited, is it still the case? I would really like to get at least network reservation upstream.
16:11:26 <diurnalist> priteau: I would like that too, but what does this entail precisely, given that it's already written and in production here?
16:12:17 <priteau> There were some comments to answer on the spec: https://review.opendev.org/#/c/674089/
16:13:06 <diurnalist> thanks, i always forget there is a separate project for specs
16:13:29 <priteau> I've added you as a reviewer of the change
16:14:20 <diurnalist> so i understand, the plan would be to review/address comments, then the spec is merged, then submit a changeset for the feature (with doc updates), and then done?
16:14:41 <priteau> On a cursory look the comments are minor, so if we can get the spec updated and approved, it will unlock review & merge of the code.
16:15:13 <priteau> That's pretty much it. The iteration on the spec might lead to some code changes but probably nothing major.
16:16:33 <diurnalist> there has been less appetite for committing time to blazar lately, but given that preemptible instances might be forthcoming, we can probably make a stronger case for this
16:16:58 <priteau> Are you interested by preemptibles in Chameleon?
16:17:14 <jakecoll> I am. I can't speak for Kate
16:17:39 <priteau> Cool, I didn't that.
16:17:57 <jakecoll> They make less sense now that we delete reservations that don't launch instances in six hours
16:18:10 <priteau> But nevermind preemptibles, if network reservation can be merged, that's one less change you have to worry about maintaining.
16:18:22 <jakecoll> But we had pretty low utilization of our leases before, especially on GPUs
16:18:29 <jakecoll> Make sense for high-demand resources
16:18:30 <diurnalist> yeah. i'm a bit skeptical it will work nicely in our model, where users typically want guaranteed access for some time. but it could be interesting, who knows
16:18:52 <diurnalist> priteau: we would deploy it, i think
16:19:24 <diurnalist> priteau: the main priority from our PoV is the usage enforcement, as it ties in with other work we are doing around how we manage quotas/allocations on our cloud. maybe we should take ownership of that one.
16:19:28 <priteau> Note that the preemptibles design I am proposing is to fill up space between reservations, not within active-but-unused reservations.
16:19:55 <priteau> diurnalist: re usage enforcement, that would be ideal. I don't have the time to push this forward at the moment.
16:22:18 <diurnalist> OK, i see there is a pre-existing spec already, i'll have a look and update w/ some of my more recent ideas
16:23:20 <diurnalist> so i am aware, what is the quota feature?
16:23:28 <priteau> Thanks a lot. We just need to make sure it's generic enough to cover most use cases, not just Chameleon
16:23:33 <diurnalist> is it just making sure that blazar doesn't allow doing things that exceed quotas?
16:23:37 <diurnalist> priteau: of course
16:24:33 <priteau> That's integration with existing OpenStack quota. Currently, in the absence of usage enforcement, any Blazar user can reserve large amounts of resources, even if their quota says they can only run N instances
16:24:53 <diurnalist> right, jakecoll and I were discussing this the other day, by chance
16:24:58 <diurnalist> OK, makes sense
16:25:08 <priteau> So either limit leases compared to the Nova quota for instances, or introduce a separate quota
16:25:25 <diurnalist> any idea how that will affect host reservations?
16:25:42 <diurnalist> i presume that would involve a new quota
16:26:18 <priteau> Host reservation is the tricky bit, because you don't know in advance how many instances might be launched on a hypervisor (unless you have just one flavor)
16:26:51 <priteau> Maybe host reservation needs a separate quota, and instance reservation can sync with Nova's quota
16:27:25 <diurnalist> right
16:27:29 <priteau> Feel free to share ideas via etherpad documents if they are not ready to be shared as a spec
16:27:37 <priteau> https://etherpad.openstack.org/
16:27:51 <priteau> Just create a new doc and link it from https://etherpad.openstack.org/p/blazar-ptg-ussuri
16:28:28 <diurnalist> :+1:
16:29:09 <priteau> I guess we've covered priorities
16:29:18 <priteau> #topic Upstream contributions
16:29:42 <priteau> I was just taking a look at your latest proposed change
16:29:44 <priteau> https://review.opendev.org/#/c/704628/
16:30:10 <priteau> I've fixed the zuul checks, mock 3.0.0 was needed (plus removal of extra newlines)
16:30:55 <priteau> I'll take a look later (probably only next week as I am off tomorrow) at the actual code
16:31:52 <priteau> Is this a change that improves a specific use case?
16:32:25 <jakecoll> It's a bug fix
16:32:29 <diurnalist> yes, any time a system uses the blazarclient to fetch a lease. mostly, the horizon lease detail page
16:32:53 <diurnalist> the blazarclient will fetch a list of all leases, iterate over them to find one with the given ID, then return that ID. then it will fetch the lease with that ID.
16:33:16 <diurnalist> skipping the first step saves an expensive call. something i found when trying to figure out why blazardashboard is so slow
16:34:22 <priteau> Nice improvement
16:35:02 <diurnalist> i didn't file a bug in blazardashboard or anything, so it appears a bit out of the blue. but i wasn't sure a bug report was appropriate in this case
16:36:25 <priteau> Not strictly necessary, but it's helpful to keep track of improvements. More so on the service side, to keep track of what we should backport.
16:37:41 <diurnalist> OK
16:38:30 <priteau> And it also bumps your institution's counter of "Fixed bugs" on Stackalytics ;-)
16:38:42 <diurnalist> haha
16:41:34 <priteau> We've covered other contributions in the previous agenda item
16:41:37 <priteau> #topic AOB
16:41:42 <priteau> Anything else to discuss today?
16:42:17 <jakecoll> I don't have anything at the moment
16:44:17 <priteau> Thanks a lot for joining today, it was good to sync
16:44:29 <jakecoll> :+1:
16:44:36 <priteau> Bye
16:44:39 <priteau> #endmeeting