Thanks for the info! Seeing as you're working on these features now, I'll explain how we'd like to use such a feature.
We're using MAAS. All the servers are connected to the MAAS control network (cnet) using one interface. That interface also has a VLAN that is connected directly to the internet. We have a very limited set of publicly addressable ip's for the VLAN so we can't just give all servers a public ip on that VLAN. So by default, no server should receive a public ip. The server should only receive a public IP when we specify it explicitly using a constraint. Moreover, we want to specify that containers on a specific server should get a public ip, even if the server itself doesn't have a public ip. What we do for the moment is to manually give a bunch of servers a public IP in MAAS and request those servers using constraints. However, this gives us a fixed set of servers with public IPs and there is no way of specifying what containers should get a public IP. We'd like to do this more dynamically, and we'd like to be able to create containers with a public IP on machines that do not have a public IP themselves. Is this something that will be possible? 2017-01-07 6:12 GMT+01:00 John Meinel <j...@arbash-meinel.com>: > On Sat, Jan 7, 2017 at 12:43 AM, Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: > >> Some questions, because this sounds like something perfect for us. >> >> Does this work on MAAS or only openstack? >> >> Does this mean that I can put the constraint "has to be connected to >> network x" on an application and this will cause the container to be >> connexted to that network? >> >> Any more info/docs on this feature? >> >> > There is a little bit of documentation here: > https://jujucharms.com/docs/2.0/charms-deploying#deploying-with-binding > https://jujucharms.com/docs/2.0/charms-bundles#binding- > endpoints-of-applications-within-a-bundle > https://jujucharms.com/docs/2.0/network-spaces > > The feature is intended to be supported across all providers (MAAS, > openstack, aws, etc). However, it does need a bit of implementation for > each one, as we have to map our primitives into what that means on the > given providers. The current work is focused on making the experience on > MAAS very good, as Openstack charms deploying on MAAS is one of the first > places where we're making heavy use of the feature. > > Our goal is to implement at least basic support for spaces across all > providers for the 17.04 timeframe (so that you can request specific > instances/applications to be only in a group of subnets that you've > defined). Having containers supported on all providers is a bit of a > stretch, as we have to worry more about how the provider has faked the > network stack. > > We have support already for spaces and containers on MAAS in 2.0, however > there has been some feedback that the particular implementation is > non-ideal, which is why we're changing it a bit. (Specifically, in 2.0 we > put containers into all spaces that the host is part of, the work we're > doing is to only put them into the spaces that they need based on bindings > and machine constraints.) > > John > =:-> > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
