16:01:04 #startmeeting ironic_neutron 16:01:05 Meeting started Mon Sep 14 16:01:04 2015 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:09 The meeting name has been set to 'ironic_neutron' 16:01:18 #topic: Agenda 16:01:25 #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_September_14.2C_2015 16:02:01 Folks, the agenda is more towards the testing and integration today - 16:02:18 feel free to add anything that you would like to discuss in addition 16:02:32 So, lets dive into this 16:02:39 #topic: Announcements 16:02:51 Ironic soft FF is this week 16:03:03 jroll: can you elaborate on this? 16:03:32 Sukhdev: we aren't merging anything remotely risky after thursday 16:03:45 in preparation for the integrated liberty release next thursday 16:04:22 so does that mean we are targeting Mitaka..? 16:04:32 jroll: I added to the agenda a topic about merging some of the patches 16:04:33 and we've decided these patches are already too risky to merge at this point 16:04:37 I saw 16:04:39 lazy_prince: yes 16:05:18 ack.. 16:05:25 Lets discuss later in the meeting - if we can have some patches merged (if we feel we are ready) 16:05:50 jroll: thanks for clarification 16:06:05 #topic: Integration Test Status 16:06:24 As you all know I have been trying to test end-to-end all of our patches 16:06:41 I have posted my findings on the etherpad - at the bottom 16:06:55 #link: https://etherpad.openstack.org/p/ironic-neutron-mid-cycle 16:07:11 I do not know if you had a chance to look at it yet 16:07:19 * lazy_prince will address some of those in next patchsets.. 16:07:50 I added validation to the api layer today 16:07:52 I noticed yhvh pushed couple of updated patches this morning 16:07:54 needs review 16:08:25 yhvh: yup - saw them this morning - will test them in the next go 16:08:50 for 194413, do we have a patch to update the node object with network_provider attribute..? 16:09:23 I was planning to do that later but looks like I will need to do it soon.. 16:10:34 lazy_prince: which one is 194413? 16:10:39 I haven't done it, I thought that was part of one of the existing patches :( 16:11:36 jroll: I will address that in my patch.. Anyways, I have a todo in patch to get it done.. 16:12:36 lazy_prince: presently, I have hard coded that value to make forward progress so that I can test the rest of the stuff 16:12:37 ok 16:12:57 lazy_prince: I forgot to list that in my list of findings :-):-) 16:13:04 Sukhdev: good to know that its not a blocker for you.. 16:13:05 lazy_prince: thanks for looking into this 16:13:33 lazy_prince: because, I could hard code the value :-):-) 16:14:12 lazy_prince: BTW, in the comments, it says somewhere that the it should be set to neutron - which tripped me 16:14:34 lazy_prince: later I discovered it should be neutron_plugin - that made it work :-) 16:14:43 However, I had discussion with jroll on gate failure for the cleaning port stuff... do we want to discuss that now or shall i bring it later..? 16:15:04 lazy_prince: This is good time 16:16:28 aha.. so I was thinking that we write a flat_neutron_provider for now to make the gates work which will imitate the existing behaviour and let the gates pass.. 16:17:03 hmm 16:17:14 and that would be "neutron dhcp + flat network"? 16:17:36 and 'none' would be "don't manage dhcp + flat network"? 16:17:56 yup.. as in current form, neither none nor neutron_plugin will work for cleaning port stuff.. 16:18:14 fwiw, the gate is basically testing for backwards compatibility right now, as it uses the existing method 16:19:05 lazy_prince: does 'none' still create ports and such for the provisioning network? is there a reason we can't do the same for cleaning network? 16:19:09 this way everyone will be happy I guess and we will not break responsibility distribution to dhcp plugin and network provider plugin.. 16:19:36 devananda: ^ you may be interested in this conversation, btw 16:19:37 none does not create the ports.. 16:19:45 * devananda lurks 16:19:59 lazy_prince: oh, because nova does it 16:20:02 :/ 16:20:27 yes.. and the assumption is that none will be used in non-vlan environment.. 16:20:56 right, but we still need to be able to clean in that environment 16:22:09 yeah.. so in that case, we need to update the none (Noop) provider to actually do the flip for cleaning-network.. 16:22:39 yeah, I think that's the best route, rather than a new provider 16:22:43 which is against Noop driver as it is supposed to do no operation.. :) 16:23:10 leave the cleaning port creation in the dhcp stuff, and then pass the ports it creates to the network provider interface to be updated 16:23:17 (and either no-op or add physical port info) 16:23:43 I am wondering how will the neutron side behave... 16:24:26 Sukhdev: ^^ 16:24:44 * Sukhdev digesting the discussion 16:25:38 lazy_prince: in terms of? 16:25:45 it should behave fine, I don't see why not 16:25:58 when dhcp will create the port, it will still need the local_link_information... as the mech driver will need it... 16:26:02 what I suggested is equivalent to what we do for tenant networks between ironic and nova 16:26:07 I am thinking the same way as jroll - it should be fine 16:26:14 nova creates the port without local link info, and then we update it 16:26:16 this is the same thing 16:27:23 okay.. got it... 16:27:26 yup - keep in mind, when you do not set the local link information, also, ensure to set the host_id to none 16:28:07 currently, when you issue nova boot - I see original call from nova to neutron does not have local-link information 16:28:27 and later in the subsequent call it comes in - 16:28:35 right.. 16:29:33 so when dhcp provider creates the port, it would create the port without host id and without local_link_info... 16:29:52 jroll: Oh BTW, one more issue I noticed (which I forgot to log) - when host_id is not set, we need to still set the vnic_type to "baremetal' - I noticed this is not set 16:30:23 Sukhdev: right, I never made a patch like that, I thought you wrote that patch? 16:30:36 and when the call comes to network provider, depending on the network provider, it will populate the host id and local_link_info.. 16:30:50 lazy_prince: correct 16:31:23 and if that network_provider happens to be noop, then it only populates the host id.. 16:31:29 jroll: my patch makes the neutron/nova API interface happy, it actually does not set the vnic_type 16:31:39 Sukhdev: oh, ok 16:31:48 lazy_prince: yep 16:32:13 lazy_prince: actually, hrm, I think we should only not populate host_id when using the neutron providr 16:32:25 because, as you said, noop provider shouldn't touch neutron 16:33:09 if we do that, gates will still fail as the devstack does not populates the local_link-info for the ports.. 16:33:31 erm, network provider should default to none 16:33:47 and we should have another job at some point that tests this with the neutron provider 16:35:00 yup.. but then in a valid use case, with dhcp provider should populate the lli, so that neutron_plugin can set the host_id.. 16:35:32 right, we'll need to add code to devstack to do that, and create a job that triggers it 16:35:48 I hope we should not end up with one provider setting up only hostid and the other adding hostid and lli.. 16:36:34 jroll lazy_prince: Is either one of you tracking or planning on this? 16:37:04 Sukhdev: you can put action on me.. 16:37:56 #action: lazy_prince to look into gate and devstack related cleanup 16:37:59 I will come up with a write up and circulate around the dev list.. to make sure what we agreed on.. 16:38:04 lazy_prince: done :-) 16:38:26 Sukhdev: ty 16:38:28 lazy_prince: please add a link to the etherpad as well - 16:38:35 Sukhdev: sure.. 16:39:02 lazy_prince: when are you planning on pushing the updated patches? 16:39:22 Sukhdev: as soon as I have them ready.. :) 16:39:35 i saw yhvh pushed updated patches - I will update my environment only when all of these ready - 16:39:46 it is takes too much time to get everything going :-):-) 16:40:06 lazy_prince: ha ha -- that really helps me with planning :-):) 16:40:48 i will look for emails and act accordingly 16:40:49 I was held up with something else last week.. Will take some time out this week to get the patches rolling out.. 16:41:04 lazy_prince: cool - thanks 16:41:18 anything else we want to discuss on this topic? 16:41:53 #topic: patch merge decision 16:42:03 I added this topic for the sake of discussion - 16:42:17 now that we know we are not going to make it in Liberty - 16:42:40 I though we discuss if it make sense to merge some of our patches - 16:42:57 in Liberty? 16:43:06 jroll: yes 16:43:24 anything which does not impact the main functionality 16:43:41 the first few aren't terribly useful without the rest, IMO 16:43:47 and the first patch is failing unit tests 16:44:19 yeah.. and even if we merge, what use they would serve without the others.. 16:44:24 right 16:44:32 jroll: I bring it from the patch management point of view - 16:44:39 I don't want to spend reviewer time on it if it isn't useful 16:45:15 If you want to test anything you have to deal with applying all the patches - I was thinking if some of these merge (the ones which will not impact the baseline) 16:45:34 then we have less number of patches to manage and continue to test forward 16:45:58 my point is, if we merge half solution, it may create confusion among users... 16:45:59 sure, but it doesn't make sense from a project perspective 16:46:08 it would be odd to have this stuff in the DB/API and not usable 16:46:36 (not to mention (again) that these are failing tests so we can't merge them anyway) 16:46:43 and again, reviewer time is a rare commodity 16:46:46 +1 16:47:03 jroll lazy_prince: understood - hence, I wanted to just discuss only :-) 16:47:14 yep 16:47:19 OK - in that case, we will put this discussion to rest 16:47:25 I think I should move those tests later in the patchset 16:48:11 yhvh: it's also existing tests failing 16:48:25 e.g. FAIL: ironic.tests.api.v1.test_ports.TestPost.test_create_port 16:48:28 ah kk I will look into it 16:49:03 Are any of you testing these patches as well? 16:49:04 yhvh: it's a wsme thing, lucasagomes might be able to help you, he's aware of why this happens 16:49:37 jroll: ty 16:50:02 np 16:50:07 Sukhdev: me.. 16:50:31 lazy_prince: can you please log your findings at the etherpad (at the bottom) as well? 16:50:52 but as I said, I have not been able to spend much on this... 16:51:07 will do if i find anything obvious.. 16:51:19 lazy_prince: cool 16:51:39 (Time check: 9 mins ) 16:51:49 lazy_prince: thanks 16:52:04 I am mostly done with what I wanted to discuss 16:52:19 #topic: Open Discussion 16:52:23 whats the update on docs.. 16:52:40 lazy_prince: no update - this part is lagging 16:53:08 who was supposed to be getting started on that? 16:53:15 well.. okay.. since we have moved to Mitaka, we have more time now... 16:53:44 umm.. some one from Japan, I guess.. I do not remember his name.. 16:53:53 jroll: akihiro had volunteered for neutron side - but, he had family emergency - I have not been able to track him 16:54:11 ah 16:54:16 lazy_prince: pshige_ maybe? 16:54:27 no amotoki 16:54:42 yes.. amotoki 16:54:56 We do not have any volunteer for the Ironic side of documentation 16:55:37 oh 16:55:50 in the neutron side, we have a core responsible for documentation, and we coordinate with him - do we have something similar on the Ironic side? 16:56:19 pshige_ is our docs liasion, but I'd love it if we had someone else responsible for writing the docs on this 16:56:23 I can be the one for ironic 16:56:35 \o/ 16:56:39 thanks cragusa. 16:56:41 cragusa: perfect - shall I assign to the action? 16:56:46 yes 16:57:02 cragusa: let us know if you need more info on this.. 16:57:10 as is for 16:57:21 sorry about that, sure I will 16:57:26 #action: cragusa to work on documenting Ironic-Neutron integration in Ironic documentation 16:57:46 info as in how it works/what to document etc.. 16:57:54 what deadline do we have being now for Mitaka? 16:58:12 probably M1 16:58:20 we should shoot for M1 16:58:24 milestones aren't a thing in ironic 16:58:26 let's say ASAP :) 16:58:33 jroll: +1 16:58:44 :) 16:58:49 cragusa: basically I'd like to land docs around the same time as the code 16:59:05 sure, will do that 16:59:06 a bit later is fine 16:59:11 docs are published from master anyway 16:59:28 cragusa: we are here to help - feel free to ping us 16:59:38 sure, thanks 16:59:43 * Sukhdev 1 min left 16:59:53 Anything else? 17:00:05 time is up - 17:00:17 bye.. 17:00:22 thanks for attending folks, this was very productive discussion 17:00:23 bye 17:00:24 bye 17:00:27 #endmeeting