20:00:50 #startmeeting heat 20:00:51 Meeting started Wed Apr 10 20:00:50 2013 UTC. The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:54 The meeting name has been set to 'heat' 20:01:08 #topic rollcall 20:01:12 o/ 20:01:14 shardy here 20:01:14 o/ 20:01:25 hi! 20:01:49 w00t 20:01:50 hi 20:03:02 #topic Review last week's actions 20:03:17 So I don't see any in the minutes, and I didn't make last weeks meeting 20:03:35 yea, I can't remember any 20:03:38 Anyone got anything to report related to last week's discussions? 20:03:42 the minutes are in a link off the agenda page but don't recall any actions 20:03:54 ok, can move on then 20:04:07 #topic Summit session review 20:04:29 So I guess we've reviewed the sessions, but are we happy with the sessions, and who's doing what? 20:04:54 yea, I need to do some work on mine 20:04:57 Hello 20:05:13 I'm planning to lead the credentials session, but anyone have anything they need help with for the sessions they proposed? 20:05:38 we should have time to prepare for the Heat Update session in person 20:05:51 stevebaker: sounds good 20:05:53 not sure if SpamapS wants me to lead the parallel resource creation session? 20:06:08 also, not sure what that session should involve 20:06:11 For those who missed it earlier, we're planning an informal Heat get-together on the SUnday night 20:06:18 "once upon a time, I already wrote all the code." 20:06:28 anyone has any thoughts on scaling heat look here: https://etherpad.openstack.org/heat-multiple-engines 20:06:42 zaneb: Live demo? :D 20:06:51 lol 20:07:05 we should really put stuff in the etherpads so others can contibute 20:07:07 that assumes I can actually still get Openstack to install and run on my laptop 20:07:14 where will the information get together be? 20:07:19 informal* 20:07:25 https://wiki.openstack.org/wiki/Summit/Havana/Etherpads#Heat 20:07:48 barefoot, don't know 20:07:51 barefoot: to be decided 20:07:58 kk thanks 20:08:19 we will meetup at the sunday summit registration 20:08:38 I think that is 3pm 20:09:17 ok 20:09:23 (see where to go from there) 20:09:35 Anything else summit related? 20:09:52 what is the deal with the OpenShift event on Sunday? 20:10:17 will that cause scheduling issues? 20:10:24 I've signed up for it but I may just drift in an out 20:10:28 not sure, but if you can go that would good 20:10:40 o/ 20:10:42 stevebaker: link? 20:11:07 http://openshiftorigincommunityday.eventbrite.com/ 20:11:11 3 tickets left! 20:11:32 btw, would any of the RAX folks who might be here like to introduce themselves? 20:12:18 o/ 20:12:37 hi sandy 20:12:53 zaneb: hey man, I'm Duncan McGreggor 20:13:14 so, there's two teams involved here from RAX, right? 20:13:14 zaneb: hey, I'm Shawn Ashlee 20:13:31 welcome guys :) 20:13:32 some other RAX folks are at lunch, but they should be here soon 20:13:35 shardy: thanks! 20:13:41 indeed, welcome 20:13:46 thanks 20:13:52 wirehead_ <-- Racker too 20:13:56 hello 20:14:05 would y'all like to give us a rundown on which areas you're working in? 20:14:07 are you guys attending other summit dev sessions? 20:14:17 asalkeld: yes 20:14:29 or could we do some more meetups on tue/wed 20:14:51 one of those days seemed a bit "light" 20:14:52 still working out the logistics on who exactly will be there, but we'll be in most of the Heat discussions at the summit 20:15:01 asalkeld: +1! 20:15:37 well maybe we can grab an unconf. room 20:17:05 I'm Felix Sargent, Hi! <-- Racker 20:17:35 hi 20:17:55 zaneb: oh, your suggestion -- yes, we can talk about the autoscale portion 20:18:06 not sure if the other team is here right now or not? 20:18:36 ok cool, thanks for that guys 20:18:53 we're super curious to see where folks want to take autoscaling 20:18:57 you guys interested in autoscale must also go to the thursday ceilometer talks 20:19:07 I'll be there. 20:19:09 planing alarming 20:19:22 whether that's to split some portion out for a user-consumable API with a standalone REST API service or whether everything happens in Heat 20:19:59 whichever one ends up being the preferred approach, we want to start hacking on contributions that make "that" possible 20:20:07 (whatever "that" ends up entailing) 20:20:14 oubiwann, we could have a "user-consumable API with a standalone REST API service" in heat 20:20:21 in other words, no agenda, just devs ready and waiting to jump in! 20:20:25 that would also be easy 20:20:31 cool 20:20:37 asalkeld: that sounds like a great start, then! 20:21:06 Yeah, agree, easiest first step is to leave the AS core logic in heat-engine and add a new API if that's what you need 20:21:24 so one problem is it is difficult to depend on a non-core project 20:21:30 +1 20:21:38 o/ 20:21:43 sorry.. got stuck in traffic 20:21:56 SpamapS: wassup! 20:23:00 wow we are going to have a pile of devs from now on 20:23:06 :-) 20:23:27 :) 20:24:11 Do we want to continue this AS discussion next week, and firm up plans potentially for some additional informal/meetup time during the week? 20:24:29 asalkeld: sorry, working on parsing intent of that comment… maybe this?: meaning that keeping it in core makes things a lot easier, and if there ever was a need to split things, it would likely be very obvious and Heat would generate a new project (that presumably would also be accepted as core)? 20:24:36 re Sunday night, thats a nogo for me, I don't arrive until nearly midnight 20:24:53 :( 20:25:09 oubiwann, well we would have to have a copy in Heat 20:25:17 ah, got it 20:25:18 yeah 20:25:22 awkward 20:25:22 so if we really want to split 20:25:32 the code will need to be sync'd 20:25:40 regarding autoscaling, I'd suggest that people do some brain dumps to mailing list today/tomorrow so we can all do our homework over the weekend and come prepared with solid questions. 20:25:41 for a while anyways 20:25:42 oubiwann: o/ 20:25:43 * oubiwann nods 20:25:55 SpamapS: +1 20:26:00 lifeless: ! 20:26:03 it's also a lot easier to incubate a new project inside an existing core project than to try and get it accepted from scratch 20:26:18 nova->glance 20:26:27 I'd also like people to think on what Heat really is and why it should encompass autoscaling. 20:26:34 I am not sure of the value in seperating - personally, there is not much logic in autoscaling 20:26:38 TO me, it is "the thing which calls the other APIs" 20:26:50 if the monitoring can do alarms 20:26:56 Which is why AS in heat makes a lot of sense. 20:27:19 basically what is left is cooldown 20:27:32 it makes sense that people who are not using templates still want to use autoscaling though 20:27:35 I can envision wanting to use AS outside of heat, though. 20:28:04 you guys are getting confused with project view and deployment view 20:28:32 zaneb: right, which is why I suggest Heat not be "the thing that parses templates into API" 20:28:38 what project some code lives in does not determine how you deploy 20:28:40 asalkeld: right. sorry, kinda new to the party here. 20:29:11 as long as we have a good seperate rest api for people to use 20:29:20 (still open to tho') 20:29:26 (still open to it tho') 20:29:26 that's true, as long as it really can be deployed independently 20:29:34 The template API is just the declarative entry point. Imperative calls "make me a stack. make an instance in the stack. make a scaling group in the stack." should be added to appease the "no templates for autoscaling" use case. 20:29:35 yip 20:29:56 nice 20:30:21 our friend from the ML will not be happy 20:30:29 * oubiwann chortles 20:30:31 but! 20:30:45 zaneb: I hope that he will, once we are all in a room and chatting about it. 20:30:47 it sounded like he just needed to have some good conversations with folks… 20:30:53 SpamapS: bingo 20:30:54 hopefully 20:31:15 in any event, even if we want to make it separate, giving it a separate api is the first step 20:31:21 This is why taking out the language from the wiki page "Heat is [basically CloudFormation]..." is so important. :) 20:31:27 so I think we can all support doing that 20:31:38 "One aspect of Heat is compatibility with CloudFormation" 20:32:18 well it has always been the project that uses everything 20:32:34 so we end up having to impl. missing stuff 20:32:39 like lb 20:32:47 autoscale/cw 20:33:02 and it makes sense to split some out 20:33:14 but maybe not everything 20:33:15 how far along is Quantum LBaaS, does anyone know? 20:33:16 asalkeld: right, that pragmatism can continue for sure.. but autoscaling feels like it will happily live just fine in heat. 20:33:34 oubiwann: PoC from what I understand, but rapidly evolving. 20:33:39 as in, they have proved the concept 20:33:57 rhm 20:33:59 okay 20:33:59 oubiwann, honestly not sure, but probably more evolved than ours 20:34:02 SpamapS: we couldn't split it out altogether without signoff from the TC anyway 20:34:20 zaneb, I think they have an api 20:34:26 (stable) 20:34:37 that multiple projects implement 20:34:46 we have a blueprint to make use of that? 20:35:06 yea there is one 20:35:14 * zaneb has lost track of what we're talking about 20:35:21 I think we're still on LB 20:35:21 lbaas 20:35:28 asalkeld: there is? 20:35:28 thanks ;) 20:35:35 looking 20:36:17 maybe not 20:36:20 we're talking about how Heat has implemented things internally that exist in other incubated or even core projects (reddwarf and quantum lbaas) 20:37:05 SpamapS: Yup, we should raise BPs for cases where there are viable projects we could use instead of our nested implementations 20:37:14 so we need to use lbaas and ceilometer for alarming (when that is ready) 20:37:17 yeah, and we should scrap those internal implementations as soon as there's an integrated project for it 20:37:39 I love you guys 20:37:40 and there is moniker too 20:37:51 yikes settle down 20:37:54 ;) 20:38:06 rofl 20:38:12 * oubiwann puts the group hug on hold 20:38:18 Are we veering OT here - there's blueprint review on the agenda, shall we move on? 20:38:20 zaneb: I think those should live-on as deprecated for a while. There will be times that compatiblity is not 100% and people need a release-cycle to fix things. 20:38:40 SpamapS: contrib/plugins? 20:38:46 zaneb: yeah I like that 20:39:06 so glad we implemented that whole plugin thing 20:39:14 haha 20:39:14 +1 20:39:15 solves so many arguments :) 20:39:57 there seems to be a new aas every week 20:40:23 asalkeld: I was saying to a colleague the other day 20:40:24 #topic Blueprint review for Havana 20:40:29 asalkeld: we need aasaas 20:40:43 other thing when you see one is to encourage them to use heat for org 20:40:52 haha 20:41:07 Looks like we got to this one: 20:41:13 #link https://blueprints.launchpad.net/heat/+spec/auth-token-only 20:41:29 stevebaker: you're working on this now right? 20:41:54 Yep, just need some reviews on what is there 20:42:13 * SpamapS will hit the review queue post meeting 20:42:17 * asalkeld not an auth guru 20:42:28 stevebaker: Ok, cool, I'll bump the status then 20:42:29 It looks like there is potential to pass the service catalog from api->engine... 20:42:56 is there anyone interested in multi-cloud? 20:42:58 so that can change anything that fetches auth_url from the context 20:43:15 or an endpoint from heat-engine.conf 20:43:16 like regersting multiple openstack clouds 20:43:31 I had a play with multicloud against HP 20:43:50 stevebaker, you could think about how we could support that 20:44:02 I think we can get there, but we'll either need to patch or subclass keystoneclient auth_token 20:44:14 #link https://blueprints.launchpad.net/heat/+spec/bash-environment-function 20:44:16 yes, but would be easier to explain with a beer in one hand 20:44:32 :) 20:44:33 zaneb: you happy to take this one? 20:44:36 asalkeld: openstack-infra is interested in multi-cloud, but dunno if they can get to it this cycle. 20:44:45 sure 20:44:48 sure 20:44:55 zaneb: or choose a template format? 20:44:58 although, there was a competing proposal too I thought 20:45:14 #link https://blueprints.launchpad.net/heat/+spec/cfn-create-aws-symlinks 20:45:19 https://blueprints.launchpad.net/heat/+spec/template-string-function 20:45:25 isn't that done? 20:45:31 So I think this one is being handled via heat-cfntools? 20:45:46 aws-symlinks 20:45:47 stevebaker: yeah, that one. I like that one better 20:45:48 ya 20:45:49 that should probably be transferred to heat-cfntools 20:46:14 stevebaker: k, I thought this was already done, we can move or obsolete it 20:46:33 https://blueprints.launchpad.net/heat/+spec/cloudwatch-update-stack 20:46:45 I'm doing this one, should be simple 20:46:46 that is going to be never ending 20:47:09 o, that one 20:47:15 shardy: I've obsoleted it 20:47:24 didn't see the cloudwatch bit 20:47:41 * shardy has been forgetting \# link 20:47:44 oops 20:48:01 #link https://blueprints.launchpad.net/heat/+spec/configurable-loadbalancer 20:48:19 heh 20:48:29 that one is obsoleted by lbaas 20:48:38 I got quite far with that one 20:48:40 lets implement an LBaaS resource type instead 20:48:53 not quite, it raised interesting issues 20:48:59 so it was good 20:49:01 ok, sounds good, we can raise a LBaaS BP and obsolete this one 20:49:01 native *and* aws please? 20:49:23 for the nested stack resources we have... 20:49:30 stevebaker, goes native 20:49:30 stevebaker: agree, same goes for lots of other resource too tho ;) 20:49:33 it might be good to load the template from a file 20:49:38 instead of putting it inline 20:49:56 11 minutes... perhaps we should remain at periscope depth for the remainder? 20:49:57 or reference a running stack? 20:50:13 I'd like to talk heat-cfntools security fix release 20:50:25 indeed 20:50:32 Ok, lets move back to open discussion for the last 10mins and talk bps more next week 20:50:42 I guess there will be lots more after summit anyway ;) 20:50:46 next week == summit ;) 20:50:50 #topic open discussion 20:50:59 https://bugs.launchpad.net/heat-cfntools/+bug/1164756 20:51:01 https://bugs.launchpad.net/heat-cfntools/+bug/1166323 20:51:03 So two things I wanted to mention: 20:51:41 stevebaker: I think once the commits are solid we should draft an announcement, and just commit/release/announce all at once. 20:51:42 1 - I've offered to step in for sdake doing PTL duties, then we'll have a proper vote on it (and anyone else can step up) after summit 20:52:23 sounds good 20:52:25 2 - There a pile of VPC/Quantum related bugs in New state - stevebaker and/or jpeeler, can you triage and take some of those? 20:52:53 yep, they should already be assigned, mostly to jpeeler ;) 20:53:03 haha, nice :) 20:53:13 Ok, anyone else got anything to discuss? 20:53:41 try sleep on your flight 20:53:53 I have zero timezone changes on my flight. 20:53:55 SpamapS has some /tmp security fixes for heat-cfntools. I just wondered if there is anything different we should do once they are ready for release 20:54:30 maybe ask the os sec folks 20:54:39 stevebaker: we don't need a CVE or anything, as heat-cfntools is pretty nascent and may not even be distributed just yet.. 20:54:45 and Sources tarball extraction isn't working for me, which is hindering testing https://bugs.launchpad.net/heat-cfntools/+bug/1166323 20:54:56 asalkeld: I did, they said incubated projects don't fall under their umbrella, and suggest an informal release. 20:55:10 maybe just release fast 20:55:17 yeah thats what I think we should do 20:55:20 so people get the fixes 20:55:24 SpamapS: OK, I guess you should just raise normal gerrit changes then 20:55:44 ok, can I get a commitment for reviews in the next 2 hours? 20:55:57 actually 20:56:00 lets coordinate in #heat 20:56:15 yep, but as i said #1166323 doesn't work for me atm 20:56:16 don't need everybody for this 20:56:23 stevebaker: right I have a fix for that 20:56:28 sweet 20:56:38 * SpamapS is spinning a lot of non-heat plates this week unfortunately 20:57:06 Ok, nearly out of time, anything else? 20:57:18 Ok, thanks all 20:57:21 #endmeeting