Comment 9 for bug 1459567

>
> Actually that would not have been a problem (my team maintains this
> charm); this will be eased once we move to the subordinate approach
> we're about to land into neutron-api - your relations would just be
> found on the subordinate charm only.

Well to add all the functionality required to the neutron-api charm, we
will have to add a plumgrid specific template file to your
BASE_RESOURCE_MAP dictionary
inside neutron-api/hooks/neutron_api_utils.py. Along with that I ll have to
add three functions to the same file to get all PLUMgrid related
configuration pushed. In the next patch I am pushing in changes to enable
KILO support aswell, which will require even more changes. Isnt it possible
to let this version of the charm run like this and just as your team comes
up with the new way for plugins I can shift to that directly?

OK - so right now you have to explicitly target neutron-iovisor to
> every other service unit that requires this feature; that's not great
> from an end user perspective as they have to know todo that.

A subordinate charm will grown alongside its principle, meaning that as
> soon as its related, juju just takes care of things from that point on -
> I still think neutron-iovisor falls into this category.

You are definitely right about it not being user friendly. It was our main
concern when we started charming.
The only real problem we have with the subordinate charm approach is that
we *do not* require plumgrid-edge running on a compute node *ONLY*. there
are use cases where our director or gateway is also running on the compute
node, which are going to be impossible to deploy if either one of these
three charms is a subordinate charm of nova-compute.

The problem with creating neutron-iovisor as the subordinate is that I need
iovisor on other nodes aswell. Like my node which has all the base services
running inside lxcs, which i call the controller node. I usually create my
director on that node.

In terms of your standalone requirement, I'd suggest that you switch to
> a subordinate approach and just deploy neutron-iovisor with the 'ubuntu'
> charm as the principle charm.

I have been using the ubuntu charm as the principle charm but If
neutron-iovisor is a subordinate charm of nova-compute, how can I deploy it
on to the ubuntu node?

On Mon, Jun 29, 2015 at 3:59 PM, James Page <email address hidden> wrote:

> Hi Bilal
>
> "> I'd still like to understand why your proposing to provide access to the
> > plumgrid director via configuration and not a relation - as plumgrid-
> > director is charmed, this seems like an obvious thing todo.
>
> Re: That was my first approach to this but I left it out because for that
> we would have to add a relation in the neutron-api charm to get the
> virtual_ip from plumgrid-director charm. I doubt that the maintainers of
> the charm would let me add that as other plugins aren't either"
>
> Actually that would not have been a problem (my team maintains this
> charm); this will be eased once we move to the subordinate approach
> we're about to land into neutron-api - your relations would just be
> found on the subordinate charm only.
>
> ">What's the scope of having this charm deployed by itself? I'd like to
> > understand the use cases.
>
> RE: in some of our use cases we require iovisor-dkms on the node only. That
> is why we went with this architecture of the charms.
>
> Do the director, edge and gateway charms get deploy on separate servers
> > normally or do they all reside on a single server.
>
> They get deployed on seperate servers but require neutron-iovisor charm to
> be deployed on the server aswell."
>
> OK - so right now you have to explicitly target neutron-iovisor to
> every other service unit that requires this feature; that's not great
> from an end user perspective as they have to know todo that.
>
> A subordinate charm will grown alongside its principle, meaning that as
> soon as its related, juju just takes care of things from that point on -
> I still think neutron-iovisor falls into this category.
>
> In terms of your standalone requirement, I'd suggest that you switch to
> a subordinate approach and just deploy neutron-iovisor with the 'ubuntu'
> charm as the principle charm.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1459567
>
> Title:
> PLUMgrid charm - neutron-iovisor - review required
>
> Status in Juju Charms:
> Incomplete
>
> Bug description:
> Review is required for neutron-iovisor charm
>
> https://code.launchpad.net/~plumgrid-team/charms/trusty/neutron-iovisor/trunk
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+bug/1459567/+subscriptions
>

--
Bilal Baqar
MTS - PLUMgrid Inc.
<http://bit.ly/1I0EhyF>