15:00:37 <ricolin> #startmeeting heat
15:00:41 <openstack> Meeting started Wed Mar  1 15:00:37 2017 UTC and is due to finish in 60 minutes.  The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:46 <openstack> The meeting name has been set to 'heat'
15:00:56 <ricolin> #topic roll call
15:01:18 <cwolferh> hello
15:01:26 <nilles> hi
15:01:30 <ricolin> hi!
15:01:37 <therve> Hey
15:02:25 <tiantian> hi
15:03:25 <ricolin> #topic adding items to agenda
15:03:53 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-03-01_1500_UTC.29
15:04:08 <ricolin> Any topic would like to discuss?
15:04:21 <ricolin> I don't have much for this week
15:05:45 <ricolin> I will make a recap for heat team's discussion in PTG later this week
15:05:50 <therve> ricolin, v2 API
15:06:10 <zaneb> o/
15:06:53 <ricolin> #topic V2API
15:07:47 <ricolin> therve: I think we have reach some agreement about v2 api, that we might not look forward to do it
15:08:05 <therve> ricolin, I don't know. At least not everyone knows about it :)
15:09:01 <ricolin> therve: you're right, I will make sure it will be mention and discussed through recap
15:09:22 <therve> ricolin, Update https://wiki.openstack.org/wiki/Heat/Blueprints/V2API too
15:09:33 <ricolin> tiantian: any through?
15:09:38 <tiantian> ricolin, I have started for v2 api and proposed some patches
15:10:29 <tiantian> now I don't know do we need the v2 api :)
15:11:22 <ricolin> We might need to get more idea about it
15:12:12 <ricolin> I think for long term we will need a microversion support
15:12:35 <ricolin> it might be V1.1 or V2
15:13:24 <ricolin> Just have to figure it out whether it sould be implement in this cycle
15:13:56 <ricolin> #link https://blueprints.launchpad.net/heat/+spec/v2-api
15:15:55 <tiantian> sorry
15:15:59 <tiantian> disconnected
15:16:03 <ricolin> tiantian NP
15:16:25 <ricolin> I said we I think for long term we will need a microversion support
15:16:34 <ricolin> Just have to figure it out whether it sould be implement in this cycle
15:16:42 <ricolin> and  V1.1 or V2 ?
15:16:45 <tiantian> not v2 api?
15:17:07 <ricolin> V1.1 or V2 might be two option we can seek
15:18:17 <therve> Before going anywhere, we need to see what's the benefit for our users
15:18:35 <therve> removing the tenant id from the URL is not a good enough reason
15:18:48 <ricolin> tiantian: your current patch is about refactor WSGI, which I think won't be affected, just have to figure it out firt
15:19:28 <tiantian> ok
15:19:37 <ricolin> I will send a mail out to dev and operators to seek any feedback:)
15:19:56 <ricolin> tiantian: sounds good?:)
15:20:23 <tiantian> sure
15:20:37 <ricolin> sweet!
15:21:01 <ricolin> #topic Open discussion
15:21:35 <ricolin> Any topic would like to propose?
15:22:33 <tiantian> about the combination alarm
15:22:39 <ricolin> yes
15:22:41 <ricolin> right
15:22:52 <tiantian> now we plan to set the REMOVED status
15:22:53 <tiantian> ?
15:23:24 <ricolin> What we going to do for an resource which been completly removed from aodh?
15:23:36 <tiantian> how to compatible with existing stacks?
15:24:04 <zaneb> I liked therve's idea, if that works
15:24:11 <ricolin> tiantain: I think that might be one option to add REMOVED status
15:24:22 <zaneb> (remap it to OS::Heat::None)
15:24:25 <ricolin> zaneb point to None?
15:24:37 <zaneb> as long as it remains hidden in the docs
15:24:47 <tiantian> which actions we support for None resource?
15:25:01 <therve> zaneb, I don't think we document things in the environment
15:25:21 <therve> tiantian, All, presumably
15:25:35 <zaneb> therve: what about the resource type list API?
15:26:01 <therve> zaneb, No idea
15:26:18 <tiantian> we won't return the HIDDEN resource types
15:26:43 <ricolin> For some resource in future, might do more work while delete it
15:27:00 <ricolin> that's why I'm more looking forward a new status like removed
15:27:23 <zaneb> what if we just change the impl to inherit from OS::Heat::None and delete all the rest of the code?
15:27:36 <tiantian> IIUC we can operate the HIDDEN resources except resource type list apI
15:27:37 <zaneb> that might be the easiest way
15:27:39 <ricolin> #link https://review.openstack.org/#/c/439433/
15:28:16 <ricolin> What about those resource which already created in env?
15:29:05 <therve> ricolin, Even deleting the resource won't work in this case though
15:29:12 <therve> So I don't see the benefit of the removed status
15:29:56 <tiantian> zaneb, how? if user update/delete the resource what we can do if aodh remove the related codes?
15:30:24 <tiantian> can we translate the combination alarm to composite alarm?
15:30:40 <therve> Why would we do that?
15:30:40 <ricolin> if we assign None to that resource, isn't that will triger a update from old type to None type, which will triger an delete action from old resource
15:31:07 <tiantian> just look for a good way for users:)
15:31:09 <therve> ricolin, Test it? :)
15:31:20 <ricolin> and inside that delete method might actually call client.alarm.delete() method which might not work
15:31:45 <zaneb> tiantian: If the Aodh team don't care enough to transition people then it certainly isn't our job imho
15:31:46 <therve> I think setting the env should be good enough, but someone has to test it
15:32:11 <ricolin> therve: sure
15:32:23 <zaneb> as long as the resource type is invisible to our users but people can still delete their existing stacks that contain it, I am happy
15:32:36 <therve> Yep
15:33:07 <tiantian> afaik, they provide tranlation tools in last two releases
15:36:56 <ricolin> I will test it out if any of above method actually works
15:37:19 <ricolin> I will be much easier if Aodh just leave the code there...
15:37:34 <ricolin> s/I/It
15:38:16 <ricolin> Okey, Any other topics?  :)
15:38:28 <nilles> Just a quick beginner question regarding with the spec process
15:38:49 <nilles> After the Neutron Trunk PTG session, ricolin approved this blueprint on launchpad:
15:38:54 <nilles> https://blueprints.launchpad.net/heat/+spec/support-trunk-port/
15:39:22 <nilles> but the blueprint itself has not merged to the heat-spec repo
15:39:35 <ricolin> We still need to review the spec
15:39:51 <nilles> ah, ok
15:40:09 <nilles> I tough it will be approved after the blueprint is merged
15:40:30 <nilles> my bad :)
15:40:48 <ricolin> NP :)
15:41:03 <ricolin> #link https://blueprints.launchpad.net/heat/+spec/support-trunk-port/
15:41:38 <ricolin> Any other topics? :)
15:41:47 <zaneb> nilles: bp approved = agreed in principle. spec merged = no more bikeshedding ;)
15:42:20 <nilles> ok, thanks for clarifying
15:42:43 <ricolin> zaneb: nice!
15:43:58 <ricolin> Okey if no other thing to discuss in meeting I think we can close it earlier
15:44:35 <ricolin> It will be great if guys can help on review those spec and give your advise:)
15:44:49 <ricolin> Thanks all:)
15:44:51 <ricolin> #endmeeting