09:00:52 <masahito> #startmeeting blazar
09:00:53 <openstack> Meeting started Tue Oct 17 09:00:52 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:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:56 <openstack> The meeting name has been set to 'blazar'
09:01:14 <masahito> #topic RollCall
09:01:28 <hiro-kobayashi> o/
09:01:36 <hrito> o/
09:02:00 <masahito> hiro-kobayashi hrito: hi
09:02:06 <GeraldK> o/
09:02:14 <masahito> Today's agenda is
09:02:21 <masahito> 1. Team Mascot
09:02:24 <priteau> o/
09:02:27 <masahito> 2. State Machine
09:02:34 <masahito> 3. Q-1 milestone
09:02:37 <masahito> 4. AOB
09:02:39 <masahito> anything else?
09:02:55 <masahito> GeraldK priteau: hello
09:03:32 <masahito> #chair hiro-kobayashi, priteau
09:03:33 <openstack> Current chairs: hiro-kobayashi masahito priteau
09:03:48 <masahito> #topic Team Mascot
09:04:19 <masahito> As we discussed at the last meeting, we can choose our team mascot.
09:05:03 <GeraldK> how do you want to proceed with the selection?
09:05:11 <masahito> we have 5 candidates b/c bauzas replayed the mail in openstack-dev.
09:05:51 <masahito> 1. house mouse, 2. squirrel, 3. shrike, 4. blazar, 5. weather frog
09:06:52 <masahito> GeraldK: I think the selection is done by +1 voting here.
09:07:37 <masahito> and decides the order by the number of +1
09:08:05 <GeraldK> masahito: okay
09:08:52 <masahito> it's easy to count +1 on irc because we are small team :-)
09:08:58 <priteau> We should give the option to vote by email if some contributors are not here
09:09:22 <priteau> e.g. Bertrand is not online?
09:09:38 <GeraldK> priteau: I will ask him to join
09:11:25 <masahito> bertys: hi
09:11:35 <bertys> masahito: hi, sorry for being late
09:12:24 <masahito> bertys: we'll start the voting +1 for our team mascot.
09:12:38 <masahito> the candidates are 1. house mouse, 2. squirrel, 3. shrike, 4. blazar, 5. weather frog
09:13:05 <priteau> Do we choose a single candidate?
09:13:33 <masahito> I wanted to ask same question :->
09:14:27 <GeraldK> priteau: i guess so as we can only have one mascot
09:15:09 <priteau> GeraldK: yes, of course. But I mean, can each of us express a preference for just one candidate, or several (maybe ordered?)
09:15:27 <masahito> priteau GeraldK: to ask the Foundation of our mascot, we needs multi mascot because they check regal problem for it.
09:15:46 <masahito> priteau: we're 6 or 7. so IMO, everyone can choose multi candidates.
09:16:06 <GeraldK> priteau: okay
09:17:38 <masahito> okay. I'll start to ask voting from #1. if you like the candidate, please write +1.
09:17:48 <hiro-kobayashi> +1
09:17:54 <priteau> +1
09:18:06 <masahito> +1
09:18:08 <hrito> +1
09:18:17 <masahito> #1 is house mouse
09:19:37 <tejaswi> +1
09:19:43 <GeraldK> +1
09:19:55 <masahito> does anyone else have +1 for house mouse? I'll wait in 30 secs
09:20:42 <masahito> okay 6 +1s for #1
09:21:10 <masahito> next, voting for #2, squirrel
09:21:31 <priteau> +1
09:21:39 <masahito> +1
09:22:48 <masahito> does anyone else have +1 for squirrel? I'll wait in 1 min.
09:23:23 <bauzas> masahito: just got highlighted so I won't interfere, but openstackstatus provides #startvote for that exact purpose :p
09:25:11 <masahito> bauzas: oh... thanks :p I didn't know that. I'll try to use it next.
09:25:40 <masahito> squirrel gets 2 +1s.
09:25:59 <masahito> next is voting for #3, shrike.
09:26:38 <masahito> +1
09:26:55 <hrito> +1
09:27:11 <GeraldK> +1
09:27:29 <masahito> Does anyone else have +1 for shrike? I'll finish it in 1 min.
09:28:43 <masahito> shrike gets 3 +1s.
09:29:00 <masahito> next voting is for #4, blazar.
09:29:19 <hrito> +1
09:29:54 <GeraldK> +1
09:30:13 <tejaswi> +1
09:30:55 <masahito> Does anyone else have +1 for blazar? I'll finish in 1 min.
09:31:52 <masahito> blazar gets 3 +1s.
09:32:13 <masahito> the final candidate is weather frog.
09:33:10 <bertys> +1
09:34:19 <masahito> Does anyone else have +1 for weather frog? I'll finish in 1 min.
09:35:23 <masahito> weather frog gets one +1.
09:36:05 <masahito> then the voting result is....
09:36:38 <masahito> house mouse got 6 +1s
09:36:53 <masahito> shrike and blazar got 3 +1s
09:37:19 <masahito> squirrel got 2 +1s.
09:37:34 <masahito> then weather frog got one +1
09:38:41 <masahito> I'll ask the Foundation of our team Mascot with following order.
09:39:07 <masahito> house mouse, blazar or shrike.
09:39:50 <masahito> any comments?
09:41:33 <masahito> okay, then move on to the next topic.
09:41:47 <masahito> #topic State Machine
09:42:18 <hiro-kobayashi> I proposed this agenda
09:42:24 <masahito> hiro-kobayashi: you have some topics?
09:42:58 <hiro-kobayashi> yes. I proposed a spec for the state-machine bp https://review.openstack.org/#/c/508093/
09:43:04 <hiro-kobayashi> Thanks for reviewing it
09:43:41 <hiro-kobayashi> http://docs-draft.openstack.org/93/508093/3/check/gate-blazar-docs-ubuntu-xenial/82ed0a6//doc/build/html/devref/specs/queens/state-machine.html
09:44:00 <hiro-kobayashi> In the spec, I proposed *_DEGRADED states for the lease, and *_RESOURCES_CHANGED and *_MISSING_RESOURCES states for the reservation
09:44:27 <hiro-kobayashi> And priteau proposed to remove these states
09:44:59 <hiro-kobayashi> Instead, priteau proposed to add  new boolean fields: ‘degraded' field for the lease, ‘missing_resources' and ‘resources_changed' field for the reservation
09:45:30 <hiro-kobayashi> priteau's idea LGTM
09:45:31 <priteau> Note that I am not sure if that's a good idea. Just something that occurred to me while reviewing.
09:45:45 <priteau> I am thinking from the point of view of a developer using the API
09:46:31 <hiro-kobayashi> I think pros/cons of introducing new boolean fields are:
09:46:47 <hiro-kobayashi> pros: state graph becomes simpler than current spec
09:46:55 <hiro-kobayashi> pros: implementation may be simpler
09:47:01 <hiro-kobayashi> cons: DB schema changes
09:47:11 <hiro-kobayashi> Any other pros/cons?
09:47:13 <priteau> They might have to write code like "if status == NOT_STARTED_DEGRADED or status == ACTIVE_DEGRADED: alert user"
09:47:28 <priteau> rather than "if lease.degraded: alert user"
09:48:10 <masahito> another cons is undesired status could happen, like status == pending and changed flag is True
09:48:13 <hiro-kobayashi> priteau: yes. So, degraded flag may simplify implementation
09:48:58 <priteau> Thinking about how the Ironic state machine work, they have an "active" node status, even though the node can be in "maintenance" (boolean) at the same time
09:50:34 <masahito> priteau: It looks strange situation for me. How do they handle it?
09:50:36 <hiro-kobayashi> masahito: I think lease can ignore the changed flag when it's NOT_STARTED
09:51:15 <priteau> masahito: maintenance is a flag that can be set by the admin for any state
09:52:08 <masahito> hiro-kobayashi: of course, lease can ignore the situation. My concern is the situation happens by bugs.
09:53:14 <masahito> priteau: only the status change is triggered by admin? if so it makes sense.
09:53:32 <hiro-kobayashi> masahito: yes, we need a mechanism that checks relationships between the status and flags.
09:54:43 <masahito> From my experience, if the flag is changed by both admin and blazar internal tasks, the undesired status could happen.
09:55:03 <priteau> in our case the admin wouldn't change these flags
09:55:11 <priteau> It would be managed by blazar
09:55:21 <hiro-kobayashi> I think degraded and related flags should be updated only by blazar internal tasks
09:55:37 <hiro-kobayashi> priteau: +1
09:56:48 <masahito> hiro-kobayashi: there is a mechanism that avoid the situation, I'm ok to use the flag.
09:57:06 <hiro-kobayashi> masahito: ok
09:57:17 <masahito> hiro-kobayashi: do you have proc/cons for only using status?
09:57:53 <hiro-kobayashi> pros: do not need to care flags
09:58:07 <hiro-kobayashi> cons: state graphs becomes complex
09:58:38 <hiro-kobayashi> I think introducing degraded flags are better than including them in the status.
09:59:04 <hiro-kobayashi> So I'm going to update the spec to introduce degraded flags.
09:59:11 <hiro-kobayashi> How do you think?
09:59:35 <masahito> okay, I'll check it once you have updated it.
09:59:44 <priteau> One advantage of flags is that if we need more of them in the future, existing client code that use states should remain compatible
09:59:44 <hiro-kobayashi> masahito: thanks!
10:00:10 <bertys> hiro-kobayashi: from our past discussions, the description of case 3 should be: At least one of reservation states is ACTIVE (best effort approach)? Is this the correct understanding?
10:00:13 <hiro-kobayashi> priteau: yes, it is important
10:00:58 <hiro-kobayashi> bertys: are you talking about the resource-monitoring spec?
10:01:31 <bertys> hiro-kobayashi: I am looking at lease_states.png
10:01:38 <hiro-kobayashi> Oh, sorry. misunderstood.
10:02:29 <hiro-kobayashi> Yes, I think it should be At least one of reservation states is ACTIVE (best effort approach)
10:02:40 <masahito> hi all, time is running out. I'll end the meeting and move to #openstack-blazar.
10:02:51 <bertys> hiro-kobayashi: ok, thanks
10:02:53 <hiro-kobayashi> or, become ERROR even if at least one reservation is not ACTIVE
10:03:15 <hiro-kobayashi> I think the former is better.
10:03:35 <hiro-kobayashi> masahito: ok
10:04:17 <hiro-kobayashi> Anyway, keep discussion at gerrit :-)
10:04:37 <hiro-kobayashi> I'll propose the update in this week
10:05:11 <masahito> hiro-kobayashi: I'll wait it.
10:05:13 <masahito> bye
10:05:21 <masahito> #endmeeting