00:01:07 #startmeeting networking_fwaas 00:01:08 Meeting started Thu Jan 7 00:01:07 2016 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:11 The meeting name has been set to 'networking_fwaas' 00:01:53 ok, for next week it seems RAX won’t be serving their famous bacon breakfast 00:02:01 o/ 00:02:05 so you gotta grab that before we meet there 00:02:27 Hi everyone. Sorry I am a couple of minutes late. 00:02:45 #topic API spec 00:03:16 I think we are done. Lot’s of +2/+1 00:03:23 So i think we are good 00:03:27 I think the spec is in a good place. Hopefully armax, dougwig or someone else on the neutron-drivers team can approve 00:03:50 dougwig? 00:03:51 I've taken the spec and have started putting together the RESOURCE_ATTRIBUTE_MAP for the new API - so far so good 00:04:02 link? 00:04:14 it's not up for review yet, started about an hour ago 00:04:25 oh, ok 00:04:50 you know the saying what’s not in git doesn’t exist 00:04:55 :-) 00:05:02 it's in my git, just not pushed up yet 00:05:29 k 00:05:31 Aish: if u do push another version pls add in the links for the stats related blueprints and u can state that more details will be covered there 00:05:37 Once the spec merges into neutron-specs, I also have a commit that pulls it into doc/ in our repo, so we can maintain it into the future, and I'll also push a new patch into neutron-specs once we publish it, to redirect people to the RST file for the API once we publish it 00:05:55 nice 00:06:03 Do we need another patch? SridarK 00:06:15 I would rather not with all the +2s/+1s 00:06:30 Aish: only if u are going to - to address dougwig's question 00:06:45 I think we can update it once we've got the RST over in neutron-fwaas repo 00:06:54 +1 00:06:55 +1 00:07:15 Yes only if we had to push another patch, no need to push one just for this 00:07:59 SridarK ok. 00:10:10 unrelated to the spec we need to decide how we version and transition users 00:10:28 to the new API 00:10:40 xgerman: good point. 00:10:46 xgerman: good point, some discussion along the lines of sc68cal: 's email ? 00:10:48 #topic API versioning and transition 00:11:01 #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg72002.html 00:11:30 if we can do something to this effect that will be good 00:12:40 doing a hard break (aka a new extension) made it so that Horizon, heat, stopped working so I am in favor of a compatibility layer 00:13:19 xgerman: yes that was ur concern 00:13:20 but like SridarK if that’s too much work/not enough time I am ok with skipping that 00:14:03 My thinking is - leave v1 API as it is today. We don't touch it, but we start work on the v2 API 00:14:16 if we finish work on the v2 API, then maybe we work on a translation layer after 00:14:20 so you can run v1 and v2 in the same install? 00:14:36 perhaps we can try to nail some of this down along with other cores next week ? 00:14:53 xgerman: most likely people will be running v1 for a while 00:15:16 we have to make something that works for v2 first, and that could take some time 00:15:22 yep, agreed. So are we allowing v1 and v2 to run on the same system 00:15:33 there is no v2 to run at this point 00:15:50 I know I am juts planning ahead 00:16:07 if we got that compat layer - that would make it possible to do v1 and v2 - but let's defer that until we actually have something 00:16:11 because for in parallel we need two different DBs 00:16:15 or schemas 00:16:22 hmm some thought is needed on the data models to have both run both together 00:16:32 yes exactly xgerman 00:16:35 yep, or we decide that’s not an option :-) 00:17:02 We should have unique DB schemes and assume both can be run together IHOM. 00:17:20 Basically I don't think we can just directly modify any of the code we currently have in the neutron-fwaas repo 00:17:52 Agreed. But there is no reason we cannot write V2 to use unique, non-conflicting data. 00:18:01 jwarendt_: agreed. 00:18:23 so we use a different schema/tables than v1 00:18:33 +1 00:18:44 yes that seems to be a good option 00:19:01 we can think in terms of deprecation of v1 at some later point 00:19:50 xgerman: does that seem to align with ur lbaas experience ? 00:20:00 Data migration from v1 to v2 should be possible - we'll just have to do it as its own task. It's big enough 00:20:21 v2 feels just like a superset of v1 00:20:23 Agree. 00:20:27 SridarK we didn’t do a compatibility layer since we felt nobody was using v1 00:20:36 ok 00:20:44 I think more people are using lbaas v1 than fwaas v1 00:20:59 true, but there are API clients already in the wild 00:21:17 my thinking is - build the new boat, then move all the deck chairs over to the new one 00:21:21 mickeys exactly and we didn’t assess that right and got burned a bit 00:21:59 I know internally we are still fighting the lbaas v1 versus lbaas v2 battle, coupled with the heat support issues 00:22:02 sc68cal +1 we make it so both boats can run on the same system and people can move them at their own leisure... 00:22:33 agree 00:22:37 Even if both don't run at same time, avoiding the overlap is useful - ex: db migration scripts. 00:22:45 jwarendt_: +1 00:22:57 On the microversion front, I talked with kevinbenton a bit and the trouble is we'd have a dependency on work being done in neutron to support microversioning 00:23:18 so, sadly we have to implement the full v2 API - I was hoping we'd be able to do it in stages and expose microversions to the user 00:23:34 as actual functionality landed 00:23:56 but for now looks like it'll have to be where we expose the full api, and in some cases we'll have gaps where it doesn't do anything or returns a Not Implemented error 00:24:04 well, if we are keeping v1 we can mark v2 experimental and do just that 00:24:20 just like v1 was experimental? ;) 00:24:21 sc68cal: sigh i was hoping that this was a discussion we can have since Kevin wil be there at the midcycle 00:24:41 well, I think we are making good progress here 00:25:08 but the whole micro versioning is a can of worms to begin with 00:25:29 aka since we release as part of neutron any API change mandates a new Neutron microversion 00:26:20 yeah. It would have been really helpful for fwaas v2, but it would be a lot of work 00:27:04 yes, esp if there are dependent pieces which are also WIP 00:27:11 well, with all the Api changes going on I can almost guarantee each release of Neutron has a new microversion 00:28:43 anything else on this topic? 00:29:02 no, I think we decided on what we want and how is a technical detail :-) 00:29:16 #chair SridarK xgerman 00:29:17 Current chairs: SridarK sc68cal xgerman 00:29:33 xgerman: SridarK: if you guys have other topics feel free 00:29:47 besides Happy New Year everybody 00:29:53 nothing from my side 00:30:33 i think we are good on this, we can thrash out the implementation details 00:32:56 well, should we finish early? 00:33:21 give sc68cal time to code :-) 00:33:26 :-) 00:33:28 :) 00:34:03 I hope for a productive 4 days next week 00:34:22 +1 00:34:27 +1 00:36:18 ok then - see you all next week :) 00:36:36 #endmeeting