15:00:23 <ramishra> #startmeeting heat
15:00:25 <openstack> Meeting started Wed Nov  9 15:00:23 2016 UTC and is due to finish in 60 minutes.  The chair is ramishra. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:28 <openstack> The meeting name has been set to 'heat'
15:00:34 <prazumovsky> hi
15:00:35 <ramishra> #topic roll call
15:01:16 <cwolferh> o/
15:01:26 <yohoffman> \o
15:02:07 <ramishra> hi all, it would be short one as there is nothing much other than o-1 status in the agenda:)
15:02:50 <therve> Let's go!
15:03:20 <ramishra> zaneb probably is recovering from the election result shock;)
15:03:42 <ramishra> #topic adding items to agenda
15:03:54 <ramishra> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-11-09_1500_UTC.29
15:04:06 <yohoffman> I added a small item
15:04:23 <ramishra> yohoffman: thanks!
15:04:28 <yohoffman> Wanted to see if anyone has thoughts on two implemented quota resources
15:04:54 <ramishra> #topic o-1 status
15:05:24 <ramishra> Next week is o-1 milestone week, only 2 weeks after summit.
15:05:34 <ramishra> #link https://launchpad.net/heat/+milestone/ocata-1
15:06:06 <ramishra> we don't have many bps, only 2, out of them one is the quota related and other some keystone resources
15:06:14 <therve> Doesn't look too bad
15:06:49 <ramishra> yeah, there are some targeted unassigned bugs.
15:06:59 <ramishra> I think we would move them to o-2?
15:07:13 <therve> I think I'll handle one at least
15:07:32 <ramishra> ok, great
15:07:32 <therve> The other shardy may have an opinion, it sounds like doc to me
15:08:19 <ramishra> I think there are 2 backports for stable/newton in review too.
15:08:44 <ramishra> we need reviews for them as we would cut a stable release with o-1
15:08:48 <prazumovsky> therve: yeah, there are several such issues, which related to absence of detailed RG description
15:09:25 <ramishra> #link https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/newton
15:10:06 <ramishra> prazumovsky: do we really want this backport https://review.openstack.org/#/c/393290/?
15:10:16 <therve> It doesn't look like a good backport
15:10:22 <therve> No new conf option
15:10:42 <prazumovsky> about my backport - originally some people need that in newton, but haven't merged to newton
15:10:59 <prazumovsky> and now they asked me to backport that
15:11:15 <prazumovsky> I answered, that this is not good practice
15:11:29 <prazumovsky> but they insisted:)
15:11:39 <ramishra> prazumovsky: I would prefer not to backport it.
15:11:52 <prazumovsky> OK, no problem
15:12:25 <prazumovsky> At least, I had to try
15:12:33 <prazumovsky> then abandon it
15:12:53 <ramishra> please review the patches for In Progress bugs:)
15:13:28 <ramishra> #topic Quota resources for neutron and nova
15:14:08 <ramishra> yohoffman: that's your item;)
15:14:14 <yohoffman> I guess that's my cue
15:14:39 <yohoffman> Just wanted to see if anyone had a chance to look at the two quota resources that have been implemented
15:14:50 <yohoffman> If there is anything that anyone would like to discuss
15:14:54 <yohoffman> Nova quota: https://review.openstack.org/#/c/373548/ and Neutron quota: https://review.openstack.org/#/c/380471/
15:15:04 <ramishra> I had looked at the nove quota resource plugin, I'm not comfortable with it. As you specify user quota in addition to project quota.
15:15:27 <ramishra> I had a few comments there, probably someone would like to look at it.
15:16:33 <yohoffman> It originally only handeled project quota. I believe someone requested that I add in user quota as well.
15:16:53 <therve> Either sound weird TBH
15:17:19 <yohoffman> It was Oleksii Chuprykov
15:17:21 <therve> It's not like it's a deployment thing, you're making it part of your project creation workflow I guess?
15:17:29 <therve> It would make more sense in mistral
15:17:44 <yohoffman> It's currently part of AT&T's orchestration process
15:18:24 <ramishra> I think we have added one quota resource for cinder already.
15:18:32 <yohoffman> correct
15:18:56 <ramishra> I'm ok if it's limited to project quotas only like the cinder one.
15:19:16 <yohoffman> The neutron one is just project quota
15:19:32 <yohoffman> And I can remove the user from nova quota
15:20:14 <therve> That doesn't sound too terrible
15:20:33 <therve> Resources are relatively low maintenance
15:20:54 <ramishra> ok, then, sounds good:)
15:21:17 <yohoffman> Great, thanks for the input!
15:21:28 <ramishra> #topic open discussion
15:21:43 <prazumovsky> I have one question to discuss
15:21:55 <prazumovsky> especially for ramishra
15:21:59 <ramishra> I wanted to know if anyone is working on any specific action items from the summit?
15:23:18 <ramishra> I had sent a mail listing some of them a week back:)
15:23:43 <ramishra> therve: should we create some bugs from them to track?
15:23:48 <prazumovsky> about naming new nova version in https://review.openstack.org/#/c/374821/ . KanagarajM prefered such universal name for version 2.26, because "api version would provide more than one feature and user/developer who implements the resource plugin would know which version to use". But if name version as MIN_SUPPORT_TAG_VERSION, it could be confused
15:24:49 <zaneb> ohai
15:25:16 <therve> ramishra, That'd be nice
15:25:27 <ramishra> prazumovsky: Without looking at api docs, no one would know that 2.26 is the version that supports tags.
15:26:17 <ramishra> prazumovsky: I did see the discussion in that review.
15:26:30 <ramishra> I'm fine if others think that's ok.
15:27:04 <prazumovsky> but if there another feature, we will cannot understand, is this suitable version or not
15:27:26 <ramishra> prazumovsky: ok
15:27:56 <prazumovsky> ... I can add several names as compromise:) V2_26 == 2.26 and MIN_VERSION_TAG_SUPPORT == 2.26, if you want.
15:28:09 <prazumovsky> And, of course, I'll add unittests
15:28:44 <ramishra> Anything else we would like discuss?
15:28:52 <cwolferh> i couldn't really tell from the etherpads or ramishra's last email what the thinking was around rolling upgrades support. on the rpc side, future_args seems like an easy way to go that wouldn't hurt much (just the extra few bytes we're passing around all the time)
15:29:34 <therve> cwolferh, We'd like to try the vhost idea before
15:30:08 <cwolferh> therve, is that "   proposed Solutions: Run multiple heat version engines with different AMQP virtual hosts, so different versions can't talk to each other"
15:30:18 <therve> cwolferh, Yes
15:31:04 <cwolferh> ok, so newer versions are listening on multiple queues?
15:31:24 <therve> Just the new one
15:31:41 <therve> I don't think it needs listening on the old vhost, does it?
15:31:47 <Drago> This is how Rackspace does updates to Heat
15:31:52 <cwolferh> so, in theory then, there could be messages lost on  the old queue when the old heat-engine goes odwn
15:32:23 <therve> Drago, Interesting data point, thanks
15:33:03 <ramishra> Drago: do you have anything that documents the process? we can just use that;)
15:33:57 <Drago> I don't think we have anything public-facing… We do a blue-green deployment, so half the time we have a set of nodes that are "inactive" that are on the old version in case we need to roll back quickly
15:34:25 <Drago> It's essentially two separate sets of engine and API nodes that are using the same DB
15:34:51 <ramishra> therve: yeah, that's what we discussed, right?
15:35:02 <ramishra> Drago: thanks for the inputs.
15:35:03 <therve> I think so yeah.
15:35:11 <cwolferh> so, it sounds a bit to me of pushing the trickiness of the upgrade onto operators
15:35:12 <Drago> Welcome, ping me anytime
15:35:31 <therve> We didn't discuss keeping old APIs, as we don't have the problem there i believe
15:36:06 <cwolferh> whereas with future_args, there is little operators have to worry about
15:36:07 <therve> cwolferh, The upgrade is tricky though
15:36:28 <therve> That only solves half the problem though?
15:36:33 <cwolferh> not sure it always has to be
15:36:33 <therve> What about new RPC calls?
15:37:00 <cwolferh> if new rpc calls have a higer minor version, only new heat-engines will receive those
15:37:24 <therve> Is it how it works?
15:37:43 <therve> AFAIR it just failed, it had no way to filter where to send
15:38:47 <cwolferh> this was my reading of http://docs.openstack.org/developer/oslo.messaging/target.html#target-versions , but i haven't proved it in the lab
15:39:09 <cwolferh> also mentioned in my post to list a few weeks back
15:39:51 <therve> I'd like it to be tested please :)
15:40:02 <cwolferh> ok :-)
15:40:08 <therve> Also, the vhost solution would mean that we can declare newton rolling upgradable
15:40:10 <therve> Which is nice
15:40:18 <therve> Also future_args is super ugly
15:40:57 <cwolferh> well, i'm more concerned with smooth rolling upgrades than one ugly arg
15:41:07 <therve> IIUC, if we had future_args, it will mean that pike supports rolling upgrades
15:41:07 <ramishra> therve: we need the gate jobs to test the upgrade before we can declare anything;)
15:41:16 <therve> With vhost, it's there now
15:41:45 <therve> cwolferh, I'm also tempted to suggest to never add argus
15:41:50 <therve> And just add methods
15:42:37 <cwolferh> stack_list_v17. i like it!
15:43:12 <cwolferh> ah, humor doesn't translate so well
15:43:16 <therve> Well that's a good example. When are we going to change stack_list? Not that many times
15:43:38 <therve> Also when we add an arg, it will be hidden in future_args forever
15:43:49 <cwolferh> but the strong consensus here seems to be for vhost. would testing the version thing i mentioned be worthwhile or not?
15:44:26 <therve> Well we're only 4 to talk, I wouldn't say "strong" :)
15:44:44 <therve> I'd say more expertise on that subject is welcome regardless
15:45:27 <ramishra> I think doing some POCs/tests irrespective of the preferred approach and documenting the results would be good.
15:45:37 <therve> +1
15:46:52 <cwolferh> therve, yeah, i think you are right. until the next major version until we start from scratch. but we don't really add that much to api's, right? ;-)
15:47:56 <therve> cwolferh, We changed one API during newton
15:48:17 <therve> Maybe 2?
15:48:56 <therve> Anyway
15:49:07 <ramishra> zaneb: If you're around, I was hoping that you would finish the 'store outputs in db' thing in the flight on your way back home;)
15:49:23 <ramishra> from the summit.
15:49:25 <zaneb> ramishra: lol
15:49:35 <therve> cwolferh, Also, understanding what happens when version is specified in the call would be interesting
15:50:06 <therve> cwolferh, I guess it's always the case for new APIs? Because we also do it when we change signature
15:51:26 <cwolferh> yeah, adding  args to the signature should be something we can handle within a given major version imo. but removing isn't going to work ever.
15:52:50 <therve> Which seems okay
15:53:02 <cwolferh> agree
15:54:16 <therve> ramishra, Think we can move on
15:54:40 <ramishra> yep, if there is anything else to discuss?
15:55:05 <ramishra> we have 5 more mins, else we can move back to #heat
15:55:25 <yohoffman> I've updated the nova quota to only handle project quota, so those quota bp are ready for lift off
15:55:41 <ramishra> yohoffman: thanks
15:55:49 <ramishra> ok, thanks all!
15:55:56 <ramishra> #endmeeting heat