20:00:08 <skraynev_> #startmeeting Heat
20:00:08 <openstack> Meeting started Wed Dec  2 20:00:08 2015 UTC and is due to finish in 60 minutes.  The chair is skraynev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:12 <openstack> The meeting name has been set to 'heat'
20:00:25 <skraynev_> #topic rollcall
20:00:30 <pas-ha> o/
20:00:31 <jdob> o/
20:00:31 <shardy> o/
20:00:35 <rpothier> o/
20:00:36 <ryansb> hey folks
20:00:43 <stevebaker> \o
20:00:48 <dgonzalez> o/
20:00:48 <skraynev_> zaneb
20:00:59 <jdandrea> p/
20:01:00 <jdandrea> o/
20:01:08 <prazumovsky> hi
20:01:15 <zaneb> o/
20:01:37 <skraynev_> ok. cool. we have a really great Agenda
20:01:53 <skraynev_> #topic Adding items to Agenda
20:01:59 <skraynev_> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-12-02_2000_UTC.29
20:02:21 <skraynev_> I suggest to skip this topic due to high load for agenda :)
20:02:27 <stevebaker> crikey
20:03:20 <skraynev_> stevebaker: I hope, that 3 item may be squashed, but it looks clear now )
20:03:28 <stevebaker> if we have time I'd like to cover liberty branch and convergence ci
20:03:30 <zaneb> I was going to ask what reno is, but I see that's on there already
20:03:50 <skraynev_> stevebaker: sure
20:03:53 <skraynev_> will add
20:03:53 <pas-ha> reno==RElease NOtes
20:04:06 <skraynev_> anyway we may continue in #heat
20:04:25 <skraynev_> in worst case :)
20:05:12 <jdandrea> We need more agenda items. ;)
20:05:22 <stevebaker> lets crack on
20:05:25 <jdob> jdandrea: ironically, thats the first agenda item
20:05:28 <skraynev_> jdandrea: no please ...
20:06:00 <skraynev_> #topic Review priorities
20:06:13 <skraynev_> #link https://etherpad.openstack.org/p/heat-reviews
20:06:30 <skraynev_> Honestly I have not check this list from previous meeting :(
20:06:52 <jdob> can someone give me a quick 15 second overview on how this etherpad works? can anyone add to it or do the priorities come from somewhere else?
20:06:54 <skraynev_> re-authentification is merged.
20:07:21 <zaneb> jdob: I think we're adding to it now
20:07:23 <jdob> i have a spec i'd like to get eyes on and two reviews that have been floating around for a while now
20:07:33 <stevebaker> shardy: do you think it would be appropriate to backport reauthentication to liberty?
20:07:37 <skraynev_> jdob: you can add it yourself. :)
20:07:42 <jdob> awesome
20:07:54 <shardy> stevebaker: it's disabled by default so should be ok
20:08:20 <skraynev_> shardy: I suppose, that it also may be enabled in liberty?
20:08:26 <stevebaker> shardy: because it would be a huge help to tripleo
20:08:36 <skraynev_> IMO we have not really big changes in this part between current code and liberty
20:08:48 <shardy> stevebaker, skraynev_: Yep, I think provided others agree a backport would be appropriate and low-risk
20:09:51 <skraynev_> jdob: btw. I wanted to ping you before move BP to M2, but did not meet in my work time :)
20:10:12 <jdob> crud, I meant to do that too
20:10:14 <skraynev_> jdob: I hope, that this change is ok for you.
20:10:20 <pas-ha> +1 on re-auth backport
20:10:42 <jdob> ya, no problem on the change
20:10:45 <skraynev_> shardy, stevebaker: btw it's already uploaded on review to stable
20:10:55 <stevebaker> oh, cool
20:10:57 <shardy> skraynev_: yup, thanks
20:11:21 <skraynev_> shardy: stevebaker: https://review.openstack.org/#/c/252313/
20:11:26 <skraynev_> #link https://review.openstack.org/#/c/252313/
20:12:09 <skraynev_> anything else ? I think, that I will take on etherpad only after M1 will be finished :)
20:12:35 <skraynev_> #topic Milestone mitaka1
20:12:48 <skraynev_> #link  https://launchpad.net/heat/+milestone/mitaka-1
20:13:07 <skraynev_> I have moved all unfinished BPs to M2
20:13:27 <skraynev_> There are 4 bugs in progress state
20:14:26 <shardy> wow 62 bugs
20:14:27 <stevebaker> looks good, when is m1 due?
20:14:27 <pas-ha> just uploaded fix for mine today, though in fact it will not fix the heat-templates gate as I hoped, so proirity might be lowered
20:14:51 <zaneb> stevebaker: today, isn't it?
20:15:07 <jdob> i thought it was yesterday
20:15:13 <jdandrea> stevebaker: Does the oslo.log bug factor in to this? https://bugs.launchpad.net/oslo.log/+bug/1516128
20:15:13 <openstack> Launchpad bug 1516128 in heat "No handler found if logging occurs before logging is ready" [Undecided,Fix committed] - Assigned to Joe D'Andrea (joedandrea)
20:15:16 <pas-ha> Dec 1-3
20:15:17 <skraynev_> stevebaker, zaneb: yeah. it's the reason why I have a special request to you guys :))))
20:15:31 <skraynev_> tomorrow is the last chance ;)
20:15:49 <stevebaker> jdandrea: yeah
20:15:50 <skraynev_> my fault, I did not thought, that it will be so fast :)
20:16:19 <stevebaker> skraynev_: those 4 bugs could always be kicked
20:16:24 <skraynev_> so first question...
20:16:27 <jdandrea> stevebaker: Ok. I think I need to do something to add the heat bug (that's a duplicate) to this, perhaps.
20:16:28 <zaneb> skraynev_: they always arrive sooner that you expect :D
20:16:37 <zaneb> s/that/than/
20:16:44 * jdandrea will take it offline in #heat
20:16:45 <skraynev_> stevebaker :you are answered on my question
20:16:55 <skraynev_> you read my thoughts :)
20:17:47 <skraynev_> stevebaker: zaneb: updated
20:17:58 <skraynev_> anything else on launchpad ?
20:19:01 <skraynev_> stevebaker, zaneb: I don't know should I do anything else on launchpad for M1 :)
20:19:21 <skraynev_> #topic: finishing Reno work
20:19:39 <skraynev_> but I know, that we have such mail from release team:
20:19:42 <stevebaker> skraynev_: I think you just need to ensure bugs are commited and bps are implemented, either by closing or kicking
20:19:48 <skraynev_> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080692.html
20:20:08 <skraynev_> stevebaker: for BPs it was done
20:20:32 <stevebaker> has reno landed in heat yet>
20:20:35 <stevebaker> ?
20:20:53 <skraynev_> good question
20:21:07 <skraynev_> #link https://review.openstack.org/#/c/250105/4
20:21:21 <skraynev_> we still have this patch on review
20:21:26 <zaneb> just approved it
20:22:00 <stevebaker> don't we need it in master too for m1> https://review.openstack.org/#/c/249744/
20:22:51 <skraynev_> stevebaker: https://review.openstack.org/#/c/250105/4 this is base implementation
20:23:02 <skraynev_> I have a doubt about release notes
20:23:06 <skraynev_> for m1
20:23:12 <skraynev_> because
20:23:22 <skraynev_> glance, i.e. has not such notes
20:23:33 <stevebaker> skraynev_: oh, ok
20:23:38 <skraynev_> https://github.com/openstack/glance/tree/master/releasenotes/notes
20:23:53 <skraynev_> but nova has
20:23:57 <skraynev_> #link https://github.com/openstack/nova/tree/master/releasenotes/notes
20:24:05 <skraynev_> so I am confused :)
20:24:18 <skraynev_> dhellmann: ping
20:24:23 <stevebaker> dhellmann: are you about? we have a query on whether m1 should be using reno
20:24:35 <jdob> why wouldn't we want them for m1? seems like it'd make life easier at the end
20:24:57 <pas-ha> because we do not have any notes yet :)
20:25:01 <zaneb> stevebaker: he just sent an email to the list today asking us to merge it today so it would be ready for m1
20:25:31 <skraynev_> zaneb: so we still need some additional notes
20:25:42 <stevebaker> nova has an unreleased.rst, we can always add that after https://review.openstack.org/#/c/249744 lands
20:25:44 <skraynev_> not only base implementation for Reno
20:25:49 <pas-ha> we'd have to back-track on important changes and fill out some notes
20:25:59 <zaneb> ah, ok
20:26:20 <skraynev_> pas-ha: but we have only tomorrow for it ;)
20:26:37 <pas-ha> well, life is hard :(
20:26:51 <skraynev_> so If we really need it, I'd request zaneb or stevebaker help with that
20:27:25 <skraynev_> otherwise It will be really fun day for me tomorrow ;)
20:27:30 <stevebaker> sure thing
20:27:57 <skraynev_> #topic milestone tag 1
20:28:14 <skraynev_> so according the mail: I have prepared two patches:
20:28:37 <skraynev_> #link https://review.openstack.org/#/c/252581/
20:28:45 <skraynev_> #link https://review.openstack.org/#/c/252579/1
20:29:16 <skraynev_> so, if you feel power - just update them, when release notes be ready
20:30:14 <stevebaker> ok
20:31:09 <skraynev_> zaneb, stevebaker: I'd request you to ping or left message me tomorrow (my morning) about what I also need to do (in case if you  do not do it yourself :) )
20:31:13 <skraynev_> ok
20:31:35 <stevebaker> sure, I'll do a handover on your morning
20:31:52 * zaneb will be asleep, so off the hook ;)
20:32:13 <skraynev_> stevebaker: awesome. Big thanks
20:32:28 <stevebaker> no problem
20:32:31 <skraynev_> zaneb: just write me a message ;) if it's ok for you ;)
20:32:47 <skraynev_> ok. go to the next item
20:32:58 <skraynev_> #topic replace tempest job with API services launched under Apache
20:33:53 <skraynev_> ochuprykov: ping
20:34:19 <skraynev_> looks like He is absent ...
20:34:33 <skraynev_> ok. I will give short intro
20:35:19 <skraynev_> 1. new  tempest job with API launched under Apache was added
20:35:28 <skraynev_> as experimental job
20:35:32 <skraynev_> it works now
20:35:46 <skraynev_> Oleksii check it on several patches
20:36:13 <skraynev_> 2. there is a patch https://review.openstack.org/#/c/252399/
20:36:16 <skraynev_> #link https://review.openstack.org/#/c/252399/
20:36:34 <skraynev_> which replace existing tempest job by this new job with Apache
20:37:07 <skraynev_> I remember, that we were agreement to do it. so please review
20:37:28 <skraynev_> also you may run check experimental and make sure, that it works
20:37:31 <therve> Why can't we keep both? Resources?
20:38:01 <skraynev_> therve: yeap + timem which again depends on resources
20:38:13 <skraynev_> s/timem/time
20:38:32 <therve> Mokay. I hope we won't break the non-apache deployment.
20:38:37 <skraynev_> more job -> more resources -> more time
20:39:21 <skraynev_> I suppose, that integration tests should be enough
20:40:25 <skraynev_> stevebaker: ^ what do you think about it?
20:40:32 <stevebaker> +1 from me
20:41:03 <skraynev_> shardy: zaneb: pas-ha
20:41:12 <pas-ha> +1
20:41:17 <skraynev_> or silent == +1 ? :)
20:41:57 <ryansb> +1
20:41:58 <skraynev_> so... yes :)
20:42:02 <zaneb> I have no strong feelings about it ;)
20:42:14 <skraynev_> ok.
20:42:18 <skraynev_> go to the next
20:42:24 <skraynev_> #topic get_reality naming poll: get_synced_state, observe_on_update for the check_reality config flag
20:42:29 <prazumovsky> oh
20:42:34 <skraynev_> short voting about naming
20:42:35 <prazumovsky> next suggestions
20:42:45 <prazumovsky> get_reality rename to:
20:42:45 <shardy> me neither tbh provided it doesn't affect our functional tests
20:42:51 <prazumovsky> 1. get_synched_state
20:42:56 <prazumovsky> 2. get_entity_state
20:43:11 <stevebaker> observe_for_update
20:43:13 <prazumovsky> (number of prefered name)
20:43:13 <skraynev_> shardy: yes. it's just for tempest
20:43:27 <prazumovsky> observe_for_update for config option
20:43:37 <prazumovsky> your opinions?
20:44:14 <skraynev_> stevebaker: I had a question: why on "update" ? I thought, that we may execute get_reality for each state
20:44:21 <skraynev_> not only for update
20:44:27 <ryansb> I like (2) better (also doesn't have the ambiguity of synced/synched/sync'd)
20:44:49 <prazumovsky> 2 for me, bth
20:44:50 <stevebaker> i guess technically everything is an update for convergence
20:44:51 <prazumovsky> *btw
20:45:02 <zaneb> this is the name of the Resource plugin API call?
20:45:14 <stevebaker> 2 is fine
20:45:20 <skraynev_> observe_for_update: this is about config option
20:45:21 <shardy> why "entity" instead of just "resource" ?
20:45:35 <skraynev_> get_entity_state - as I understand for API
20:45:38 <zaneb> shardy: yeah, that's what I was wondering
20:45:51 <pas-ha> shardy, because "resource" is Heat's thing
20:45:54 <shardy> get_resource_state, check_resource_state, observe_resource_state
20:46:01 <pas-ha> entity is what heat has created
20:46:03 <shardy> pas-ha: well there's a good reason we call it that
20:46:12 <shardy> because we're creating an openstack resource
20:46:14 <prazumovsky> pas-ha +1'
20:46:17 <skraynev_> zaneb: we have also stacks... which state we also check, I suppose
20:46:18 <pas-ha> resource state is alread CREATE_COMPLET
20:46:23 <pas-ha> for example
20:46:23 <shardy> I don't see why we need to reinvent another term tbh
20:47:11 <therve> +1 for get_resource_state
20:47:13 <zaneb> I'm still not clear on what we are trying to name here, but I think shardy is right
20:47:14 <shardy> pas-ha: in the resource plugins, we refer to the actual thing as physical_resource generally don't we?
20:47:14 <pas-ha> my be sync_resource_state
20:47:18 <skraynev_> shardy: but we check status for whole stacks...
20:47:25 <shardy> get_physical_resource_state?
20:47:46 <zaneb> get_live_properties?
20:47:57 <prazumovsky> live is same as reality
20:48:12 <pas-ha> but shorter ;)
20:48:20 <prazumovsky> pas-ha +1 for name
20:48:22 <skraynev_> prazumovsky: and simpler ;)
20:48:36 <skraynev_> obviously :)
20:48:58 <skraynev_> get_live_properties - I am ok with it
20:49:05 <skraynev_> therve:
20:49:09 <skraynev_> ^
20:49:31 <jdob> only hiccup there is we already use properties, parameters, and attributes
20:49:34 <stevebaker> what if the resource is missing or in an error state? that is not really properties related
20:49:35 <therve> Erm
20:49:46 <shardy> but we're not getting properties though, those are inputs to the resource, we're getting the resource attributes, and comparing them against the stored resource state, aren't we?
20:50:08 <skraynev_> prazumovsky: ^
20:50:14 <stevebaker> get_live_state?
20:50:19 <jdob> get_current_state?
20:50:24 <zaneb> shardy: I have no idea, because I still don't know what API we're talking about ;)
20:50:31 <shardy> stevebaker: +1
20:50:33 <therve> Let's move on
20:50:45 <skraynev_> zaneb: lol
20:50:52 <shardy> zaneb: Heh, I'm assuming its the observer call to poll actual resource state, vs our stored "complete"
20:50:53 <therve> That was a horrible waste of meeting time, sorry for putting that :)
20:51:00 <zaneb> shardy: but the inputs we have are properties, so in order to compare outputs, we're going to have to turn the outputs into the properties format
20:51:03 <stevebaker> therve: lets bikeshed for the rest of the meeting :D
20:51:05 <zaneb> I would have thought
20:51:27 <prazumovsky> shardy, yes, we are
20:51:28 <zaneb> therve: lol
20:51:28 <therve> stevebaker, I don't see why not! :)
20:51:41 <prazumovsky> sorry for dealy
20:51:44 <prazumovsky> *delay
20:52:27 <zaneb> prazumovsky: you have a bunch of ideas now and most of them weren't terrible. just pick one
20:52:30 <skraynev_> stevebaker:  continue in #heat looks so obvious ...
20:52:46 <zaneb> then we can bikeshed again on the review ;)
20:52:52 * zaneb ducks
20:53:09 <stevebaker> 4 topics, 8 minuts left
20:53:11 <prazumovsky> get_live_state as for me is fine
20:53:16 <shardy> zaneb: I can't really parse the outputs->properties comment but, meh, it's getting late ;)
20:53:20 <prazumovsky> and i suggest to go on
20:53:28 <skraynev_> stevebaker: as pas-ha said life is hard ...
20:53:39 <skraynev_> ok.
20:53:44 <zaneb> shardy: yeah, that was a horrible explanation
20:53:52 <skraynev_> #topic get_reality implementation problems with default properties specified in configs
20:53:54 <pas-ha> mine are not super important, can skip them
20:54:07 <prazumovsky> yes, this is the main problem now
20:54:13 <prazumovsky> for get_reality, i mean
20:54:27 <pas-ha> or postpone to the next, relase mgmt took lots of time :(
20:54:46 <skraynev_> #agreement to continue bikeshed about API on review
20:54:51 <shardy> lol
20:54:52 <prazumovsky> we have non-updatable properties, which is optional, but if we don't specify it
20:55:03 <prazumovsky> it specified with default value
20:55:17 <prazumovsky> which defined in config file
20:55:18 <pas-ha> prazumovsky, you mean those "immutable"
20:55:19 <pas-ha> ?
20:55:21 <prazumovsky> of other project
20:55:40 <pas-ha> or update_allowed=False?
20:55:42 <prazumovsky> i mean required=False, update_allowed=False
20:55:50 <zaneb> prazumovsky: this sounds like a mailing-list type of question
20:55:51 <prazumovsky> like AZ in Nova::Server
20:55:52 <pas-ha> ok
20:55:59 <prazumovsky> zaneb, ok
20:56:14 <skraynev_> prazumovsky: agree with zaneb. please describe issue in mail
20:56:19 <prazumovsky> I can write a mail with this problem
20:56:26 <skraynev_> #topic Liberty branch and convergence CI
20:56:32 <prazumovsky> ok.
20:56:35 <skraynev_> I choose this one due to importance
20:56:39 <skraynev_> ;)
20:56:47 <skraynev_> stevebaker: ^
20:56:58 <skraynev_> convergence is now voting
20:57:08 <stevebaker> ok
20:57:08 <zaneb> is this two different topics?
20:57:14 <skraynev_> with three skipped tests
20:57:30 <stevebaker> convergence CI is passing and voting \o/
20:57:33 <skraynev_> zaneb: I suggest In #heat after meeting
20:57:55 <zaneb> \o/
20:57:57 <skraynev_> zaneb: I apologize  for the jumping
20:58:00 <stevebaker> the original plan was to backport fixes to liberty so that its convergence CI is also passing. Should we still aim to do that?
20:58:06 <stevebaker> (discuss)
20:58:10 <zaneb> meh
20:58:14 <skraynev_> 2 min
20:58:31 <skraynev_> stevebaker: I don't think, that it's possible... honestly
20:58:48 <stevebaker> changes too high risk? too many?
20:58:49 <skraynev_> looks like porting tens patches....
20:58:59 <pas-ha> don't really see anyone enabling convergence in liberty stable release
20:59:05 <shardy> skraynev_: so, we're saying convergence doesn't work in liberty?
20:59:10 <zaneb> agree with pas-ha
20:59:14 <skraynev_> I suppose second + need more code changes due to dependencies from other parts..
20:59:27 <zaneb> if anyone wants to experiment they should be doing it on master
20:59:53 <stevebaker> In that case we should probably delete the liberty ci job
20:59:59 <skraynev_> shardy: we are saying : it's experimental part
21:00:02 <shardy> time's up -> #heat
21:00:09 <zaneb> stevebaker: +1
21:00:10 <skraynev_> #endmeeting