Standard Vlan list

[Mark Shuttleworth]

Rather than standardise VLANs, which would be brittle to share, we can
standardise the names of common 'spaces' in Juju / MAAS networking
terminology.

Having, for example, a list like:


 * dmz - a space that includes machines which can also bind directly to
internet routable addresses
 * pcidss - a space that is PCI-DSS secure
 * internal - a catchall for non-internet address space
   ...

If we had a standard set of those used in bundles, then it becomes easy
to have very reusable deployments with shared bundles, because people
just need to either tag their own spaces with the same names or map them
at runtime from the bundle name to the space they want to use in their
own MAAS.

Mark

On 12/04/17 07:41, Brett Mackinga wrote:
> Hi all
>
> Thank you for letting me know a newbie can ask questions here, very
> much a fan.
>
> Went through the old "4 part of 5" from Dimiter Naydenov's blog and
> realised how to start to deal with networking in MAAS.
>
>
> Wow with MAAS and Juju you dev guys have control of the whole stack.
> really amazing....
>
>
> So I wonder with with 4094 vlans available and the ability to
> identify the proper vlans needed for real bundles like openstack,
> hadoop etc. I wonder if you have thought to standardize the Vlan list
> like they did with ports back in the day?
>
> I would also like to know if there is/we can create a mode in MAAS
> where if someone opts-in for a fully MASS-JUJU stack we can have MAAS
> auto-configure the hosts interfaces that join based on the bundle they
> choose to use?
>
> The reason I ask it that it is very clear that MAAS already knows the
> information of the interfaces  involved and the speeds they run at.
>
>
> I personally envisage it to be something like
>
>
> Vlan                         Bundle                            Vlan
> name    Vlan description
>
> 2001                        Openstack                      
> OS-public-api                                 Puplic vlan to connect
> to outside clients
> 2002                        Openstack                     
>  OS-internal-api                                 Blah blah blah
> 2003                        Openstack                      
> OS-admin-api                                      Blah blah blah
>
> ....
> 2019                         Openstack                     OS-Future
> develpoment                           Blah blah blah
> 2020                         Openstack                   
>  OS-compute-external                             Blah blah blah
>
>
> 2031                        Hadoop                          
> OS-public-api                                 Puplic vlan to connect
> to outside clients
> 2032                        Hadoop                     
>  OS-internal-api                                 Blah blah blah
> 2033                        Hadoop                       OS-admin-api
>                                      Blah blah blah
>
> ....
> 2039                         Hadoop                     OS-Future
> develpoment                             Blah blah blah
> 2040                         Hadoop                   
>  OS-compute-external                             Blah blah blah 
>
>
> ...
>
> and it goes on for all other _potential_ bundles.
> ...
>
> 4080-4094                        none after this         may reduce
> clashes                           Some places use the end of a range....
>
>
>
>
>
> and once it is defined the JUJU charm creators can require these
> standard vlans knowing that they exist in MAAS when the bundle is used.
>
>
>
> I realize this all may exist already, but if it does not, I will say
> this. It may be possible when a user installs a bundle in juju, MAAS
> can auto-configure all of the interfaces and sub-interfaces
> automatically with the standard vlans without conflict, from what I
> can tell.
>
>
> Not a small task to set up, but am I wrong in thinking so and is this
> a direction that we may want to go?
>
> Brett
>
>
>
>
>
>
>  
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20170412/4412bc00/attachment.html>