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