09:00:44 <masahito> #startmeeting blazar
09:00:44 <openstack> Meeting started Tue Mar  7 09:00:44 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:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:45 <hiro-kobayashi> hi
09:00:48 <openstack> The meeting name has been set to 'blazar'
09:00:56 <masahito> #chair priteau hiro-kobayashi
09:00:56 <openstack> Current chairs: hiro-kobayashi masahito priteau
09:01:20 <masahito> #topic RollCall
09:01:29 <hiro-kobayashi> o/
09:01:30 <masahito> \o/
09:01:46 <priteau> o/
09:02:32 <masahito> Todays agenda is...
09:02:42 <masahito> 1. action items from last call
09:02:46 <masahito> 2. O release
09:02:53 <masahito> 3. Pike blueprints
09:02:56 <masahito> 4. AOB
09:03:03 <masahito> anything else?
09:03:34 <hiro-kobayashi> nothing
09:03:48 <masahito> #topic Action items from last meeting
09:04:23 <masahito> I can see one action item from last meeting
09:04:35 * masahito tejaswi to open bug about 'host update'
09:05:01 <masahito> but it looks like tejaswi isn't here today.
09:05:22 <hiro-kobayashi> I cannot find the bug entry on Launchpad
09:05:44 <masahito> yes, so skip to next topic.
09:06:02 <masahito> #topic O release
09:07:40 <masahito> I'm thinking I'll cut 0.2.0 release tomorrow morning because other team starts their activities and it affects blazar repo now.
09:08:04 <hiro-kobayashi> +1
09:08:07 <GeraldK> o/
09:08:10 <bertys__> +1
09:08:17 <GeraldK> +1
09:08:23 <tejaswi_> o/
09:08:32 <priteau> I'll try to push my patch later today
09:08:49 <priteau> I am working on an update following your comments
09:08:59 <masahito> From etherpad page, only this patch is under the review but easy to backport lator
09:09:10 <masahito> GeraldK: tejaswi_: o/
09:09:38 <bertys__> priteau: have you received feedback from previous cores?
09:09:47 <priteau> none :(
09:10:33 <masahito> priteau: thanks. I'll check it tomorrow.
09:11:09 <bertys__> priteau: well this is 3 years old...
09:13:02 <masahito> we can improve current blazar. if we get any feedback we can respond it.
09:13:23 <masahito> any comments for the release?
09:13:35 <hiro-kobayashi> About docs
09:13:46 <hiro-kobayashi> I've published docs on readthedocs.org
09:13:54 <hiro-kobayashi> #link http://blazar.readthedocs.io/en/latest/
09:14:14 <hiro-kobayashi> This docs are built from the doc directory of blazar git repo
09:14:32 <priteau> hiro-kobayashi: great job!
09:14:35 <hiro-kobayashi> And I will update the wiki to link the new readthedocs page
09:14:43 <bertys__> hiro-kobayashi: nice!
09:15:04 <masahito> hiro-kobayashi: nice work!
09:15:25 <hiro-kobayashi> So, we can stop managing duplications!
09:16:18 <masahito> we're ready to release :)
09:16:25 <GeraldK> thx hiro-kobayashi
09:16:36 <masahito> #topic Pike Blueprints
09:17:17 <masahito> I see hiro-kobayashi want to discuss some topics because of he added the agenda.
09:17:25 <masahito> hiro-kobayashi: want to start?
09:17:33 <hiro-kobayashi> Yes. I’ve updated 2 blueprints. I want you to review them.
09:17:45 <hiro-kobayashi> 1 on-end-options #link https://blueprints.launchpad.net/blazar/+spec/on-end-options
09:17:54 <hiro-kobayashi> 2 terminate-lease-at-anytime #link https://blueprints.launchpad.net/blazar/+spec/terminate-lease-at-anytime
09:18:06 <hiro-kobayashi> And I want to discuss 1 here
09:18:37 <priteau> In Chameleon we use an on_end action to terminate instances
09:19:05 <hiro-kobayashi> priteau: Yes, so I want your feedback :-)
09:19:15 <hiro-kobayashi> I'm thinking of 'How to specify the on-end option?'
09:19:32 <priteau> But we've hardcoded it in the code. I think it should be something more flexible that can be chosen via config file
09:19:48 <hiro-kobayashi> priteau: +1
09:19:52 <hiro-kobayashi> 1 idea is 'By config value'
09:20:11 <hiro-kobayashi> The other is 'By parameters of create/update lease request (REST API)
09:20:11 <GeraldK> IMHO for Pike it would be okay to go with the easier approach. we can optimize later on.
09:20:42 <hiro-kobayashi> GeraldK: +1. I think 'By config value' is easier.
09:20:56 <GeraldK> if we can have options as listed in the BP that should be fine.
09:21:10 <hiro-kobayashi> Because 'By parameters of requests' needs modification of REST API
09:21:20 <masahito> I prefer to config value because it doesn't need API schema changes.
09:21:31 <hiro-kobayashi> masahito: +1
09:21:35 <priteau> Actually some kind of on end action is necessary, because if an instance stays running on the node, blazar fails to end the lease properly
09:21:48 <priteau> +1 masahito
09:22:03 <hiro-kobayashi> Yes, so I will add actions in on_end() method
09:22:19 <masahito> And need to resolve on_end conflicting behaviors.
09:22:23 <hiro-kobayashi> Then, I will adopt 'By config value'
09:22:42 <GeraldK> masahito: which on-end conflicts do you forsee?
09:23:34 <GeraldK> hiro-kobayashi: another option for on_end is "kill"
09:23:59 <masahito> GeraldK: For instance if user#1 specifies keep_running at on_end but default is terminating, how the reserved_host is treated?
09:24:12 <hiro-kobayashi> GeraldK: kill is same with 'delete' which I plan to do by default
09:24:22 <masahito> after on_end.
09:24:41 <GeraldK> hiro-kobayashi: okay. got it.
09:24:50 <hiro-kobayashi> masahito: Yes, that is the big problem.
09:25:33 <GeraldK> masahito: what about removing "keep_running" from the list of options?
09:25:58 <GeraldK> if the user wants to extend the lease, it should/could do an update lease to keep its resources running
09:26:29 <hiro-kobayashi> GeraldK: That make sense
09:26:33 <hiro-kobayashi> +1
09:26:38 <masahito> GeraldK: it's reasonable.
09:27:02 <GeraldK> on the "snapshot" option: this will take some time to create the snapshot so a) the snapshot must be triggered prior to end time or b) we need sufficient safety times between two leases
09:27:15 <hiro-kobayashi> So, we don't allow any lease to block other leases
09:27:31 <hiro-kobayashi> GeraldK: right
09:27:31 <GeraldK> same issue for "migration".
09:28:54 <hiro-kobayashi> The period taken for snapshot/migration is not easy to predict, though
09:29:19 <GeraldK> we should use a conservative time here. better to reserve too long time than too short.
09:29:57 <hiro-kobayashi> The time depends on instance size, how active the instance write on memory, and so on.
09:30:07 <priteau> Transition between leases is a general problem with Blazar, we will need to work on it
09:30:11 <GeraldK> if we assign 24h it should be sufficient :)
09:30:18 <masahito> haha
09:30:28 <priteau> e.g. a lease with many nodes can take a long time to put back all hosts in the freepool
09:30:49 <hiro-kobayashi> yeah
09:30:58 <masahito> priteau: right. I notice blazar polls every 10 sec. so
09:31:44 <hiro-kobayashi> There are still some critical problem that we should work on in long term.
09:31:46 <masahito> It's needed to change something like push type event handling.
09:32:00 <GeraldK> can we add a safety_time as parameter the user can set, i.e. safety_time minutes prior to lease end the action will be triggered. if the action is not completed by the end of the release, then it's bad luck for the user. that is, it is in the responsibility of the user to plan for sufficient safety_time
09:32:53 <masahito> +1
09:33:08 <hiro-kobayashi> GeraldK: sounds good.
09:33:31 <priteau> This will require API changes though?
09:33:39 <GeraldK> most important for Pike IMHO is to have the delete running instances. the on_end actions are a nice addon.
09:33:51 <masahito> I thought it's specified in config file.
09:34:21 <hiro-kobayashi> How about implement it by config file for now?
09:34:21 <priteau> then it is the admin who sets it, not the user?
09:34:48 <hiro-kobayashi> priteau: Yes, it should.
09:34:55 <masahito> IMHO, first step of on_end options is delete instance, then snapshot or others are next steps.
09:34:56 <GeraldK> it think that would be acceptable.
09:35:52 <hiro-kobayashi> Then I will start implementation from the first step
09:35:53 <GeraldK> priteau: do you expect to have safety_times that largely defer from user to user?
09:36:11 <masahito> priteau: i think so. the admin notifies the safety_time to user and the user sets the end time including the time.
09:36:17 <priteau> GeraldK: For snapshot it could be much higher for users with lots of data in their image
09:37:26 <GeraldK> priteau: okay. I guess you have some experiments with large data sets
09:38:45 <hiro-kobayashi> So, step 1: force delete all leases. step2: add options. step3: add safety_time in config_value. step4: add safety_time in REST API.
09:39:09 <GeraldK> +1
09:39:21 <priteau> +1
09:39:25 <masahito> +1
09:39:57 <hiro-kobayashi> OK, thank you all! Now its clear and I can start implementation!
09:40:08 <GeraldK> for migrate we may also need API change to specify location WHERE to migrate
09:40:51 <GeraldK> so I propose to do that action with/after step 4 only
09:41:40 <hiro-kobayashi> GeraldK: +1. so only 'snapshot' option will be introduced for the first, right?
09:41:52 <masahito> We could use Nova scheduler first b/c Nova choose some hosts when migration requests doesn't have a dest host.
09:43:20 <masahito> Of course, it's just one idea.
09:43:21 <GeraldK> masahito: good idea. this could be the default option if no dest host is specified
09:43:25 <hiro-kobayashi> masahito: A problem is VMs running on leased hosts may be bound to the AZ
09:44:07 <hiro-kobayashi> The AZ is created per lease by Blazar,
09:44:23 <masahito> IIRC, when blazar has admin role, admin user can specify any hosts.
09:45:30 <masahito> hiro-kobayashi: The scheduling happens b/c create instance API request body has 'scheduler hints'
09:46:04 <hiro-kobayashi> masahito: Got it
09:46:47 <masahito> anyway, please check it. and if it can't work, we can skip the feature in step2
09:46:50 <masahito> :-)
09:47:05 <hiro-kobayashi> ok
09:47:35 <hiro-kobayashi> That's all for what i want to discuss about Blueprints
09:47:40 <masahito> hiro-kobayashi: do you want to discuss BP#2?
09:47:56 <hiro-kobayashi> No, #2 is clear.
09:48:02 <masahito> hiro-kobayashi: got it.
09:48:27 <masahito> Speaking of BP, I thought we need a place to discuss the details of each BP.
09:48:59 <masahito> Do you make sense to have spec repo for this purpose?
09:49:19 <hiro-kobayashi> It's better
09:49:32 <masahito> or have a dir in blazar repo.
09:50:07 <hiro-kobayashi> in blazar repo is easy.
09:50:29 <hiro-kobayashi> How about creating specs repo in blazar repo for now?
09:50:52 <masahito> ok, I'll create the spec repo.
09:50:56 <hiro-kobayashi> And create blazar-specs repo if we think we need it?
09:51:03 <hiro-kobayashi> masahito: thanks!
09:51:21 <GeraldK> +1
09:51:30 <priteau> grepping through my local git clones, I see a couple of projects using doc/source/specs
09:51:40 <priteau> ./diskimage-builder/doc/source/specs
09:51:40 <priteau> ./python-openstackclient/doc/source/specs
09:51:52 <priteau> bigger projects use a dedicated repo
09:52:17 <hiro-kobayashi> priteau: thanks. it looks better to create specs directory under doc/source
09:53:29 <masahito> Proc of having the dir under doc/source is the spec is published in readthedoc.
09:54:11 <masahito> Proc of having the different repo is.... what?
09:55:04 <hiro-kobayashi> clearly separate design process and impl process...?
09:55:32 <masahito> hiro-kobayashi: oh, yes. right.
09:56:01 <priteau> masahito: also you can have specs for multi-repo projects
09:56:09 <priteau> like ours, we have blazar, blazar-nova, python-blazarclient
09:56:59 <masahito> priteau: right.
09:58:06 <masahito> Putting specs under doc/source looks better now for me.
09:58:19 <hiro-kobayashi> +1
09:58:51 <masahito> because all of bp are related to only blazar repo.
09:59:37 <masahito> anyway, I'll create some place to discuss.
09:59:42 <masahito> last one min.
09:59:45 <masahito> #AOB
09:59:51 <masahito> #topic AOB
10:00:09 <masahito> do you all have another thing to discuss.
10:00:12 <masahito> ?
10:00:13 <GeraldK> do we need a new Etherpad page?
10:00:23 <masahito> For Pike?
10:00:49 <GeraldK> yes, e.g. for general discussion/planning for Pike and Q
10:01:21 <masahito> sounds good.
10:01:48 <GeraldK> okay. I will create a Blazar_status_2017 page
10:01:53 <masahito> ok, I created :-)
10:02:01 <masahito> https://etherpad.openstack.org/p/Blazar_status_2017
10:02:03 <GeraldK> okay. thanks masahito.
10:02:16 <hiro-kobayashi> thanks
10:02:59 <masahito> running out time.
10:03:05 <masahito> thanks, all!
10:03:09 <GeraldK> bye. thx
10:03:12 <masahito> #endmeeting