Open Stack

Greetings, Comments in-line.

Thanks,

-Julia

On Sat, Sep 29, 2018 at 11:27 PM Moshe Levi <moshele at mellanox.com> wrote:

> Hi Julia,
>
>
>
> I don't mind to update the ironic spec [1]. Unfortunately, I wasn't in the
> PTG but I had a sync meeting with Isuku.
>
>
>
> As I see it there is 2 use-cases:
>
>    1. Running the neutron ovs agent in the smartnic
>    2. Running the neutron super ovs agent which manage the ovs running on
>    the smartnic.
>
>
My takeaway from the meeting with neutron is that there would not be a
neutron ovs agent running on the smartnic. That the configuration would
need to be pushed at all times, which is ultimately better security wise if
the tenant NIC is somehow compromised it reduces the control plane exposure.


>    1.
>
>
>
> It seem that most of the discussion was around the second use-case.
>

By the time Ironic and Neutron met together, it seemed like the first use
case was no longer under consideration. I may be wrong, but very strong
preference existed for the second scenario when we met the next day.


>
> This is my understanding on the ironic neutron PTG meeting:
>
>    1. Ironic cores don't want to change the deployment interface as
>    proposed in [1].
>    2. We should  a new network_interface for use case 2. But what about
>    the first use case? Should it be a new network_interface as well?
>    3. We should delay the port binding until the baremetal is powered on
>    the ovs is running.
>       1. For the first use case I was thinking to change the neutron
>       server to just keep the port binding information in the neutron DB. Then
>       when the neutron ovs agent is a live it will retrieve all the baremeal port
>       , add them to the ovsdb and start the neutron ovs agent fullsync.
>       2. For the second use case the agent is alive so the agent itself
>       can monitor the ovsdb of the baremetal and configure it when it up
>    4. How to notify that neutron agent successfully/unsuccessfully bind
>    the port ?
>       1. In both use-cases we should use neutron-ironic notification to
>       make sure the port binding was done successfully.
>
>
>
> Is my understanding correct?
>
>
> Not quite.

1) We as in Ironic recognize that there would need to be changes, it is the
method as to how that we would prefer to be explicit and have chosen by the
interface. The underlying behavior needs to be different, and the new
network_interface should support both cases 1 and 2 because that interface
contain needed logic for the conductor to determine the appropriate path
forward. We should likely also put some guards in to prevent non-smart
interfaces from being used in the same configuration due to the security
issues that creates.
3) I believe this would be more of a matter of the network_interface
knowing that the machine is powered up, and attempting to assert
configuration through Neutron to push configuration to the smartnic.
3a) The consensus is that the information to access the smartnic is
hardware configuration metadata and that ironic should be the source of
truth for information about that hardware. The discussion was push that as
needed into neutron to help enable the attachment. I proposed just
including it in the binding profile as a possibility, since it is transient
information.
3b) As I understood it, this would ultimately be the default operating
behavior.
4) Was not discussed, but something along the path is going to have to
check and retry as necessary. That item could be in the network_interface
code.
4a) This doesn't exist yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181001/0187789d/attachment.html>