16:03:08 <Sukhdev> #startmeeting ironic_neutron
16:03:09 <viveknarasimhan> Sukhdev: Good morning
16:03:09 <openstack> Meeting started Mon Jun 15 16:03:08 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:12 <openstack> The meeting name has been set to 'ironic_neutron'
16:03:20 <lazy_prince> o/
16:03:37 <Sukhdev> #topic: Agenda
16:03:43 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron
16:04:07 <Sukhdev> #topic: Announcements
16:04:24 <Sukhdev> Folks, we have two specs which are looking very good
16:04:44 <Sukhdev> thanks to jroll and lauramoore for pushing the updated versions
16:05:06 <Sukhdev> I see lots of people left some good comments
16:05:27 <Sukhdev> I just wanted to go over these specs quickly
16:05:42 <Sukhdev> And, also want to ask if anybody wants to add anything to the agenda?
16:06:25 <Sukhdev> #topic: Network Flip spec
16:06:31 <Sukhdev> #link: https://review.openstack.org/#/c/187829/
16:07:20 <Sukhdev> jroll: can you spend few minutes to address your concern about the API?
16:08:01 <Sukhdev> did others have opportunity to review it?
16:08:16 <Sukhdev> jroll is in two meetings :-)
16:08:29 <viveknarasimhan> Sukhdev: can we add neutron-side questions to the agenda
16:08:49 <Sukhdev> viveknarasimhan: what do you in mind?
16:09:25 <jroll> Sukhdev: 1) I need to think about it more :)
16:10:18 <viveknarasimhan> Sukhdev: we can take that after discussing prime Ironic things in this meeting
16:10:51 <Sukhdev> viveknarasimhan: sounds good
16:12:47 <Sukhdev> jroll: still waiting for your 2) :-)
16:14:21 <Sukhdev> lazy_prince: did you have a chance to review the updated version of the specs?
16:14:38 <jroll> Sukhdev: oh, I take back the 2) :P
16:14:44 <lazy_prince> yes.. i did.. and it looks good to me..
16:15:02 <Sukhdev> jroll: ah ha - you fooled me :-)
16:15:17 <amotoki> very basic question from a newbie of ironic on 'NetworkProvider' driver in the net-flip spec. When is this driver called?
16:15:24 <jroll> sorry Sukhdev :P
16:15:50 <lazy_prince> network provider :)
16:17:12 <Sukhdev> amotoki: jroll can give more precise answer, my understating is during deploy phase,
16:17:47 <Sukhdev> amotoki: prior to the local boot of node
16:17:48 <lazy_prince> aha.. when.. okay.. here is the answer..
16:17:54 <amotoki> I am a neutron guy and need to study more... I just wonder when new methods are called in the procedure of launcing instance.
16:18:34 <lazy_prince> first.. before image is deployed on server..
16:19:03 <lazy_prince> and second, after the server is provisioned..
16:20:08 <Sukhdev> jroll: anything specific you want to talk about API?
16:20:19 <lazy_prince> during first part, the node will be connected to the provisioning network (where server can PXE boot and reach ironic APIs..
16:20:50 <jroll> Sukhdev: no, I need to think on it more. it will be similar, let's focus on any other questinos etc
16:21:15 <lazy_prince> during second part, it will be connected to the tenant network where there will be no connectivity to PXE and Ironic APIs.
16:22:10 <viveknarasimhan> lazy_prince: For the initial connectivity on the provisioning network, Neutron is not involved right?
16:22:21 <lazy_prince> it is...
16:22:37 <Sukhdev> viveknarasimhan: in both cases, neutron is involved
16:22:45 <spandhe> lazy_prince: maybe from somewhere here? https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/pxe.py#L290
16:22:50 <amotoki> viveknarasimhan: the provisioning network is a neutron network.
16:22:56 <viveknarasimhan> In the first case do we take action, I mean neutron takes any action?
16:22:57 <lazy_prince> jroll: why do we need two different network for cleaning and provisioning.. ?
16:23:07 <viveknarasimhan> wouldn't bind-requested be False in the first boot
16:23:08 <Sukhdev> viveknarasimhan: yes
16:23:30 <jroll> lazy_prince: some deployers may want that as untrusted machines are coming into cleaning. could be configured to be the same network, though
16:24:06 <amotoki> in my understanding, we can use a same network for provisioning and cleaning, but we can use separate networks.
16:24:28 <lazy_prince> jroll: then someone should configure that in the config file.. right..?
16:24:44 <lazy_prince> jroll: is that captured in the spec..?
16:24:52 <jroll> lazy_prince: correct. maybe? not sure :)
16:25:19 <Sukhdev> lazy_prince: I thought I saw cleaning network in the spec
16:25:49 <selvakumar_s> lazy_prince line no 198 it is mentioned
16:25:50 <amotoki> but I see only one config (provisioing_network) now
16:26:39 <jroll> please note that on the spec so I can fix it :)
16:26:45 <Sukhdev> amotoki: you may want to leave a comment there - I think it should be there as well
16:27:05 <amotoki> Sukhdev: sure. I just know the spec and am reading it now :-)
16:27:13 <lazy_prince> Sukhdev: thats for provisioning network. we are talking about cleaning network.. i left a comment on the spec.
16:27:17 <jroll> Sukhdev: ok, I'm clear of my other meeting now, you have my full attention :)
16:27:44 <Sukhdev> jroll: cool - thanks
16:28:01 <Sukhdev> lazy_prince: good
16:28:40 <Sukhdev> jroll: lazy_prince: so, if the deployer wants to you use cleaning network, then we are switching between three networks
16:28:53 <Sukhdev> i.e. provisioning, cleaning and tenant network
16:29:08 <jroll> Sukhdev: yes. cleaning happens after "nova delete". shouldn't be a problem.
16:29:22 <Sukhdev> All three should be in the config - if not already there
16:29:33 <jroll> tenant network should not be in config, but yes I get what you mean :)
16:29:37 <amotoki> two should be in the config.
16:29:50 <jroll> and lazy_prince fwiw cleaning_network is already in the config, maybe that's why I didn't add it to the spec
16:30:36 <Sukhdev> jroll: Oh in that case, you can just clarify for the new readers :-)
16:30:44 <jroll> Sukhdev: indeed
16:30:58 <lazy_prince> is it so...? Sorry if i missed it.. but as of now, there is no network switching in ironic. i wonder how is it being done today..
16:31:34 <jroll> lazy_prince: it's used to set up dhcp for cleaning things. generally assumed to be the same network as the provisioning/tenant networks
16:32:14 <jroll> lazy_prince: since usually nova initializes the ports used for provisioning network
16:32:16 <jroll> lazy_prince: https://github.com/openstack/ironic/blob/master/ironic/dhcp/neutron.py#L52
16:32:28 <lazy_prince> aha.. i get it now..
16:32:49 <Sukhdev> jroll: on a flat network, they will be all same, right - that is what you mean?
16:32:54 <amotoki> ah.. got it.
16:33:05 <jroll> Sukhdev: yes
16:33:18 <jroll> but ironic needed to know what that network was somehow
16:34:35 <Sukhdev> So, jroll, this spec looks pretty good to me, hence I gave it a +1
16:35:05 <lazy_prince> I will change my vote then..
16:35:19 <Sukhdev> most of the discussion is essentially clarifications
16:35:28 <jroll> ok great
16:35:33 <jroll> still need ironic people to review it more :)
16:35:43 <Sukhdev> devananda: are you here?
16:36:01 <Sukhdev> jroll: yes, we need ironic cores to bless it
16:36:18 <Sukhdev> jroll: may be nova folks too
16:36:39 <jroll> Sukhdev: I'll talk to nova folks about it
16:36:44 <jroll> don't think it should be a big deal
16:36:49 <jroll> and will mention it in ironic meeting
16:37:05 <Sukhdev> jroll: cool - thanks
16:37:20 <Sukhdev> Anything else on this spec?
16:37:33 <Sukhdev> Any other questions/clarifications?
16:37:48 <Sukhdev> Please leave comments on the spec so that jroll can clear it up
16:37:53 <jroll> ++
16:38:13 <Sukhdev> Shall we move to next spec?
16:38:26 <Sukhdev> #topic: Port connectivity spec
16:38:30 <Sukhdev> #link: https://review.openstack.org/#/c/188528/2
16:38:46 <Sukhdev> Laura or Bertie are not here
16:38:55 <lauramoore> Sukhdev, I just joined
16:39:02 <lauramoore> apologies for being late
16:39:07 <Sukhdev> lauramoore: perfect timing :-)
16:39:26 <Sukhdev> This spec looks good as well
16:39:44 <lauramoore> so first off, thanks to everyone who has commented so far, i'm just going through the comments now
16:40:19 <Sukhdev> I did not see any show stopper
16:40:34 <amotoki> I think it looks good in general.
16:40:48 <amotoki> regarding neutron side, I am thinking to define a new field for a neutron port to pass physical information rather than using a binding:profile in Neutron.
16:40:50 <jroll> so I reviewed this shortly before the meeting, and it's looking good so far. just lots of questions from me, but nothing major :)
16:41:08 <viveknarasimhan> amotoki: +1
16:41:13 <amotoki> binding:profile was originally introduced to allow vendor drivers to use it freely and the field has no schema check.
16:41:24 <amotoki> Thus I think it is better to define a new attribute with a schema definition.
16:41:25 <viveknarasimhan> This information is going to expand in the future
16:42:00 <viveknarasimhan> amotoki: the new field could be used by mech-drivers to claim a physical port to bind
16:42:14 <amotoki> viveknarasimhan: yes
16:42:16 <Sukhdev> amotoki: I had detailed discussion on this topic - and decided that we should proceed with the proposed model
16:42:18 <jroll> amotoki: while I tend to agree with more strict schemas, there's two things here: 1) this info may not be the same for all drivers, and 2) we're trying not to modify core neutron things unless we really need to.
16:42:40 <viveknarasimhan> amotoki: I also saw that existing mech-drivers that donot support physical ports, can tag on this and Unclaim serving the port
16:43:00 <Sukhdev> amotoki: We can discuss this in the neutron meeting - but, I have already covered it somewhat
16:43:13 <amotoki> jroll: agree. at least we need to define the same level of API definitions as we define in Ironic API.
16:43:13 <viveknarasimhan> Sukhdev:  we can proceed with binding-profile for this release for rolling out
16:43:35 <Sukhdev> amotoki: You are referring to new resource label model, this requires more thinning an hardening
16:43:48 <viveknarasimhan> Sukhdev: but as we build more capabilities in Ironic and neutron, this would be better off treated as separat column in Port model of neutron
16:44:20 <amotoki> Sukhdev: i don't necessarily think about resource label model, but it is one option.
16:45:02 <Sukhdev> viveknarasimhan, amotoki : there are few issues with any of those models and I articulated those in a different meeting
16:45:03 <amotoki> we can simply define a new attribute in port:binding (or another) neutron extension.
16:45:24 <Sukhdev> viveknarasimhan amotoki : unless we harden those, we do not want to risk this integration -
16:45:43 <amotoki> it does not affect Ironic spec and the spec discusses what information are needed.
16:46:04 <Sukhdev> the interface to the neutron (from Ironic side) is very simple and clean and information can be dumped into any field in the future -
16:46:14 <viveknarasimhan> Sukhdev: yes we discussed ramifications and neutron rpprovals required for new extensions
16:46:25 <Sukhdev> but, it has ramifications on the neutron core, ML2 plugin and ML2 drivers
16:46:27 <amotoki> Sukhdev: agree. we are clarifying what are needed.
16:46:58 <viveknarasimhan> Sukhdev:  we can probably pursue the expansion in next release ... and pursue binding_profile for vlan-provisioning in Liberty
16:47:34 <jroll> I agree that we should continue to think about it for the future and go with binding_profile for now.
16:48:02 <Sukhdev> amotoki: binding profile was designed for this kind of information - adding additional field will be almost same, isn't it?
16:48:03 <viveknarasimhan> Sukhdev, amotoki: one more point on neutron side to put on is mech-driver claiming
16:48:51 <viveknarasimhan> since VLAN is widely supported in neutron today by all mech-drivers, it becomes imperative to fix such mech-drivers to ignore binding physical -ports on VLAN network
16:49:12 <viveknarasimhan> except for those mech-drivers that woudl want to serve Ironic
16:49:19 <Sukhdev> viveknarasimhan: actually, it will be fully backward compatible -
16:49:35 <amotoki> Sukhdev: binding:profile was designed for free area, so i personally want not to apply a specific data model for biding profile.
16:49:41 <Sukhdev> no body uses binding profile
16:50:03 <Sukhdev> amotoki: understood -
16:50:03 <amotoki> hehe.... mellanox driver use it.
16:50:25 <lauramoore> hi Sukhdev, can i also raise the issue of security of info in binding-profile - do we need an additional way of securing it?
16:50:43 <Sukhdev> amotoki: there is one (i was trying to finish my sentence :-)) -
16:51:26 <amotoki> lauramoore: could you elaborate more?
16:51:38 <Sukhdev> amotoki: it is used to pass the physical connectivity information
16:51:56 <Sukhdev> lauramoore: did not understand security related issue
16:51:56 <viveknarasimhan> Sukhdev: in our POC's we saw OVS claiming the ironic port and failing binding
16:52:08 <viveknarasimhan> when we reorder the mech drivers from hP to top, things went fine for Ironic ports
16:52:30 <viveknarasimhan> so that is somehting I thought to share here :)
16:53:15 <Sukhdev> viveknarasimhan: that is interesting data
16:53:46 <lazy_prince> we do not have much time left..
16:53:46 <lauramoore> i mean if it contains a switch port id (eg Ethernet 3/14) we don't want a user to be able to change it to say the next switch port id (eg Ethernet 3/15) because that could have a different customer server attached
16:53:57 <Sukhdev> viveknarasimhan: all drivers are invoked in the order they are registered - so, this is a deployment issue
16:54:14 <lauramoore> so i was wondering about security settings in neutron regarding updates to port binding profile
16:54:37 <amotoki> lauramoore: in the default neutron configuration, binding:profile information is avaialble only to admin (which is defined in policy.json).
16:54:49 <lauramoore> i don't know enough about this so thought to ask
16:55:26 <lauramoore> amatoki: ok, so it should only be changeable by admins
16:55:34 <amotoki> even if we define a new field (or other thing), we need to have the similar default setting.
16:55:38 <amotoki> lauramoore: yes.
16:55:56 <amotoki> and it is only visible to admin.
16:56:25 <lauramoore> ok thanks
16:56:30 <Sukhdev> amotoki: thanks for clarification
16:56:37 * Sukhdev time check
16:56:50 <amotoki> I think viveknarasimhan has an item.
16:57:02 <Sukhdev> viveknarasimhan: please shoot
16:57:20 <viveknarasimhan> Sukhdev: I did discuss the item... ordering of mech drivers
16:57:47 <Sukhdev> viveknarasimhan: ah good - then we are covered - you understood my answer, right?
16:57:59 <lazy_prince> in my opinion, it should not be left on the deployer..
16:58:02 <amotoki> viveknarasimhan: we need to clarify what are the cause of the problem you had.
16:58:30 <viveknarasimhan> Sukhdev: yes..  only thing is deployer should order them right when ironic comes into play which as you said is deployment concern.
16:58:42 <Sukhdev> lazy_prince: ML2 plugin simply loops throughout the list of registered drivers and invokes them
16:58:50 <viveknarasimhan> one more thing to add
16:59:10 <viveknarasimhan> the mech-driver in neutron for Ironic will claim port based on presence
16:59:24 <lazy_prince> i guess, we should handle it in a better way.. can we handle if from inside the mech driver,, some flag let know that it should skip it..
16:59:26 <viveknarasimhan> of switch-id in binding-profile ,, if that is the right approach?
16:59:47 <jroll> we pass a binding type of ironic
16:59:48 <Sukhdev> viveknarasimhan: based upon Bind_request flag
16:59:58 <jroll> could use that or something. dunno.
17:00:02 <lazy_prince> k..
17:00:33 <Sukhdev> Folks, we are out of time
17:00:36 <viveknarasimhan> Sukhdev: ok
17:00:43 <jroll> thanks everyone :)
17:00:46 <Sukhdev> thanks for joining us - this was a great discussion
17:00:48 <lauramoore> thankyou
17:00:55 <amotoki> thank you
17:01:00 <Sukhdev> I will move over to neutron channel and we can continue there
17:01:02 <Sukhdev> bye
17:01:04 <viveknarasimhan> Sukhdev: i perceive Bind_request flag is unique for Ironic and so all th emech-drvers would tag on it
17:01:05 <lazy_prince> thank you.. bye..
17:01:05 <Sukhdev> #endmeeting