20:00:26 <stevebaker> #startmeeting heat
20:00:27 <openstack> Meeting started Wed May  6 20:00:26 2015 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:29 <ryansb> \o
20:00:30 <openstack> The meeting name has been set to 'heat'
20:00:47 <skraynev_> \o/
20:00:53 <stevebaker> #topic rollcall
20:00:57 <randallburt> o/
20:01:15 <stevebaker> welcome to the first liberty meeting :)
20:01:25 <jruano> hi
20:01:37 <tspatzier> hi
20:01:51 <stevebaker> zaneb: ping
20:02:01 <zaneb> o/
20:02:03 <zaneb> thanks
20:02:06 <ryansb> \o
20:02:41 <stevebaker> #topic Adding items to the agenda
20:02:45 <skraynev_> stevebaker: first it's cool
20:02:46 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:03:33 <stevebaker> anything else to add?
20:04:03 <stevebaker> #topic Discussing design summit sessions
20:04:14 <stevebaker> #link https://etherpad.openstack.org/p/liberty-heat-sessions
20:04:36 <stevebaker> so we have 5 fishbowl slots and 10 working slots
20:05:46 <stevebaker> I've assigned fishbowls for things that are more outward facing, or ones which might attract a crowd. working rooms only fit around 28, so if you can think of more boring titles for those then that might help
20:06:35 <stevebaker> could we quickly go through each one and make sure there is a session's worth of things to cover? and look for potential gaps?
20:07:05 <stevebaker> I probably need to push *something* to the schedule today or tomorrow, but things can change a bug
20:07:08 <stevebaker> a bit
20:08:13 <stevebaker> 1. Heat client usability
20:08:59 <skraynev_> stevebaker: I agree with this one. it was really useful on previous summit
20:09:11 <jdandrea> \o (late)
20:09:31 <stevebaker> I was thinking spend the first half talking about the experience of managing complicated stacks with our current client tools, and maybe the second half talking about having an in-tree openstackclient plugin
20:10:02 <stevebaker> ryansb: are you keen on running that part? I can do the first
20:10:09 <ryansb> yeah, I'd really like to hear from ops what they'd like out of clients
20:10:14 <ryansb> well, ops/users
20:10:45 <ryansb> stevebaker: sure, not sure the in-tree osc plugin will take up half a session, but I'm sure we can find something useful to chat about
20:11:11 <stevebaker> cool
20:11:15 <skraynev_> stevebaker: can we also discuss here what we want to see in Horizon ?
20:11:34 <ryansb> I'd really like to just get in the OSC tree proper
20:11:53 <stevebaker> skraynev_: yes, good idea
20:12:49 <stevebaker> 18. Heat template format improvements
20:14:04 <stevebaker> I thought we could take a look at the Paris session and see what was implemented.
20:14:28 <skraynev_> stevebaker: yeah, also how about some conditions staff ?
20:14:59 <randallburt> more imperative syntax in our declarative templates? we're going there?
20:15:28 <stevebaker> Then we probably need to discuss possible solutions to a general intrinsic function to transform anything->anything, maybe spend some time evaluating YAQL
20:16:22 * zaneb groans
20:16:36 <stevebaker> lol
20:18:26 <stevebaker> we could keep adding piecemeal intrinsic functions, but some analysis of the gaps would be useful
20:18:51 <stevebaker> 3. REST API design and roadmap
20:19:09 <randallburt> that sound pretty awful. espectially considering external methods of pre-processing template files
20:19:32 <stevebaker> we could discus the potential for v2, take a look at how nova does microversions
20:19:53 <randallburt> I think the question should be "why *not* v2" at this point.
20:19:57 <stevebaker> randallburt: if we do it right we might avoid becoming PHP
20:20:33 <randallburt> stevebaker:  we could avoid that possibility all together by just avoiding putting control structures in our template language
20:20:38 <zaneb> randallburt: possible reason: v2 will be better when we know what convergence is and isn't capable of
20:21:04 <randallburt> zaneb:  fair enough. though I think shardy had a pretty compelling list of stuff already
20:21:16 <stevebaker> randallburt: because the experience of nova and keystone suggests transitioning to new API version is super painful
20:21:30 <zaneb> it was an extensive list of mostly minor warts
20:22:02 <randallburt> stevebaker, zaneb good points all, I'm just saying that's something we should discuss in the session
20:22:08 <randallburt> otherwise, why have the session
20:22:18 <stevebaker> anyway, sounds like a perfect fisbowl topic, 40 minutes of bikeshed arguing :D
20:22:44 <randallburt> stevebaker:  fairly normal summit session then.
20:22:55 <stevebaker> 5. Orchestrating containers with Heat
20:23:52 <stevebaker> I'm a little worried this would just be a presentation of all the container things that are happening, its all around the periphery(sp?) of heat
20:23:53 <randallburt> I know there are other parts to the (swconfig managing containers etc), but does magnum make this largely moot?
20:24:24 <stevebaker> randallburt: sure, if you have magnum deployed
20:24:54 <zaneb> I'd say not necessarily
20:25:08 <zaneb> sw deployments in containers are still relevant imo
20:25:14 <stevebaker> if there was a fishbowl session to be dropped this might be it.
20:25:20 <randallburt> stevebaker:  I mean managing containers isn't in our wheelhouse really. Here's an openstack service for containers that heat can support or you can use sw config.
20:25:22 <asalkeld> o/
20:25:28 <randallburt> stevebaker:  agreed
20:25:53 <stevebaker> lets see if there is a working session to swap it with
20:26:05 <stevebaker> 13. Senlin Autoscaling Project - Deep Dive
20:26:24 <stevebaker> I've put Qiming in the fishbowl for maximum exposure ;)
20:27:04 <stevebaker> I'm hoping for a reasonably technical overview of Senlin, and some discussion on how it would fit with Heat
20:27:12 <ryansb> +1
20:27:24 <randallburt> yep
20:27:32 <skraynev_> stevebaker: is it separate autoscaling project or something else?
20:27:43 <asalkeld> skraynev_: yip
20:27:45 <stevebaker> skraynev_: its a separate autoscaling service
20:27:47 <zaneb> +1
20:27:55 <zaneb> I wish I'd had more time to read about this
20:27:59 <stevebaker> right, Working Sessions
20:28:00 <skraynev_> got it. thx.
20:28:07 <zaneb> so I definitely want to hear about it instead :)
20:28:13 <randallburt> if that's true, I won't be sad if we get out of the autoscaling business
20:28:22 <stevebaker> 2. Finishing off Convergence phase 1
20:28:31 <stevebaker> 12. Convergence phase 2 planning
20:28:50 <stevebaker> 2 convergence sessions, and maybe some more for our meetup morning on Friday
20:29:07 <asalkeld> +1
20:29:12 <skraynev_> +1
20:29:18 <randallburt> +1
20:29:28 <jdandrea> +10
20:29:35 <randallburt> thats too many!
20:29:37 <jdandrea> ;)
20:29:39 <jdandrea> Ok, ok
20:29:39 <jdandrea> +1
20:29:43 <randallburt> whew.
20:29:45 <stevebaker> I'm not sure that topic name is boring enough
20:29:50 <stevebaker> we'll see
20:30:01 <skraynev_> stevebaker: :)
20:30:02 <stevebaker> 4. Functional and integration testing, identify gaps and suggest improvements
20:30:19 <stevebaker> that one is definitely boring enough ;)
20:30:29 <asalkeld> but needed
20:30:30 <zaneb> stevebaker: it sounds pretty mind-numbing, but maybe that's just me ;)
20:30:33 * jdandrea chuckles
20:30:43 <stevebaker> very needed
20:30:53 * jdandrea agreed
20:31:08 <stevebaker> 7. Better support for lifecycle operations on heat stacks (upgrades etc)
20:31:23 <randallburt> wait, just change the names. lets talk about the good stuff during the testing slot!
20:31:30 <jdandrea> haha
20:31:35 <stevebaker> randallburt: evil!
20:32:09 <randallburt> alternatively, add "functional testing imact of …" in front of everything
20:32:28 <jdandrea> ;)
20:32:44 <stevebaker> How would people feel about 7. being fairly tripleo focused? Overcloud is a complex stack which has definite lifecycle needs
20:32:53 <randallburt> stevebaker:  so back on topic, this one is for lifecycle callbacks, vendor callbacks, debugging or all of the above?
20:32:59 <stevebaker> it would be a good example on heat in the real world
20:33:27 <asalkeld> i don't mind
20:33:40 <tspatzier> could that be a candidate for the fishbowl if the containers slot is kicked out?
20:33:43 <randallburt> agreed, but might need to be specific about that to keep from drifting into the other stuff I mentioned
20:33:59 <stevebaker> randallburt: more like running workflows in a running stack (via stack updates, or some other methods)
20:34:11 <randallburt> tspatzier:  could be hard to keep on this specific meaning of "callbacks" and heat, but don't see why not
20:34:38 <stevebaker> OK, if folk don't mind I'll add a tripleo tag to the session, so we get some of them turning up
20:34:42 <randallburt> cool. again, I think it will be harder to keep this one on track the larger the audience tbh
20:35:10 <stevebaker> 17. Push to port to python 3
20:35:11 <tspatzier> randallburt: agreed. but depends on who much focused this is. the title sounds broad
20:35:25 <stevebaker> tspatzier: I'll make the title a bit more specific
20:35:42 <asalkeld> stevebaker: i'd rather focus on the migrate/almbic
20:35:46 <randallburt> tspatzier, stevebaker +1 to specifics int he title
20:35:52 <stevebaker> sounds like the time could be now to port to python 3
20:36:15 <tspatzier> stevebaker, randallburt - or make it something like "coding style guidelines" to keep the group small
20:36:15 * asalkeld not convinced there is much to talk about
20:36:32 <randallburt> asalkeld:  agreed. porting to python 3 doesn't sound controvercial or particularly tricky enough for a design discussion. Almbic and migrations do
20:36:43 <stevebaker> tspatzier: "pep8 and you"
20:36:46 <asalkeld> exactly
20:36:46 <jdandrea> lol
20:36:48 <tspatzier> lol
20:36:49 <randallburt> or might rather. not terribly familiar tbh
20:37:15 <asalkeld> stevebaker: s/python3/alembic ?
20:37:43 <stevebaker> asalkeld: how about a session on technologies to transition to. alembic, pecan, wsgi-on-apache
20:38:16 <asalkeld> well : everyone wants python3, we pretty much have to use pecan
20:38:17 <randallburt> stevebaker:  would we realistically tackle api technologies without a plan to start on v2?
20:38:29 <randallburt> oh, well there is that then.
20:38:29 <ryansb> stevebaker: "Technology migration planning and you: the session"
20:38:39 <randallburt> lol +1 ryansb
20:38:42 <asalkeld> but using migrate and alemibc together is a bit tricky
20:38:50 <asalkeld> not nova still are not using it
20:38:53 <asalkeld> note
20:39:03 <stevebaker> "technical debt hygene"
20:39:08 <jdandrea> heh
20:39:11 <randallburt> yeah, well nova is slow to migrate aren't they?
20:39:28 <randallburt> in general I mean
20:39:28 <asalkeld> randallburt: there has been a lot of effort to try
20:39:33 <randallburt> gotcha
20:39:52 <stevebaker> ok, i'll make the session less python 3, more alembic, with potential for other topics
20:40:01 <randallburt> sounds good.
20:40:05 <stevebaker> 15. Future of Versioned objects in heat
20:40:08 <randallburt> make it sound painful to attend though
20:40:28 <stevebaker> back in 30 seconds
20:40:29 <ryansb> stevebaker: there's an oslo session on versionedobjects
20:40:43 <ryansb> maybe schedule close to that one?
20:41:02 <randallburt> ryansb:  or make sure we don't overlap for sure
20:41:59 <stevebaker> back
20:42:44 <asalkeld> stevebaker: how long is a working session?
20:43:06 <stevebaker> I'd like to split this into 2 distinct topics, versioned objects for live db upgrades, and versioned objects for RPC (because it is not clear to me yet that the latter is needed)
20:43:14 <stevebaker> asalkeld: 40 minutes I think
20:44:10 <stevebaker> 19. Autoscaling improvements
20:44:10 <asalkeld> yes it needed;) /me gets ready for an arguement
20:44:42 <asalkeld> +1
20:45:16 <stevebaker> neither 16. nor 8. made much sense to me, but I'm sure we could fill a session with scaling/cluster talk. It would need a driver to set the agenda though. any takers?
20:45:21 <randallburt> is the format of this discussion dependent on the outcome of the Senlin discussion?
20:45:39 <randallburt> the autoscaling one I mean
20:45:41 <stevebaker> randallburt: potentially
20:46:03 <asalkeld> note, if pushed 6 and 10 *could* be merged
20:46:16 <asalkeld> they are both about contrib resources
20:46:26 <stevebaker> asalkeld: +1, but you're jumping ahead
20:46:41 <randallburt> well relevant to, not just about
20:47:14 <randallburt> I think the contrib discussion could dominate depending on attendance
20:47:16 <asalkeld> stevebaker: so 8 is so you can have a unique config for a particual instance of a scaling group
20:47:32 <asalkeld> that has been asked for many times
20:47:50 <asalkeld> now someone is actually stepped up to do the work
20:47:55 <stevebaker> asalkeld: then it talks about cluster membership, which can already be done with OS::Heat::SoftwareDeployments
20:47:57 <randallburt> asalkeld:  I still don't get why that's not a separate resource outside the group.
20:48:27 <stevebaker> any volunteer to be the driver for this?
20:48:30 <asalkeld> ok well we need to talk to the author
20:49:00 <stevebaker> pas-ha I guess
20:49:04 <asalkeld> yeah
20:49:22 <stevebaker> 9. Our deprecation process:
20:49:44 <stevebaker> skraynev_: could you put together a list of things which we have currently deprecated so we can decide their fate?
20:49:57 <skraynev_> stevebaker: sure
20:49:58 <randallburt> so sinister
20:50:06 <skraynev_> will add tomorrow
20:50:43 <stevebaker> 6. Heat contrib resources - deciding their fate
20:50:51 <stevebaker> 10. Conditional registering of resources
20:52:03 <randallburt> I think we should decide on 10 before we talk about 6.
20:52:24 <asalkeld> randallburt: they are seperate
20:52:48 <asalkeld> (one is more about auth)
20:53:06 <stevebaker> after the recent pbr release, I'd actually like contrib to go away. So I'd like to discuss each resource to figure out where it ends up. Conditional registering of resources sounds fine but it seems like more of a documentation issue
20:53:56 <miguelgrinberg> +1 (hi, sorry i'm late)
20:54:18 <miguelgrinberg> having these sub-packages is a headache
20:54:23 <randallburt> I don't see the big deal tbh. its worked for this long and pbr has caused other problems unrelated to contrib
20:54:30 <randallburt> miguelgrinberg:  in what way?
20:54:41 <miguelgrinberg> cannot use pip to install sub-packages that don't have a version
20:54:59 <randallburt> miguelgrinberg:  was that fixed or just hacked around?
20:55:01 <stevebaker> randallburt: they can't be pip-installed
20:55:14 <randallburt> and that's a "Big Deal"?
20:55:14 <miguelgrinberg> we had to hack around it in our ansible deployment
20:55:15 <stevebaker> randallburt: or sdist packaged
20:55:24 <randallburt> stevebaker:  ah, that's a bigger deal then
20:55:50 <stevebaker> asalkeld, miguelgrinberg: do you mind if I am the driver for that session?
20:56:00 <miguelgrinberg> stevebaker: not at all
20:56:01 <asalkeld> yes
20:56:05 <asalkeld> :-)
20:56:06 <randallburt> in our deployment our ci/cd and chef handles all of that and its painless tbh
20:57:05 <stevebaker> randallburt: maybe we should consider rax resources going to a stackforge project which co-gates on unit tests
20:57:36 <randallburt> stevebaker:  if the problem was only the rax resources, I'd agree. I'd rather have a more comprehensive policy though
20:57:53 <asalkeld> randallburt: +1
20:57:55 <stevebaker> OK, I'll merge 10 and 6, that brings us down to 10 working sessions
20:58:20 <asalkeld> not in favor of random clean up that results in a hassle for users
20:58:23 <stevebaker> randallburt: yes, that is why I'd like to go through each resource. I think the only sticking points will be rax and dockerinc
20:58:53 <randallburt> k, lgtm
20:58:57 <stevebaker> 2 minutes
20:59:07 <stevebaker> 11. User messaging with Zaqar?
20:59:19 <asalkeld> user messaging
20:59:20 <stevebaker> I added "with Zaqar"
20:59:22 <skraynev_> +1 if we also discuss alternatives
20:59:26 <randallburt> I do like this one, but wonder if its dead horses at this point.
20:59:26 <stevebaker> and the question mark ;)
20:59:34 <asalkeld> remove the zaqar i think
20:59:34 <ryansb> +1
20:59:56 <randallburt> are those alternatives in the openstack umbrella?
20:59:59 <asalkeld> it's is going to get a cross project session
21:00:21 <asalkeld> randallburt: not everything needs to be
21:00:36 <stevebaker> asalkeld: should we ditch it then and leave 10 and 6 unmerged?
21:00:38 <ryansb> randallburt: tbh if something is a good tool, no reason to knock it with the NIH stick
21:00:57 <randallburt> ryansb:  not true. that's pretty much the openstack motto.
21:00:57 <skraynev_> randallburt: I just want to depends on Zaqar. if it will e optional - I am ok
21:01:09 <stevebaker> times up, should we move to #heat?
21:01:13 <asalkeld> stevebaker: you could
21:01:18 <ryansb> lets
21:01:20 <randallburt> exactly. it should be pluggable but have a default implementation that's openstack-only
21:01:23 <stevebaker> #endmeeting