16:00:45 #startmeeting blazar 16:00:46 Meeting started Thu Jun 6 16:00:45 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:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:49 The meeting name has been set to 'blazar' 16:01:20 #topic Roll call 16:01:46 Helllo 16:04:58 Hi jakeco 16:05:01 Hi tzumainn 16:06:03 Anyone else for the Blazar meeting? 16:06:08 Hi diablo_rojo 16:06:13 Oops sorry 16:06:15 Hi diurnalist 16:06:56 Agenda for today 16:07:01 1. Reservation usage enforcement 16:07:04 2. Upstream contributions 16:07:08 3. AOB 16:07:37 #topic Reservation usage policy enforcement 16:08:41 I've started a spec about this topic. It's still early, I mostly described the problem, use cases, and suggested solutions 16:08:44 #link https://review.opendev.org/#/c/663394/1/doc/source/specs/train/flexible-reservation-usage-enforcement.rst 16:09:01 It would be nice to get your input on it to make sure we are on the same page 16:09:23 If we agree on the approach, next step will be to draft the API schema 16:11:58 thanks priteau, i will have a look 16:13:30 You're the main Blazar users so your input is most appreciated ;-) 16:14:28 Do you have an example of a policy web service blazar would be querying? 16:15:52 Not yet, that's the next step in writing the spec. But I assume it could be similar to the way the usage enforcement module in Chameleon's fork is implemented 16:16:37 Calls on create_lease and update_lease to check if the operation is approved 16:16:52 The trick is which info needs to be passed so that the service can make a good decision 16:19:21 We can discuss more the interaction between the services once I have a strawman 16:21:03 Anything else you want to add on this topic? 16:21:35 not from me, i imagine discussion can move to that review 16:21:54 yes 16:22:24 #topic Upstream contributions 16:23:42 I wanted to talk about other features or bug fixes that might be in Chameleon's Blazar and would make sense upstream. 16:23:50 IIRC there are several: 16:24:31 - Network segment reservation. It's on my TODO list to write the spec, I will ask you to review and once approved we can push upstream Chameleon's code for it 16:25:17 - the randomness in the node selection 16:25:52 I don't remember where but I had left a comment saying that the randomness could be made configurable as it is in the placement API 16:26:36 #link https://github.com/ChameleonCloud/blazar/pull/5#issuecomment-422465427 16:27:43 - the heat integration would need to be spec'ed, personally I am not yet convinced if this is the right approach 16:28:19 - blazar-dashboard enhancements (including calendar) 16:28:32 yea, neither is Zane over on the Heat team 16:29:00 Where did you have this discussion? 16:30:18 I submitted a storyboard and code for review 16:31:05 He just said he wasn't sure if stack initialization was the right approach. 16:31:42 I had missed it, I was looking for contributions using your uchicago address 16:32:24 It should be under my gmail since I already had an Ubuntu One account 16:33:44 #link https://storyboard.openstack.org/#!/story/2005652 16:33:49 #link https://storyboard.openstack.org/#!/story/2005654 16:33:53 #link https://storyboard.openstack.org/#!/story/2005653 16:34:18 yep, those the ones 16:35:39 Last one is pure Heat, not linked to Blazar at all. 16:36:54 I am sure I forgot many bug fixes in the list above. It would be good to figure out what is left to push upstream. I think I had a document at some point but it must be out of date. 16:39:24 Is there any other feature that would make sense to upstream? 16:39:56 I cut a stein branch a few weeks ago. Added more lease info to allocations api. 16:40:12 Should help us ease off db reliance in blazar-dashboard 16:40:27 we also have a patch to allow running an operator-defined script before a lease ends. we use it to send notification emails 16:40:48 What is the actual timeline on Train? 16:41:15 i'm not sure about this one. the use-case is good, but it's a bit difficult to integrate with (a) containers and (b) various mail idiosynchracies 16:41:33 diurnalist: I thought again about this feature. I think this would be better implemented using notifications 16:41:46 *idiosyncrasies - can never spell that right 16:41:50 When enabled, Blazar already sends notifications on before_end_lease events 16:42:05 so you mean listening on the message bus? 16:42:13 You could have a completely separate service listening for them and generating the emails 16:42:58 yes. another thing though is, usually sending a mail is something best done quite a ways before the lease ends. the "normal" use of before_end is to do something immediately before ending. like taking a snapshot 16:43:16 so i'm not too sure. long story short, we have this patch but idk how it fits upstream 16:45:24 We could add support for multiple before_end_lease events with configurable timers 16:45:38 One for emails 48h before, one for snapshot 30 minutes before 16:49:09 I think that would be a more flexible approach, including for users if we eventually have more before_end actions 16:50:08 We've lost Jason 16:50:37 I'll open a bug on Launchpad to remember about the multiple before_end events 16:50:46 #topic AOB 16:50:51 Anything else to discuss folks? 16:52:45 #link https://bugs.launchpad.net/blazar/+bug/1831925 16:52:46 Launchpad bug 1831925 in Blazar "Support multiple before_end_lease events" [Undecided,New] 16:54:11 If there's nothing else to discuss we can end the meeting early. 16:54:34 Thanks for joining! 16:54:34 :+1: 16:54:38 #endmeeting