Re: 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 :

> 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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

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

[John Meinel]

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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

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

[Rick Harding]

You will notice this is beta4 vs the rc1 we had been working toward.

Part of 2.1 is an improvement to juju container networking that corrects
issues that many users are facing. This updates Juju to only create bridges
on a host machine only when a container is placed on the host and only for
the specific network interfaces that the container needs to function. This
code has been moving along and has been demonstrated to work properly when
used correctly.

However, in working to complete those changes it came up that we're missing
the ability to specify the correct network spaces that the application and
thus the container need to be on in the current bundle spec and format. We
support specifying on a per-endpoint basis with the changes done in Juju
2.0, however there's not a key to set the default value the charm wants to
use for any hook/endpoint that it leverages. These updates will hold the
RC1 while those are updated and landed.

If anyone is curious and would like to try out the new networking container
behavior please try out the feature branch that the work is taking place in
here:

https://github.com/juju/juju/tree/2.1-dynamic-bridges

We refer to this as dynamic bridging because the changes cause bridges to
be dynamically generated as required based on direct spaces information.

If you have any questions please let me know.

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