On Thu, Dec 15, 2016 at 03:46:05PM -0600, Ben Nemec wrote: > > > On 12/08/2016 08:05 AM, Jiri Tomasek wrote: > > Hi all, > > > > I've been investigating how to implement TripleO network configuration > > in TripleO UI. Based on my findings I'd like to propose a solution. > > > > tl;dr proposal: Slightly refactor Network environment files to match GUI > > usage, Use Jinja Templating to generate dynamic parts of the > > templates/environments > > > > > > # Overview > > > > I've used Ben Nemec's amazing Network template generator as a reference > > to help me understand how the network configuration works [1]. In > > general the process of configuring the network in TripleO is: > > > > Define which Networks we intend to use -> Assign Roles to the Networks > > (+ Assign Role Services to the Network) -> Generate NIC config templates > > based on previous information > > > > > [snip] > > # The proposal > > > > So having described previous, here is the approach I think we should use > > to achieve network configuration using TripleO UI: > > > > 1. Put networks definitions into separate environment for each network: > > - this way GUI can provide a list of networks available to use and let > > user select which of them he wants to use. These environments are not > > dynamic and if user wants to add a new network, he does so by creating > > new templates and environment for it. UI also provides means to > > configure parameters for each network at this point (if needed). > > > > For example the environment for a Storage Network looks like this: > > > > resource_registry: > > OS::TripleO::Network::Storage: ../network/storage.yaml > > OS::TripleO::Network::Ports::StorageVipPort: > > ../network/ports/storage.yaml > > This seems like an obvious improvement, and is essentially how my tool works > too except that it munges all of the individual environments back together > at the end. > > Definite +1 from me. > > > > > 2. Assign Roles to Networks > > Having the Networks selected as well as Roles defined, TripleO UI > > provides user with means to assign Roles to Networks. This step involves > > generating the network-environment.yaml file. So TripleO UI sends the > > mapping of roles to network in json format to tripleo-common which in > > turn uses network-isolation.j2.yaml Jinja template to generate the > > environment file. I expect that pre-defined network-isolation.yaml will > > be included in default plan so the user does not need to start from > > scratch. Tripleo-common also provides an action to fetch network-roles > > assignment data by parsing the network-isolation.yaml > > > > In addition, user is able to assign individual Role Services to a > > Network. ServiceNetMap parameter is currently used for this. GUI needs > > to make sure that it represents Services-Networks assignment grouped by > > Role so it is ensured that user assigns Services to only networks where > > their Role is assigned. > > This sounds reasonable to me, but I do want to note that assigning roles to > networks feels a little backwards to me. I tend to think of a role as kind > of the top level thing here, to which we assign other things (services and > networks, for example). So my mental model kind of looks like:
I agree - we already have a list of roles (in roles_data.yaml), so the approach I've been experimenting with is to also define a list of networks, then we can assign those networks to each role in roles_data.yaml (or some other file containing the same data). > > roles: > Controller: > networks: > - provision > - external > - internal > ... +1 this is pretty much what I have proposed here: https://review.openstack.org/#/c/409920/2/roles_data.yaml Then the missing piece is a list of networks (so that in future we can have fully composable or custom networks), I proposed a network_data.yaml here: https://review.openstack.org/#/c/409921/ There is some discussion about if we do that, or instead have a single file e.g "plan_data.yaml" or similar, but logically I think both of these fit with your preferred mental model? :) > Compute: > networks: > -provision > ... > > as opposed to what I think you're describing, which is > > networks: > Provision: > roles: > - controller > - compute > External: > roles: > - controller > ... > > Maybe there are benefits to modeling it as the latter, but I think the > former fits better with the composable roles architecture. I agree, this second approach is awkward wrt the custom roles architecture, and I'd prefer the former. Thanks! Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
