Re: default network space

[John Meinel]

So at the moment, I don't think Juju supports what you're looking for,
which is cross model relations without public addresses. We've certainly
discussed supporting all private for cross model. The main issue is that we
often drive parts of the firewalls (security groups) but without
understanding all the routing, it is hard to be sure whether things will
actually work.

I do believe the intended resolution is to use juju relate --via X, and
then X can be a space that isn't public. I'm pretty sure we don't have
everything wired up for that yet, and we want to make sure we can get the
current steps working well.

The very first thing I noticed in your first email was that charms should
*not* be aware of spaces. The abstractions for charms are around their
bindings (explicit or via binding their endpoints). The goal of spaces is
to provide human operators a way to tell charms about their environment.
But you shouldn't ever have to change the name of your space to match the
name a charm expects.

So if you do 'network-get BINDING -r relation' that should give you the
context you need to coordinate your network settings with the other
application. The intent is that we give you the right data so that it works
whether you are in a cross model relation or just related to a local app.

John
=:->


On Oct 13, 2017 19:59, "James Beedy"  wrote:

I can give a high level of what I feel is a reasonably common use case.

I have infrastructure in two primary locations; AWS, and MAAS (at the local
datacenter). The nodes at the datacenter have a direct fiber route via
virtual private gateway in us-west-2, and the instances in AWS/us-west-2
have a direct route  via the VPG to the private MAAS networks at the
datacenter. There is no charge for data transfer from the datacenter in and
out of us-west-2 via the fiber VPG hot route, so it behooves me to use this
and have the AWS instances and MAAS instances talk to each other via
private address.

At the application level, the component/config goes something like this:

The MAAS nodes at the data center have mgmt-net, cluster-net, and
access-net, interfaces defined, all of which get ips from their respective
address spaces from the datacenter MAAS.

I need my elasticsearch charm to configure elasticsearch such that
elasticsearch <-> elasticsearch talk on cluster-net, web server (AWS
instance) -> elasticsearch to talk across the correct space for the AWS
instance, and the access-net space for the MAAS instance (I'm thinking this
is where bindings and '--via' might come in handy).

(I know the openstack charms have to make similar network mitigation, for
which they use the bindings, I must just be looking at it backwards, or not
looking into network bindings which are the key here I think)

For example, my web server charm in AWS will be deployed to a NAT
space/subnet, and will only get a private ip from the AWS subnet. It needs
to give the ip to elasticsearch (deployed in MAAS), and to a loadbalancer
(deploy to different model and space in the same AWS VPC) - this all seems
like there should be no issues with getting it to happen because the web
server charm only has a single ip address to be handing out, but what I'm
after here is a consistent way to be able to retrieve this information at
the charm level - but I think what you are telling me is that if I use the
functionality correctly, then I won't have to do any mitigating at the
charm/network-get level.

Looks like I need to take a deeper dive into the network bindings at the
charm level and see how that functionality fits into the bigger picture to
make the whole picture make sense.

Thanks



> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about
> public
> vs private addresses in terms of what to put into relation data - the other
> remote unit should not be exposed to things in those terms.
>
> There's some doc here to explain things in more detail
>
> https://jujucharms.com/docs/master/developer-network-primitives
>
> The TL;DR: is that charms need to care about:
> - what address do I bind to (listen on)
> - what address do external actors use to connect to me (ingress)
>
> Depending on how the charm has been deployed, and more specifically
> whether it
> is in a cross model relation, the ingress address might be either the
> public or
> private address. Juju will decide based on a number of factors (whether
> models
> are deployed to same region, vpc, other provider specific aspects) and
> populate
> the network-get data accordingly. NOTE: for now Juju will always pick the
> public
> address (if there is one) for the ingress value for cross model relations
> - the
> algorithm to short circuit to a cloud local address is not yet finished.
>
> The content of the bind-addresses block is space aware in that these are
> filtered based on the space with which the specified endpoint is
> associated. The
> 

Re: default network space

[John Meinel]

So at the moment, I don't think Juju supports what you're looking for,
which is cross model relations without public addresses. We've certainly
discussed supporting all private for cross model. The main issue is that we
often drive parts of the firewalls (security groups) but without
understanding all the routing, it is hard to be sure whether things will
actually work.

I do believe the intended resolution is to use juju relate --via X, and
then X can be a space that isn't public. I'm pretty sure we don't have
everything wired up for that yet, and we want to make sure we can get the
current steps working well.

The very first thing I noticed in your first email was that charms should
*not* be aware of spaces. The abstractions for charms are around their
bindings (explicit or via binding their endpoints). The goal of spaces is
to provide human operators a way to tell charms about their environment.
But you shouldn't ever have to change the name of your space to match the
name a charm expects.

So if you do 'network-get BINDING -r relation' that should give you the
context you need to coordinate your network settings with the other
application. The intent is that we give you the right data so that it works
whether you are in a cross model relation or just related to a local app.

John
=:->


On Oct 13, 2017 19:59, "James Beedy"  wrote:

I can give a high level of what I feel is a reasonably common use case.

I have infrastructure in two primary locations; AWS, and MAAS (at the local
datacenter). The nodes at the datacenter have a direct fiber route via
virtual private gateway in us-west-2, and the instances in AWS/us-west-2
have a direct route  via the VPG to the private MAAS networks at the
datacenter. There is no charge for data transfer from the datacenter in and
out of us-west-2 via the fiber VPG hot route, so it behooves me to use this
and have the AWS instances and MAAS instances talk to each other via
private address.

