Open Stack

On 11/06/2012 11:58 PM, Ian Wells wrote:
> On 6 November 2012 19:39, Gary Kotton<gkotton at redhat.com>  wrote:
>> GET /network-implementation-details/<net-id>
> A minor quibble, but these commands will probably change the state on
> the host that you're getting an attachment for for (or, at least, it
> would the way I would do it - you do the call, and e.g. a bridge pops
> up and Nova knows where to find it by the return of the call).  If
> that's the case, it is a POST rather than a GET as you're creating
> something.

I need to update the blueprint. The idea in general is to have something 
like

GET /port/<id>/binding
and
PUT /port/<id>/binding/<something>

This will enable the information to be passed to Quantum.

>
> I'm sure you could do it the other way around (GET the details of how
> to connect to the network and then do the work in Nova to make an
> endpoint that the hypervisor could use) but I prefer that the work of
> buggering about with the networking remained entirely within Quantum.
> This seems eminently sensible for PCI passthrough in particular, where
> the call would hand over the details of the card to be attached and
> return that it had been attached - versus bridge creation, where you'd
> probably say 'give me a bridge' and be told the details of the
> arbitrarily named bridge you'd just had created.

I would hope that the above PUT command enables Nova to provide this 
information to Quantum.

Each plugin has its way of allocating and managing the resources. Some 
may be done via agents, others may be done directly in Nova. It is allo 
debatible whether this is good or bad. At this stage I would like to 
provide an API that can ensure that we have our bases covered for the 
interim period and the long run.

>
> The options seem to be:
>   - be explicit about which port we're attaching (and, presumably, that
> a port can only be attached once)
>   - implicitly create a port iff you attach to a network, use an
> existing port otherwise
>   - drop ports altogether, or replace them with these attachments that
> we're talking about right now (get a 'realised' attachment point and
> you have effectively added a port to the network, after all).
>