20:00:13 <skraynev_> #startmeeting heat
20:00:14 <openstack> Meeting started Wed Oct 21 20:00:13 2015 UTC and is due to finish in 60 minutes.  The chair is skraynev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:17 <openstack> The meeting name has been set to 'heat'
20:00:18 <jdob> o/
20:00:32 <skraynev_> #topic rollcall
20:00:41 <jasond> o/
20:00:43 <shardy> o/
20:00:44 <jdob> o/
20:00:45 <tspatzier> hi
20:00:46 <Drago> o/
20:00:53 <pas-ha> o/
20:00:55 <ryansb> o/
20:01:01 <zaneb> o/
20:01:17 <dgonzalez> o/
20:01:20 <jonesbr1> o/
20:01:52 <stevebaker> \o
20:02:03 <rpothier> o/
20:02:11 <skraynev_> #topic Adding items to agenda
20:02:19 <skraynev_> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-10-21_2000_UTC.29
20:02:30 <skraynev_> we have a really short agenda for now
20:02:59 <stevebaker> short meetings are allowed, especially before summit
20:03:12 <skraynev_> ok ;)
20:03:14 <markvan> o/
20:03:29 <jonesbr1> skraynev_: can we revisit the namespace decision for lbaasv2 resources?
20:03:45 <jdandrea> \o
20:04:02 <skraynev_> jonesbr1: sure, we may discuss it on Open discussion part today
20:04:12 <skraynev_> #topic Canceling meeting for the next 2 weeks
20:04:29 <zaneb> why 2 weeks?
20:04:36 <shardy> Yeah, same question from me
20:04:43 <skraynev_> 1 summit ;)
20:04:54 <skraynev_> second, because I will be in trip, so...
20:05:07 <shardy> skraynev_: someone else can chair the meeting in your absense
20:05:13 <skraynev_> anybody can help me and be in chair ?
20:05:30 <shardy> skraynev_: I'm happy to do it
20:06:16 <skraynev_> shardy: ok. thx for volunteering ;)
20:06:40 <skraynev_> #info we will skip only meeting during summit week
20:07:23 <skraynev_> #action shardy will be in chair for week after the summit.
20:07:46 <skraynev_> that's why I wanted to discuss this topic ;)
20:08:19 <skraynev_> #Open discussion
20:08:32 <skraynev_> #topic Open discussion
20:09:09 <skraynev_> jonesbr1: your turn
20:09:40 <skraynev_> what did  you want to discuss about lbaasv2 ?
20:09:50 <jonesbr1> What namespace should the new LBaaS v2 resources live in? The current patch sets have OS::LBaaS::* but we feel they belong in the Neutron namespace
20:10:19 <jonesbr1> something like OS::Neutron::LBaaS_*
20:10:39 <jonesbr1> or OS::Neutron::*_v2
20:10:43 <zaneb> LBaaS isn't a project name, so using that as the namespace would be inconsistent with all the other resource types
20:10:43 <stevebaker> jonesbr1: to me this depends entirely on what we want the user experience to be for existing stacks which are transitioning from old to new lbaas
20:11:08 <zaneb> so +1 for Neutron, unless LBaaS actually falls under some other project now?
20:11:24 <stevebaker> zaneb: but still separate resources from the v1 ones?
20:11:39 <jonesbr1> LBaaS is still under Neutron, but separate resources from the v1 ones
20:11:44 <zaneb> stevebaker: no comment
20:12:16 <skraynev_> LBAAS - it's only for splitting between v2 and v1 resources. Neutron namespace is more useful, because it uses neutron client
20:12:57 <skraynev_> zaneb: jonesbr1: I like the idea with suffix _v2 and Neutron namespace
20:13:22 <shardy> Versioning in resource types is evil :(
20:13:26 <skraynev_> I tend to say, that it;s more clear then LBAAS prefix or LBAAS namespace
20:13:45 <stevebaker> the v1 resources are mixed into the base OS::Neutron::* namespace. How about we put v2 in OS::Neutron::LBaaS::* since it is its own project now
20:14:25 <shardy> How does neutronclient handle abstracting the two incompatible versions?
20:14:42 <neelashah1> stevebaker +1 given the trend of neutron to have plugins, would there be more such cases so the one more nesting would work across the board
20:14:46 <skraynev_> shardy: can we do such exception for it? ah no... bad example for other projects to start use such suffixes....
20:14:52 <markvan> neutron has a LB_* and a LBAAS_* spaces, o abit ugly
20:15:15 <shardy> skraynev_: It's bad practice - what happens when there's an otherwise compatible version bump to a v3 neutron API?
20:15:20 * jdandrea is not fond of _v2 or _2 or any kind of suffix
20:15:30 <shardy> the whole point of heat is to provide an abstraction above those sorts of things
20:15:56 <stevebaker> shardy: hmm, to a point
20:16:14 <skraynev_> shardy: yeahhh.. it's true
20:16:24 <shardy> obviously we're being bitten by the lack of backwards compatibility in this case, but if we can avoid it I'd rather we didn't start encoding versions in resource types
20:16:39 <randallburt> shardy:  +1
20:16:44 <jdandrea> +1
20:16:50 <shardy> If everyone else thinks it's Ok then fair enough, but it just seems...wrong to me :)
20:17:00 <randallburt> also, neutron plugin versions are tied to the neutron api verions?
20:17:01 <jdandrea> I don't like it. Versioning doesn't belong in the name.
20:17:12 <markvan> I think the OS::Neutron::LBaaS::* is a reasonable choice here.
20:17:15 <stevebaker> shardy: +1, so how about OS::Neutron::LBaaS::* ?
20:17:24 <shardy> stevebaker: +1 that's fine IMO
20:17:28 <pas-ha> +1
20:17:31 <jdandrea> Is it a matter of checking for existence of things? Of modules/classes/methods?
20:17:35 <skraynev_> ok. what do you think about suffix or middle namespace ?
20:17:43 <skraynev_> shardy: ^
20:17:52 <zaneb> stevebaker: +1
20:17:58 <prazumovsky> hi, sorry, I had problems with internet
20:17:58 <shardy> skraynev_: OS::Neutron::LBaaS::Foo is fine IMO
20:18:12 <stevebaker> and this may be the first of many OS::Neutron::*::* resources from neutron's stadium inside the big tent ;)
20:18:12 <pas-ha> this actually sounds ok, as lbaas is now a kind of out-of-neutron thing/plugin
20:18:41 <prazumovsky> +1
20:18:42 <pas-ha> moar plugins awaits :)
20:18:45 <neelashah1> +1 there will be more of these from neutron's perspective
20:18:46 <skraynev_> shardy: I just afraid, that it may became a common practice to use middle namespace for some extensions. is it ok ?
20:19:17 <jonesbr1> stevebaker: +1, as a follow up, where should the custom constraints for these new resources should live? neutron.lbaas.foo
20:19:19 <skraynev_> some kind OS::<service name>::<Extension name>::<resource>
20:19:30 <pas-ha> theese are basically just for UX
20:19:36 <shardy> skraynev_: Personally I think it's OK, provided the namespaces are descriptive and don't expose stuff like underlying API versions
20:19:39 <stevebaker> jonesbr1: that sounds fine
20:20:02 <jdandrea> Better!
20:20:04 <pas-ha> jonesbr1: +1
20:20:12 <jonesbr1> stevebaker: thanks that looks good to me as well
20:20:25 <markvan> shardy: +!
20:20:37 <zaneb> skraynev_: if the architecture of Neutron is a core thing with a bunch of plugins then it makes sense to have our namespaces follow the same structure
20:20:57 <skraynev_> stevebaker: I'd like to avoid another file for it. we have module per client mapping in heat/engine/clients/os
20:21:45 <skraynev_> and if we will add neutron.lbaas - it sounds like a separate lbaas client...
20:22:03 <stevebaker> skraynev_: we can do whatever is most maintainable, it can be broken out if the implementation gets too big
20:22:36 <stevebaker> skraynev_: lets keep namespace of constraints separate from source file structure
20:23:33 <skraynev_> stevebaker: can we something like: subdirectory clients/os/neutron/ with neutron.py and lbaas.py ?
20:24:01 <stevebaker> skraynev_: that sounds reasonable
20:25:00 <skraynev_> #info suggest to use middle namespace for resources from extensions, e.g. OS::Neutron::LBaaS::LB_resource
20:25:31 <skraynev_> stevebaker: ok with new directory it looks ok for me
20:25:38 <skraynev_> stevebaker : thx
20:25:53 <skraynev_> jdandrea: ^
20:26:15 <jdandrea> skraynev_: Sounds good
20:27:24 <skraynev_> zaneb: I agree with this idea, just start thinking about renaming all resources, which are based on extensions... (unfortunately it's blocked by backward compatibility)
20:27:44 <skraynev_> I mean a lot of renaming and deprecation ;)
20:27:56 <jonesbr1> skraynev_: Thanks for the clarification, we will work these suggestions into the new resources
20:27:57 <zaneb> how many do we actually have?
20:28:53 <skraynev_> zaneb: I remember Rabi's patch for Neutron resources... and it was about 3 or 2 groups with 3 or 2 resources
20:29:05 <skraynev_> not sure about other services
20:29:16 <skraynev_> its not critical
20:29:23 <skraynev_> it's
20:30:24 <skraynev_> jonesbr1: ok
20:31:01 <skraynev_> anything else for discussion ? or we may finish earlier ;)
20:31:44 <jdandrea> Since versions were mentioned, *could* there ever a situation where we need something like version: in a resource (alongside type and properties)?
20:31:59 <jdandrea> Or does it not even belong *there*?
20:32:28 <skraynev_> jdandrea: not sure about type
20:32:29 <stevebaker> jdandrea: there could always be a version property added to the resource
20:32:46 <jdandrea> OK. But there's no pressing need for that now, AFAIK.
20:32:59 <zaneb> jdandrea: if you get to that point you've failed. that said, API design in OpenStack fails a lot :/
20:33:11 <jdandrea> zaneb: Heh, I hear you. *sigh*
20:33:16 <jdandrea> Ok, good.
20:33:21 * jdandrea yields the floor
20:33:41 <zaneb> I agree with stevebaker that it would be better as a property in the cases where we're forced to
20:33:41 <skraynev_> :)
20:33:55 <jdandrea> *nodnod*
20:34:33 <skraynev_> because we have a pretty good deprecation mechanism for resource properties ;)
20:34:43 <jdandrea> This is true.
20:34:57 <prazumovsky> +1:)
20:35:13 <shardy> well, we don't really, because there's no user-visible deprecation warning except the docs ;)
20:35:25 <shardy> There is a validation spec up atm which may help with that
20:35:57 <jdandrea> Ahh, the deprecation is noted in the log.
20:36:01 <skraynev_> shardy: your truth, but we already has a spec for it.
20:36:02 <jdandrea> Right?
20:36:05 <ryansb> exactly
20:36:07 <jdandrea> ok
20:36:22 <shardy> jdandrea: yeah, we need a way to make user-visible noise, not just logs
20:36:23 <skraynev_> jdandrea: and in documentation too
20:36:53 <jdandrea> Hence the validation spec thingy
20:38:07 <shardy> Yeah, it's https://review.openstack.org/#/c/228425/ if anyone's interested
20:38:29 <shardy> it doesn't warn on create, but it at least provides potential way to warn on template-validate
20:41:21 <shardy> Anything else or shall we wrap things up?
20:41:44 <skraynev_> nothing from me :)
20:42:22 <ryansb> sounds like a plan
20:42:25 <jdandrea> :)
20:42:26 <skraynev_> #endmeeting