20:00:05 <skraynev_> #startmeeting heat
20:00:07 <openstack> Meeting started Wed Feb 10 20:00:05 2016 UTC and is due to finish in 60 minutes.  The chair is skraynev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:10 <openstack> The meeting name has been set to 'heat'
20:00:16 <skraynev_> #topic rollcall
20:00:49 <skraynev_> anybody here?
20:00:53 <shardy> o/
20:00:54 <stevebaker> hey
20:00:55 <ochuprykov> hi
20:00:55 <pas-ha> O/
20:01:01 <skraynev_> :)
20:01:05 <prazumovsky> hello
20:01:56 <skraynev_> ramishra: ping
20:02:19 <skraynev_> #topic Adding items to agenda
20:02:25 <skraynev_> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-02-10_2000_UTC.29
20:02:56 <skraynev_> does anybody want to add something else?
20:03:49 <skraynev_> ok. let's start with existing items :)
20:04:21 <skraynev_> #topic ec2-token migration to OS resources
20:05:07 <skraynev_> shardy: I have seen some mail thread about it. And it looks for me as a good candidate for summit session
20:05:16 <stevebaker> skraynev_: agenda item, evaluating convergence as the default
20:05:34 <shardy> skraynev_: why are you thinking a summit session is needed?
20:05:35 <skraynev_> shardy: could you clarify a bit current status of it?
20:06:00 <skraynev_> shardy: because I don't know where we are in  this area.
20:06:04 <skraynev_> stevebaker: sure
20:06:26 <shardy> skraynev_: so there are two things - one is moving the default metadata/signal transport away from depending on the CFN API by default
20:06:45 <skraynev_> and it's in progress afaik
20:06:51 <shardy> and the other is that keystone folks are planning to move the ec2tokens implementation to a different repo
20:07:14 <shardy> I've only recently heard about the latter, we need to keep track of it and ensure it doesn't break us
20:07:31 <shardy> skraynev_: we've not changed any defaults yet have we?
20:07:41 <Drago> o/
20:08:07 <skraynev_> shardy: I thought, that I have seen some patch on review
20:08:09 <shardy> I haven't proposed any patches, but I have started looking into how we may avoid breaking existing deployments such as TripleO
20:08:11 <skraynev_> Drago: hi
20:08:42 <shardy> skraynev_: I haven't yet, I'll be happy to send a followup mail to the list tho, where we can work out what needs to be done
20:08:53 <skraynev_> shardy: another repo sounds like a new requirements in future
20:10:06 <shardy> skraynev_: yes, long term we may want to look at following the path of other projects and decouple the AWS compatibility APIs from the main repo
20:10:15 <shardy> then we can decouple the requirements
20:10:32 <shardy> I don't see how we can really discuss that until we no longer depend on the CFN API by default tho
20:11:10 <skraynev_> shardy: got it. do you know when keystone team plan to move ec2tokens to another repo?
20:11:27 <shardy> skraynev_: No, the first I learned about it was on the ML this week
20:11:31 <skraynev_> because if it is planned as part of Mitaka we have a really short time period
20:11:36 <skraynev_> heh
20:11:54 <shardy> skraynev_: Yeah, I hope it's only a deprecation for mitaka
20:12:17 <skraynev_> shardy: yes. I currently open first mail too.
20:12:34 <stevebaker> shardy: I think it is reasonable to request that whatever keystone does it should be possible for the current ec2token endpoint to continue working - even if it proxies to something else. Otherwise things may break
20:12:44 <skraynev_> shardy: so we have enough time for doing it. just need to keep it in mind, as you said
20:12:46 <shardy> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085998.html
20:12:50 <shardy> that's the thread btw
20:13:07 <skraynev_> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085998.html
20:13:16 <shardy> stevebaker: Yeah, I think we need the keystone team to clarify the migration plan
20:13:31 <shardy> also that v2.0 compatibility of tokens thing mentioned worries me
20:13:42 <shardy> as it implies trust scoped tokens won't work with v2.0 auth anymore
20:13:58 <shardy> which would be a problem for many deployments unless it's papered over by authtoken middlware
20:14:15 <shardy> hopefully folks will reply to the thread soon and we can discuss further there
20:14:26 <stevebaker> yeah
20:14:48 <shardy> stevebaker: one advantage is we actually maintain our own ec2token middleware
20:15:03 <shardy> so if we have to, we can work around some sorts of breakages or moves in there
20:16:14 <stevebaker> shardy: I suggested as much some time ago - if keystone are deprecating it then maybe we should just bring that logic into the heat tree
20:16:54 <shardy> stevebaker: Yeah, although other AWS compatibility APIs need it, so a common repo somewhere makes sense long term
20:17:10 <skraynev_> stevebaker: I am not a big fan of maintaining some deprecated somewhere code
20:17:54 <skraynev_> stevebaker:  but if we have not alternative I tend to agree with this suggestion
20:17:55 <stevebaker> sure, but consumable as a lib (and rest api for those that really need it)
20:18:11 <stevebaker> like tripleo-common
20:18:27 <shardy> I think enough things depend on it that there will have to be a common repo somewhere
20:18:31 <skraynev_> stevebaker: yeah. I understand.
20:18:38 <shardy> it's not that much logic, only the signature calculation code really
20:19:08 <shardy> the credentials API in keystone isn't going anwywhere AIUI, which is what backs the ec2tokens extension in v3
20:20:19 <shardy> anyway, lets move on, we can continue this on the ML
20:20:49 <skraynev_> shardy: ok. thank you for the clarification. now I know what happens with this stuff
20:21:04 <skraynev_> #topic OSC commands
20:21:31 <skraynev_> stevebaker: do we have any progress with it?
20:21:44 <prazumovsky_> I have one little question about osc patches
20:21:53 <skraynev_> I plan to enjoy review  of some patches tomorrow
20:21:58 <stevebaker> progress is good but we *really* need reviews for things to land https://review.openstack.org/#/q/topic:bp/heat-support-python-openstackclient+status:open
20:22:20 <skraynev_> prazumovsky_ : what is the question?
20:22:33 <stevebaker> client lib freeze is in 2.5 weeks so we have a shot at having 1.0.0 ready for that
20:23:01 <skraynev_> stevebaker: aha. so it's the same dates as for m-3, right?
20:23:03 <prazumovsky_> Why one of them have methods on module level (like in https://review.openstack.org/#/c/254330/25/heatclient/osc/v1/resource_type.py) and another are inner class methods (like in https://review.openstack.org/#/c/267731/7/heatclient/osc/v1/snapshot.py)?
20:23:08 <shardy> stevebaker: is it worth having an etherpad with the full list of patches?
20:23:23 <stevebaker> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html
20:23:28 <markvan> suggestion, maybe we go top to bottom of etherpad cmd list to prevent unneeded rebasing churn unless your patch in next.  Most are ready, if one is not note that in the review and move on
20:23:36 <stevebaker> shardy: there is one, hang on
20:23:42 <jonesbr> shardy: https://etherpad.openstack.org/p/heat-support-python-openstackclient
20:23:50 <shardy> jonesbr: thanks!
20:24:10 <prazumovsky_> I mean, why some of them are out of the classes
20:24:10 <stevebaker> markvan, jonesbr: hi!
20:24:15 <prazumovsky_> it's confusing me
20:24:24 <stevebaker> prazumovsky_: developer preference
20:25:05 <stevebaker> they are private functions, someone can always refactor to a consistent style later
20:25:43 <prazumovsky_> hm... how about incapsulation?
20:26:07 <prazumovsky_> stevebaker: thanks
20:26:08 <markvan> yeah, I was trying to follow the current style, but could be changed later
20:26:37 <stevebaker> markvan, jonesbr: I might reorder that etherpad so reviewers can focus on the top items
20:26:37 <prazumovsky_> IMO, if method using only in one class, it should be in it
20:26:50 <prazumovsky_> (oh it's boring formatting...:-) )
20:26:55 <skraynev_> prazumovsky_: looks like we can fix/refactor it later
20:27:03 <jonesbr> stevebaker: That would help us rebase the patches in order as well
20:27:13 <stevebaker> true
20:27:20 <skraynev_> prazumovsky_: you may file a bug as a reminder for these changes
20:27:29 <prazumovsky_> ok, thanks
20:27:35 <markvan> prazumovsky_: yup I would not disagree with your point
20:28:13 <stevebaker> markvan, jonesbr: do you know if Amey is still contributing?
20:28:36 <jonesbr> stevebaker: we contacted him and he gave us control of his patches
20:28:58 <ryansb> prazumovsky_: I don't see why it has to be in the class - if the usage/ownership is clear in file structure that's ok too
20:29:22 <stevebaker> jonesbr: ok, it doesn't look like there are any orphaned changes at the moment, so good.
20:30:12 <stevebaker> #link https://etherpad.openstack.org/p/heat-support-python-openstackclient
20:30:34 <neelashah1> stevebaker there is one that has seen no activity in almost a month, I just sent an email to them today to check if they plan to continue on it…otherwise jonesbr or markvan can pick that up - zengyingzhe@huawei.com …for this patch - https://review.openstack.org/#/c/268554/
20:31:30 <stevebaker> neelashah1: yeah, feel free to just take that over if there is no response
20:32:07 <skraynev_> go to the next one.
20:32:15 <neelashah1> ok, thanks stevebaker
20:32:16 <skraynev_> #topic evaluating convergence as the default
20:32:51 <stevemar> stevebaker and shardy sorry this is off topic, but the plans to move the ec2 bits around (or out) in keystone is on hold until the summit
20:33:14 <stevemar> things are staying as-is for M, we're too late to start shaking things up
20:33:15 <skraynev_> hm. I don't see any one from HP guys, who have patches on review for convergence
20:33:19 <stevebaker> stevemar: oh cool, thanks for the update
20:33:31 <shardy> stevemar: thanks for the clarification, will be good to join your session & discuss the migration plan at summit then :)
20:33:46 <stevebaker> stevemar: consider our request that nothing break duely lodged ;)
20:33:49 <skraynev_> stevemar: great. could you please post link on session if you decide to schedule it on summit ?
20:34:11 <stevemar> skraynev_: will do. stevebaker request has been noted :)
20:34:28 <skraynev_> stevemar: thank you
20:34:48 <randallburt> regarding convergence as the default, I am −2 on that at this point.
20:35:25 <skraynev_> randallburt: could you add more details : why?
20:35:26 <randallburt> trying to rebase and fix https://review.openstack.org/#/c/190183/17 and I'm running into one of the scenarios that looks broken from convergence standpoint
20:35:40 <shardy> I'm also worried about it - I've tried testing a couple of times and ran into DB scalability/connection issues both times
20:35:44 <randallburt> also, scenario coverage is still a bit incomplete.
20:35:55 <stevebaker> I periodically switch to convergence and try deploying tripleo - my issues at the moment are around stack deleting
20:36:10 <randallburt> sabeen has run into a breaking case for cancel update as well and there's no unit test coverage for that as well
20:36:24 <randallburt> sabeen was seeing similar stevebaker
20:36:26 <stevebaker> https://bugs.launchpad.net/heat/+bug/1523748
20:36:28 <openstack> Launchpad bug 1523748 in heat "Convergence: Nothing returned from resource-list after stack-delete is called" [High,In progress] - Assigned to Sirushti Murugesan (sirushtim)
20:36:28 <skraynev_> stevebaker: shardy: we have one important fix here https://review.openstack.org/#/c/248676/
20:36:35 <stevebaker> https://bugs.launchpad.net/heat/+bug/1542123
20:36:36 <openstack> Launchpad bug 1542123 in heat "Convergence: stack-delete stalls on stacks stuck with IN_PROGRESS resources" [Undecided,New]
20:36:40 <shardy> stevebaker: interesting, I tried that a couple of months ago and ran into DB issues, similar to what I found when doing stress tests previously
20:37:28 <randallburt> this fix is also important: https://review.openstack.org/#/c/277762/2
20:37:42 <shardy> I would suggest we defer switching anything until N, but document it in the release notes as ready for more serious testing
20:38:12 <shardy> then in N, we can consider switching some non-heat CI jobs to enable it, e.g one of the TripleO jobs
20:38:49 <randallburt> shardy:  +1
20:39:02 <stevebaker> and commit to backporting fixes to Mitaka until it turns out that backports are too big
20:39:28 <randallburt> stevebaker:  do we strictly *have* to do that?
20:39:35 <randallburt> stevebaker:  for convergence that is
20:39:37 <shardy> stevebaker: +1 backporting bugfixes where reasonable sounds OK to me
20:40:04 <randallburt> oh, ok, as long as there's a "this is too disruptive, no backport" option
20:40:15 <stevebaker> randallburt: there may be users who want to switch, like tripleo
20:40:27 <skraynev_> shardy: Then it make sense do during month after m-3
20:40:32 <stevebaker> randallburt: yeah, thats what I meant by "too big"
20:40:33 <randallburt> stevebaker:  IMO they should wait for N to do that though
20:40:41 <skraynev_> otherwise it may be more difficult for backporting, I suppose
20:40:43 <randallburt> stevebaker:  its def not in a state for production use in M.
20:40:53 <stevebaker> randallburt: sure
20:41:46 <shardy> I think it's about the message - saying we commit to reasonable bugfix backports shows we want non-developer consumers of heat to actually use it and report back
20:42:41 <skraynev_> stevebaker: shardy: I will send mail about our plan to openstack-dev . That convergence is officially ready for testing and it's still alternative feature, which can contain some sporadic errors.
20:42:50 <randallburt> sure, I'm ok with it for certain values of "reasonable" :)
20:42:55 <ryansb> also higher risk backports might be acceptable since it's a nondefault
20:43:11 <ryansb> (note: that isn't a license to ignore "reasonable")
20:43:24 <skraynev_> also what do you think about doing convergence default in N master after rc-1 ?
20:43:58 <shardy> skraynev_: I think it is too soon
20:44:24 <shardy> we have to get feedback from real consumers of heat for a while, e.g a TripleO CI job running for a month or so
20:44:42 <randallburt> shardy:  however, it *would* provide some incentive for those (like myself) that are coming in late to help
20:45:12 <skraynev_> shardy: ok. can we then enable it for our tripleo job on gate
20:45:34 <skraynev_> and after 1 month from this event do it default ?
20:45:40 <shardy> randallburt: I guess, but I see it as poor form to force an unstable feature on all users by default because we've not found all the bugs yet ;)
20:45:59 <shardy> skraynev_: Yeah, perhaps we can get the tripleo job running against heat again by default
20:46:03 <skraynev_> my main idea is to have defined time line for convergence
20:46:13 <shardy> and make that enable convergence on the undercloud
20:47:29 <skraynev_> sounds like a plan.
20:47:33 <randallburt> sure
20:48:07 <shardy> Related to convergence, there is a propoal to add Tacker (NFV orchestration service) to the big tent:
20:48:10 <shardy> https://review.openstack.org/#/c/276417/
20:48:17 <skraynev_> #action skraynev will send mail about convergence related plans
20:48:57 <shardy> there is a comment from russellb that some aspects of their proposed functionality may overlap with our long term roadmap for convergence
20:49:15 <shardy> it'd be good to get some feedback there from folks close to the convergence work
20:49:20 <randallburt> ouch. that commit message tho
20:49:26 <shardy> e.g to add a summary of the current state, and the immediate roadmap
20:49:48 <russellb> randallburt: the tacker one?  yeah.  it's acronym heavy.  read my version in a comment that tries to explain it with less telco buzz.
20:49:57 <shardy> randallburt: heh, yeah it's pretty acronym heavy ;)
20:50:30 <randallburt> reading now russellb. thanks!
20:50:37 <russellb> it's a bit of an essay ..
20:51:29 <skraynev_> russellb: 100 % like an essay :)
20:51:39 <stevebaker> tacker uses heat, but ancient tacker didn't use heat to provision nova - I haven't got a clear answer if that has changed
20:51:45 <skraynev_> but looks interesting
20:51:56 <russellb> stevebaker: it has a "nova" driver and a "heat" driver
20:52:17 <stevebaker> hmm, ok
20:52:21 <russellb> for its "infrastructure driver" option ...
20:52:40 <russellb> i asked if that was just for historical reasons, or if there was some reason the nova driver was still there
20:52:42 <skraynev_> #topic Open discussion
20:52:47 <shardy> I guess the question is do we need to be actively collaborating on "monitoring, healing and scaling" aspects
20:53:12 <shardy> it'd certainly be good to get visibility of their requirements in that area
20:54:22 <russellb> they monitor VMs with ping or simple HTTP requests, and if it stops responding, it will execute some policy.  policy is pretty simple too: respawn, log_and_kill, log
20:54:25 <zaneb> oh hey it's meeting day
20:54:37 <ryansb> zaneb: yup..
20:54:40 <russellb> some more info on http://git.openstack.org/cgit/openstack/tacker/tree/doc/source/devref/monitor-api.rst
20:54:50 <skraynev_> zaneb: hey. we are really close to the end
20:55:02 <russellb> looks like they want to do auto-scaling too ...
20:55:22 <stevebaker> they should really be talking to the Senlin folk then
20:55:23 <russellb> just occurred to me as something that really shouldn't be tacker-specific
20:55:41 <stevebaker> because that would be a significant overlap
20:55:47 <russellb> ok, if there's another project that should be looked at, a comment on the review would be great
20:55:56 <ryansb> I guess everyone wants in on that sweet, sweet autoscale action. If only there were a project trying to do autoscaling...really well...
20:56:22 <randallburt> yeah, it sounds like this could/should leverage several other openstack apis
20:56:58 <shardy> russellb: thanks for highlighting it, there are certainly several potential areas for integration by the look of it
20:57:00 <russellb> *nods* that's what we're trying to figure out for their application
20:57:13 <russellb> basically, are they sufficiently taking advantage of existing stuff vs. reinventing stuff
20:59:16 <skraynev_> time is out
20:59:27 <skraynev_> thank you all.
20:59:44 <skraynev_> all questions and discussion -> #heat
20:59:48 <skraynev_> #endmeeting