09:00:58 <anteaya> #startmeeting nova-net-to-neutron-migration
09:00:58 <openstack> Meeting started Tue Feb 17 09:00:58 2015 UTC and is due to finish in 60 minutes.  The chair is anteaya. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:01:01 <openstack> The meeting name has been set to 'nova_net_to_neutron_migration'
09:01:04 <anteaya> hello
09:01:05 <jlibosva> hello
09:01:23 <obondarev_> hi
09:01:28 <anteaya> mikal gus ping
09:02:02 <anteaya> jlibosva: I have forgotten her irc nick, is the yahoo developer available, do you know?
09:02:23 <jlibosva> sec
09:02:38 <jlibosva> anteaya: spandhe ?
09:02:39 <anteaya> thanks
09:02:44 <anteaya> thats the one
09:02:56 <anteaya> spandhe ping
09:03:03 <anteaya> let's get going
09:03:11 <anteaya> #link https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration#Agenda
09:03:14 <anteaya> our agenda
09:03:34 <anteaya> #topic the state of the Neutron spec (obondarev)
09:03:44 <obondarev_> ok
09:04:01 <obondarev> not really much to update on the specs side
09:04:09 <obondarev> I added several comments to the second spec
09:04:24 <obondarev> #link https://review.openstack.org/#/c/142456
09:04:43 <obondarev> one of them is that I think we won't need a special extension in neutron to get/save data that is special for nova-net
09:05:00 <obondarev> we can continue to use nova db for such fields without any drawbacks
09:05:01 <anteaya> what data might that be/
09:05:07 <anteaya> ?
09:05:20 <obondarev> the data like integer id field
09:05:37 <obondarev> or bridge, bridge_interface
09:05:53 <anteaya> will those ever be used in neutron?
09:06:13 <obondarev> I believe no
09:06:19 <obondarev> so that's the idea
09:06:30 <anteaya> what might be the point of retaining that data?
09:07:07 <obondarev> so it will be needed for nova-net wjile we are in a mixed env
09:07:14 <obondarev> while*
09:07:34 <obondarev> it's about nova-proxy mode
09:08:03 <anteaya> okay well let's think about that then since we seem to be at an impasse in the proxy department
09:08:19 <anteaya> so you have some concerns about data
09:08:21 <anteaya> fair enough
09:08:32 <anteaya> anything else in the specs for now?
09:08:50 <obondarev> I believe we should continue to work on the spec and prototyping in parallel
09:09:07 <anteaya> that feels reasonable to me
09:09:32 <anteaya> anything more on specs?
09:09:56 <obondarev> not from my side
09:10:03 <anteaya> great let's move on
09:10:13 <anteaya> #topic the state of implementation (obondarev)
09:10:38 <obondarev> so for db migration
09:10:49 <obondarev> I looked through new revision briefly, I still have a concern that we should keep nova-net uuids of resources
09:10:56 <obondarev> instead of generating new in neutron
09:11:07 <obondarev> that's needed for transparent transition to nova-net proxy
09:11:22 <anteaya> jlibosva: any opinion on uuids?
09:11:40 <jlibosva> I just wanted to make it consistent with networks created in neutron.
09:11:46 <jlibosva> but if it's needed for proxy
09:11:50 <jlibosva> i'll remake it
09:11:57 <anteaya> hang on
09:12:15 <jlibosva> the thing is nova-net uses integers while neutron uses uuids
09:12:24 <anteaya> so retaining uuids from nova would make that inconsistent with neutron?
09:12:24 <obondarev> not really
09:12:35 <obondarev> nova-net uses both
09:12:47 <obondarev> can see in networks at least
09:13:05 <obondarev> it has id and uuid
09:13:20 <anteaya> but is that the deployer's choice?
09:13:22 <obondarev> so I mean to keep same uuid in neutron
09:13:29 <jlibosva> ahaaa
09:13:33 <jlibosva> but id is PK, right?
09:13:38 <jlibosva> let me check
09:13:57 <obondarev> anteaya: no, both id and uuid are used at the same time by nova-net
09:14:04 <anteaya> oh okay
09:14:22 <obondarev> jlibosva: same for vifs
09:15:40 <anteaya> if the choice results in consistency with the rest of neutron after the migration is complete, then I'm fine with the choice
09:15:54 <jlibosva> obondarev: but if we'll have neutron db as a source of truth
09:16:17 <obondarev> jlibosva: it should still be ok
09:16:18 <jlibosva> obondarev: and you want to re-construct e.g. fixed_ip model, you'll need to know network's id
09:16:39 <obondarev> yep
09:16:58 <obondarev> id can be fetched from nova db
09:17:04 <jlibosva> and still fixed ip will be reconstructed from neutron's db
09:17:25 <obondarev> correct
09:17:27 <jlibosva> so after migration, I still don't see the point of needing to know the id :)
09:17:49 <jlibosva> basically data are migrated, are consistent and previous ids are not relevant anymore
09:18:09 <obondarev> after db migration we'll still have nova-net hypervisors
09:18:26 <obondarev> configured for proxy mode
09:18:53 <obondarev> those hypervisors will expect same uuid/id
09:18:58 <obondarev> as well as users
09:19:01 <anteaya> let's talk about the proxy actually
09:19:11 <obondarev> ok
09:19:12 <anteaya> since we seem to have different opinions on that
09:19:20 <obondarev> osimple example
09:19:22 <anteaya> so if we move to look at the proxy patch
09:19:34 <obondarev> anteaya: go ahead
09:19:45 <anteaya> #link https://review.openstack.org/#/c/150490/
09:20:00 <anteaya> this has not got a lot of agreement from nova at the moment
09:20:14 <obondarev> yes
09:20:23 <anteaya> I had been expecting mikal to attend to help us move forward here
09:20:35 <obondarev> it's more regarding the approach
09:20:37 <anteaya> but I'll proceed with my best understanding
09:20:40 <anteaya> yes
09:20:55 <anteaya> so let's see if we can understand what the concerns about the approach are
09:21:05 <anteaya> I belive this has to do with interfaces
09:21:15 <anteaya> and nova would prefer the use of an api
09:21:27 <obondarev> as I see the concerns are in the level at which to implment the proxy
09:21:36 <anteaya> I believe there is actually an api available for interacting with neutron is there not?
09:21:41 <anteaya> obondarev: yes
09:21:50 <anteaya> and nova would prefer using an api
09:22:21 <obondarev> the problem is that we can't just switch to using neutron api in nova right after db migration
09:23:20 <anteaya> okay let's just take a minute
09:23:29 <anteaya> dansmith would like nova/network/neutronv2/api.py used
09:23:36 <anteaya> have we looked at this api?
09:23:47 <obondarev> sure
09:23:55 <anteaya> we have
09:24:06 <anteaya> are we able to use any part of it?
09:24:15 <obondarev> that's the api that is used when cloud is configured to work with neutron
09:24:22 <anteaya> great
09:24:39 <obondarev> and that api will be used when we switch a hypervisor to neutron
09:24:45 <anteaya> let's take a minute and look at the logs from the last nova meeting
09:24:48 <anteaya> #link http://eavesdrop.openstack.org/meetings/nova/2015/nova.2015-02-12-21.00.log.html
09:25:12 <anteaya> timestamp 21:08:42
09:26:47 <anteaya> do you understand the points that are being made?
09:27:13 <anteaya> at this point I don't see the use of having separate meetings
09:27:33 <anteaya> since if this meeting has one opinion and the other meeting has another opinion
09:27:40 <anteaya> and I am the only one that attends both
09:27:46 <anteaya> that falls down
09:27:55 <obondarev> I think all opinions should be reflected in the review anywhay
09:28:07 <anteaya> do you think they are at this point?
09:28:19 <obondarev> I think yes
09:28:28 <obondarev> Dan's is there
09:28:38 <obondarev> Andrew's as well
09:28:47 <anteaya> great
09:28:50 <obondarev> mine and gus also
09:28:50 <anteaya> so we have the opinions
09:29:02 <anteaya> now how do we get moving forward again
09:29:18 <anteaya> since the patch is currently -2'd by johnthetubaguy
09:29:36 <obondarev> I'd like folks to comment on my last comments
09:29:43 <anteaya> which folks?
09:29:44 <obondarev> -2 is for the spec
09:29:45 <jlibosva> but that's just because of bp not merged
09:29:54 <anteaya> jlibosva: okay thanks
09:30:17 <obondarev> johnthetubaguy wants blueprint for this
09:30:23 <obondarev> which is fair
09:30:27 <anteaya> okay
09:30:33 <anteaya> can we create a blueprint?
09:31:13 <obondarev> yes
09:31:44 <obondarev> but really the concep is in the patch
09:31:46 <anteaya> great
09:31:49 <anteaya> yes it is
09:31:55 <obondarev> and discussion may proceed
09:32:02 <anteaya> how do we address the concerns?
09:32:13 <anteaya> discussion doesn't feel like it is proceeding to me
09:32:22 <anteaya> so how do we get it moving again?
09:32:42 <obondarev> I'd like to see comments on my last replies
09:32:49 <anteaya> comments from whom?
09:32:56 <obondarev> Dan and Andrew
09:32:59 <anteaya> great
09:33:14 <anteaya> can you tell them you would like to see their thoughts?
09:33:17 <obondarev> as I don't think that proxying at a higher level will be any simpler
09:33:23 <anteaya> or perhaps ask them what their thoughts are?
09:33:29 <anteaya> obondarev: fine
09:33:35 <anteaya> but convincing me isn't useful
09:33:41 <obondarev> that's what I did on the review
09:33:54 <anteaya> are you willing to ask dan and andrew to share their thoughts
09:34:00 <anteaya> yes
09:34:03 <anteaya> yes you did
09:34:14 <anteaya> but we don't have agreement yet
09:34:21 <anteaya> so we have to try something new
09:34:24 <obondarev> so I'd like all thoughts be in the review
09:34:25 <anteaya> something different
09:34:28 <obondarev> to have history
09:34:32 <anteaya> that is fair
09:35:06 <anteaya> anything more on this topic then?
09:35:44 <anteaya> okay thanks, let's move on
09:35:57 <anteaya> #topic documentation (emagana)
09:36:15 <anteaya> we have a patch to review
09:36:19 <anteaya> #link https://review.openstack.org/#/c/155947
09:36:25 <obondarev> great!
09:36:50 <anteaya> this is the documentation that is intended to accompany sdague, ttx, markmcclain and emagana_ at the ops summit
09:37:10 <anteaya> so it would be great if you can review it and make sure it is sending the right message to operators
09:37:51 <obondarev> will review
09:37:51 <anteaya> I do have a concern that the documentation sends readers with questions to ask.o.o, which I don't participate in
09:37:54 <anteaya> obondarev: thanks
09:38:14 <anteaya> my preference is that readers with questions attend the meetings
09:38:29 <anteaya> not sure how to address that in the documentation though
09:38:55 <anteaya> anything more on documentation?
09:39:04 <anteaya> moving on
09:39:07 <anteaya> #topic      testing
09:39:28 <anteaya> jlibosva: any movement on testing your db migration patch?
09:39:38 * johnthetubaguy someone mentioned nova blueprints?
09:39:45 <jlibosva> I talked to spandhe
09:39:56 <anteaya> jlibosva: awesome
09:40:03 <jlibosva> she said she's gonna prepare environment with nova network
09:40:14 <obondarev> johnthetubaguy: we were talking about https://review.openstack.org/#/c/150490
09:40:19 <jlibosva> currently they use icehouse, so they will probably need to build  a new one with kilo
09:40:24 <anteaya> johnthetubaguy: hello yes, we were saying we need to create one for the neutron proxy patch in nova
09:40:47 <anteaya> jlibosva: testing with icehouse should be a good path too
09:40:49 <jlibosva> I have no other news since then on whether env is ready or not
09:41:10 <jlibosva> no, the script is not compatible with icehouse I guess. at least not on neutron side
09:41:19 <anteaya> we haven't discussed releases but we can't make assumptions about what release deployers are on
09:41:27 <anteaya> jlibosva: oh
09:41:34 <jlibosva> I think it will make sense to say "upgrade to kilo first"
09:41:47 <johnthetubaguy> anteaya: OK, I can help get the paperwork sorted, just hit me up after the meeting
09:41:48 <jlibosva> as db schemas vary among releases
09:41:49 <anteaya> jlibosva: is that a reasonable request?
09:41:57 <anteaya> johnthetubaguy: thank you
09:42:01 <johnthetubaguy> anteaya: we do actually assume people upgrade only from the previous release, if that helps
09:42:16 <jlibosva> anteaya: obondarev what are your thoughts on releases?
09:42:30 <anteaya> johnthetubaguy: it does, so making a path for kilo only is reasonable?
09:42:48 <johnthetubaguy> anteaya: yes, that fits our usual upgrade model
09:42:51 <obondarev> jlibosva: I think we will support Kilo only
09:42:57 <jlibosva> that makes sense to me
09:43:13 <obondarev> jlibosva: at least nova net proxy will be available in kilo
09:43:15 <anteaya> have we said anywhere that we support kilo only?
09:43:19 <johnthetubaguy> anteaya: basically it means, people have to upgrade to kilo, then do the migration, which seems OK, in terms of what we normally do
09:43:28 <anteaya> johnthetubaguy: okay thanks
09:43:31 <obondarev> johnthetubaguy: agree
09:43:34 <johnthetubaguy> np
09:43:38 <anteaya> so we should say somewhere kilo only
09:43:40 <anteaya> yes?
09:43:49 <anteaya> so perhaps in the spec?
09:44:04 <anteaya> or should we say prior release?
09:44:05 <johnthetubaguy> +1 for that being in the spec, for the avoidance of doubt
09:44:12 <jlibosva> +1
09:44:16 <obondarev> +1
09:44:22 <anteaya> then if this drags on we don't have to keep with kilo
09:44:56 <anteaya> can someone make a comment on the spec to that effect?
09:45:06 <anteaya> johnthetubaguy: actually since you are here
09:45:16 <johnthetubaguy> fire away
09:45:23 <anteaya> johnthetubaguy: can we bother you on your opinion on the proxy patch?
09:45:41 <anteaya> #link https://review.openstack.org/#/c/150490/
09:45:47 <anteaya> it feels stuck to me
09:45:57 <anteaya> apart from needing a blueprint
09:46:10 <anteaya> any thoughts on how we might get unstuck?
09:46:14 <johnthetubaguy> yeah, getting aggreement on the spec helps avoid some of these situations
09:46:22 <anteaya> true
09:46:29 <anteaya> we are a bit chicken and egg though
09:46:30 <obondarev> johnthetubaguy: that's the prototype
09:46:48 <anteaya> since we were asked to show code for folks to feel comfortable reviewing the spec
09:46:52 <obondarev> sometimes it's better to have prototype prior to the spec)
09:46:53 <johnthetubaguy> after a quick read of dan and andrew's comments, they seem reasonable, I just need to think about more about what I was expecting to see
09:47:05 <anteaya> fair enough
09:47:15 <johnthetubaguy> obondarev: very true, its often worth a prototype
09:48:37 <johnthetubaguy> obondarev: did you get dan's comment on that patch?
09:49:09 <johnthetubaguy> basically, its cleaner to go up the stack and subclass the nova-net adapter, rather than try to plug in between the DB
09:49:09 <obondarev> after reading nova meeting logs I think dansmith may have feeling that the patch is going to be only for network object
09:49:42 <johnthetubaguy> I think we are saying, its an odd use of objects thats likely to cause problems
09:50:05 <johnthetubaguy> it would be better to create a whole new API, that subclasses the nova-net one, to share code
09:50:12 <johnthetubaguy> or something a bit like that
09:50:14 <obondarev> so from my comment on the patch
09:50:35 <obondarev> Both nova-net api and manager are using nova-objects all over the place. So I'm afraid subclassing would mean a significant rewriting of nova-net code (developing/review nightmare!)
09:51:28 <johnthetubaguy> I guess we are just not convinced that the alternative will be "enough"
09:51:52 <obondarev> you mean enough for all the cases?
09:52:07 <obondarev> currently it proxies just network object
09:52:23 <obondarev> but the plan is to proxy all objects that nova-net operates
09:52:28 <johnthetubaguy> right, basically, it doesn't seem like it would work
09:52:41 <obondarev> why?
09:53:01 <obondarev> replacing the persistence layer from nova to neutron db is all what we're trying to accomplish with the proxy
09:53:04 <johnthetubaguy> its so low level, theres likely a miss match in the data that layer has for what you need to talk to neutron
09:53:11 <johnthetubaguy> at least, thats the impression I get
09:53:48 <johnthetubaguy> but anyways, lets not derail this meeting, I need to read more to give you better answers
09:53:53 <anteaya> do I understand correctly that the suggested way forward from nova is to write a new api?
09:54:13 <anteaya> johnthetubaguy: actually your thoughts are really helpful, thank you
09:54:39 <anteaya> johnthetubaguy: we had finished the agenda and are glad to have some light on how to unstick the proxy
09:54:43 <obondarev> anteaya: my understanding is the same
09:55:31 <obondarev> and I feel it's a lot harder
09:55:32 <anteaya> if nova is suggesting this, then we just need to feel we have support for patch review and merging of the new api code from nova
09:55:52 <anteaya> obondarev: true, but if this is the only door open, I think we need to consider it
09:56:08 <obondarev> I think we should continue discussion
09:56:20 <anteaya> yes
09:56:24 <obondarev> to be sure everybody understands everybody
09:56:28 <anteaya> right
09:56:43 <anteaya> which is why I am curious to hear if my understanding is correct
09:56:52 <anteaya> I'm discussing
09:57:43 <obondarev> I'd really like to hear the case where folks think the approach will not work
09:57:54 <anteaya> I thought we just did
09:58:12 <obondarev> I mean particular case
09:58:14 <johnthetubaguy> network['rxtx_base'] thats a really hard one, its implied by the compute flavor, and is a VM global qos setting, if I remember correctly, anyways, we except at the DB later you just can't hide enough details
09:58:24 <johnthetubaguy> https://review.openstack.org/#/c/150490/3/nova/network/neutron_migration/proxy_objects/network_proxy.py,cm
09:58:27 <johnthetubaguy> looking in there
09:59:04 <obondarev> so for such fields
09:59:14 <obondarev> the idea is to still use nova db
09:59:29 <obondarev> I put a comment there on this
09:59:57 <obondarev> I'll upload new revision
10:00:08 <johnthetubaguy> so, this isn't a good idea, but it just feels "messy" faking this stuff at that level
10:00:14 <johnthetubaguy> … so here is the thing
10:00:35 <johnthetubaguy> you can go build it this way, and it might work, and we might find the code debt "OK" for now
10:00:45 <obondarev> for such fields nothing will differ in proxy mode
10:00:54 * anteaya listens to johnthetubaguy
10:01:00 <johnthetubaguy> but the folks that know that code are saying you are likely to hit a snag that means it gets so horrible they would force it to be written the other way
10:01:22 <johnthetubaguy> its kinda your call which way you want to go
10:01:36 <anteaya> well it also is code destined for nova
10:01:47 <johnthetubaguy> I guess those folks are trying to say its likely to be more low risk and neater to hook in at the API level, which a bit of subclassing
10:01:48 <anteaya> so the solution needs to be acceptable to nova
10:02:04 <anteaya> johnthetubaguy: I'm hearing you
10:02:20 <johnthetubaguy> so the current approach may turn out to be acceptable, it just seems very unlikely when we look at the prototype
10:02:24 <anteaya> johnthetubaguy: how do we get nova to say they will agree to those code changes if submitted?
10:02:41 <anteaya> johnthetubaguy: or is your word sufficient?
10:02:46 <johnthetubaguy> we will not, basically
10:03:01 <anteaya> johnthetubaguy: nova won't agree to api changes?
10:03:02 <johnthetubaguy> basically if it works out, and looks good in the end, then all is well
10:03:12 <johnthetubaguy> but its just that seems unlikely
10:03:17 * anteaya is confused
10:03:23 <johnthetubaguy> so we wouldn't recommend that approach up front
10:03:33 <johnthetubaguy> … let me step back
10:03:51 <johnthetubaguy> we are basically saying we don't like the approach, but its only a prototype
10:04:09 <johnthetubaguy> if we looked at code thats fully features and working, and it looks OK, then we would merge it
10:04:33 <johnthetubaguy> but we are saying, its looking a lot like it would be horrible looking once its finished, but its hard to tell at this point
10:04:47 <johnthetubaguy> I guess I am sitting on the fence pointing in the direction we would like you to go
10:05:02 <anteaya> which direction are you pointing?
10:05:19 <johnthetubaguy> towards subclassing the API, like Dan and Andrew recommend
10:05:28 <anteaya> and if we do that direction
10:05:45 <anteaya> do we have support from nova to get patches reviewed and merged?
10:05:59 <anteaya> for new api subclasses?
10:06:01 <johnthetubaguy> thats a harder question, we should get core reviews to sponsor you
10:06:18 <anteaya> how do we find core reviewers to sponsor?
10:06:24 <johnthetubaguy> the problem is we are closed to blueprints and features and exception requests at this point in kilo
10:06:28 <anteaya> right
10:06:33 <anteaya> this also is my concern
10:06:45 <johnthetubaguy> but this is a priority thing, so we can look at adding that in, if we get some agreement
10:06:59 <anteaya> can we work on this with the idea that it won't be merged until L
10:07:03 <johnthetubaguy> its just, we really need the final code up for review already, if its got a hope of getting merged in kilo
10:07:06 <anteaya> but we can continue to work on it
10:07:11 <johnthetubaguy> yep, we totally can
10:07:17 <anteaya> johnthetubaguy: right I agree
10:07:35 <johnthetubaguy> ah, I got the wrong end of the stick
10:07:43 <johnthetubaguy> but yes, we can agree this for L
10:07:48 <anteaya> so at this point, I am floating the idea that we pat ourselves on the back for having something to show ops in kilo
10:07:55 <anteaya> meaning the documentation
10:07:57 <johnthetubaguy> I think you need to submit the spec for L, and that should help decide things the "normal" way
10:08:05 <johnthetubaguy> cool
10:08:05 <anteaya> #link https://review.openstack.org/#/c/155947
10:08:14 <anteaya> and move toward code for L
10:08:23 <anteaya> do you think that will work for nova?
10:08:23 <johnthetubaguy> makes sense
10:08:38 <johnthetubaguy> I don't see a problem with it, but its worth raising in the meeting
10:08:44 <anteaya> great
10:08:57 <anteaya> that is the approach I will see if we can get agreement around
10:09:14 <anteaya> since I think we are putting too much pressure on everyone to have this finished for kilo
10:09:31 <anteaya> we need to keep working but we need to give ourselves more room to breath
10:09:43 <anteaya> and we are way over time
10:09:48 <anteaya> thanks everyone for attending
10:09:50 <johnthetubaguy> honestly, the problem I have, is rackspace have already done the nova-network to neutron migration a year ago, so I have not really fully engaged in all the bits of the debate
10:10:03 <anteaya> fair enough
10:10:06 <johnthetubaguy> anyways, we do appreciate seeing progress from the nova point of view, its great
10:10:23 <anteaya> we are trying, thanks for the support
10:10:28 <anteaya> any final thoughts?
10:10:49 <johnthetubaguy> the problem is when we can remove nova-network from nova, docs is probably not quite enough, but its better than zip, which is great
10:10:49 <anteaya> okay see you next week, please review the docs patch
10:11:02 <anteaya> agreed
10:11:02 <jlibosva> will do, thanks
10:11:06 <anteaya> thank you
10:11:11 <anteaya> #endmeeting