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