deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Koper, Dies" <di...@fast.au.fujitsu.com>
Subject RE: cimi network support
Date Wed, 29 May 2013 13:07:30 GMT
Hi Marios,

> yes, cimi_network <--> dcloud_subnet and cimi_forwarding_group
> <-->dcloud_network is exactly the mapping I had in mind; I'm not sure
> how well it will work and there may be some tweaks required (e.g.
adding
> any missing attributes to the models).

I've summited a PR with these mappings. I only added a mandatory
attribute for networkType (PRIVATE/PUBLIC).
We can add more later if there are backends that can populate them.

One issue I wasn't sure how to resolve (left a TODO) was the reference
from cimi networks to forwarding groups.
DC subnets have a reference to DC networks, but a requirement for
forwarding groups is that they have multiple networks (forwarding groups
don't forward to themselves), so I can only populate this reference if I
can be sure that there is at least one other subnet pointing at the same
network. Which may require some additional calls to the backend to
check.
As the attribute is optional, I'd like to exclude it from this PR leave
it to you to take a look at later :)

Also, I'm not sure about the serialization of the forwarding group.
The cimi spec says about its networks attribute:
A reference to the list of references to the Networks in this Forwarding
Group.
The phrase "A reference to the list of references" is also used for
System's subcollections (system machines, etc.). E.g. <networks
href="http://localhost:3001/cimi/forwarding_groups/group1/networks"/>
But the json and xml schema seem to indicate multiple references to the
networks inlined.

"networks": [
  { "href": string }, +
], ?

E.g.
   <network href="http://localhost:3001/cimi/networks/N-DMZ" />
   <network href="http://localhost:3001/cimi/networks/N-SECURE1" />

I haven't checked Mantis and I'm working from the pdf so maybe this has
been addressed already.

> well, not sure about that. I think cimi_net_port <-->
> dcloud_net_interface could work, though we'd need to add a couple of
the
> mandatory attributes to the net_interface, like state, type and
> classOfService which are missing.

Hmm.. When I looked at network ports a few months ago I thought fgcp
didn't have an equivalent, but reading the spec again, it does look like
a good match for what I mapped to DC network interfaces.
I may look at that after this PR's been accepted.

Cheers,
Dies


> -----Original Message-----
> From: marios@redhat.com [mailto:mandreou@redhat.com]
> Sent: Tuesday, 28 May 2013 6:19 PM
> To: Koper, Dies
> Cc: dev@deltacloud.apache.org
> Subject: Re: cimi network support
> 
> On 28/05/13 00:36, Koper, Dies wrote:
> > Hi Marios,
> >
> Hi!
> 
> > When you mentioned network support is still on DC's roadmap I assume
> > fixing cimi network support was what you had in mind.
> 
> not sure which exchange you are referring to exactly ;) but yes, that
> is
> definitely one part of 'network_support'. The other is to see how
'sane'
> the current networks mapping/implementation is and also document it.
> This last part and documentation in general (e.g. update website
install
> instructions, tidy up the api etc) is something I plan to spend some
> time on in the coming weeks, though progress will likely be slow due
to
> other pressing commitments.
> 
> >
> > As I understand it, we had cimi network (and related collections)
> > support, implemented at least for mock.
> > You then added Deltacloud network support, using the same method
name
> > (networks), breaking cimi network because the driver now has two
methods
> > with the same name.
> 
> right
> 
> >
> > I looked at fixing it. As it turned out a bit more complicated that
> I
> > thought (ran into a weird backtrace again), I thought I'd first
check
> > with you how you thought it should be implemented.
> > And is this something you've already started working on and I'd
better
> > wait for you to complete that?
> 
> no, this isn't something I'm currently working on. It is however
> something that I want to look at, when I can. However if you've got
the
> traction to get into it now, please go ahead.
> 
> >
> > I thought we could map cimi networks to DC subnets (i.e. delete all
> the
> > cimi network operations and yaml files from mock driver) as we do
for
> > machines and instances.
> > Also, I thought we could map cimi forwarding groups to DC networks
that
> > have more than one subnet.
> 
> yes, cimi_network <--> dcloud_subnet and cimi_forwarding_group
> <-->dcloud_network is exactly the mapping I had in mind; I'm not sure
> how well it will work and there may be some tweaks required (e.g.
adding
> any missing attributes to the models).
> 
> >
> > If I understand correctly, cimi network ports are not equivalent to
> DC
> > network interfaces, so for cimi network ports we'd keep the current
> > network_ports methods in the drivers.
> 
> well, not sure about that. I think cimi_net_port <-->
> dcloud_net_interface could work, though we'd need to add a couple of
the
> mandatory attributes to the net_interface, like state, type and
> classOfService which are missing.
> 
> all the best, marios
> 
> >
> > Is that what you had in mind?
> >
> > Regards,
> > Dies Koper
> >
> 



Mime
View raw message