16:00:57 <priteau> #startmeeting blazar
16:00:58 <openstack> Meeting started Thu Feb 27 16:00:57 2020 UTC and is due to finish in 60 minutes.  The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:01 <openstack> The meeting name has been set to 'blazar'
16:01:05 <priteau> #topic Roll call
16:01:23 <priteau> Hi jakecoll
16:01:47 <jakecoll> good morning
16:02:13 <priteau> Is diurnalist around?
16:02:20 <jakecoll> He wanted to join today
16:02:52 <jakecoll> I'll ping. He wanted to talk about a spec today.
16:03:14 <diurnalist> o/
16:03:38 <priteau> Hi diurnalist
16:03:47 <diurnalist> Hello- I got mixed up with DST
16:04:07 <priteau> Has it changed in the US already?
16:04:49 <priteau> Nah it's in 10 days
16:04:53 <priteau> Anyways
16:05:03 <jakecoll> It messes with calendar if you haven't downloaded the ics file from the meetings page
16:05:06 <priteau> Agenda for today:
16:05:15 <priteau> * Update on specs work
16:05:19 <diurnalist> ok, not sure what happened. i had it written down for 11am
16:05:19 <priteau> * Upstream contributions
16:05:21 <priteau> * AOB
16:05:29 <jakecoll> http://eavesdrop.openstack.org/#Blazar_Team_Meeting
16:05:51 <jakecoll> You'll want to add ics file at this link
16:05:55 <priteau> Import the ical file and you won't have to ever update it
16:06:10 <diurnalist> thx
16:06:20 <priteau> #topic Update on specs work
16:06:50 <priteau> I am happy to say that I finally reviewed your spec diurnalist
16:06:51 <priteau> #link https://review.opendev.org/#/c/707042/
16:07:06 <priteau> Sorry it took a couple of weeks
16:08:04 <priteau> Overall I like the approach, just need to iron out some details of the payload
16:09:15 <priteau> Looks like tetsuro is not yet convinced
16:09:44 <diurnalist> sounds good--I still prefer the service approach, but I'd be willing to follow something like a plugin approach using stevedore. with the downsides that it requires you to (a) use Python and (b) package the module locally (which usually means "manually") when using something like Kolla
16:10:18 <diurnalist> i'll call out the downsides i see a bit more clearly in the alternatives and add the links you mentioned ot nova vendordata2. in that spec they discuss similar things
16:10:24 <priteau> Did you see my suggestion from today
16:10:30 <diurnalist> Yes
16:10:51 <priteau> Use the plugin approach, with one of the plugins making calls to the external service
16:11:25 <priteau> This way we could have a SimpleEnforcement plugin that does simple things like check max duration
16:11:35 <priteau> NoopEnforcement would be default
16:11:37 <diurnalist> ah, that's what you meant. yes, that might make sense
16:11:46 <priteau> ExternalEnforcement would be your approach
16:12:18 <priteau> Anyone could load their CustomEnforcement if they wish, their responsible for figuring out how to include the code in their container images if using kolla
16:12:26 <priteau> s/their/they're/
16:12:47 <diurnalist> yes, that's of course more work but i had thought it would likely move in that direction eventually
16:12:51 <priteau> A downside is that it means more places where the interface might change over time
16:13:20 <priteau> But maybe it's not that much more work. After all, we probably want to encapsulate this anyway
16:13:24 <diurnalist> it also opens the door to some sort of default QuotaEnforcement thing, which i think there is related work being thought about?
16:13:34 <priteau> That's right
16:13:58 <priteau> Although one might want QuotaEnforcement + ExternalEnforcement
16:14:08 <diurnalist> >.<
16:14:11 <diurnalist> haha
16:14:21 <priteau> So it could be a list of plugins that are called sequentially
16:14:26 <diurnalist> yeah, like nova's scheduler
16:14:27 <priteau> like scheduler filters
16:15:09 <priteau> This is making the design a fair amount bigger, but it might be more flexible down the line
16:15:21 <priteau> And if it solves tetsuro's concerns at the same time…
16:15:30 <diurnalist> yep
16:15:36 <diurnalist> I like the idea
16:16:10 <priteau> The spec should describe the plugin API first then
16:16:37 <priteau> Or another spec for the plugin API, the current one focusing on a specific implementation
16:17:11 <diurnalist> Probably two specs makes sense in this case. If you have suggestions of how best to logically link them, I'd be interested
16:17:19 <diurnalist> I can just put it in 'related' links
16:17:30 <diurnalist> But I don't know if something more formal is usually done
16:17:54 <priteau> I am not aware of any specific approach
16:18:35 <priteau> References would be fine
16:19:03 <priteau> What do you think about the need for identifying cloud & region in case the external service is shared?
16:20:35 <diurnalist> Yes, I think that will be necessary. But, do you think that auth URL will be enough? I wonder if you can get region/domain from the client token.
16:22:05 <diurnalist> I was just inspecting a token. One can get domain from that, but not region
16:23:11 <priteau> I wanted to ask you why you were passing the client token to the service
16:23:29 <priteau> In one of the vendordata2 specs, they say they should actually be passing a token from nova
16:24:18 <diurnalist> I guess we don't need to. I initially thought it would be useful to fetch the list of leases under the user. But you can do that with the admin token. So, I guess user_id, project_id, user_domain_id, project_domain_id, and region_name will all have to be sent. Kind of a lot, but not sure how else to do it.
16:24:28 <diurnalist> and auth_url
16:25:01 <priteau> What's inside a fernet token?
16:25:51 <diurnalist> project (id+name+domain), user (id+name+domain), roles attached, expiry, and endpoint catalog
16:26:19 <diurnalist> and an issue date, and some other bookkeeping things like an audit ID and which auth method was used
16:27:07 <priteau> Are you sure the catalog is in there?
16:27:10 <priteau> https://docs.openstack.org/keystone/latest/admin/fernet-token-faq.html#why-should-i-choose-fernet-tokens-over-pki-or-pkiz-tokens
16:27:21 <diurnalist> i'm just saying, if you inspect the token, the catalog is returned
16:27:22 <priteau> "This issue is mitigated when switching to fernet because fernet tokens are kept under a 250 byte limit."
16:27:28 <diurnalist> it's likely not encoded in there directly
16:27:32 <priteau> Oh I see
16:27:44 <priteau> PKI and PKIZ tokens apparently include the catalog
16:28:16 <priteau> I think we should avoid transferring those tokens around
16:28:30 <diurnalist> Sure
16:28:52 <diurnalist> If everything can be done with the admin token, that is simpler
16:29:12 <diurnalist> I was more worried that admin APIs might have missing functionality
16:29:58 <diurnalist> if one needed to call other openstack APIs. a design where the token is decomposed as early as possible in the request chain is better in these distributed systems IMO
16:30:00 <priteau> I think you can get all the information you need
16:30:50 <diurnalist> We do at least need blazar to send some token of its own to the service, so the service knows it's actually blazar
16:31:03 <priteau> I don't really like the idea of an external service making requests using a user token
16:31:03 <diurnalist> which is in fact another argument for not sending the user token
16:31:12 <diurnalist> I am not disagreeing
16:32:05 <diurnalist> I'll update the spec
16:32:13 <priteau> Thanks
16:32:25 <priteau> I think that's the main points I wanted to raise
16:32:31 <priteau> Already quite a lot :-)
16:33:39 <priteau> #topic Upstream contributions
16:34:49 <priteau> jakecoll: I see you've updated your network reservation patch, thanks
16:34:53 <priteau> It's next on my review list
16:35:27 <priteau> I've also flagged it as a review priority for the rest of the team
16:35:54 <jakecoll> yep. I just finished add allocations to networks on our fork. I'll update that as well.
16:36:35 <priteau> That's great
16:36:48 <priteau> Are you using the allocations API for blazar-dashboard now?
16:37:22 <jakecoll> Yes. Just went live on prod 5 minutes ago.
16:37:33 <priteau> wooo
16:37:36 <diurnalist> We've been using it for the hosts dashboard for a few months
16:37:50 <diurnalist> now it's in place for all types :)
16:38:11 <priteau> I didn't realise it was already on the host dashboard
16:38:44 <priteau> So except for gathering node types (which is a Chameleon concept), calendar could be database-query-free?
16:39:14 <jakecoll> Well, diurnalist has another spec he wanted to talk about to get us there.
16:39:47 <priteau> Ah, that's what you wanted to talk about?
16:39:55 <priteau> Sorry, I thought it was the usage enforcement one
16:39:59 <priteau> Let's talk about it then
16:41:48 <diurnalist> Yes, sorry
16:42:12 <diurnalist> So, one of the improvements we've additionally made to blazar-dashboard is around making resource_properties easier to use
16:42:28 <diurnalist> Right now you have to know the somewhat arcane invocation needed, especially when combining queries
16:42:44 <diurnalist> So we have this resource filter (I know you know this, I'm just expanding for IRC logs)
16:43:14 <diurnalist> It's a UI element that lists all the resource property keys that are available for filtering. The user selects which key they want to filter on, and then a list of all possible values for that key are displayed, allowing them to pick one.
16:43:26 <diurnalist> This makes discovering possible resource property constraints much easier
16:43:34 <priteau> And so we would need an API to discover these properties, as I think they are not visible to users by default?
16:43:39 <diurnalist> Yes
16:43:52 <diurnalist> They _may_ be visible to users by default, I'm not sure what the default host:list or host:get permissions are
16:44:16 <diurnalist> But in any case, an API call will likely be much more efficient than the alternative, which is asking for every possible resource and then itemizing all keys/values
16:44:36 <diurnalist> Plus, I thought it might actually be kind of easy to implement given how Blazar already has support for these extra capabilities, which are arbitrary k/v pairs
16:44:45 <priteau> It's admin only by default
16:45:01 <diurnalist> It's a bit of a weird API as it'd mainly be used in the dashboard, but if we design it nicely, it would probably be helpful for CLI users as well
16:45:06 <diurnalist> Ah ok, then another reason to do it.
16:45:16 <priteau> One thing I would say then
16:45:33 <priteau> We may want to extend the DB schema to flag extra cap as user-visible
16:45:50 <priteau> Because operators may want to reserve some for them
16:45:55 <diurnalist> That's a good point
16:46:24 <priteau> You were thinking of something like GET /os-hosts/properties?
16:46:56 <diurnalist> Yes, though extensions in to networks and other resources like IPs would also make sense
16:47:03 <diurnalist> it's a cross-cutting feature in my mind
16:47:04 <priteau> Of course
16:47:16 <priteau> Though we already have /os-hosts/allocations
16:48:07 <diurnalist> I think the API design is a bit odd in that we are re-implementing the same thing on multiple paths, but that's neither here nor there. I think if we define /properties as the path, it can extend os-hosts/ and networks/ and whatever else
16:49:25 <diurnalist> to be honest i'm not even sure how easy it is to make it a "general" feature because i think we re-implement all of the DB schemas as well for each resource type. don't we have to re-implement extra caps for example? i need to double-check
16:49:40 <priteau> extra caps is per-model
16:49:59 <priteau> Although I was thinking of abstracting it into a ResourceExtraCap model to make it more reusable
16:50:30 <diurnalist> I would support that. I think there are other aspects of Blazar that should really be shared logic as well. it's becoming more important as the types of resources are scaling
16:50:50 <diurnalist> But from this "properties" API--sounds OK in principle?
16:50:56 <diurnalist> *for
16:51:00 <priteau> Sounds OK to me
16:51:05 <priteau> Spec needed of course
16:51:18 <diurnalist> Yep
16:53:13 <priteau> We're getting near the end of the hour
16:53:18 <priteau> #topic AOB
16:53:20 <priteau> Anything else to cover?
16:54:18 <diurnalist> We have not yet discussed participating at Vancouver
16:54:21 <jakecoll> I'm good for now. I'll keep a look out for comments on networks plugin
16:54:28 <jakecoll> oh right
16:54:46 <diurnalist> Maybe next time we will know what the plan is. Pierre, are you planning on being there? Are any other Blazar core members?
16:54:49 <priteau> diurnalist: I've requested 0.5 to 1.5 day for Blazar
16:54:51 <diurnalist> ok
16:54:56 <priteau> tetsuro will be there. I don't know yet
16:56:28 <priteau> Still some months away
16:56:45 <diurnalist> mmhmm
16:57:19 <diurnalist> Nothing else from me then
16:57:19 <priteau> Wrapping up if there's nothing else?
16:57:29 <priteau> Thanks a lot for the good discussion today
16:57:38 <priteau> Great to get contributions from you
16:58:03 <priteau> Next meeting the time will have changed in your local timezone!
16:58:13 <diurnalist> Cheers!
16:58:17 <priteau> #endmeeting