15:00:03 <ricolin> #startmeeting heat
15:00:04 <openstack> Meeting started Wed Apr 19 15:00:03 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:09 <openstack> The meeting name has been set to 'heat'
15:00:15 <ricolin> #topic roll call
15:00:57 <ramishra> hi
15:01:06 <ricolin> hi:)
15:01:34 <cwolferh> hi
15:01:36 <zaneb> hola
15:01:54 <tiantian> hi
15:02:10 <ricolin> ramishra thx for mark that deprecated bug, not notice there is a similar one
15:02:53 <ricolin> s/deprecate/duplicate/
15:03:20 <ramishra> ricolin: yeah, but the user has some strange issue though;)
15:03:23 <ricolin> #topic adding items to agenda
15:03:36 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-04-19_1500_UTC.29
15:04:03 <ricolin> pilgrimstack1 around?
15:05:26 <ricolin> dose anyone know what's the floating ip provider issue pilgrimstack1 was referring to?
15:07:02 <ricolin> I think we can skip the floating ip topic, since he seems not here to tell:)
15:07:26 <ricolin> #topic force delete resource
15:07:36 <ricolin> #link https://review.openstack.org/#/c/454941/
15:08:01 <zaneb> ick
15:08:28 <ricolin> the code looks fine, just would like to know how we want to do force delete in heat
15:09:16 <ricolin> current propose is to add a property in server for `force_delete`
15:09:50 <zaneb> what's the difference between force_delete() and delete() in Nova?
15:10:02 <zaneb> and wth were they thinking
15:10:16 <ramishra> Anyway the server is gone right? Though reclaimed later by nova?
15:10:20 <ricolin> to force detach I think?
15:10:42 <tiantian> there is a config option
15:11:12 <ricolin> `reclaim_instance_interval`
15:11:22 <ricolin> in Nova :)
15:11:32 <ramishra> oh it's for bdm boot disk
15:11:52 <zaneb> #link http://www.stillhq.com/openstack/000018.html
15:11:56 <tiantian> yes, if the config set then the delete is not really execute
15:12:27 <ricolin> ramishra yes
15:12:38 <zaneb> my first thought is that we should just call force_delete all of the time
15:13:17 <therve> It's probably not backward compatible
15:13:37 <ricolin> zaneb not it is not:)
15:14:57 <ricolin> So what is the best way to introduce this feature
15:15:29 <ricolin> adding properties in server for force?
15:15:40 <therve> That patch looks okay to me
15:15:40 <tiantian> anyway I gave my +2 ;)
15:15:48 <therve> It sucks, but because nova sucks
15:15:56 <zaneb> deletion_policy: half-a**
15:15:58 <therve> We don't have to hide the suckiness all the time
15:16:49 <ramishra> We still have number of issues with bdm, when replaced during update, it fails
15:17:12 <ramishra> when bdm is used to boot
15:17:28 <zaneb> why are we counting the SOFT_DELETE state as deleted?
15:17:59 <ricolin> zaneb a deletion_policy sounds nice
15:18:48 <ricolin> zaneb Not getting what you mean, why not?
15:18:50 <tiantian> if `reclaim_instance_interval` is set in nova, then the status of server is SOFT_DELETED after delete
15:19:19 <zaneb> ricolin: could we always force_delete except when there's a deletion_policy: soft_delete? or would that still not be backwards-compat enough?
15:19:34 <tiantian> deletion_policy is for 'all' resources
15:19:39 <zaneb> ricolin: what tiantian said
15:19:59 <zaneb> tiantian: yeah, that is the downside of deletion_policy
15:20:19 <ricolin> I see
15:20:58 <zaneb> ricolin: if it's not DELETED, as in, it's safe to go ahead and delete the stuff that it depends on, then we should consider it DELETE_IN_PROGRESS imho
15:21:03 <therve> ? deletion_policy is a resource attribute? You mean we would have a value that's specific to server?
15:21:41 <zaneb> literally the entire point of Heat is that we don't delete(/create/update) stuff in the wrong order
15:22:27 <therve> reclaim_instance_interval is just some crappy pet support
15:22:42 <tiantian> sorry
15:23:11 <zaneb> therve: yeah, I'm starting to go off the deletion_policy idea
15:23:39 <tiantian> I mean adding property 'force_delete' for server is enough
15:24:14 <zaneb> to me this is like adding a "not_broken" property and defaulting it to False
15:25:05 <therve> But only a few people are going to use that option
15:25:32 <ricolin> It might be weird to mention but what should we do with force delete for cinder volume? or other force delete able resource?
15:26:03 <zaneb> therve: so why are we worried about backwards compat with their already-broken stuff?
15:26:34 <therve> zaneb, Well presumably if you didn't use anything like network and volume you could have a working template?
15:27:23 <therve> But maybe I worry too much, no one uses that thing
15:27:32 <therve> We're already wasting too much time on that :)
15:29:35 <ricolin> anyway, feel free to put your idea on top of that review
15:30:48 <ricolin> #topic releasenote scope
15:32:33 <ricolin> I would like to propose to add releasenot in the feature bugs at least for some high Importance bugs
15:32:54 <tiantian> +1
15:33:21 <ricolin> our releasenote seems not cover `bug fix` much
15:34:35 <ricolin> #link https://docs.openstack.org/releasenotes/heat/ocata.html
15:34:44 <zaneb> that seems reasonable for major bugs
15:35:42 <ramishra> yeah, if that makes sense to the user not for high importance gate issues;)
15:35:42 <zaneb> heh, the one "Bug Fix" on there is actually a new feature and not a bug
15:37:03 <ricolin> ramishra I think it might depends on cores to decide if that's something user should notice about
15:37:43 <ramishra> ricolin: sure, let's add more release notes:)
15:37:53 <ricolin> zaneb exactly！
15:38:04 <ricolin> okey, solved:)
15:38:20 <ricolin> #topic Open discussion
15:38:31 <zaneb> so this happened https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html
15:38:57 <ramishra> zaneb: cool
15:39:25 <ricolin> zaneb so is there will be a room for all to working on that in summit?
15:39:54 <zaneb> ricolin: likely yes, working on getting it on the schedule now
15:40:18 <ramishra> Are we ok to make the py35 dsvm job voting now?
15:40:31 <zaneb> I mena, not *now* now cuz of this meeting ;)
15:40:45 <ramishra> https://review.openstack.org/#/c/456253/, I can unblock it
15:42:05 <ricolin> ramishra I do feel it's okey to vote:)
15:43:46 <ramishra> silence means 'no'? therve?
15:44:01 * zaneb hasn't been watching the gate for a couple of weeks
15:44:33 <ricolin> zaneb basically green
15:44:38 <zaneb> ramishra: according to the official OpenStack rule of lazy consensus, silence means yes :)
15:44:57 <ramishra> zaneb: ok:)
15:45:47 <ricolin> we can always make it non vote again if a good reason comes up:)
15:45:52 <ramishra> I've not seen any failures since it's been green though, other than normal issues that affects other jobs too.
15:46:54 <zaneb> +1 for make it voting then
15:47:03 <ricolin> +1
15:47:54 <ricolin> If no against shall we make it vote?
15:47:54 <ramishra> ok done
15:48:06 <ricolin> nice:)
15:48:30 <ricolin> #action ramishra make py35 vote
15:49:02 <ricolin> anything would like to discuss?
15:50:31 <ricolin> cool
15:50:32 <therve> ramishra, I'm a bit afraid to be broken by other projects for no reason, but that's like the other gates :)
15:51:10 <ramishra> I think the server bdm stuff is already a mess. We can make even more broken;)
15:51:47 <ricolin> ramishra but to add properties means the property stay there for almost ever
15:53:46 <ricolin> anyway hope we can make more discussion on that review and think it through before we land it:)
15:54:25 <ricolin> okey, if no other stuff, shall we back to heat:)
15:54:43 <ramishra> +1
15:54:58 <ricolin> thx all
15:54:59 <ricolin> #endmeeting