18:04:34 <rkukura> #startmeeting networking_policy
18:04:34 <openstack> Meeting started Thu Aug 31 18:04:34 2017 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:04:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:04:38 <openstack> The meeting name has been set to 'networking_policy'
18:04:41 <tbachman> rkukura: thx!
18:04:58 <rkukura> hi tbachman, annak[k]
18:05:15 <rkukura> So Sumit is not available today
18:05:55 <rkukura> annakk: Do you want to start with hour horizon question?
18:06:02 <annakk> sure
18:06:34 <annakk> I was trying to check out ui patches in review, and discovered half of the ui is not working for me
18:06:41 <tbachman> :(
18:06:54 <tbachman> annakk: is this stable/ocata?
18:06:55 <annakk> So I wondered whether its ocata to blame, me to blame or something else..
18:06:58 <annakk> yes
18:07:15 * rkukura wonders if stable/newton still works
18:07:58 <annakk> did anyone try it after newton/ocata sync?
18:08:01 <tbachman> annakk: did it work for you somewhat recently, or is this the first time you’ve tried the UI?
18:08:06 * tbachman has not
18:08:24 <tbachman> annakk: we’re working on creating a stable/ocata setup for testing
18:08:28 <rkukura> I have not tried horizon in a long time
18:08:29 <tbachman> but we’re not there yet
18:08:32 <annakk> I think its the first time. I looked at it a while ago but I don't think I ever tried to create things
18:08:46 <tbachman> I just looked at the stable/ocata merges
18:08:55 <tbachman> ah
18:08:57 <tbachman> wrong project
18:08:58 <tbachman> just a sec...
18:09:46 <tbachman> there are no patches into stable/ocata for group-based-policy-ui
18:09:53 <tbachman> which is interesting
18:10:36 <rkukura> tbachman: are there any ocata sync patches in master?
18:10:51 <tbachman> I must have made an incorrect query
18:11:00 <tbachman> b/c I searched for merges in master and came up with nothing
18:11:48 <annakk> there is this one https://review.openstack.org/#/c/483138/
18:12:04 <annakk> but its minimal
18:12:18 <tbachman> there is one after it to fix a delete button
18:12:23 * tbachman fixed his query
18:12:44 <tbachman> other than that - march 16th, april 4th, may 17th
18:13:09 <rkukura> the delete button patch needs back-porting I guess
18:13:33 <tbachman> rkukura: ack
18:13:51 <rkukura> wasn’t there something about an upcoming django version dropping some backward compatability we were depending on? Maybe that happended.
18:14:08 <tbachman> rkukura: news to me
18:14:30 <tbachman> rkukura: was that on openstack-dev?
18:14:52 <rkukura> https://review.openstack.org/#/c/493830/
18:15:22 <annakk> I think some of the patches in review deal with deprecations
18:15:39 <rkukura> If annakk has django 1.10, that patch might fix it
18:16:19 <annakk> OK, will try
18:16:23 <tbachman> annakk: when you say “half of the UI” — can you elaborate?
18:16:42 <rkukura> looks like there are a number of patches waiting review on master
18:17:10 <rkukura> #link https://review.openstack.org/#/q/status:open+project:openstack/group-based-policy-ui,n,z
18:17:51 <rkukura> annakk: Are the recent ones from your team?
18:18:12 <tbachman> ultimum.io
18:18:33 <annakk> tbachman: I wasn't able to create groups, rule sets..
18:18:43 <annakk> rkukura: you mean the patches? no
18:19:30 <tbachman> are the buttons/selectors not there? Or is that nothing happens when you try to select/use them?
18:20:37 <annakk> tbachman: the buttons are there, but cause errors (i don't think the request reaches our server)
18:21:00 <tbachman> annakk: okay, that helps. Thanks!
18:22:10 <annakk> tbachman: np. I don't understand much in UI sadly
18:23:00 <annakk> I'll see if the patches from ultimum improve it
18:23:02 <tbachman> annakk: sorry we don’t have a better answer for you now
18:23:40 <annakk> tbachman: sure, I just wanted to verify I wasn't missing something
18:24:15 <rkukura> ok, annakk, please let us know if you are using django >= 1.8, and if the recent patches help
18:24:43 <annakk> rkukura: ok
18:24:45 <rkukura> and we should be reviewing those a bit more proactively
18:24:52 <tbachman> rkukura: ack
18:25:01 <rkukura> anything else on horizon?
18:25:09 <annakk> not from me
18:25:22 <rkukura> so lets discuss db migration a bit
18:25:45 <tbachman> #topic DB migrations
18:25:51 <tbachman> ah, I’m not chair
18:25:55 <rkukura> #topic DB migrations
18:25:59 <tbachman> rkukura: thx!
18:26:11 <rkukura> #chairs tbachman, rkukura, annakk
18:26:15 <tbachman> :)
18:26:23 <annakk> :)
18:26:32 <rkukura> not sure if that works
18:26:38 <tbachman> it does
18:26:55 <tbachman> #link https://review.openstack.org/#/c/499240/ <= gerrit where Sumit discusses options for backporting DB migrations
18:27:18 <rkukura> as you probably know, GBP has historically been more aggressive with back-ports than most projects
18:27:39 <rkukura> we’ve been back-porting new features across several stable branches
18:28:05 <rkukura> but have not been back-porting all patches to every branch
18:28:21 <rkukura> so the result is we have different chains of DB migrations for each branch
18:28:39 <rkukura> this works ok for updates within a stable branch
18:29:04 <rkukura> but will result in some migrations being missed when upgrading to a new release
18:30:41 <rkukura> I first noticed this when reviewig a mitaka back-port
18:30:43 <rkukura> #link https://review.openstack.org/#/c/499185/
18:30:51 <annakk> rkukura: by "within stable branch" do you mean upgrading to newer version of same branch?
18:31:01 <rkukura> annakk: yes
18:31:17 <rkukura> so the chain might make sense within stable/mitaka
18:31:38 <annakk> but is this supposed to happen?
18:31:48 <rkukura> and a new migration might be at the HEAD of both stable/mitaka and stable/newton
18:32:34 <rkukura> but a migration skipped on stable/mitaka will not be run when upgrading to stable/newton, even though it is in the stable/newton chain
18:33:14 <rkukura> I think the OpenStack stable branch policy avoids this kind of issue by forbidding schema changes, along with API changes, etc.
18:33:39 <tbachman> forbidding *backports of* schema changes…
18:33:51 <rkukura> tbachman: can you summarize Sumit’s proposal?
18:33:58 <tbachman> rkukura: I can try :)
18:34:27 <tbachman> I believe SumitNaiksatam’s proposal is to backport all DB migrations in order to keep them consistent across stable branches
18:34:39 <tbachman> This means care needs to be taken when creating DB migrations
18:35:27 <tbachman> SumitNaiksatam also said it’s possible for the DB migration to be a No-Op, if for some reason the actual migration would be determintal as a backport
18:35:32 <rkukura> seems to me that we need to decide how to prevent issues going forward, but also need to fix the issues that already exist
18:35:38 <annakk> tbachman: backport migrations only, without the actual feature?
18:35:44 <tbachman> annakk: ack
18:36:15 <rkukura> we wouldn’t want it to be a no-op, or else we’d need the real version of the migration somewhere else on the chain
18:36:21 <annakk> are we sure all the migration are extend-like?
18:36:34 <tbachman> annakk: they aren’t
18:36:48 <tbachman> for example, one of the NFP patches has some more significant changes
18:36:52 * tbachman pulls up patch
18:36:53 <annakk> tbachman: isn't that a problem?
18:38:01 <tbachman> #link https://github.com/openstack/group-based-policy/commit/dc25f7154314d4b0d143a3f55d4ea4cc8a3eafe2#diff-9ae7c407a57ed5bb5e916dbbf4530e8b <== NFP patch, where a primary key is added and columns are altered
18:38:06 <tbachman> annakk: that was my thought as well
18:38:16 <tbachman> that said, I know SumitNaiksatam spent some time thinking about this
18:38:23 <tbachman> so maybe he has some thoughts there
18:38:40 <tbachman> The above patch seemed to be problematic as a backport w/o code
18:39:06 <rkukura> I doubt we can in general back port migrations without the correponding code
18:39:23 <tbachman> we may have to shelve this discussion until next week, where SumitNaiksatam can shed some light on the issues
18:39:48 <rkukura> shorter term, I think we need to resolve some of the current issues
18:40:32 <rkukura> For example, there are two migrations skipped on stable/mitaka that are needed on stable/newton, but will be skipped on an upgrade
18:41:30 <annakk> I think someone mentioned that it we re-do a migration that already exist, it will not cause an error?
18:42:43 <rkukura> annakk: I think migrations need to be written to handle that, for example checking if the new table or column already exists before adding it
18:43:35 <annakk> maybe that's a tolerable solution for short-term
18:43:52 <tbachman> #link https://review.openstack.org/#/c/498940/4/gbpservice/neutron/db/migration/alembic_migrations/versions/4c0c1e2c0160_ha_ip_address_to_port_id_association.py@32 <== example of checking for an existing table before applying migration
18:44:40 <rkukura> So one option is to make the skipped migration idempotent and move it to towards the head of the chain in the newer stable branch
18:47:18 <rkukura> I think there are 4 migrations total that are skipped on some stable branch and needed on a newer branch
18:47:43 <tbachman> rkukura: where does that patch go in master then?
18:48:15 <tbachman> it seems like it has to go to the point in the migration in the furthest backport
18:48:21 <tbachman> across all branches
18:48:30 <rkukura> tbachman: if we make a migration idempotent, I guess we should move it towards the head on all newer branches, including master
18:49:02 <tbachman> Didn’t we say that would cause migrations to be skipped on upgrades?
18:49:19 <tbachman> if not all branches have the same migrations?
18:50:15 <annakk> sorry but what is the reason for aggressive backports?
18:50:17 <rkukura> Adding a migration in the middle of chain on a stable branch doesn’t help deployments that are using that stable branch
18:50:29 <rkukura> annakk: good question!
18:50:46 * tbachman thinks we need SumitNaiksatam for this answer
18:51:34 <annakk> maybe we could consider changing the approach going forward..
18:52:19 <rkukura> annakk: we should consider that, or at least come up with a policy going forward that will prevent these issues
18:52:56 * tbachman notes the time
18:52:59 <rkukura> but we also need to fix things so that current deployments don’t break when upgrading to newer stable versions
18:53:23 <rkukura> doesn’t seem we are going to resolve either the short term or longer term issue here right now
18:53:32 <tbachman> rkukura: ack
18:53:38 <annakk> ack
18:54:11 <tbachman> I think we need SumitNaiksatam here to provide his insight/perspective on this
18:54:21 <tbachman> we’re left guessing at his intent
18:54:27 <tbachman> which doesn’t seem safe
18:54:31 <rkukura> but I think we are likely to try to come up with some sort of fix for the short term problem (existing branches and migrations) over the next few days, and can discuss this on email and/or gerrit
18:54:43 <tbachman> rkukura: sounds good
18:54:52 <rkukura> annakk: are you ok with that?
18:54:56 <annakk> (also with backporting we might hit issues with neutron tables, like FK to non-existing tables..)
18:55:03 <annakk> rkukura: yes, sure
18:55:19 <rkukura> annak: good point about FKs, etc.
18:55:39 <rkukura> ok, anything else to cover before we wrap up?
18:55:50 <tbachman> rkukura: nothing from me
18:56:17 <annakk> neither from me
18:56:25 <rkukura> ok, thanks everyone!
18:56:29 <annakk> thanks!
18:56:33 <rkukura> #endmeeting