20:00:05 #startmeeting heat 20:00:07 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:10 The meeting name has been set to 'heat' 20:00:16 #topic rollcall 20:00:49 anybody here? 20:00:53 o/ 20:00:54 hey 20:00:55 hi 20:00:55 O/ 20:01:01 :) 20:01:05 hello 20:01:56 ramishra: ping 20:02:19 #topic Adding items to agenda 20:02:25 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-02-10_2000_UTC.29 20:02:56 does anybody want to add something else? 20:03:49 ok. let's start with existing items :) 20:04:21 #topic ec2-token migration to OS resources 20:05:07 shardy: I have seen some mail thread about it. And it looks for me as a good candidate for summit session 20:05:16 skraynev_: agenda item, evaluating convergence as the default 20:05:34 skraynev_: why are you thinking a summit session is needed? 20:05:35 shardy: could you clarify a bit current status of it? 20:06:00 shardy: because I don't know where we are in this area. 20:06:04 stevebaker: sure 20:06:26 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 and it's in progress afaik 20:06:51 and the other is that keystone folks are planning to move the ec2tokens implementation to a different repo 20:07:14 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 skraynev_: we've not changed any defaults yet have we? 20:07:41 o/ 20:08:07 shardy: I thought, that I have seen some patch on review 20:08:09 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 Drago: hi 20:08:42 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 shardy: another repo sounds like a new requirements in future 20:10:06 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 then we can decouple the requirements 20:10:32 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 shardy: got it. do you know when keystone team plan to move ec2tokens to another repo? 20:11:27 skraynev_: No, the first I learned about it was on the ML this week 20:11:31 because if it is planned as part of Mitaka we have a really short time period 20:11:36 heh 20:11:54 skraynev_: Yeah, I hope it's only a deprecation for mitaka 20:12:17 shardy: yes. I currently open first mail too. 20:12:34 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 shardy: so we have enough time for doing it. just need to keep it in mind, as you said 20:12:46 http://lists.openstack.org/pipermail/openstack-dev/2016-February/085998.html 20:12:50 that's the thread btw 20:13:07 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085998.html 20:13:16 stevebaker: Yeah, I think we need the keystone team to clarify the migration plan 20:13:31 also that v2.0 compatibility of tokens thing mentioned worries me 20:13:42 as it implies trust scoped tokens won't work with v2.0 auth anymore 20:13:58 which would be a problem for many deployments unless it's papered over by authtoken middlware 20:14:15 hopefully folks will reply to the thread soon and we can discuss further there 20:14:26 yeah 20:14:48 stevebaker: one advantage is we actually maintain our own ec2token middleware 20:15:03 so if we have to, we can work around some sorts of breakages or moves in there 20:16:14 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 stevebaker: Yeah, although other AWS compatibility APIs need it, so a common repo somewhere makes sense long term 20:17:10 stevebaker: I am not a big fan of maintaining some deprecated somewhere code 20:17:54 stevebaker: but if we have not alternative I tend to agree with this suggestion 20:17:55 sure, but consumable as a lib (and rest api for those that really need it) 20:18:11 like tripleo-common 20:18:27 I think enough things depend on it that there will have to be a common repo somewhere 20:18:31 stevebaker: yeah. I understand. 20:18:38 it's not that much logic, only the signature calculation code really 20:19:08 the credentials API in keystone isn't going anwywhere AIUI, which is what backs the ec2tokens extension in v3 20:20:19 anyway, lets move on, we can continue this on the ML 20:20:49 shardy: ok. thank you for the clarification. now I know what happens with this stuff 20:21:04 #topic OSC commands 20:21:31 stevebaker: do we have any progress with it? 20:21:44 I have one little question about osc patches 20:21:53 I plan to enjoy review of some patches tomorrow 20:21:58 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 prazumovsky_ : what is the question? 20:22:33 client lib freeze is in 2.5 weeks so we have a shot at having 1.0.0 ready for that 20:23:01 stevebaker: aha. so it's the same dates as for m-3, right? 20:23:03 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 stevebaker: is it worth having an etherpad with the full list of patches? 20:23:23 http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html 20:23:28 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 shardy: there is one, hang on 20:23:42 shardy: https://etherpad.openstack.org/p/heat-support-python-openstackclient 20:23:50 jonesbr: thanks! 20:24:10 I mean, why some of them are out of the classes 20:24:10 markvan, jonesbr: hi! 20:24:15 it's confusing me 20:24:24 prazumovsky_: developer preference 20:25:05 they are private functions, someone can always refactor to a consistent style later 20:25:43 hm... how about incapsulation? 20:26:07 stevebaker: thanks 20:26:08 yeah, I was trying to follow the current style, but could be changed later 20:26:37 markvan, jonesbr: I might reorder that etherpad so reviewers can focus on the top items 20:26:37 IMO, if method using only in one class, it should be in it 20:26:50 (oh it's boring formatting...:-) ) 20:26:55 prazumovsky_: looks like we can fix/refactor it later 20:27:03 stevebaker: That would help us rebase the patches in order as well 20:27:13 true 20:27:20 prazumovsky_: you may file a bug as a reminder for these changes 20:27:29 ok, thanks 20:27:35 prazumovsky_: yup I would not disagree with your point 20:28:13 markvan, jonesbr: do you know if Amey is still contributing? 20:28:36 stevebaker: we contacted him and he gave us control of his patches 20:28:58 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 jonesbr: ok, it doesn't look like there are any orphaned changes at the moment, so good. 20:30:12 #link https://etherpad.openstack.org/p/heat-support-python-openstackclient 20:30:34 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 neelashah1: yeah, feel free to just take that over if there is no response 20:32:07 go to the next one. 20:32:15 ok, thanks stevebaker 20:32:16 #topic evaluating convergence as the default 20:32:51 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 things are staying as-is for M, we're too late to start shaking things up 20:33:15 hm. I don't see any one from HP guys, who have patches on review for convergence 20:33:19 stevemar: oh cool, thanks for the update 20:33:31 stevemar: thanks for the clarification, will be good to join your session & discuss the migration plan at summit then :) 20:33:46 stevemar: consider our request that nothing break duely lodged ;) 20:33:49 stevemar: great. could you please post link on session if you decide to schedule it on summit ? 20:34:11 skraynev_: will do. stevebaker request has been noted :) 20:34:28 stevemar: thank you 20:34:48 regarding convergence as the default, I am −2 on that at this point. 20:35:25 randallburt: could you add more details : why? 20:35:26 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 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 also, scenario coverage is still a bit incomplete. 20:35:55 I periodically switch to convergence and try deploying tripleo - my issues at the moment are around stack deleting 20:36:10 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 sabeen was seeing similar stevebaker 20:36:26 https://bugs.launchpad.net/heat/+bug/1523748 20:36:28 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 stevebaker: shardy: we have one important fix here https://review.openstack.org/#/c/248676/ 20:36:35 https://bugs.launchpad.net/heat/+bug/1542123 20:36:36 Launchpad bug 1542123 in heat "Convergence: stack-delete stalls on stacks stuck with IN_PROGRESS resources" [Undecided,New] 20:36:40 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 this fix is also important: https://review.openstack.org/#/c/277762/2 20:37:42 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 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 shardy: +1 20:39:02 and commit to backporting fixes to Mitaka until it turns out that backports are too big 20:39:28 stevebaker: do we strictly *have* to do that? 20:39:35 stevebaker: for convergence that is 20:39:37 stevebaker: +1 backporting bugfixes where reasonable sounds OK to me 20:40:04 oh, ok, as long as there's a "this is too disruptive, no backport" option 20:40:15 randallburt: there may be users who want to switch, like tripleo 20:40:27 shardy: Then it make sense do during month after m-3 20:40:32 randallburt: yeah, thats what I meant by "too big" 20:40:33 stevebaker: IMO they should wait for N to do that though 20:40:41 otherwise it may be more difficult for backporting, I suppose 20:40:43 stevebaker: its def not in a state for production use in M. 20:40:53 randallburt: sure 20:41:46 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 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 sure, I'm ok with it for certain values of "reasonable" :) 20:42:55 also higher risk backports might be acceptable since it's a nondefault 20:43:11 (note: that isn't a license to ignore "reasonable") 20:43:24 also what do you think about doing convergence default in N master after rc-1 ? 20:43:58 skraynev_: I think it is too soon 20:44:24 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 shardy: however, it *would* provide some incentive for those (like myself) that are coming in late to help 20:45:12 shardy: ok. can we then enable it for our tripleo job on gate 20:45:34 and after 1 month from this event do it default ? 20:45:40 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 skraynev_: Yeah, perhaps we can get the tripleo job running against heat again by default 20:46:03 my main idea is to have defined time line for convergence 20:46:13 and make that enable convergence on the undercloud 20:47:29 sounds like a plan. 20:47:33 sure 20:48:07 Related to convergence, there is a propoal to add Tacker (NFV orchestration service) to the big tent: 20:48:10 https://review.openstack.org/#/c/276417/ 20:48:17 #action skraynev will send mail about convergence related plans 20:48:57 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 it'd be good to get some feedback there from folks close to the convergence work 20:49:20 ouch. that commit message tho 20:49:26 e.g to add a summary of the current state, and the immediate roadmap 20:49:48 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 randallburt: heh, yeah it's pretty acronym heavy ;) 20:50:30 reading now russellb. thanks! 20:50:37 it's a bit of an essay .. 20:51:29 russellb: 100 % like an essay :) 20:51:39 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 but looks interesting 20:51:56 stevebaker: it has a "nova" driver and a "heat" driver 20:52:17 hmm, ok 20:52:21 for its "infrastructure driver" option ... 20:52:40 i asked if that was just for historical reasons, or if there was some reason the nova driver was still there 20:52:42 #topic Open discussion 20:52:47 I guess the question is do we need to be actively collaborating on "monitoring, healing and scaling" aspects 20:53:12 it'd certainly be good to get visibility of their requirements in that area 20:54:22 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 oh hey it's meeting day 20:54:37 zaneb: yup.. 20:54:40 some more info on http://git.openstack.org/cgit/openstack/tacker/tree/doc/source/devref/monitor-api.rst 20:54:50 zaneb: hey. we are really close to the end 20:55:02 looks like they want to do auto-scaling too ... 20:55:22 they should really be talking to the Senlin folk then 20:55:23 just occurred to me as something that really shouldn't be tacker-specific 20:55:41 because that would be a significant overlap 20:55:47 ok, if there's another project that should be looked at, a comment on the review would be great 20:55:56 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 yeah, it sounds like this could/should leverage several other openstack apis 20:56:58 russellb: thanks for highlighting it, there are certainly several potential areas for integration by the look of it 20:57:00 *nods* that's what we're trying to figure out for their application 20:57:13 basically, are they sufficiently taking advantage of existing stuff vs. reinventing stuff 20:59:16 time is out 20:59:27 thank you all. 20:59:44 all questions and discussion -> #heat 20:59:48 #endmeeting