09:00:56 #startmeeting blazar 09:00:57 Meeting started Tue Apr 18 09:00:56 2017 UTC and is due to finish in 60 minutes. The chair is masahito. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:01:00 The meeting name has been set to 'blazar' 09:01:18 #topic RollCall 09:01:25 o/ 09:01:31 o/ 09:01:39 \o/ 09:01:55 Today's agenda is... 09:02:06 1. Boston Summit 09:02:22 2. role of resource plugin 09:02:25 3. AOB 09:02:30 anything else? 09:02:38 #chair hiro-kobayashi priteau 09:02:39 Current chairs: hiro-kobayashi masahito priteau 09:02:49 How's instance reservation etherpad? 09:03:01 all right. 09:03:08 3. instance reservation 09:03:37 ok, let's move on first topic. 09:03:49 #topic Boston Summit 09:04:12 about Boston summit, I have two items 09:04:23 1. team meeting time 09:04:30 2. team dinner 09:04:42 go on first. 09:05:01 I prepared doodle to organize Blazar team meeting 09:05:09 Thank you for coordinating the meeting! 09:05:12 #link http://doodle.com/poll/a7pccnhqsuk9tax7 09:05:34 please vote time you can join 09:05:36 o/ 09:05:52 r-mibu: hi 09:05:59 tejaswi, r-mibu: hi! 09:06:19 we're now talking about blazar team meeting time in Boston 09:06:20 masahito, hiro-kobayashi: hi :) 09:06:28 hiro-kobayashi: hi 09:06:32 sorry for the delay 09:06:38 tejaswi: np 09:07:42 r-mibu: tejaswi: if you're in the summit, please add your available time slots 09:07:43 http://doodle.com/poll/a7pccnhqsuk9tax7 09:08:00 got it! 09:08:02 will do 09:08:27 done 09:09:09 I'm thinking 2 or 3 hours for the meeting are good length. 09:09:19 +1 09:09:24 +1 09:10:27 anyway, I plan to pick the slots on Friday. 09:10:57 if you need more time to check, please let me know. 09:11:33 ok, go on next 09:11:46 In the summit, I'd like to have team dinner. 09:11:53 how do you think? 09:11:55 i'll leave on Thursday evening... 09:12:04 +1 to team dinner 09:12:13 +1 Great! 09:13:02 r-mibu: sorry, I mean I plan to decide the slot on this Friday. 09:13:49 Any preference for the day? 09:14:05 +1 to team dinner. I will also attend one from the Scientific Working Group, I don't remember if the day is already chosen 09:14:54 ok, I'll send it in ML because some doesn't join today's meeting. 09:15:08 thanks 09:15:17 There is an official Summit party on Tuesday night 09:15:29 The Scientific-WG dinner is tentatively Wednesday night 09:15:42 Monday for Blazar? 09:15:54 so Monday or thusday? 09:16:30 r-mibu will not be there Thursday evening 09:16:37 r-mibu_ seems to leave on Thusday, so Monday night looks good. 09:16:46 So Monday is the best for the members here. 09:17:05 masahito, yes, i prefer monday 09:17:08 +1, Thursday I will probably be at another event's dinner 09:18:04 ok, then we'll have Monday evening. 09:18:33 Monday evening is booth crow, so after it, right? 09:18:49 get shirts then dinner :) 09:20:03 yep, and wear them 09:20:12 haha 09:20:31 ok, go on next topic. 09:20:49 #topic role of resource plugin 09:21:25 hiro-kobayashi and me discussed role of resource plugin and blazar-manager at https://review.openstack.org/#/c/451365/ 09:22:16 hiro-kobayashi: said blazar-manager should focus on managements about a lease and a reservation. 09:23:05 and resource plugin should only handle *resources*, like host, aggregate and so on. 09:23:40 but resource plugin handles a reservation instead of blazar-manager in current implementation. 09:24:16 so the question here is 09:24:52 1) we should fix the resource plugin only to handle resource, and blazar-manager handles a reservation. 09:25:19 then what is the plugins for? 09:25:32 or 2) we'll change the architecture 09:25:34 plugin of resource manager? 09:25:38 host-reservation plugin 09:26:19 https://github.com/openstack/blazar/blob/master/blazar/plugins/oshosts/host_plugin.py#L63 09:26:45 here is the plugin handles a reservation 09:27:05 masahito: to me the plugin should encapsulate the code managing the reservation of the resource. Blazar-manager creates the lease, but then delegates to each plugin to create/manage a reservation 09:27:34 Currently we have a 1 to 1 mapping between lease and reservation, but the design allows for 1 lease to many reservations 09:27:51 That's right 09:28:00 e.g. one lease containing one host reservation, one volume reservation, and one floating IP reservation 09:28:16 these reservations of different types might need different DB models 09:28:54 so having a common plugin interface to create / update / destroy reservation would make sense to me 09:29:31 it sounds resource plugin represents one resource? 09:29:53 priteau: you mean the manager should delegate the management of reservation to the plugins, right? 09:30:42 I mean if there is some common code for all plugins, it can go in manager, but each plugin will probably need to be called at reservation creation / update time too 09:31:26 Okay. 09:31:27 separation in reservation/lease manager (blazar manager) and resource manager sounds like a clean approach 09:31:41 because we have just one working plugin now, it's hard to separate concerns 09:31:51 blazar manager could also include some policies for reservation validation 09:31:53 when we have another plugin, it will be easier to separate them 09:32:13 GeraldK: hi 09:32:21 That would be a new instance plugin 09:33:00 hi. sorry, i have joined late. i will fill the doodle later today 09:33:07 yes, I'm thinking new instance plugin have one plugin that represents some resources. 09:33:51 In the architecture docs, manager is in charge of reservation. 09:33:51 i support the idea to move reservation handling from plugins 09:33:51 https://github.com/openstack/blazar/blob/master/doc/source/architecture.rst 09:34:35 if I understand the proposed architecture correct, the blazar manager could also do some translation between the northbound APIs and the resource APIs 09:34:50 this original architecture seems good 09:34:56 IMO, it's better to be reservation handling in manager. 09:35:51 and the handler of reservation in manager calls plugin's interface(method) to create resources. 09:36:24 but also calls plugins to do some validation 09:36:47 e.g. for host reservation, checking that min/max or properties arguments are correct should be done in plugin 09:37:03 because these arguments will be likely different for other plugins 09:37:27 right 09:37:54 Who should have a resource allocation algorithm? 09:38:06 so, validate_request() or something is needed to plugin interface. 09:38:08 we need a better interface between manager and plugins 09:38:12 yes 09:38:18 priteau: +1 09:38:31 the interface should be redesigned. 09:38:37 plus ways for plugins to throw exception and ensure the manager cleans up what it already started to do 09:39:12 yes. 09:39:29 GeraldK, yes, but the proposal won't change interaction between manager and api 09:39:53 the reason I raised the topic is for making blazar's task more concrete. 09:40:04 " Who should have a resource allocation algorithm?" is really good question 09:40:44 I would say plugin 09:40:44 'concrete' means more easy to handle rollback and rollfoward in error. 09:40:54 resource allocation is inherently specific to each resource 09:40:58 r-mibu_: I think the allocation algorithm depends on the type of resource. So, the resource plugin should have 09:41:06 priteau: +1 09:41:13 +1 09:41:18 i suggest to put it in plugins and hide whole magic code from manager 09:41:27 right 09:42:04 even we have cascaded resource, we can have wrapper resource plugin 09:42:33 right. 09:42:35 masahito: sounds good 09:43:08 Oh, sorry. r-mibu: sounds good 09:43:43 ok 09:44:03 hiro-kobayashi, np, we had nice discussion 09:44:13 what about a reservation for two instances that should be placed into two different zones? if we treat each resource (=instance) allocation separately, who can we ensure this condition? 09:44:35 And who should manage the reservation info in the Blazar DB? 09:45:09 GeraldK: it depends on what's the pluging. 09:45:16 The problem with the reservation table is that it contains a resource_id 09:45:37 and in the case of the host plugin, this resource_id is the ID of the aggregate allocated by Nova 09:45:55 should we setup an Etherpad with all the different tasks and then try to map tasks to entity? 09:46:05 so, either the plugin creates the reservation DB row, or it returns the values to the manager who creates it 09:46:10 currently host plugin only represents 1 resource. If the plugin represents multi resources. the plugin handle the multi instances. 09:46:39 priteau: Yes. That's complicate the separation of concern 09:47:01 priteau: yes, I planed to raise the question in next topic. 09:47:25 ok, I'll make etherpad to discuss details 09:47:58 we can dig into this topic at the summit, maybe 09:48:06 masahito: thanks! 09:48:07 then we can discuss it with concerns/restrictions/vice verse at next meeting or summit. 09:48:26 # i might propose heat approach 09:49:09 r-mibu_: make sense 09:49:26 let's move on next. 09:49:28 It's good to use heat to handle multiple resources, right? 09:49:55 hiro-kobayashi: it's depends on what heat can handle. 09:50:06 yes, i think so, and user can use HOT for reservations 09:50:31 OK. Let's discuss at the summit 09:50:37 yep 09:50:57 I'm sorry but I have to leave in 5 mins 09:51:10 I created https://etherpad.openstack.org/p/blazar-resource-plugin 09:51:26 #topic instance reservation 09:52:24 some wrote down their comment at the etherpad 09:52:35 https://etherpad.openstack.org/p/resource-plugin 09:53:34 Basing on the page, I'm writing the spec now. 09:53:50 thanks! 09:54:11 I'll push the spec in this week. so we can start to discuss the details soon. 09:54:29 I'm sorry but I have to leave. Thanks! bye 09:55:42 in the instance reservation, resources in a reservation is a map of flavor to number of instances. 09:56:19 so it could hit the topic we talked just before. 09:57:08 any comments or questions? 09:57:25 i cannot see any content in the above link... 09:58:11 I'll check later and reach out you if i still have the same issue 09:58:15 The correct link is: 09:58:17 #link https://etherpad.openstack.org/p/new-instance-reservation 09:58:32 sorry, I missed 09:58:33 https://etherpad.openstack.org/p/new-instance-reservation 09:58:42 thanks! 09:59:03 last 2 mins 10:00:31 running out the time. 10:00:33 thanks all, 10:00:35 bye 10:00:45 bye everyone, thanks for a great meeting 10:00:54 #endmeeting