Re: default network space
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
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
On 18 October 2017 at 02:21, John Meinelwrote: > 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
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