A new development release of Juju, 2.1-beta4, is here!

[Merlijn Sebrechts]

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 <john at arbash-meinel.com>:

> On Sat, Jan 7, 2017 at 12:43 AM, Merlijn Sebrechts <
> merlijn.sebrechts at 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
> =:->
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170112/78026939/attachment.html>