20:01:37 #startmeeting heat 20:01:38 Meeting started Wed Dec 4 20:01:37 2013 UTC and is due to finish in 60 minutes. The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:41 please don't start a Marketing Committee meeting 20:01:42 The meeting name has been set to 'heat' 20:01:45 #topic rollcall 20:01:45 hah 20:01:50 hello 20:01:50 o/ 20:01:51 hi 20:01:51 heyya 20:01:52 o/ 20:01:52 o/ 20:01:54 o/ 20:01:57 o/ 20:01:57 o/ 20:02:02 o/ 20:02:08 hi o/ 20:02:13 hi 20:02:13 hi 20:02:19 hi 20:02:20 hi 20:02:42 irc.freenode.net just crashed from o/ 20:02:46 #topic Review last meeting's actions 20:03:04 #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-11-27-20.00.html 20:03:13 Randall to publish use cases for heat template catalog 20:03:25 \o/ 20:03:37 we have template catalog on the agenda, lets talk about that later 20:03:47 k 20:03:49 #topic Adding items to the agenda 20:04:02 Any items to add? 20:04:10 o/ 20:04:15 #linkg https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda 20:04:18 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda 20:04:38 o/ 20:04:43 #topic * icehouse-1 release 20:04:50 SpamapS: you made it !1 20:05:06 no quorum without spamaps ;) 20:05:14 #link https://launchpad.net/heat/+milestone/icehouse-1 20:05:16 if that were true... there would be no quorum ;) 20:05:23 we're looking pretty good 20:05:35 * stevebaker checks if we've actually branched yet 20:05:43 green is good 20:05:45 wow, that looks pretty good. 20:06:10 bumping all the non-green-things ftw! ;) 20:06:12 it did not look so good yesterday.. :) 20:06:26 can always do tomorrow what can't be done today ;0 20:06:27 damn, that's awesome 20:06:30 SpamapS: I just kicked all the things to i-2 ;) 20:06:33 right 20:06:36 https://github.com/openstack/heat/tree/milestone-proposed 20:06:58 we can still get bug fixes into i-1 20:07:22 stevebaker: this is merged, but not listed in the i-1 list https://blueprints.launchpad.net/heat/+spec/rackconnect 20:07:26 by tagging the bug with... 20:07:30 maybe it needs to be approved? 20:07:32 does anybody know? 20:07:37 milestone-proposed? 20:07:46 stevebaker: yea 20:08:07 stevebaker: Or actually, you just propose them by the backport process (same as stable) 20:08:15 jasond: fixed 20:08:17 but the branch you propose to is milestone-proposed 20:08:25 stevebaker: thanks 20:08:27 don't necessarily have to tag the commit 20:08:53 ok, what shardy said. 20:09:20 we got a lot of blueprints in, way better than grizzly-1 20:09:35 more community members ftw! 20:09:39 stevebaker: Anyone can propose them in theory, but normally I think the PTL monitors the bugs merged between branch and release, and propose as needed 20:09:50 or at least that's what I did 20:10:10 yeah, anything that gets fixed in the next few days I'll evaluate for milestone-proposed 20:10:24 well, the next day and a bit 20:10:30 * randallburt yells at tests to hurry up and work 20:10:36 #topic * Template catalog use cases 20:10:49 tims: commence the link spam ;) 20:10:51 randallburt: shoot! 20:10:55 https://blueprints.launchpad.net/heat/+spec/heat-template-repo 20:11:00 https://wiki.openstack.org/wiki/Heat/htr 20:11:15 \o/ 20:11:33 shouldn't that be HeaTR? 20:11:35 we basically added them to the existing bps and spec. We're still working on specs and don't want to spend much time there until everyone has a chance to review the use cases 20:11:39 shardy your wish is tims command :) 20:11:41 stevebaker: I like 20:11:52 haha 20:12:17 so there will also be a follow up ML post after the meeting to continue refining/consensus if that's cool with everyone. 20:12:21 randallburt had to tell me what HTR stands for 20:13:01 maybe HOTTeR? 20:13:07 oh, my 20:13:13 my money is on heat template repository 20:13:24 heattr 20:13:32 tims: So will this be a new orchestration project, not something we add via the existing heat API? 20:13:47 shardy: well that's up for debate 20:13:49 shardy: that's the plan ATM. 20:13:49 Has there been any evaluation of existing API driven things for managing a catalog of documents? 20:14:15 Like, what makes HOT special that it needs a new one? 20:14:39 Ok, my position has always been that we shouldn't be storing templates via the orchestration API, but I can see the value in some other service related to heat, provided we don't reimplement git in the process ;) 20:14:41 yes, surely the CMS crowd has solved this problem many times 20:14:51 SpamapS: some, but we still need to dig a bit more into your Glance proposal; I still need to see if it will actually work 20:15:12 shardy: There are lots of cool things that we could do if it were part of existing heat api 20:15:19 tims: such as? 20:15:21 Glance doesn't have versioning and it may never have it. So I accept Glance isnt necessarily the answer (though adding versioning to glance would probably make some image deployers very happy..) 20:15:35 but I haven't clearly defined those things atm which I why I'm not super passionate about it 20:15:36 shardy: we've talked a bit about HTR using git as a backing store and alternate means of management, but still need to document that as well 20:15:43 things that require engine parsing the template 20:15:51 I worry that there is a default position of building rather than consuming. 20:16:10 tims, randallburt: I have a use case which would be nice to add: 20:16:13 As a template author I want to add and manage templates in the repository using git 20:16:15 that may not do Heat things but we would not want to duplicate the parsing logic 20:16:18 SpamapS could you expand on that point? 20:16:51 For instance, cgit has search, tagging, versioning.. why not just add keystone token auth to cgit? 20:16:56 stevebaker: yup sounds good to me and something tims and I discussed yesterday quite a bit. we still just need to put those thougts into the associated wiki 20:17:15 stevebaker: agreed 20:17:21 tims: I may need a little more detail to really understand what you're proposing 20:17:35 SpamapS: fair point, but we've tried to step back and "do the right thing" here and just talk general use cases and get consensus around the service iteself 20:17:44 tims: Can you add a section to the wiki with the arguments for keeping the two things together? 20:17:48 shardy: Yes I'm working on a formal proposal 20:17:53 good idea 20:17:54 randallburt: fantastic, the use cases look realy solid actually. 20:18:09 tims: Just a quick brain-dump into the wiki is fine for now 20:18:18 shardy: will do 20:18:23 randallburt the approach seems right for a contentious change ;) 20:18:24 tims did all the heavy lifting. I just do reviews and go on vacation. 20:18:46 and vineethv too 20:19:05 " A service maintainer would like to have a repository in which he can manage Heat templates and maintain associated keywords and metadata." 20:19:12 can we please use non-gender-specific pronouns? 20:19:26 SpamapS: sure 20:19:27 tims, randallburt, so another issue is the apparent overlap with the scope of Murano. I think you guys really need to get together and find some common ground. The TC is only going to allow one template catalog into OpenStack. https://wiki.openstack.org/wiki/Murano 20:19:31 SpamapS: yeah I started going back through and fixing that stuff 20:19:34 but I haven't finished 20:19:44 cool 20:20:28 stevebaker: agreed. tims or I can reach out to them. They originally posted a comment on the BP a while back and I think they may be complementary when I read what they proposed, but I'll go see where they're at. 20:21:11 randallburt: chances are they would be more than happy to use heattr as their cataloging layer 20:21:27 shardy: an initial idea is parsing the template to retrieve the "planned stack" resources based on parameters 20:21:45 so we know exactly what resources are created before stack instantiation 20:21:47 stevebaker: my thoughts exactly 20:21:59 the argument I'm having with randallburt is whether thats a feature of Heater or Heat 20:22:04 stevebaker my understanding is Murano is a 3rd party (sell your stuff) Application Catalog. and, HTR is a template catalog for Heat templates. 20:22:14 tims: You mean like a template cost estimate or something? 20:22:14 randallburt: and maybe https://github.com/stackforge/murano-dashboard can be the start of a horizon frontend to heattr 20:22:23 tims shardy but that is a different bp imo and may belong in heat api proper, but its another issue to discuss 20:22:31 shardy: more or less 20:22:36 stevebaker: oh cool. I'll check that out. 20:22:53 randallburt: agreed but it could have ramifications on the discussion about putting Heater in Heat proper 20:23:12 tims: oh, right. yeah, thats going to be a fun one ;) 20:23:34 kebray: Sell your stuff or give your stuff away, sounds _very_ related. 20:23:39 tims: Ok, maybe we could have an API call which validates a template and returns a list of resources or something 20:23:49 FWIW, lets get mailing list consensus on the UC/scope of Heater before we dive in to those waters. 20:23:57 kebray: ah. that sounds they are a layer above heattr. They should be strongly encouraged to get involved 20:24:02 tims: Heat is a component of the Orchestration program, so hopefully the ramifications won't be overblown 20:24:03 SpamapS agreed... will connect with the Murano folks more. That project keeps changing. One day it's windows, the next it's an app store. 20:24:03 Make sure the Murano folk have seen everything. 20:24:18 kebray: agreed, that may be enough reason to stay away ;) 20:24:22 shardy: :) yes I have thoughts about the validate endpoint too 20:24:30 shardy: yeah, IMO its a tangental use case in which the user wants to know before they create a stack just how many of which resources would be created; not sure that's a Heater thing. 20:24:40 so if there is some POC code that already exists, lets get it into stackforge with a new gerrit core team 20:24:48 Yeah, they knew about HTR before they switched Muran's definition. The answer I got was they are doing something different. but, we will def reach out to them again. 20:25:03 tims: So IMO we could add some calls to support this, but I still remain very unconvinced that we should expose a template store via the heat (*orchestration*) endpoint 20:25:14 stevebaker: about that, there is, but is having it in the Orchestration *program* still on the table? 20:25:22 If it eventually gets proposed to being part of the orchestration program, the gerrit team will become heat-core 20:25:28 shardy: fwiw I agree. 20:25:30 sdake_ shardy point taken and I am in general agreement 20:26:20 stevebaker: because IMO, it belongs in the program and if we have a proposal for it now, I'd rather avoid the double work of getting it in stackforge and then moving it. 20:26:29 shardy randallburt , I think tims and I are in opposition with you guys... will definitely be good to understand each other's sides. More discussion to be had. 20:26:38 fwiw, I took a good look at Murano, and I don't think it's similar enough to be a fit for this. 20:26:41 ok, maybe it's just me :-) 20:26:44 as long as the proposed schema for heater has not valid use for Heat 20:26:55 kebray I have some conditions in my agreement ;) 20:26:58 one thing about a program.. 20:27:03 hehe.. sure sure tims . 20:27:05 I agree with randallburt they are complimentary 20:27:11 is that programs can reach across to other projects and programs to achieve their mission. 20:27:35 programs are specifically _not_ silos. 20:27:46 randallburt: moving from stackforge -> openstack isn't a huge deal. I don't know the process but I think a new source tree still needs some form of incubation even if it is part of the orchestration program from the start 20:27:46 SpamapS +1 20:27:53 +1 20:28:10 Yeah, my real question is "Can we develop this under github.com/openstack/heat-repository from the get go"? 20:28:13 #action stevebaker find out the incubation process for new projects in existing programs 20:28:28 as part of the orchestration program 20:28:37 stevebaker that sounds like a popcorn-filled conversation :) 20:28:43 randallburt: yes 20:28:50 I don't think there is a process yet 20:29:06 we've added lots to openstack/xxx in TripleO 20:29:09 SpamapS: k. certainly something we can explore more on the ML 20:29:20 randallburt: we probably could, but it would most likely mean being owned by heat-core from the start. You might make quicker process with a new -core team, which would imply stackforge for now 20:29:25 integration into the release is what the incubation process brings, but the program gives you "officialness" 20:29:37 thats a word 20:29:39 I swear 20:30:06 stevebaker: what's wrong with using the current head-core for it? 20:30:09 another possible solution is to grow heat-core, which we should anyway 20:30:14 s/head/heat/ 20:30:14 stevebaker: true and good point which we've of course discussed before. Just want to make sure we're all aware of the actual options. 20:30:16 reviews! reviews! reviews! 20:30:26 :3 pages: 20:30:32 need moar reviewers -> more heat core !! 20:30:36 adrian_otto: If most of the folks working on it aren't heat-core, they may get frustrated when we're slow reviewing their stuff ;) 20:30:45 shardy: I see 20:31:03 adrian_otto: I guess there are advantages to either approach 20:31:04 stevebaker: we can create sub-teams that are not heat-core but have access to a different openstack/xxxx repo 20:31:18 yeah we do actually need more reviewers 20:31:19 SpamapS: do tripleo do that? 20:31:35 SpamapS: with all your many many repos? 20:31:37 http://russellbryant.net/openstack-stats/heat-openreviews.html 20:31:49 stevebaker: we have talked about doing so for tuskar 20:31:57 stevebaker: but ultimately we just encouraged tuskar folk to review everything ;) 20:32:05 Average wait time: 1 days, 1 hours, 20 minutes 20:32:19 not too bad in comparison to some other projects IME 20:32:27 unfortunately I spend 2 hours a day doing reviews 20:32:34 would be nice to trim that to 1 hour :) 20:32:41 shardy: but that could be spread over way more reviewers 20:32:48 http://russellbryant.net/openstack-stats/heat-reviewers-60.txt 20:32:53 sdake_: only 2!!?? 20:33:00 stevebaker: I agree, and I think there are some potential candidates coming along :) 20:33:09 I haven't had the willpower to do any reviews since thanksgiving :( 20:33:10 Right I think we're doing well because we're all committed to doing well... but we could use more reviewers 20:33:25 * SpamapS notes ----> Open Discussion as we are OT 20:33:49 hi all 20:34:10 can we create a topic in openstack-dev specifically for heat? 20:34:19 randallburt: so you should start a ML thread to talk about new project, where to host, who to be -core etc? 20:34:32 stevebaker: that's the plan 20:34:39 sounds good 20:34:43 lets move on 20:34:43 one more thought: if Heater is separate from Heat as just a template store that's fine, the problem is we are defining additional schema for Heater which may be useful to templates or users not interfacing with Heat via Heater. so when looking at the proposed schema maybe some of it goes in the template and then Heater is literally crud operations on templates? 20:35:03 we can discuss on ml 20:35:13 tims details on ml I think are better 20:35:19 got it 20:35:43 yeah and also the schema-for-packaging is contentious 20:35:45 tims: we can add things to the HOT schema. Most potential additions would probably be useful to things other than heater 20:36:17 #topic open discussion 20:36:47 sorry for offtopic above - couldn't wait.. 20:37:08 we have a [heat] tag on openstack-dev ml already? 20:37:15 stevebaker: should I not have approved https://review.openstack.org/#/c/59577/5 ? 20:37:19 pshchelo_: the way it generally works is we have [heat] prefix for our subjects 20:37:21 yes, but you can not subscribe to it 20:37:30 stevebaker: or will the branch just be made off some commit that is already there? 20:37:33 there's only one openstack-dev 20:37:39 only filtering 20:37:52 pschelo_ thats what mail filters were invented for :) 20:37:53 can we discuss autoscaling api in this open discussion, I have a question on the load balancer member 20:37:56 pshchelo_: That's what the tags are for ;) 20:38:33 you can subscribe to specific topics on openstack-dev, but heat is not one of them 20:38:46 SpamapS: milestone-proposed is already branched, so we're open for features again I think 20:38:50 pshchelo_: contact Stefano about that, he can and should add it. 20:38:52 pschelo_ do you have a link as an example? 20:38:55 stevebaker: ok cool 20:39:11 filters I know, but still receiving the whole list 20:39:32 which is a bit overwhelming 20:39:33 prasadv: ask away 20:39:33 mark all read ftw ;) 20:39:47 can the load balancer member be non IP based 20:39:48 that's a solution for now 20:40:10 there are cases where the autoscaling can be done on a neutron port or mac address 20:40:44 in that case it would be a custom LB 20:40:53 i mean non neutron LB 20:41:05 prasadv: it seems reasonable for a member to be a port UUID instead of an IP 20:41:18 ideally we dont want to reimplement neutron's load balancer 20:41:23 * radix reads backlog 20:41:36 but if people use heat in that way, I don't think we should be in a position to stop them 20:41:53 i assume one can configure any load balancer right? 20:41:57 when you log in to your mailman subscription manage page for openstack-dev 20:41:59 http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev 20:42:14 prasadv: are you referring to the idea for a PoolMember resource? 20:42:17 not just Lbaas 20:42:24 Right Heat should be enabling the Neutron LB the way Neutron users want it to work. So if it allows adding port UUID members, then Heat should do that. 20:42:26 pschelo_ contact the list manager at the bottom of the page - he can add heat there I suspect 20:42:26 radix: yes 20:42:43 prasadv: presumably PoolMember will match the pool member API in whatever it accepts 20:42:46 sdake_: thanx 20:43:07 pschelo_ nobody here knows the list admin password :) 20:43:23 radix: thanks 20:43:35 prasadv: I don't know if that answers your question, I'm having a hard time understanding it 20:43:39 prasadv: how would a FloatingIP become a pool member? 20:44:10 wasn't sure if I'm not missing smth 20:44:35 stevebaker: I dont understand the question? Are you talking about non neutron LB? 20:45:20 radix: Load balancing in some scenarios can be based on port, particularly related to service chaining 20:45:45 prasadv: for neutron LB, should we support adding a FloatingIP to a LB pool? 20:46:16 radix: autoscale is one important component of service chaining 20:46:24 I think he might be asking if you could use a pool as an inventory of floating IPs 20:47:17 stevebaker: generally floating IP is external and it is mapped to internal IP addresses. One could get away with using internal IP addresses. I think 20:47:34 I think what I'm referring to is this bug https://bugs.launchpad.net/heat/+bug/1256836 20:47:35 Launchpad bug 1256836 in heat "associate vip with floating ip" [Medium,Triaged] 20:48:13 stevebaker: I will look at the bug. Dont have the context on that 20:48:40 prasadv: ok, feel free to comment on it, especially if you think it is not valid 20:48:57 anything else, should we wind up the meeting? 20:49:00 anyone interested in talking a bit about the sync/convergence feature: https://blueprints.launchpad.net/heat/+spec/stack-convergence? 20:49:23 lets wind up! 20:49:51 we're working through initial implementations and have been trying to work through some scenarios: https://etherpad.openstack.org/p/heat-convergence 20:50:29 arbylee: it looks like zaneb has started working on https://blueprints.launchpad.net/heat/+spec/update-failure-recovery which may be tangentially related 20:50:30 arbylee: is that a duplicate bp? I thought we discussed convergence at the summit, but it might have been a result of another bp. Just want to make sure they're linked. 20:51:25 randallburt: not duplicate, but related I think 20:51:33 we didn't see a blueprint raised out of the summit for sync/converge. There was one for auto-retry on create failures 20:51:43 one is about restarting a failed update, or updating from a failed state 20:52:02 rather than updating from a complete state and inspecting all the resource states 20:52:10 shardy, arbylee ok, cool. just wanted to row the ducks if needed ;) 20:52:17 oops, bit late 20:52:27 howdy 20:53:00 arbylee: would you like to target heat-convergence to icehouse-2 or icehouse-3? 20:53:49 stevebaker: icehouse-2 sounds like a good target so far 20:54:02 done, and approved 20:54:06 and IIRC, we discussed there being two separate operations 1. tell me what the differences are and 2. Make the stack match the template if it doesn't. 20:54:57 https://etherpad.openstack.org/p/icehouse-summit-heat-convergence 20:55:09 randallburt: right, our initial WIP commit produced a diff. there were concerns about the scalability of that operation though 20:55:47 the resulting vision seemed to be to provide the two actions: 1) make my local stack reflect the real world resources and 2) Make the stack match the template if it doesn't. 20:56:21 arbylee: ah, cool, though 1 sounds a little tricky when you get to instance configuration stuff 20:56:47 randallburt: we could have an update which just aligns the resource states with the state of the underlying resource 20:57:15 shardy: sounds simple enough in that case. 20:57:20 shardy: that's our current development right now 20:58:01 andersonvom: Cool, that's the first step IMO, then the next is to actually update the resource to e.g align from FAILED to COMPLETE state 20:58:14 the second step will probably be the difficult bit ;) 20:58:34 2 min 20:58:36 shardy: agree. and agree. =P 20:58:51 shardy: we've been having some debate on that first bit even. 20:59:13 arbylee: sounds like a good ML discussion then ;) 20:59:18 andersonvom: That second step may end up being related to the restart-from-failed work which zaneb is looking at 21:00:12 randallburt: then ML discussion it shall be 21:00:21 shardy, randallburt: true. we'll bring it up on the ML and sync up with zane to see what parts may be 'shared' 21:00:30 andersonvom: +1 21:00:43 endofmeeting? 21:00:48 whoops 21:00:48 seems so 21:00:52 #endmeeting