16:01:19 <Sukhdev_> #startmeeting ironic_neutron
16:01:20 <openstack> Meeting started Mon Jul 11 16:01:19 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:21 <TheJulia> o/
16:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:23 <davidlenwell> o/
16:01:25 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:45 <hshiina> o/
16:01:48 <Sukhdev_> We'll for a minute to give others time to join in
16:02:54 <Sukhdev_> jroll sambetts devananda: are you here?
16:03:11 <Sukhdev_> #topic: Agenda
16:03:19 <Sukhdev_> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_July_11.2C_2016
16:03:54 <Sukhdev_> I kept the previous agenda - as we did not have a meeting last week
16:04:29 <sambetts> o/
16:04:38 <TheJulia> jroll is not available today
16:04:47 <Sukhdev_> If anybody wants to add to the agenda, feel free to add
16:04:56 <Sukhdev_> TheJulia : thanks for update
16:05:04 <Sukhdev_> lets keep going in that case
16:05:22 <Sukhdev_> #topic: Announcements
16:05:22 <devananda> o/
16:05:47 <Sukhdev_> We skipped last week's meeting and I missed the previous week's
16:06:00 <sambetts> I think the biggest Annoucement of all is we missed the nova FF with a major patch to get the networking stuff done
16:06:27 <TheJulia> 297895?
16:06:31 <Sukhdev_> sambetts : I noticed that
16:06:44 <sambetts> TheJulia: yup
16:06:57 <Sukhdev_> sambetts : what happened? I thought it was going to go in -
16:07:50 <TheJulia> It seems like ironic can navigate around the issue though, since essentially there is already a bug in the behavior that wouldn't change nova setup/configuration in a production deployment.  I think ironic just needs to see if the port already exists, delete it in neutron, and then re-create it as part of the deployment process.
16:08:18 <mjturek1> I thought it was said during mid-cycle that we weren't aiming for nova feature freeze anymore? sorry if I misunderstood
16:08:56 <sambetts> mjturek1: we thought we didn't have any patches that would affect the current work, but it seems like we missed one :(
16:09:06 <mjturek1> dang :(
16:09:20 <TheJulia> visibility was not raised until last week :(
16:10:18 <sambetts> My concern is that I'm not sure if the code already merged in nova might cause us problems too, because the code already merged is actually incorrect now too
16:10:19 <Sukhdev_> and, I take it nova does not allow exceptions
16:10:34 <sambetts> Sukhdev_: they wouldn't give us one because we didn't have the Ironic stuff merged
16:10:40 <sambetts> as I understand it
16:11:01 <TheJulia> sambetts: good point, but I thought it was minimal, I'm likely wrong though
16:11:26 <devananda> sambetts: can you elaborate on "the code already merged is actually incorrect" ?
16:12:09 <sambetts> devananda: we already have code in Nova that expects the network_provider field, and none instead of network_interface and flat
16:12:28 <sambetts> devananda: https://review.openstack.org/#/c/297895/3/nova/virt/ironic/driver.py
16:12:38 <sambetts> its a update patch
16:12:47 <sambetts> :/
16:13:06 <TheJulia> is it just network_binding_host_id ?
16:13:45 <Sukhdev_> sambetts: I do not believe that is incorrect code, is it?
16:14:36 <sambetts> it might be safe, because of the getattr, but its looking for a field name that doesn't exist anymore
16:15:51 <Sukhdev_> I do not see that patch merged though - did it merge as a part of different patch?
16:17:27 <TheJulia> https://github.com/openstack/nova/commit/0e6e28aed74e8029e394bb16298436a239c7192e is where initial support went in to nova
16:17:34 <TheJulia> Just that link to provide the diff view
16:19:18 <Sukhdev_> TheJulia : yes - that is the correct one -
16:21:09 <Sukhdev_> the one sambetts pointed out modifies this merged code - and, I have tested it - but, I do not believe it is merged
16:21:16 <devananda> is the problem that, in ironic, it was decided to use a different field name inthe API, since that patch merged in Nova? (or have I misunderstood the issue?)
16:21:34 <devananda> s/network_provider/network_interface/ ?
16:22:01 <TheJulia> devananda: pretty much, plus ironic is coded to expect no network to possibly be attached, correct or not, upon the beginning of deployment
16:22:05 <sambetts> devananda: right, a different field name in the API and a different stevedore name for the network interface that represents the existing network support
16:22:18 <sambetts> s/none/flat
16:23:05 <lazy_prince> o/
16:23:35 <Sukhdev_> sambetts : so, I tested everything with this patch - did not test without patch - so, perhaps, it may be problematic
16:24:31 <Sukhdev_> so, I wonder if we merge ironic patches and go back to nova folks for exception on the basis that the merged code may be broken, we may be able to get one -
16:24:52 <Sukhdev_> jroll is guy I rely on for nova communications - wish he was here to answer
16:25:24 <sambetts> TBH as the orignal patch is merged, and its all our code is designed to be backwards compatible (as far as I can see) with the getattr etc I don't see why we shouldn't be allowed to merge it with the Ironic side changes, (although that puts us in the same situation as before in regards to thinks might change)
16:26:41 <lazy_prince> sambetts: which patch has merged..?
16:26:59 <Sukhdev_> lazy_prince: the link posted by TheJulia
16:27:07 <sambetts> lazy_prince: https://github.com/openstack/nova/commit/0e6e28aed74e8029e394bb16298436a239c7192e
16:27:15 <lazy_prince> aha..
16:27:47 <Sukhdev_> sambetts : so, I think we may have a shot, if we can get ironic stuff merged -
16:28:12 <sambetts> jroll is going the nova midcycle on the 19th of July, so I think we might need to work hard to get the ironic side merged to give him the best shot to convice them to give us a FFE
16:28:35 <Sukhdev_> that leads me to next point - how come we did not merge the ironic patches ?
16:29:00 <Sukhdev_> sambetts : right that gives us a week to get ironic stuff merged -
16:29:33 <lazy_prince> yeah.. i have the same question.. whats taking so long for the patches.. its almost three cycles..
16:29:53 <Sukhdev_> what is barrier to get ironic patches merged - they have gone through so many revs
16:30:13 <sambetts> So there was a couple of things that delays the patches again, the first was that we've changed the Ironic port model a little to support this logic better, Ironic ports now have an internal_info field to hold the data about ports created by Ironic, that merged pretty fast
16:31:02 <lazy_prince> is there anything else..?
16:31:04 <sambetts> there is currently some contention on the patch adding network_interfaces because of how it plays with the driver reform Ironic is currently working on
16:31:19 <TheJulia> That is an agenda itemf or the next ironic meeting
16:31:40 <sambetts> For reference: https://review.openstack.org/#/c/285852/63/ironic/common/driver_factory.py
16:31:43 <sambetts> #link https://review.openstack.org/#/c/285852/63/ironic/common/driver_factory.py
16:33:27 <Sukhdev_> so, folks how do converge on these? - we have really gone through these so many times - we should not keep holding and keep making changes -
16:33:51 <sambetts> other delays include the problems highlighted when trying to run this new code in Ironic standalone mode, which I hope are resolved now, and that Ironic wanted to have grenade upgrade testing before merging any of this code
16:34:02 <sambetts> which is done too
16:34:57 <Sukhdev_> TheJulia: are you planning on discussing the plan to merge these patches in ironic meeting?
16:35:12 <TheJulia> AFAIK we are
16:36:52 <Sukhdev_> sambetts : as you had suggested once, perhaps we can set up a chat session for people to dial in and go over these to get merged?
16:38:02 <sambetts> Yeah I think it might be worth trying to organise a time and place to sync and push these in
16:38:26 <sambetts> by place I mean the Jitsi audio call thing
16:38:44 <TheJulia> agreed
16:38:46 <Sukhdev_> right - if that makes things move...
16:39:26 <Sukhdev_> we have to do it this week
16:39:56 <TheJulia> It should, we just need to come to a consensus, and land what we have, and iterrate from there
16:40:18 <Sukhdev_> TheJulia : +1
16:40:31 <sambetts> +1 the only think out of all of it thats hard to interate on is the API
16:40:34 <sambetts> thing*
16:41:24 <Sukhdev_> sambetts : what is the contention over api?
16:41:37 <TheJulia> sambetts: Agreed, in the next meeting, lets discuss identifying a time to get on a call in the next day or two to work through the items
16:42:15 <sambetts> right now there is contention over whether network_interfaces should be known as network_interfaces or not which affects how its represented in the API
16:43:45 <sambetts> because we have a new concept of *_interfaces coming, which is why we wanted to call them network_interfaces in the first place, but there are some new interactions between *_interfaces and the concept of a hardware_type we're adding which don't fit very well for the network_interfaces
16:45:12 <Sukhdev_> network will be always needed - so, the contention is to call it network_interface or something else?
16:45:17 <sambetts> the main one being that hardware_type have vendor specified defaults for each of the *_interfaces (power/managemnt) etc but network_interfaces are very environment specific and only in some cases (e.g. my out of tree driver) hardware specific
16:47:04 <devananda> sambetts: huh. also, network interface doesn't depend on the server's OOB management device in the same way that, say, power, RAID, etc do
16:47:31 <sambetts> devananda: my out of tree one will but I'm special
16:47:47 <devananda> network_interface could vary by server, but is logically decoupled from the physical server (expcet special cases where it isn't)
16:47:59 <sambetts> exactly
16:48:11 <Sukhdev_> exceptions do not set the rules - I believe we will always need network
16:48:58 <sambetts> Sukhdev_: its not that we won't always need network, its that vendors can not set sane defaults on a hardware_type because its dependant on the environment its deployed in
16:49:50 <Sukhdev_> I see these two as orthogonal items - (perhaps I am missing something)
16:49:51 <sambetts> and for all the other *_interfaces vendors set a sane/recomended default interfaces which is using unless overridden by the operator using Ironic
16:50:16 <sambetts> (sorry that was terrible english)...
16:50:40 <TheJulia> That won't be quite true with storage/boot from volume so there are some in which it makes sense, and some it does not, and it seems like we've already discussed that being the case
16:50:59 <TheJulia> (sorry for being slow responding, was on a call until a moment ago)
16:51:40 <devananda> TheJulia: good point. this affects more than just network_interface
16:51:57 <sambetts> :'(
16:52:29 * Sukhdev_ time check 8 min
16:52:45 * devananda notices that the meeting topic is still "announcements"
16:53:12 <Sukhdev_> devananda : oppss...my fault - too late now :-)
16:55:12 <Sukhdev_> TheJulia : is the ironic meeting right after this meeting?
16:55:21 <sambetts> Yup, in openstack-meeting3
16:55:29 <sambetts> Hopefully we can unsick this in the main Ironic meeting
16:55:59 <Sukhdev_> Yup I will stick around
16:56:12 <Sukhdev_> #topic Open Discussion
16:56:29 <Sukhdev_> devananda : ha ha I changed the topic :-)
16:56:42 <sambetts> I believe this problem (no easy sane default) is the origial reason we it so network_interfaces had to be set on node create, and there was no default
16:56:51 <sambetts> we made it so*
16:59:19 <Sukhdev_> didn't we used to have flat network as default?
16:59:42 <lazy_prince> or the default from config file...?
17:00:09 * devananda goes over to the other room to get ready for hte next meeting
17:00:23 <sambetts> I believe that we ended up with flat if you used an old client if I remember correctly
17:00:41 <Sukhdev_> time is up for this meeting - lets move over to other room
17:00:45 <sambetts> ++
17:00:53 <Sukhdev_> thanks for attending this meeting
17:00:55 <Sukhdev_> bye
17:00:59 <sambetts> o/
17:00:59 <Sukhdev_> #endmeeting