At the application level, the component/config goes something like this:

The MAAS nodes at the data center have mgmt-net, cluster-net, and
access-net, interfaces defined, all of which get ips from their respective
address spaces from the datacenter MAAS.

I need my elasticsearch charm to configure elasticsearch such that
elasticsearch <-> elasticsearch talk on cluster-net, web server (AWS
instance) -> elasticsearch to talk across the correct space for the AWS
instance, and the access-net space for the MAAS instance (I'm thinking this
is where bindings and '--via' might come in handy).

(I know the openstack charms have to make similar network mitigation, for
which they use the bindings, I must just be looking at it backwards, or not
looking into network bindings which are the key here I think)

For example, my web server charm in AWS will be deployed to a NAT
space/subnet, and will only get a private ip from the AWS subnet. It needs
to give the ip to elasticsearch (deployed in MAAS), and to a loadbalancer
(deploy to different model and space in the same AWS VPC) - this all seems
like there should be no issues with getting it to happen because the web
server charm only has a single ip address to be handing out, but what I'm
after here is a consistent way to be able to retrieve this information at
the charm level - but I think what you are telling me is that if I use the
functionality correctly, then I won't have to do any mitigating at the
charm/network-get level.

Looks like I need to take a deeper dive into the network bindings at the
charm level and see how that functionality fits into the bigger picture to
make the whole picture make sense.

Thanks



> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about
> public
> vs private addresses in terms of what to put into relation data - the other
> remote unit should not be exposed to things in those terms.
>
> There's some doc here to explain things in more detail
>
> https://jujucharms.com/docs/master/developer-network-primitives
>
> The TL;DR: is that charms need to care about:
> - what address do I bind to (listen on)
> - what address do external actors use to connect to me (ingress)
>
> Depending on how the charm has been deployed, and more specifically
> whether it
> is in a cross model relation, the ingress address might be either the
> public or
> private address. Juju will decide based on a number of factors (whether
> models
> are deployed to same region, vpc, other provider specific aspects) and
> populate
> the network-get data accordingly. NOTE: for now Juju will always pick the
> public
> address (if there is one) for the ingress value for cross model relations
> - the
> algorithm to short circuit to a cloud local address is not yet finished.
>
> The content of the bind-addresses block is space aware in that these are
> filtered based on the space with which the specified endpoint is
> associated. The
> 

Re: Relation scope clarification

[Stuart Bishop]

On 18 October 2017 at 02:21, John Meinel  wrote:

> Ah, I guess that telegraf is actually gathering extra data from mysql or
> postgres about database specific stats, and thus it should have a container
> scoped relation because it wants to explicitly sit with postgres and collect
> general machine information, as well as collect postgres specific
> information. It isn't that telegraf is using postgresql as its data store,
> its that it knows how to get extra statistical information about a database.
>
> In that case, telegraf *should* use a container scope for its postgresql
> interface. I wonder how that works when you have HA postgres, and each
> telegraf connection to postgres is at least logically different. (telegraf
> should care very much that it never connect to the postgresql on a different
> machine and get its information.)

In the current implementation, the 'subordinate' telegraf has access
to the master so it can connect to it and create the resources in the
database that it needs (if some other unit hasn't already beaten it
too it).

If a container scoped relation is used, the subordinate telegraf would
need to create the database resources if it happens to be connected to
the master, or wait until some other subordinate creates them if not.

Either way, my original query remains.

Is it allowed to relate charms with one end declaring the scope as
global and the other end declaring the scope as container?

If yes, should a PostgreSQL unit still be able to see the relation
data from its peers, even if it is related to a charm declaring the
relation as container scoped? Or should charms avoid inspecting
relation data of peer units because it will fail in this case?


> Is this a case where we actually need postgresql to offer up a
> "pgsql-monitoring" relation, rather that use the existing "store my data in
> postgres, 'pgsql' relation"
> ?

If mismatched relations are not allowed (one end declaring global, but
the other end disagreeing and declaring container), then I can provide
a separate relation, yes. It might also be the simplest solution, as
having the PostgreSQL charm share relation connection details from
master to standbys via the peer relation instead of the client
relation is fairly invasive.

-- 
Stuart Bishop 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Nagios - Additional Contacts via Juju

[Lee Harrison]

Hi,

I am running nagios revision 21 to monitor my OpenStack deployment and want to 
extend the defined contacts and groups, but doesn't appear to be a way via Juju?

The 'admin_email' section in juju config is a string so I create a file with my 
additional contacts defined and ran 'juju config nagios 
admin_email=@nagios_contacts' and it did add it to the juju config ok and 
updated the '/etc/nagios3/conf.d/contacts_nagios2.cfg' file with the contact 
details. The Nagios service then failed to restart and investigating I found 
that juju also updated the '/etc/nagios3/nagios.cfg' with the additional 
contact in the same section as the admin_email and admin_pager entries so the 
service failed to parse that cfg file.

After testing I know adding additional contact details to the 
'/etc/nagios3/conf.d/contacts_nagios2.cfg' file works fine but then if the 
jujud service ever gets restarted then Juju will remove the additional contacts 
(to replace with whatever is shown from juju config Nagios admin_email).

Question:
How do I create additional contacts, and for that matter groups, in Nagios via 
Juju?

Thanks,

Lee

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju