16:00:57 #startmeeting blazar 16:00:58 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:01 The meeting name has been set to 'blazar' 16:01:05 #topic Roll call 16:01:23 Hi jakecoll 16:01:47 good morning 16:02:13 Is diurnalist around? 16:02:20 He wanted to join today 16:02:52 I'll ping. He wanted to talk about a spec today. 16:03:14 o/ 16:03:38 Hi diurnalist 16:03:47 Hello- I got mixed up with DST 16:04:07 Has it changed in the US already? 16:04:49 Nah it's in 10 days 16:04:53 Anyways 16:05:03 It messes with calendar if you haven't downloaded the ics file from the meetings page 16:05:06 Agenda for today: 16:05:15 * Update on specs work 16:05:19 ok, not sure what happened. i had it written down for 11am 16:05:19 * Upstream contributions 16:05:21 * AOB 16:05:29 http://eavesdrop.openstack.org/#Blazar_Team_Meeting 16:05:51 You'll want to add ics file at this link 16:05:55 Import the ical file and you won't have to ever update it 16:06:10 thx 16:06:20 #topic Update on specs work 16:06:50 I am happy to say that I finally reviewed your spec diurnalist 16:06:51 #link https://review.opendev.org/#/c/707042/ 16:07:06 Sorry it took a couple of weeks 16:08:04 Overall I like the approach, just need to iron out some details of the payload 16:09:15 Looks like tetsuro is not yet convinced 16:09:44 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 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 Did you see my suggestion from today 16:10:30 Yes 16:10:51 Use the plugin approach, with one of the plugins making calls to the external service 16:11:25 This way we could have a SimpleEnforcement plugin that does simple things like check max duration 16:11:35 NoopEnforcement would be default 16:11:37 ah, that's what you meant. yes, that might make sense 16:11:46 ExternalEnforcement would be your approach 16:12:18 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 s/their/they're/ 16:12:47 yes, that's of course more work but i had thought it would likely move in that direction eventually 16:12:51 A downside is that it means more places where the interface might change over time 16:13:20 But maybe it's not that much more work. After all, we probably want to encapsulate this anyway 16:13:24 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 That's right 16:13:58 Although one might want QuotaEnforcement + ExternalEnforcement 16:14:08 >.< 16:14:11 haha 16:14:21 So it could be a list of plugins that are called sequentially 16:14:26 yeah, like nova's scheduler 16:14:27 like scheduler filters 16:15:09 This is making the design a fair amount bigger, but it might be more flexible down the line 16:15:21 And if it solves tetsuro's concerns at the same timeā€¦ 16:15:30 yep 16:15:36 I like the idea 16:16:10 The spec should describe the plugin API first then 16:16:37 Or another spec for the plugin API, the current one focusing on a specific implementation 16:17:11 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 I can just put it in 'related' links 16:17:30 But I don't know if something more formal is usually done 16:17:54 I am not aware of any specific approach 16:18:35 References would be fine 16:19:03 What do you think about the need for identifying cloud & region in case the external service is shared? 16:20:35 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 I was just inspecting a token. One can get domain from that, but not region 16:23:11 I wanted to ask you why you were passing the client token to the service 16:23:29 In one of the vendordata2 specs, they say they should actually be passing a token from nova 16:24:18 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 and auth_url 16:25:01 What's inside a fernet token? 16:25:51 project (id+name+domain), user (id+name+domain), roles attached, expiry, and endpoint catalog 16:26:19 and an issue date, and some other bookkeeping things like an audit ID and which auth method was used 16:27:07 Are you sure the catalog is in there? 16:27:10 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 i'm just saying, if you inspect the token, the catalog is returned 16:27:22 "This issue is mitigated when switching to fernet because fernet tokens are kept under a 250 byte limit." 16:27:28 it's likely not encoded in there directly 16:27:32 Oh I see 16:27:44 PKI and PKIZ tokens apparently include the catalog 16:28:16 I think we should avoid transferring those tokens around 16:28:30 Sure 16:28:52 If everything can be done with the admin token, that is simpler 16:29:12 I was more worried that admin APIs might have missing functionality 16:29:58 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 I think you can get all the information you need 16:30:50 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 I don't really like the idea of an external service making requests using a user token 16:31:03 which is in fact another argument for not sending the user token 16:31:12 I am not disagreeing 16:32:05 I'll update the spec 16:32:13 Thanks 16:32:25 I think that's the main points I wanted to raise 16:32:31 Already quite a lot :-) 16:33:39 #topic Upstream contributions 16:34:49 jakecoll: I see you've updated your network reservation patch, thanks 16:34:53 It's next on my review list 16:35:27 I've also flagged it as a review priority for the rest of the team 16:35:54 yep. I just finished add allocations to networks on our fork. I'll update that as well. 16:36:35 That's great 16:36:48 Are you using the allocations API for blazar-dashboard now? 16:37:22 Yes. Just went live on prod 5 minutes ago. 16:37:33 wooo 16:37:36 We've been using it for the hosts dashboard for a few months 16:37:50 now it's in place for all types :) 16:38:11 I didn't realise it was already on the host dashboard 16:38:44 So except for gathering node types (which is a Chameleon concept), calendar could be database-query-free? 16:39:14 Well, diurnalist has another spec he wanted to talk about to get us there. 16:39:47 Ah, that's what you wanted to talk about? 16:39:55 Sorry, I thought it was the usage enforcement one 16:39:59 Let's talk about it then 16:41:48 Yes, sorry 16:42:12 So, one of the improvements we've additionally made to blazar-dashboard is around making resource_properties easier to use 16:42:28 Right now you have to know the somewhat arcane invocation needed, especially when combining queries 16:42:44 So we have this resource filter (I know you know this, I'm just expanding for IRC logs) 16:43:14 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 This makes discovering possible resource property constraints much easier 16:43:34 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 Yes 16:43:52 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 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 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 It's admin only by default 16:45:01 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 Ah ok, then another reason to do it. 16:45:16 One thing I would say then 16:45:33 We may want to extend the DB schema to flag extra cap as user-visible 16:45:50 Because operators may want to reserve some for them 16:45:55 That's a good point 16:46:24 You were thinking of something like GET /os-hosts/properties? 16:46:56 Yes, though extensions in to networks and other resources like IPs would also make sense 16:47:03 it's a cross-cutting feature in my mind 16:47:04 Of course 16:47:16 Though we already have /os-hosts/allocations 16:48:07 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 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 extra caps is per-model 16:49:59 Although I was thinking of abstracting it into a ResourceExtraCap model to make it more reusable 16:50:30 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 But from this "properties" API--sounds OK in principle? 16:50:56 *for 16:51:00 Sounds OK to me 16:51:05 Spec needed of course 16:51:18 Yep 16:53:13 We're getting near the end of the hour 16:53:18 #topic AOB 16:53:20 Anything else to cover? 16:54:18 We have not yet discussed participating at Vancouver 16:54:21 I'm good for now. I'll keep a look out for comments on networks plugin 16:54:28 oh right 16:54:46 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 diurnalist: I've requested 0.5 to 1.5 day for Blazar 16:54:51 ok 16:54:56 tetsuro will be there. I don't know yet 16:56:28 Still some months away 16:56:45 mmhmm 16:57:19 Nothing else from me then 16:57:19 Wrapping up if there's nothing else? 16:57:29 Thanks a lot for the good discussion today 16:57:38 Great to get contributions from you 16:58:03 Next meeting the time will have changed in your local timezone! 16:58:13 Cheers! 16:58:17 #endmeeting