14:00:17 <ricolin> #startmeeting heat
14:00:18 <openstack> Meeting started Wed Jun  6 14:00:17 2018 UTC and is due to finish in 60 minutes.  The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'heat'
14:00:25 <ricolin> #topic roll call
14:00:50 <zaneb> o/
14:00:55 <ricolin> o/
14:00:57 <kazsh_> o/
14:01:22 <ricolin> kazsh_, sorry didn't review your patch yet, but will do it right after meeting!
14:01:40 <kazsh_> ricolin: no worries, mate & thanks!
14:02:00 <ricolin> ramishra, therve ?
14:02:09 <ramishra> hi
14:03:03 <ricolin> #topic adding items to agenda
14:03:08 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282018-06-06_1400_UTC.29
14:04:22 <ricolin> #topic Vancouver Summit
14:04:28 <ricolin> #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131221.html
14:05:09 <ricolin> I send a ML for video and slide link from summit sessions
14:05:23 <ricolin> also the user feedback etherpad
14:05:54 <ricolin> We seems got a lot of require by users
14:06:22 <ricolin> at least every user I ask are using heat in some interesting way:)
14:07:38 <ricolin> ramishra, there was user asking about swift backend for heat template:)
14:08:27 <ricolin> Also some requirement for multi cloud and improve our ASG
14:08:37 <ricolin> anyway that's what I got from Summit
14:08:56 <ricolin> #topic Review policy for Heat cores
14:09:39 <ricolin> zaneb proposed to change our review policy with allow a core to directly approve patch when it's proposed by another core.
14:10:14 <ricolin> Any idea on that?
14:11:15 <zaneb> with only 4 active cores, who are also doing most of the development, 75% of us have to be involved to get a patch in at the moment
14:11:56 <zaneb> that seems like too high a bar to get anything done
14:12:21 <therve> I'd say, on all patches then
14:13:46 <ricolin> ramishra, what you think
14:14:02 <ramishra> +1, unless the patch is too complex
14:14:28 <ricolin> +1 from me too
14:14:45 <ramishra> I mean more eyes is always good, but we've limitations:)
14:15:02 <zaneb> ramishra: yeah, it's never compulsory to approve a patch after you've +2d (even if there is already a +2). you can always wait for more feedback if you think it's warranted
14:15:29 <ramishra> zaneb: yep
14:15:56 <zaneb> therve: by 'all patches' do you mean including patches from non-cores?
14:16:05 <therve> zaneb: Yeah
14:17:34 <zaneb> therve: that feels like a bigger step. this is just saying 'we assume you reviewed your own patch before submitting it/clearing Workflow-1"
14:17:56 <ramishra> I mean if the core feels like approving with only him/her reviewing, it should be fine, no?
14:18:09 <zaneb> let's try this out first rather than jump straight to 'only 1 +2 required to merge'
14:18:22 <therve> ok
14:18:51 <zaneb> unless it's trivial of course. we already approve trivial patches with a single +2 (at least I do)
14:19:37 <ricolin> I think trivial patch not limited:)
14:19:45 <ricolin> Wonder if we can also apply this new policy to our stable branch review?
14:20:39 <ramishra> I think we should approve stable patches with only one stable core revewing as an agreed policy from now on
14:21:16 <ricolin> ramishra, yeah
14:21:29 <ramishra> unless stable maint team makes noise about it;)
14:21:42 <ricolin> I remember stable-maintain-cores once mention they willing to direct provide +2 if any of our stable core +2ed, which sounds like what allow directly a single core policy:)
14:21:45 <zaneb> ramishra: and by 'we' you mean me, right? ;)
14:21:53 <ricolin> zaneb, yes!
14:21:59 <ramishra> zaneb: exactly:)
14:22:07 <ricolin> zaneb, that obvious?
14:22:31 <zaneb> I'm happy to do that (and often end up doing that anyway)
14:22:43 <zaneb> there's still a problem for stable backports that I submit
14:22:52 <zaneb> somebody needs to review those
14:23:20 <therve> Yeah just stop doing that :)
14:23:43 <zaneb> so I would appreciate it if y'all could do +1s on stable reviews so that I can nominate more people for stable core
14:23:57 <zaneb> therve: stop doing backports myself?
14:24:04 <therve> Yeah
14:24:26 <ricolin> zaneb, will try to keep that in mind
14:24:35 <zaneb> therve: if you're volunteering, I'm fine with that ;)
14:25:47 <ricolin> since all agree, I assume we can close this topic now
14:26:07 <ramishra> zaneb: yeah we can manage that, it's not that difficult to handle with gerrit UI support for backports unless there are conflicts
14:26:12 <zaneb> ricolin: should we put some #agreed things in the minutes?
14:26:26 <ricolin> zaneb, right
14:27:17 <ricolin> #agreed team aggree to allow core reviewer to directly approved on patches what was proposed by another core
14:28:20 <ricolin> #agreed in stable branch, single stable core can directly approve patches
14:28:33 <ricolin> therve, ramishra zaneb sounds right? ^^^
14:28:45 <zaneb> yep
14:29:10 <ricolin> BTW zaneb queens gate is broken and need this backport  https://review.openstack.org/#/c/562455
14:29:10 <ricolin> :)
14:29:29 <ricolin> two patches actually:)
14:29:32 <zaneb> I just +2d them earlier, but I guess I can approve now :)
14:29:49 <zaneb> I suspect those patches will need to be squashed together to pass the gate now though
14:30:00 <ricolin> zaneb, cheers for the sudo power:)
14:30:16 <ricolin> Move on
14:30:17 <zaneb> apparently I am not allowed to do that myself, so...
14:30:30 <ricolin> haha
14:30:42 <ricolin> #topic Credential in Multi-Cloud
14:31:59 <ricolin> As we plan to work on multi-cloud in this release, would like to collect idea on what we should deal with credential. I working on using clouds.yaml to record provider information for other clouds https://docs.openstack.org/os-client-config/latest/user/configuration.html  .
14:32:00 <ricolin> Ops input cloud provider name and barbican id(from remote side).
14:32:00 <ricolin> Pregenerate clouds.yaml file with cloud auth info. Use that auth to talk to another cloud (in future it can be a application credential with only limited to access to heat stack operations).
14:32:00 <ricolin> Remote Heat receive API to create Stack, and use that stored barbican credential to refresh context with actual user credential
14:33:13 <ricolin> Try to working on spec and POC right now, would like to learn if that sound like the right track or not
14:33:47 <ricolin> zaneb, ideas?
14:34:35 <zaneb> s/actual user credential/token/
14:34:50 <zaneb> but yes, that sounds correct
14:36:05 <ricolin> cool
14:36:18 <zaneb> ideally we should support any sort of credential (password, application credential, &c.) that a user can use with the SDK and clouds.yaml/secrets.yaml
14:36:49 <zaneb> we use that to grab a token from the remote cloud's auth_url, and we go from there
14:38:28 <ricolin> when you mean by grab a token, you mean as a heat service to greb a token to access to another heat service right?
14:38:51 <ricolin> zaneb, try to figure out if I can do better in protect any credential
14:39:31 <zaneb> that's what we're getting a token for, yes. at the time we're getting the token, we just get it from keystone, it doesn't know what we're going to use it for
14:41:05 <ricolin> zaneb, yeah, and once Application credential allow only access to single API, we can try to use that instead acquire a token with full power
14:41:41 <zaneb> ricolin: we don't have to do anything. the *user* can give us a locked down credential
14:43:14 <ricolin> fair enough, just have to make sure os client config allow taht credential, everything should be the same
14:43:56 <zaneb> as long as we allow app creds in general, then we can't tell the difference
14:44:35 <ricolin> zaneb, true
14:45:08 <ricolin> will try to working on more detail and keep you all sync!
14:45:14 <openstackgerrit> Harald Jensås proposed openstack/heat master: Allow updating the segment property of OS::Neutron::Subnet  https://review.openstack.org/567206
14:46:10 <ricolin> okay, let's move on
14:46:15 <ricolin> didn't put this is agenda, but I think maybe we can talk about long term support?
14:46:50 <ricolin> I mean Extended Maintenance
14:47:33 <ricolin> #topic Open discussion
14:47:53 <ricolin> Do we have anything to discuss about that?
14:47:55 <zaneb> I can give an update about Extended Maintenance if you want?
14:48:02 <ricolin> zaneb, sure
14:48:10 <zaneb> basically this is the new policy: https://docs.openstack.org/project-team-guide/stable-branches.html
14:48:35 <zaneb> so stable branches are open for all bugfixes for 18 months
14:49:01 <zaneb> they remain open after that as long as someone is maintaining them
14:49:10 <zaneb> (gate is not broken, patches still get reviewed)
14:49:40 <zaneb> if they've been unmaintained for 6 months we'll call them EOL
14:49:58 <zaneb> but iirc we're no longer going to delete the branch and replace it with a -eol tag
14:50:20 <zaneb> oh, also no releases after the first 18 months
14:51:01 <zaneb> so downstreams can co-operate on backporting patches, but they'll have to grab them from git not a tarball
14:51:02 <ricolin> zaneb, yeah, old branch will all keep in repo now
14:51:23 <zaneb> (from my perspective, this is what we do in RDO anyway so that wfm)
14:51:35 <zaneb> any questions?
14:51:46 * ricolin raise hand!
14:52:02 <zaneb> oh no
14:52:22 <ricolin> is this actually working well? I mean you mention RDO doing it
14:52:50 <zaneb> importing patches from git?
14:53:11 <ricolin> yes
14:53:18 <ricolin> for old version
14:53:42 <ricolin> I mean version > 2years
14:53:52 <zaneb> we have lots of tooling to make it easy, so yeah. for us it works well. we just rebase on the latest git master instead of the tarball
14:54:22 <zaneb> tbh ocata is the first branch that is following this, so we don't have any data on that yet
14:54:49 <ramishra> Is releasing such an overhead? there could have been independent releases if the project teams wants
14:54:58 <zaneb> but the old way was after the branch was closed, we had to do backports downstream, and so did all the other distros
14:55:20 <ricolin> I assume you guys will have to do it for Pike eventually
14:55:55 <zaneb> so the new way is better because everyone can continue to collaborate on backports even after 18 months
14:56:38 <zaneb> ramishra: I don't think it's about overhead so much as not creating expectations that a series is still supported by upstream, including VMT &c.
14:56:44 <ricolin> zaneb, we only allow security backport for Old branch, so did that also apply to extended?
14:57:01 <zaneb> extended maintenance is a sandbox for distros to share work
14:57:13 <ramishra> zaneb: OK, makes sense
14:57:34 <zaneb> ricolin: no: "All bugfixes (that meet the criteria described below) are appropriate. No Releases produced, reduced CI commitment."
14:58:18 <ricolin> right! that rule is changed even for all maintained branch
14:58:59 <zaneb> correct, it's changed for the entire lifetime of the branch
14:59:39 <ricolin> let's wait for our first requirement come:)
15:00:04 <zaneb> actually that doc says at EOL we still delete the branch and tag, so I may have misremembered that bit, or it may just not have been updated since the Forum
15:00:42 <zaneb> on another topic
15:00:51 <ricolin> I think only if branch stay in Unmaintained for so long
15:01:16 <zaneb> ricolin: yes. that will eventually happen to all branches though
15:01:25 <zaneb> I posted this yesterday: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131183.html
15:01:54 <zaneb> ricolin: we discussed this ^ in the hallways at summit
15:02:02 <ricolin> zaneb, oh! that cool stuff!
15:02:07 <zaneb> looking for volunteers
15:02:15 * zaneb stares at therve
15:02:22 <therve> Hi
15:03:01 <zaneb> that is all.
15:03:40 <ricolin> Let's keep that part up to dated!
15:04:27 <ricolin> we're running out of time
15:04:47 <ricolin> Thanks all for join
15:04:53 <ricolin> #endmeeting