15:00:23 <ricolin> #startmeeting heat
15:00:29 <ricolin> #topic roll call
15:00:30 <openstack> Meeting started Wed Jun  7 15:00:23 2017 UTC and is due to finish in 60 minutes.  The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:33 <openstack> The meeting name has been set to 'heat'
15:00:46 <zaneb> howdy
15:00:53 <gaborm> hello
15:00:59 <ramishra> hi
15:01:03 <mrwolf> hi all
15:01:06 <kazsh> Hi team
15:01:06 <ricolin> o/
15:01:07 <therve> Hey
15:01:14 <gaborm> I am Gábor Márton from Nokia
15:01:32 <LanceHaig> Hi
15:01:33 <ricolin> gaborm, so glad you're here!
15:01:39 <strigazi> o/
15:01:56 <ricolin> #topic adding items to agenda
15:01:58 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-06-07_1500_UTC.29
15:01:58 <gaborm> thanks rico, looking forward to discussing
15:02:21 <ricolin> gaborm, I already put it in agenda
15:02:27 <ricolin> feel free to add more in
15:02:43 <gaborm> thanks for putting it onto the agenda
15:03:25 <mrwolf> connecting to the adopt/abandon topic, I would like to discuss the state/future of externalId/external reference
15:03:32 <mrwolf> (Peter Wolf, also from Nokia)
15:03:57 <ricolin> mrwolf, sure
15:04:04 <zaneb> +1
15:04:12 <ricolin> #topic weekly report
15:04:41 <ricolin> no big bug this week, uwsgi just got reverted:/
15:05:11 <ricolin> #link https://review.openstack.org/#/c/471730/
15:06:06 <ricolin> #topic pike-2 release
15:06:06 <ramishra> I now have patch to fix that issue though https://review.openstack.org/#/c/471804/
15:06:09 <zaneb> there was a big bug this week, but ramishra squashed it pretty quick: https://review.openstack.org/#/c/470942/
15:06:18 <tiantian> hi ;)
15:06:49 <ricolin> #link https://review.openstack.org/#/c/470942/
15:07:29 <ricolin> should we wait for that fix before pike-2?
15:08:01 <ramishra> ricolin: nope
15:08:02 <ricolin> I already send release patch for stable branch
15:08:03 <ricolin> #link https://review.openstack.org/#/c/471760/
15:08:54 <ricolin> Also plan to release heat, python-heatclient, heat-agents
15:09:48 <ricolin> If nothing to raise here, I will send release patch today
15:10:38 <zaneb> ricolin: newton gate is in bad shape, with lots of patches queued up
15:10:50 <zaneb> https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/newton
15:12:16 <ricolin> zaneb, we never actually fix that issue
15:12:27 <zaneb> yeah
15:12:33 <ramishra> last 2 patches are green
15:12:43 <zaneb> https://review.openstack.org/#/c/466008/1 needs to merge before it will get better, but that is also blocked
15:12:49 <zaneb> I just rechecked it
15:15:08 <ricolin> will try to dive in that and hope we can pass that patch or find something to work with it
15:16:31 <ricolin> #link https://review.openstack.org/#/q/topic:heat-pike-2-release
15:16:45 <ricolin> release patch is up
15:17:16 <ricolin> move on:)
15:17:43 <ricolin> #action dive in newton gate and make it green
15:17:47 <ricolin> #topic deprecate ceilometer client
15:18:22 <ricolin> once https://review.openstack.org/#/c/439433/12 land
15:18:59 <ricolin> we will have no resource depend on ceilometer client plugin(at least not in heat repo)
15:19:33 <ricolin> as ramishra suggest, we should consider mark it as deprecate
15:20:23 <ricolin> before we do that, is there any concern not to do so?:)
15:21:38 <ricolin> nice:)
15:21:55 <ricolin> move on:)
15:21:59 <ricolin> #stack abandon/adopt
15:22:19 <ricolin> gaborm, it's yours:)
15:22:25 <gaborm> ok
15:22:47 <gaborm> abandon/adopt is important for us
15:23:38 <gaborm> would like to make sure that it is not dropped until external_id turns out to be a good replacement
15:24:02 <zaneb> I don't have a problem with that
15:24:06 <ramishra> gaborm: does it work well with convergenceengine ? Do you use it with newton+ heat?
15:24:18 <zaneb> it's disabled by default, so currently mostly not hurting anyone
15:24:29 <mrwolf> :)
15:24:47 <mrwolf> we actually have to support from  liberty+
15:25:21 <mrwolf> I'm not even sure if we have to support newton yet.
15:25:32 <gaborm> we rely on it as a tool for doing whatever topology change needed for upgrading a vnf _in-service_
15:25:46 <zaneb> ramishra: I believe it should work with convergence. it's basically a variation on create/delete. it definitely didn't work at first but iirc that was fixed
15:25:53 <ricolin> gaborm, maybe you guys can give a heads up for convergence, since you might want to test it with abandon/adopt before you actually move your env to use it
15:25:57 <therve> There is no reason to drop it really. Did we deprecate it?
15:26:14 <mrwolf> From what we see, enterprise environment tend to lag behind.
15:26:39 <zaneb> therve: the config option is not deprecated afaik
15:26:45 <mrwolf> To be honest, I'm not have to catch up on what convergence engine is
15:27:01 <zaneb> mrwolf: it will change your life ;)
15:27:10 <mrwolf> on the latest summit, it was brought up that the adopt/abandon interface might be deprectaed and dropped
15:27:49 <mrwolf> so what I see, from major release to another major release VNFs tend to have major topology changes
15:27:59 <LanceHaig> I agree Enterprise lags behind others
15:28:10 <mrwolf> and sometimes they approach it with the following way
15:28:10 <LanceHaig> so we should make sure we don't break stuff to much
15:28:26 <ricolin> mrwolf, maybe this can help you a little
15:28:29 <ricolin> #link https://www.youtube.com/watch?v=FVo_zHXcMC0
15:28:51 <mrwolf> they would like to build a new stack, representing new topology
15:28:59 <ricolin> a bad video for onboarding
15:29:30 <mrwolf> but there are key resources that should somehow be moved from the old stack to the new one
15:29:53 <kazsh> umm we also rely on abandon well....
15:30:27 <mrwolf> (for example they hold random allocated IP for port, or floatingIp, that are propagated to other systems so they should be kept)
15:30:38 <zaneb> topology of what exactly here?
15:30:44 <zaneb> networks?
15:30:46 <gaborm> ricolin: hopefully only the audio quality is bad :)
15:30:59 <mrwolf> sorry, topology of VNFs
15:31:12 <mrwolf> ~application
15:31:16 <ricolin> gaborm, lol
15:31:36 <gaborm> zaneb: ports and volumes seem the most critical ones
15:31:43 <zaneb> mrwolf: just trying to get an idea of why this requires a whole new stack and can't be done with an update
15:31:47 <gaborm> e.g. keep an IP address
15:31:53 <mrwolf> basicaly a bunch of vms, volumes, networking deployed to satisfy a given purpose/service
15:32:04 <gaborm> or keep a volume that was originally attached as "delete on terminate"
15:32:07 <zaneb> (still clueless so far)
15:32:35 <mrwolf> yeah, so this is 5-9 environment, it is often reqired or advised
15:32:54 <mrwolf> to do sanity check on the new deployment ,before traffic is routed there
15:33:06 <gaborm> say someone was not careful enough to define the HOT such that it can be upgraded by consecutive stack updates
15:33:23 <gaborm> practically noone is careful enough like that
15:33:25 <mrwolf> basically the old stack does everything up until the very last minute, where they do a quick switch over
15:34:30 <ricolin> mrwolf, you mean "adopt" stack?
15:34:39 <mrwolf> and sometimes, it just laziness where it's easier to build anew, the figuring out a logical path via stack updates to get from one topology to a majorly different new one
15:34:42 <zaneb> mrwolf: we're working toward a future where Heat can automate all of that, but I understand
15:35:52 <mrwolf> with abandon and adopt, one can create let go of the resources and if they are very lucky they can manually create an "export json", they can use for adopt
15:35:53 <LanceHaig> I have to jump off something has come up sorry
15:36:06 <mrwolf> -create
15:36:23 <ricolin> LanceHaig, np, see you soon:)
15:36:27 <mrwolf> hence importing resources
15:36:47 <zaneb> mrwolf: use export *before* abandon, then you don't need as much luck
15:37:10 <gaborm> zaneb: thanks, that's a great feature1
15:37:18 <gaborm> *!
15:37:32 <mrwolf> I also saw, that the original blueprint for external resoucres contained use cases like this: #link https://specs.openstack.org/openstack/heat-specs/specs/liberty/external_resource.html
15:38:12 <zaneb> external resources is designed to be the long-term solution to this
15:38:12 <mrwolf> but my trials show me, that actually updating the externalId of a resource, if it was created by HEAT is not allowed
15:38:27 <mrwolf> so this is no way to let go, or import a resource
15:38:37 <mrwolf> (currently)
15:38:49 <zaneb> mrwolf: you can always set deletion_policy: retain and then delete the stack
15:39:11 <mrwolf> ok, that's half way there :)
15:40:01 <ricolin> mrwolf, what we might do in long term, is to make sure external resource can fully take over abandon/adopt before we retire abandon/adopt
15:40:24 <zaneb> ricolin: yes, absolutely
15:40:35 <mrwolf> export is useful indeed, the lucky part was about editing that output with addnig new resources, in the perfect way so heat can consume it
15:41:32 <gaborm> ricolin, zaneb: that's already great news for us
15:41:38 <zaneb> mrwolf: haha, yeah, you will always need luck for that bit. one reason that external resources are a considerably better design
15:41:56 <mrwolf> in Boston @zaneb said that the adopt/abandon is disabled because it is buggy, and not maintained
15:42:12 <mrwolf> is there a list for bugs that are still valid?
15:42:51 <zaneb> there is a standing query for those bugs :)
15:42:56 <zaneb> #link https://bugs.launchpad.net/heat/+bugs?field.tag=abandon-adopt
15:43:57 <mrwolf> how far back it is realistic to backport a fix, if we provide one? (I mean as an OS version, like liberty). Or is there major changes (like convergence sounds like) that would mean the same fix most probably won't work for older verions?
15:44:09 <ricolin> newton
15:44:17 <ricolin> if for security
15:44:57 <zaneb> https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
15:45:08 <zaneb> we're obliged to follow that policy ^
15:45:18 <ricolin> zaneb, thx
15:45:26 <mrwolf> :(, ok so what can be an earliest realistic target for new features to external resources?
15:45:44 <zaneb> that said, it should be *technically* possible to backport fixes without too much difficulty in most cases
15:45:54 <gaborm> I encountered strange behavior of adopting nested stacks: the "files" map needed to be filled in inconsistently, depending on the level
15:46:00 <mrwolf> (yes, thx for all the answers, we're kind of newbie, we were at the user side of heat for the most part)
15:46:09 <zaneb> the convergence_engine is a separate code path
15:47:00 <mrwolf> i see
15:47:25 <ricolin> mrwolf, gaborm do hope if you guys can help us to test with convergence mode + export/abandon/adopt for your use case when you try to move to mitaka or further
15:47:35 <gaborm> btw, adopting nested stacks does not work with the cli---only with python-heatclient (with the create method; no adopt)
15:48:12 <gaborm> ricolin: sure, we hope so too
15:49:21 <gaborm> convergence can be turned on from mitaka?
15:49:27 <mrwolf> internally we "play" with newton
15:50:03 <ricolin> gaborm, yes, and it's default= true since newton
15:50:13 <ricolin> mrwolf, ^^^
15:50:27 <mrwolf> but as long as we have to support down to liberty, we have to come up with solutions that can cover all supported platforms
15:50:43 <mrwolf> ...again enterprise
15:50:46 <mrwolf> :)
15:50:58 <zaneb> tbh I wouldn't recommend using it in mitaka, just because it's so much better tested since it became the default in newton
15:51:24 <gaborm> ok, we'll start testing with newton
15:51:26 <ricolin> zaneb, +1
15:52:35 <mrwolf> thx, I look into convergence.
15:52:44 <gaborm> thanks a lot so far! we'll talk to our managers on that we need to contribute to heat
15:52:47 <ramishra> mrwolf: liberty is EOL for us https://releases.openstack.org/ , though as zaneb mentioned you can technically backport fixes
15:52:47 <ricolin> gaborm, mrwolf  looking forward for any bug report from you guys
15:52:53 <mrwolf> thanks for the time and aswers
15:53:28 <gaborm> ok, we'll report at least those two issues above
15:53:43 <zaneb> mrwolf, gaborm: thanks, I think this was productive :)
15:54:02 <ricolin> mrwolf, yes, like ramishra just said, it's possible that you can backport our work in new version, if that can do any help to you
15:54:05 <gaborm> same here! :)
15:54:43 <ricolin> nice:)
15:54:49 <ricolin> move on
15:54:50 <ricolin> #topic Open discussion
15:55:10 <ricolin> anything would like to discuss?:)
15:56:24 <ramishra> zaneb: what should we do for nova floatingip resources? They are broken atm, Is there a different approach than https://review.openstack.org/#/c/466187/ you've in mind?
15:57:20 <zaneb> so I read somewhere that nova-network actually still exists, and it's just the passthrough to neutron in the client that was deleted
15:57:33 <zaneb> now I don't know what to believe or what we should be doing
15:57:43 <ramishra> zaneb: the support is removed from novaclient
15:58:19 <zaneb> all support for nova-network?
15:58:23 <ramishra> yes
15:59:00 <zaneb> but nova-network still exists in nova?
15:59:45 <ramishra> yes, they have kept it in the server due to some dependency with placement services, that's the most I know
16:00:12 <ramishra> I think that's what also mentioned in the mail you mentioned
16:00:17 <ricolin> okay guys time
16:00:17 <zaneb> "nova-network still exists in Pike and will continue to exist until we can get rid of cells v1, which isn't until we can claim support for multiple cells v2 cells."
16:00:22 <ricolin> time's up
16:00:55 <ricolin> shall we move this back to heat:)
16:01:22 <zaneb> by all means
16:01:52 <ricolin> thanks all:)
16:01:54 <ricolin> #endmeeting