20:02:39 <zaneb> #startmeeting heat
20:02:40 <openstack> Meeting started Wed Sep 24 20:02:39 2014 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:44 <openstack> The meeting name has been set to 'heat'
20:02:56 <ryansb> hey folks
20:02:59 <BillArnold> hi
20:03:14 <zaneb> I know stevebaker has been waiting for 24 hours for this :)
20:03:21 <pas-ha> lol
20:03:45 <stevebaker> \o/
20:03:49 <tspatzier> hi
20:04:27 <zaneb> stevebaker: do we really need a FFE status agenda item, or was that a copy-paste fail?
20:04:46 <stevebaker> its copypasta
20:05:17 <zaneb> it's goneburger
20:05:50 <zaneb> #topic Review action items from last meeting
20:06:13 <zaneb> #link http://eavesdrop.openstack.org/meetings/heat/2014/heat.2014-09-17-12.00.html
20:06:28 <zaneb> review python-heatclient support for merged features as a priority
20:06:36 <zaneb> we got all that stuff in!
20:06:40 <pas-ha> https://review.openstack.org/#/c/122934/
20:06:40 <zaneb> thanks everyone
20:06:49 <zaneb> nice job on the release stevebaker
20:06:52 <pas-ha> stack check is missing
20:07:11 <zaneb> doh!
20:07:14 <stevebaker> there are a couple of regressions which will need a 0.2.12, likely today
20:07:23 <zaneb> because it wasn't submitted until this weekend :/
20:07:24 <stevebaker> pas-ha, is it ready for review?
20:07:34 <pas-ha> stevebaker, seems so
20:07:50 <stevebaker> pas-ha, ok, lets review that for inclusion in 0.2.12
20:08:07 <pas-ha> I've +1 already
20:08:38 <stevebaker> #action all review https://review.openstack.org/#/c/122934/
20:09:00 <zaneb> ok
20:09:01 <ryansb> related: I'm ready to package 0.2.12 once it's set to go
20:09:04 <zaneb> therve sync oslo incubator
20:09:10 <zaneb> not sure if that happened?
20:09:28 <pas-ha> I did not see it in reviews
20:09:43 <zaneb> #action therve sync oslo incubator
20:09:58 <zaneb> #topic Adding items to the agenda
20:10:09 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-09-24_2000_UTC.29
20:10:13 <zaneb> anything else?
20:10:46 <stevebaker> zaneb, how about discuss deprecating HARestarter
20:11:07 <zaneb> we already discussed that once, do we have any new information?
20:11:33 <stevebaker> an actual review https://review.openstack.org/#/c/121702/
20:11:43 <pas-ha> also deprecating CWLiteAlarms
20:12:23 <zaneb> stevebaker: https://review.openstack.org/#/c/121824/ <- what did you think started that discussion?
20:13:09 <stevebaker> lol, I did a search but didn't find that
20:13:19 <zaneb> oh wait, you were first by the looks of it
20:13:21 <stevebaker> carry on
20:13:41 <stevebaker> yours has enhanced verbosity
20:14:03 <zaneb> lol
20:15:22 <zaneb> ok, lots of time available for...
20:15:30 <zaneb> #topic Release cadence
20:15:37 <pas-ha> I've added CWLiteAlarms to agenda
20:16:43 <zaneb> so IMO mordred's proposal on release cadence has both up- and down-sides for us
20:17:08 <zaneb> but I think before we can have that discussion, we need to have a discussion about standalone mode
20:17:28 <stevebaker> So if you haven't already read http://inaugust.com/post/108 you should. mordred's suggestion #10 is that end-user tools like heat and horizon should adopt a rolling release model so that users get the user-focused features as soon as they are available. this likely affects ttx and david-lyle too. Discuss!
20:17:49 <pas-ha> I actually fail to see a use-case for rolling release - how many clouds are running openstack master?
20:17:51 <zaneb> because the truth is that atm Heat requires tight integration with Keystone to be really useful
20:18:01 <stevebaker> pas-ha, rackspace
20:18:25 <pas-ha> do they run the whole openstack from master? ot just Heat?
20:18:32 <zaneb> I'm not sure if it's working for HP because they have their proprietary-not-keystone auth thing still (do they?)
20:18:41 <zaneb> or if they just make very limited use of Heat
20:18:51 <stevebaker> zaneb, we're close to using swift TempURLs for all the things, so we won't even need to create users for resources soon
20:19:12 <zaneb> stevebaker: that might help one part of the issue
20:19:17 <stevebaker> I think HP are waiting for heat to scale
20:19:18 <zaneb> the other part is trusts
20:19:52 <stevebaker> with standalone, password deferred auth seems entirely appropriate since it is their heat
20:20:16 <zaneb> so maybe we need a (potentially cross-project) plan to address standalone mode
20:20:34 <zaneb> but that would be a pre-requisite to changing the release cycle
20:20:52 <zaneb> that said, I would still personally be -1 on changing the release cadence
20:21:04 <stevebaker> I cleaned up devstack support recently, and it works quite well https://review.openstack.org/#/c/123330/
20:21:52 <ryansb> I see a value in it for active contributors (Rackspace) but I don't think it'd be good for the Heat community overall
20:22:08 <ryansb> esp. since Rackspace serves its own needs just by running master
20:22:20 <stevebaker> I think we should only do it if horizon does. It is unfortunate that a feature that adds one property to a resource can't be delivered to users who want it for 6 months
20:23:00 <mordred> so - the reason I was suggesting rolling release is to support folks running them as end-user tenants
20:23:17 <stevebaker> mordred, you mean standalone?
20:23:19 <mordred> yes
20:23:57 <mordred> because if I'm running standalone heat _against_ A cloud, waiting for 6 months to pick up support for a new feature just because seems silly
20:24:13 <mordred> I obviously might be wrong of course
20:24:21 <stevebaker> milestones tend to get packaged downstream anyway, so they can always consume those. Or the impending docker images which might be available at whatever cadence
20:24:49 <zaneb> mordred: yeah, that sucks. but I'm not sure that it is _more_ true of Heat/Horizon than of any other program
20:24:59 <mordred> yah. it may even just be more having awareness that heat may be running against a different version of the cloud than it was written for
20:25:06 <zaneb> it sucks that you ever have to wait for features
20:25:18 <mordred> indeed
20:25:23 <zaneb> but we do also do releases for a reason
20:25:42 <stevebaker> other programs only expose themselves to users as the REST APIs, which really shouldn't change that much
20:25:44 <zaneb> which is that it's really hard to be not broken 100% of the time
20:25:49 <mordred> ++
20:26:12 <stevebaker> and feature freeze is a mess of big features which have never worked together before
20:26:39 <stevebaker> (sometimes. juno has been pretty smooth)
20:26:56 <david-lyle> mordred: why not just pull master
20:27:27 <zaneb> also, releases are organised around the Summit, &c.
20:27:38 <zaneb> it's moderately convenient for us as developers
20:27:39 <david-lyle> that's as rolling as you get
20:27:48 <david-lyle> :)
20:28:30 <stevebaker> yes, basically our gating should be good enough to ensure master can always be consumed. If it isn't then we need to improve functional and integration testing
20:30:26 <stevebaker> mordred, as for multi-cloud, it will be implemented as nested stacks. So a sub-template will be launched with different credentials to a different cloud. There will always be one default keystone that gets authenticated against first though
20:30:32 <mordred> david-lyle: that would work - it's just to make sure that master of horizon/heat could run against $releases
20:30:39 <mordred> stevebaker: kk
20:31:30 <zaneb> stevebaker: not if your master Heat is a standalone one, that one need not auth with keystone at all in theory except to create the child stacks
20:32:27 <stevebaker> zaneb, we could have some noop middleware, yes
20:32:51 * asalkeld rubs eyes- sorry , a bit early here
20:33:33 <zaneb> asalkeld: we're discussing mordred's thoughts on release cadence
20:33:41 <asalkeld> o, ok
20:34:24 <asalkeld> not a bad idea, nice in some ways
20:34:49 <zaneb> conclusion: maybe, maybe not, need to get standalone mode into properly working shape first in any event
20:34:58 <mordred> ++
20:35:06 <stevebaker> zaneb, a while ago I was close to having multi-cloud standalone working, so that heat.conf had a list of allowed keystone endpoints, and heatclient specified which one to use. I still think that has some merit but I need more buy-in - otherwise we may as well deprecate it
20:35:06 <mordred> not that I normally list this as a reason to care about things ...
20:35:20 <mordred> but we do have a very large internal customer at HP running standalone heat in production
20:35:29 <mordred> so, fwiw, there's at least one real world person who cares
20:35:43 <zaneb> mordred: I'm curious if they're using it with Keystone?
20:35:55 <asalkeld> we might need to be better at autodiscovering services and features
20:35:58 <mordred> not any more so than an unpriviledged user has
20:36:04 <stevebaker> mordred, good to know. I'm edging towards having a gate job that exercises standalone
20:36:11 <zaneb> because Keystone has a lot of limitations that prevent standalone mode from being really something we could recommend at the moment
20:36:26 <mordred> that woudl be great - I could probably find someone to help
20:36:44 <asalkeld> it would be nice to have user based services
20:36:55 <mordred> asalkeld: ++
20:36:59 <asalkeld> then a user could add the heat service
20:37:06 <mordred> we were just discussing that the other day
20:37:08 <mordred> with morganfainberg
20:37:11 <mordred> (I think)
20:37:15 <mordred> but I'd LOVE to be able to do that
20:37:23 <zaneb> mordred: it's also probably only secure because they're running it inside your firewall
20:37:30 <mordred> zaneb: they are not
20:37:36 <mordred> zaneb: this is against hp public cloud
20:37:57 <asalkeld> also with a paas, you could be super flexible in defining services
20:37:59 <zaneb> then they're opening up ports for instances to talk back to Heat? or perhaps they're just not using those features
20:38:04 <zaneb> mordred: ^
20:38:12 <mordred> they are not using those features
20:38:24 <mordred> it's all for creating 50-node single-purpose stacks and deleting them, AIUI
20:38:29 <stevebaker> zaneb, swift TempURL makes all that unnecessary
20:38:38 <zaneb> mordred: ah, ok. but those are pretty important features for most users
20:38:40 <zaneb> in any event, stuff we have planned will fix that
20:38:45 <zaneb> like stevebaker said
20:38:46 <mordred> zaneb: totally
20:38:46 <ryansb> Using zaqar would also make it unnecessary. ;)
20:39:03 <stevebaker> ryansb, yes!
20:39:14 <zaneb> putting communication with the instances through Swift or Zaqar or both will solve the problem
20:39:20 <stevebaker> which may end up being backed by swift ;)
20:39:37 <zaneb> mordred: can we have Zaqar graduated now please? ;)
20:39:37 * flaper87 sneaks in, reads, smiles and steps away
20:39:45 <asalkeld> more service dependancy is going to make standalone tricky
20:39:56 <ryansb> yeah...kinda defeats standalone mode's purpose
20:40:07 <ryansb> "It's standalone...as long as it's with these other things"
20:40:12 <stevebaker> asalkeld, it will always be optional. the template author chooses their transports
20:40:30 <asalkeld> sure, ssh based waitcond. anyone?
20:40:50 <asalkeld> more options, more testing
20:41:12 <zaneb> asalkeld: that has its own issues, with isolated networks
20:41:33 <stevebaker> and heat storing private keys... just no.
20:41:53 <asalkeld> stevebaker, this is in standalone mode
20:42:01 <asalkeld> so the sure should have the key
20:42:14 <asalkeld> so the user should have the key
20:42:28 <zaneb> stevebaker: as much as I don't like it storing passwords in standalone mode, storing keys is not so much worse
20:42:35 <zaneb> but only in standalone mode
20:42:44 <zaneb> and there should be big warning signs
20:43:21 <zaneb> remind me why Keystone isn't just kerberos again?
20:43:24 <stevebaker> asalkeld, sure, its still more for the user to set up than TempURL, since they need to make sure there is incoming ssh security group (which generally they already will)
20:43:29 <asalkeld> if the user is running heat-engine it could just look in .ssh/
20:43:39 <stevebaker> zaneb, I think they're working on it ;)
20:43:51 <zaneb> oh, excellent
20:44:05 <asalkeld> (anyways, semi crazy idea - the ssh thing)
20:44:31 <stevebaker> so I think we've nicely covered mordred #8, #9, #10
20:45:42 <asalkeld> so the big thing with standalone is "what can we depend on for services that we really need"
20:45:43 <zaneb> I think we already have a process for #7 via /contrib
20:46:12 <zaneb> asalkeld: only things required for Wordpress, apparently
20:46:14 <asalkeld> zaneb, the one that mordred is super happy about;)
20:46:34 <zaneb> so I hear ;)
20:46:50 <asalkeld> ok
20:46:54 <stevebaker> yep, it would be nice if there was some process for big-tent projects to require writing heat plugins, just to validate that their REST API isn't rubbish. mordred?
20:47:18 <asalkeld> they have the plugin in their tree
20:47:25 <zaneb> asalkeld: I posted a very long mail to the list disagreeing with that concept today
20:47:32 <asalkeld> lol
20:47:53 <zaneb> (the Wordpress-only concept, that is)
20:48:10 <ryansb> zaneb: don't you know? People only ever use their clouds to host wordpress
20:48:19 <ryansb> Get with the times.
20:48:29 <asalkeld> basically we shouldn't need plugins, if people had jsonschema
20:48:42 <asalkeld> it could be automagical
20:48:53 <asalkeld> for the basic cases
20:49:07 <zaneb> I think convergence may well make the plugins simpler
20:49:19 <stevebaker> I need to go. If you're looking for something to do our rc1 bugs need to go to zero https://launchpad.net/heat/+milestone/juno-rc1
20:49:31 <zaneb> there are still some terrible APIs out there though :(
20:49:35 <zaneb> I won't name names
20:49:43 <asalkeld> yeah
20:49:52 <zaneb> again
20:50:33 <asalkeld> https://review.openstack.org/#/c/122627/
20:50:47 <asalkeld> tool to get you reviews based on bugs
20:51:07 <zaneb> nifty
20:51:27 <zaneb> I guess this means we have come to the end of this topic :)
20:51:45 <zaneb> #topic Deprecating CWLiteAlarms
20:51:51 <zaneb> pas-ha: go
20:52:02 <pas-ha> given asalkeld's https://review.openstack.org/#/c/123039/ that tries to solve orphan stackwatch tasks I'd like to hear if there is indeed a plan to deprecate heat-native autoscaling.
20:52:10 <pas-ha> I know some and suspect there are more clouds that use Nova network and do not deploy ceilometer. For them the only openstack-y loadbalancing solution is our's (probably crappy) AWS LoadBalancer, that depends on.. CWLiteAlarm.
20:52:44 <zaneb> I don't know if we have a plan to deprecate, but +1 if we do
20:52:52 <pas-ha> So, are we going to prohibit such use-case?
20:53:01 <asalkeld> pas-ha, aws lb doesn't depend on cwlite does it?
20:53:14 <asalkeld> afaik it depends on cw alarms
20:53:26 <asalkeld> btw: https://review.openstack.org/#/dashboard/?foreach=status%3Aopen+NOT+owner%3Aself&title=Priortized+Bug+Fix+Dashboard&&Milestone+juno-rc1+Importance+High=change%3A122592+OR+change%3A121693+OR+change%3A123417+OR+change%3A122568&Milestone+juno-rc1+Importance+Medium=change%3A90109+OR+change%3A84664+OR+change%3A110713+OR+change%3A123291+OR+change%3A122274+OR+change%3A123039+OR+change%3A123023&Milestone+juno-rc1+Impo
20:53:27 <asalkeld> rtance+Low=change%3A117076
20:53:37 <stevebaker> lets push metrics to swift TempURLs!
20:53:44 * stevebaker is really gone now
20:53:58 <zaneb> our AWS LB is indeed terrible, for the record
20:54:26 <asalkeld> we should at some point take cwlite out of the tree
20:54:34 <asalkeld> and make it an api
20:54:36 <pas-ha> yes, indeed, was confused by all our remappings
20:55:14 <asalkeld> that ceilometer and the new monitoring thing can implement
20:55:40 <pas-ha> +
20:55:41 <asalkeld> why do all the new project have names i can't spell or pronounce
20:56:07 <asalkeld> monasca and zaqar
20:56:11 <zaneb> asalkeld: I've seen your spelling and that's not a high bar ;)
20:56:19 <asalkeld> :)
20:56:41 <zaneb> but seriously, all English words are taken
20:56:55 <zaneb> usually multiple times over
20:56:58 <ryansb> but seriously, we ran out of names.
20:57:22 <asalkeld> ryansb, tell me you had nothing to do with zaqar
20:57:43 <asalkeld> pas-ha, are you ok with the cwlite deprecation?
20:58:02 <ryansb> Nothing at all. I do take great pleasure in pronouncing zaqar in a thick french accent though.
20:58:20 <pas-ha> still looking and parsing those mappings of one to another..
20:58:26 <asalkeld> ok
20:58:49 <asalkeld> pas-ha, i am a bit worried real users are consuming cwlite
20:58:59 <asalkeld> it's a toy
20:59:34 <asalkeld> we probably need to have monasca integration
20:59:56 <pas-ha> I will ask my colleagues on real life deployments
20:59:58 <asalkeld> we are out of time?
21:00:19 <pas-ha> IMO no critical issues, no?
21:00:21 <zaneb> wow, that went quick
21:00:26 <zaneb> #endmeeting