09:00:35 #startmeeting nova-net-to-neutron-migration 09:00:35 Meeting started Tue Jan 27 09:00:35 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:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:39 The meeting name has been set to 'nova_net_to_neutron_migration' 09:00:47 jlibosva: hello 09:00:48 hello! 09:00:50 hi obondarev 09:00:56 this is spandhe 09:01:01 anteaya: hi 09:01:11 I met her today and she works with yahoo's deployment 09:01:22 so she is attending today's meeting 09:01:29 anyone else here for the migration meeting? 09:01:34 great! 09:01:36 Hi obondarev ! 09:01:47 gus: you here? 09:01:51 spandhe: nice to meet you :) 09:01:59 belmoreira: ping 09:02:19 let's look at today's agenda 09:02:23 #link https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration 09:02:34 obondarev: I have tried your earlier patch in Yahoo (with few changes) and have tested out successful live migration. I am trying to see thr new approach now. 09:02:35 hi, I'm late... 09:02:42 belmoreira: welcome 09:02:50 spandhe: let's follow our agenda 09:03:00 spandhe: then we can have a chance to discuss 09:03:00 spandhe: cool! 09:03:03 anteaya: ok.. 09:03:06 #topic he state of the Neutron spec (obondarev) 09:03:09 spandhe: thanks 09:03:18 so the specs first 09:03:22 obondarev: take it away 09:03:23 so for the specs 09:03:33 just saw an activity on the specs this morning 09:03:39 \o/ 09:03:42 most probably related to the discussion at nova midcycle 09:03:51 it was yes 09:03:53 gus has uploaded new revisions on the specs so he probably knows more than me :) 09:04:12 gus: pingity ping ping 09:04:22 I'm going to go through them and left comments, if any 09:04:31 obondarev: wonderful thank you 09:04:43 anteaya: are you at the midcycle? 09:05:07 obondarev: I am, I am only there tomorrow morning and then I have to leave for the cinder mid-cycle 09:05:16 the two overlap 09:05:28 anteaya: ok, great! 09:05:28 so we discussed the specs today 09:05:50 and there is agreement to solve the simplest use case, as we have been working to do 09:06:12 and I would really like to get at least the first part of the two part spec merged this week 09:06:23 so that is this patch 09:06:27 #link https://review.openstack.org/#/c/147723/4 09:06:34 I think we are close 09:06:57 so if folks can review that then hopefully we can get that polished and finished this week 09:07:01 that is my goal 09:07:14 anteaya: is Salvatore at the midcycle as well? 09:07:24 obondarev: he was there today 09:07:31 and then had to go to vmware meetings 09:07:35 I'm asking because one of the comments from Salvatore was his concern on whether we need a proxy in nova at all. 09:07:45 hopefully he will be there tomorrow before I leave 09:07:52 As I started to work on it I'd really like this concerns to be sorted asap :) 09:07:53 obondarev: yes, I saw that 09:07:59 obondarev: yes 09:08:15 obondarev: can you submit your code to gerrit, so folks can look at it? 09:08:16 good to know he's there 09:08:22 he is, yes 09:08:27 I was happy to see him 09:08:28 yeah. I'll try to put a WIP on gerrit this week 09:08:35 hopefully this will be something that makes sense and not a complete waste of reviewers time 09:08:36 can you do that today please? 09:08:44 anything is a start 09:08:59 it is frustrating for me to tell people there will be code and there is no code 09:09:00 not sure for today 09:09:13 just submit what you have 09:09:19 it doesn't have to be perfect 09:09:26 but anything is better than nothing 09:09:36 yeah, I know, I'll try 09:09:42 it really holds up discussions when folks have nothing to look at 09:09:44 thank you 09:10:07 and progress on the second patch of the spec hinges on folks being able to see code 09:10:36 so we need to have some code to make any progress on https://review.openstack.org/#/c/142456/ in a meaningful way 09:10:40 #link https://review.openstack.org/#/c/142456/ 09:11:01 obondarev: seeing what you have written may answer some of salv-orlando's concerns 09:11:16 anteaya: I see 09:11:30 obondarev: thanks, so anything you have is great 09:11:48 if folks make you feel unhappy for putting something up in wip state, then let me know 09:12:05 since you should be supported by showing unfinished coce 09:12:07 code 09:12:15 and if you don't, I will address it 09:12:27 thanks anteaya 09:12:31 thank you 09:12:45 obondarev: and yes, I want your efforts to be valued, not wasted 09:13:05 anteaya: appreciate that :) 09:13:11 so without gus, I'm not sure what else we need to talk about regarding the specs 09:13:15 obondarev: :) 09:13:24 does anyone else have anything for specs? 09:13:28 nope 09:13:29 or shall we move on? 09:13:45 okay great, please review them as soon as you are able 09:13:57 moving on 09:14:07 #topic the state of implementation (obondarev) 09:14:19 so we already started to talk a bit about implementation I guess 09:14:57 will try to put a wip on proxy asap 09:15:03 thank you 09:15:18 I see jlibosva has progress on his DB migration patch 09:15:24 jlibosva: can you please update? 09:15:34 #link https://review.openstack.org/#/c/148260/ 09:15:41 I'm gonna send new PS soon. I'm rewriting the code structure to be more declarative 09:15:51 jlibosva: great thank you 09:15:53 jlibosva: thanks 09:16:06 every neutron table has its own definition how the table should be populated 09:16:27 currently I'm in state of getting ports and fixed/floating ips populated and that's the last part 09:16:36 so ETA this week I think prototype should be ready 09:16:43 jlibosva: perfect! 09:16:48 jlibosva: wonderful work, thank you 09:17:04 jlibosva: great 09:17:09 spandhe: did you have any more comments for obondarev? 09:17:55 anteaya: I have questions about the previous spec.. mostly because I wasnt involed earlier.. I can talk to him later too... 09:18:15 spandhe: doens't hurt to ask now 09:18:27 since this is logged it would be helpful to ask 09:18:32 spandhe: you mean juo spec, right? 09:18:37 juno* 09:18:50 anteaya: ok cool.. obondarev, have questions on kilo specs 09:19:08 spandhe: ah, ok 09:19:33 are we not planning to do a live migration? I thought you kind of achieved that in Juno spec.. or at least we did using that code 09:19:59 seems like both the APIs are down during the db migration period. 09:20:22 Is my understanding correct? 09:20:41 spandhe: right, the first iteration does not include live migration 09:20:56 spandhe: but API are partially down 09:21:18 spandhe: Nova API is down during only initial db migration 09:21:43 spandhe: then it's up again 09:21:58 obondarev: ok.. whats initial db migration? Also, once the db is migrated, where do new VMs come up? in nova-net land or neutron land? 09:22:29 spandhe: so after the db migration the source of thruth will be in neutron db 09:22:43 truth* 09:23:00 obondarev: ok.. and nova is the active API and the calls are proxied to neutron API, am I right? 09:24:01 spandhe: nova is the active API, calls are operated by nova-network which will go for data to neutron DB 09:24:10 spandhe: using special proxy in nova 09:25:09 obondarev: ok thanks.. I am not sure what this special proxy is.. does it help nova in accessing neutron DB? because usually nova user wont have acess to neutron db.. 09:26:05 yep, it does, it should go to neutron to get data 09:26:35 after that we can start The big migration loop 09:26:58 obondarev: ok.. thanks! I got the gist now.. I can review the specs and the db migration script.. 09:27:14 spandhe: great! thank you! 09:27:24 spandhe: thanks for asking 09:27:33 so implementation 09:27:47 does anyone have anything more on implementation? 09:27:52 nope 09:27:58 not from me 09:28:00 anteaya: thanks for giving me the opportunity :) 09:28:13 spandhe: glad to have your participation 09:28:17 okay moving on 09:28:23 #topic documentation 09:28:37 obondarev: you did your part here, thank you 09:28:43 * gus apologises for arriving late. 09:28:44 not much to update on the docs side 09:28:51 yes 09:28:56 actually let's go back 09:28:59 #undo 09:29:00 Removing item from minutes: 09:29:06 gus: hello 09:29:21 gus: anything to share in the specs/implementation topics? 09:30:14 I put up a new revision a few hours ago that addresses all the comments so far. 09:30:38 gus: yes thank you 09:30:42 In particular, it now says that we won't deal with cells in this spec, but we expect that to be a followup. 09:31:10 gus: i.e. in L cycle? 09:31:16 belmoreira: we talked this morning about that 09:31:36 belmoreira: and understanding that to move forward we need to focus on the simplest use case 09:31:55 but I am talking with alaski who is one of the authors of cells 09:32:13 and working on figuring out what we can do for your situation, belmoreira 09:32:19 jlibosva: It's possible, but I doubt it. It will need some more discussion/involvement from interested parties to make sure we do it in a way that is most useful, and we'll need some much better testing environments than we typically have available (devstack won't cut it). 09:32:23 anteaya: thank you 09:32:31 whether it is within this initiative or outside it 09:32:41 belmoreira: we are thinking of you, by all means 09:33:07 we just need to figure out how to keep the migration path moving forward as well, as it has stalled in teh past 09:33:28 gus: makes sense. thanks 09:33:28 so in short, the spec is saying simplest use case 09:33:48 we are providing some tools which we invite deployers to take and expand to fit their needs 09:34:16 folks who work with us and have specific needs, such as cern and cells, we will work with to find a path forward 09:34:26 but that won't make everyone happy 09:34:44 so we are telling folks that we know that 09:34:50 to set reasonable expectations 09:35:16 make sense? 09:35:34 anteaya: I think is very reasonable 09:35:39 totally 09:35:40 belmoreira: thank you 09:35:45 spandhe: great thank you 09:35:54 gus: thanks for your input 09:36:00 any more now that gus is here? 09:36:05 or back to documentation? 09:36:23 moving on 09:36:32 #topic documentation 09:36:40 back again 09:36:55 so obondarev thank you here, emagma has said he will lead this 09:37:09 the difficulty is the meeting time, which I don't expect him ever to make 09:37:11 anteaya: awesome! 09:37:24 anteaya: where is he located? 09:37:28 I get up in the middle of the night but I don't expect others from north america to do so 09:37:31 anteaya: indeed, we talked about it with him too 09:37:36 ah 09:37:37 jlibosva: in texas I think 09:37:58 and I got an email from somone named chris cannon who also said he wants to help 09:38:09 which is awesome but he is in north america as well 09:38:11 anteaya: so if we can have an alternate time for this meeting that would be good I think 09:38:20 just like we have for neutron team meeting 09:38:25 so I'm sill looking for somone to attend meetings 09:38:32 obondarev: I'd like to avoid that acutally 09:38:53 as disruption in the meeting time reduces effectiveness for the transition period 09:39:04 anteaya: I see 09:39:06 this time works for russia, australia and eu 09:39:11 which is why I picked it 09:39:27 let's just proceed and hope someone from docs is able to attend meetings 09:39:28 anteaya: should we find a compromise then? 09:39:55 obondarev: do you want to ping emagma and ask him what he needs to get started on the docs process? 09:40:12 I think just ensuring somone talks to emagma is our best way forward 09:40:21 obondarev: if you would do that, that would be great 09:40:26 anteaya: agree 09:40:30 anteaya: sure I can 09:40:35 great, thank you 09:40:47 anything more for docs? 09:40:58 #topic testing (belmoreira) 09:41:09 belmoreira: anything to say here? 09:41:29 As ops point of view for now I don't have nothing 09:41:34 okay great 09:41:37 I'll proceed 09:41:40 I have something to discuss/think about 09:41:51 oh okay, jlibosva go ahead 09:42:00 Do we plan to test particular tools? 09:42:06 good question 09:42:10 let me share something 09:42:15 as I was working with db things, I think some real big bunch of data would be helpful 09:42:27 jlibosva: ah I see 09:42:43 jlibosva: well mikal and jhesketh do test data 09:42:55 with their db datasets ci 09:43:21 jlibosva: so it might be possible to chat with jhesketh to see how they work with real data 09:43:30 anteaya: is it the turbo-hipster or something else? 09:43:33 and utilize their approach if possible 09:43:40 turbo-hipster 09:43:43 ok, I'll try to reach out to him 09:43:50 which has the name db datasets ci 09:44:03 jlibosva: thank you, I think that would be a good first step 09:44:15 and at the nova midcycle we discussed testing 09:44:19 anteaya: ok, thank you too for the info 09:44:28 jlibosva: sure 09:44:48 mikal is at nova midcycle, jhesketh is still here in .au if you want me to ask him tomorrow. 09:44:48 and one suggestion is to package up the tools and let deployers test them 09:44:55 and incorporate feedback 09:45:07 (I feel bad I have no idea how my colleagues' tool works) 09:45:08 gus: yes thank you that would be awesome 09:45:15 gus: ha ha ha 09:45:26 will do. 09:45:28 working in -infra I had to get over that long ago 09:45:31 :) 09:46:15 so belmoreira you mentioned this morning/yesterday to me that you could test the db migration and proxy once you see some code 09:46:19 belmoreira: yes? 09:46:52 spandhe: would you be able to do the same? 09:46:53 the proxy it will be easier to test 09:47:04 belmoreira: great, I'll take what I can get 09:47:04 testing is going to be awkward generally for this project, given that the usual devstack/grenade tests aren't so useful (multi-node devstack testing isn't quite ready yet). 09:47:07 anteaya: yup.. 09:47:16 spandhe: great thank you 09:47:32 data migration, I'm still checking how can we do it 09:47:41 gus: yes, I think we are going to have to stumble through testing until we reach a happy place amoungst ourselves 09:47:54 belmoreira: great, well don't keep your findings a secret 09:48:15 belmoreira: once you learn anything, do share so we can figure out how to get the support to make it happen 09:48:38 gus: and yes multi-node did come up today 09:48:42 anteaya: sure 09:48:57 gus: which we are working on but yes, isn't there yet 09:49:00 belmoreira: thank you 09:49:38 so for testing, basically we have to have some code and then try some things and share what we tried and keep going until we decide it is good enough 09:49:58 which isn't great for satisfying the spec, but I don't know what else to suggest at this point 09:50:16 * jhesketh is here 09:50:23 hello jhesketh 09:50:27 (trying to catchup on context) 09:50:41 jhesketh: the tl;dr is we would like your input on testing data migrations 09:51:04 jhesketh: you being the turbo-hipster dude, we were hoping you might have some wisdom to share 09:51:28 tl;dr answer would be it's worth doing 09:51:37 jhesketh: that is good 09:51:45 and worth knowing thank you 09:51:48 not necessarily as a 3rd party CI, but at the very least before you upgrade so you know how long it'll take 09:51:51 want to be able to test a db migration tool on largish amounts of data. wondering what your experience is re getting access to that, privacy, etc. 09:52:25 turbo-hipster is designed in ways to make it difficult to get data out, I did a talk on that at the summit 09:52:27 let me find a link 09:52:46 * jlibosva remembers the talk from Atlanta 09:52:49 https://www.youtube.com/watch?v=VeoUpmPim8c 09:52:55 oh, well, not much has changed 09:53:04 #link https://www.youtube.com/watch?v=VeoUpmPim8c 09:54:08 so jlibosva perhaps you can watch/re-watch that video and follow up with jhesketh if you have questions? 09:54:24 and of course, anyone else as well 09:54:44 jhesketh: thank you 09:54:49 if we have large nova-net volunteers, then we could set up a similar 3rd party CI migration test. We have the additional complication that verifying the neutron version matches the nova-net version is itself an interesting exercise. 09:55:06 jhesketh: I reserve a slot in your time schedule :) 09:55:09 true 09:55:32 so we have more to discuss on the testing front 09:55:54 let's all keep that in mind as we move forward and bring questions and comments to next week's meeting 09:55:56 fair? 09:55:59 we should be able to do a round trip: migration tool -> nova-neutron-proxy -> back to something that matches the same nova API. 09:56:01 I have still question, how to validate neutron db is correct 09:56:17 jlibosva: ah, another good question 09:56:26 gus: that sound reasonable 09:56:27 specifically vif migrations 09:56:27 we'll need additional testing from the neutron pov however. 09:57:07 hmmmm, more thought needed here 09:57:29 can we capture these thoughts, questions in the spec comments at all? 09:57:37 ack 09:57:45 #link https://review.openstack.org/#/c/142456/ 09:57:46 jlibosva: I can't think of any magic answers here - I think we'll just need to add the usual unittests to cover cases we foresee while writing the code as best we can. 09:58:15 gus: yes, let's start with what we can do and expand from there 09:58:37 gus: I don't think UT would be useful here as it validates implementation. We're more interesting in making sure the actual mapping between two databases is correct. The implementation is not that crucial 09:59:15 jlibosva: is there anyone else doing what you think needs to be done? 09:59:25 can we copy a current effort at all? 09:59:42 time to wrap up 09:59:42 jlibosva: Agreed. I don't know how to do that without writing some other new code that will be based on the same possibly incorrect assumptions however :/ 10:00:04 let's comment in the testing section of https://review.openstack.org/#/c/142456/8/specs/kilo/migration-from-nova-net.rst 10:00:08 yeah 10:00:17 and talk more about testing next week 10:00:21 anteaya: I was just thinking loud, I'll try to bring it to specs 10:00:28 please review the latest spec 10:00:35 jlibosva: of course, and thank you 10:00:38 :) 10:00:47 great meeting everyone, thank you! 10:00:52 see you next week 10:00:54 yep, suggest things for the spec and I'll attempt to merge them. 10:00:58 #endmeeting