Feature/cocktail #693
Feature/cocktail #693
Conversation
…static_inventories accordingly for all stacks.
…d cf-porch jumphosts.
… firewall and hostname lookup on CopperFist and BetaBarrel.
…ingedhelix_cluster/secrets.yml.
…g and openstack_computing.
pneerincx
requested review from
scimerman,
Gerbenvandervries and
marieke-bijlsma
README.md
Outdated
| The _wrapper playbooks_ execute several _roles_ in the right order to create the complete `stack`. | ||
| _Playbooks_ from the `single_role_playbooks/` or `single_group_playbooks/` sub directories can be used to | ||
| (re)deploy individual roles or all roles for only a certain type of machine (inventory group), respectively. | ||
| These shorter subset _playbooks_ can a lot of time during development, testing or regular maintenance. |
There was a problem hiding this comment.
can a lot
something is missing here
| betabarrel: | ||
| vlan983: | ||
| address: 172.23.41.225 | ||
| netmask: /23 |
There was a problem hiding this comment.
Careful: range 23 is not a typo!
It was extended from the false setting of 24 as Betabarrel needs it in order to access the extended network to the support servers.
There was a problem hiding this comment.
This is a bit confusing. The vlan983 network segment uses /23, but here we specify a single IP address. We use the same ip_addresses data structure in several places to make it easier to parse it with the same code/logic. Therefore the ip_addresses variable can contain both info for networks as well as info for individual IP addresses for a specific machine. All of that can then be parsed with the same code for configuring iptables firewalls or OpenStack security groups. In this case the var contains a single IP for a NIC of the betabarrel machine: that must be /32 to make it a single IP. In other words the value for netmask listed here is not used to configure the netmask for the NIC on betabarrel. If you want to configure iptables of an OpenStack security group to allow access to/from the whole VLAN it should be 172.23.41.0/23, but if you want to allow access only to/from betabarrel it should be 172.23.41.225/32.
There was a problem hiding this comment.
Well that is quit confusing, yes.
If we talk about the BB CentOS interface itself: network range was previously defined at /24, which prevented BB to access the network. That has nothing to do with the network configuration itself.
In other words the value for netmask listed here is not used to configure the netmask for the NIC on betabarrel.
This is particularly confusing, I think that then it should either:
- not be defined there, but somewhere else,
- be defined with another variable name
- or not being defined at all, and be by default
/32- it that's expected.
I think that it would be less confusin in general if
- in
static_inventories/...ymlmachine's configuration sets thenetmaskon the machine's interface only - on CentOS level - if machine has in static inventories also defined
netmask, it should be used inside CentOS configuration for the appropriate interface as network range netmaskfor openstack networking should be configured in the network configuration (insidevars.yml) and used by openstack (and later if needed in firewal)
| copperfist: | ||
| vlan983: | ||
| address: 172.23.41.226 | ||
| netmask: /23 | ||
| netmask: /32 |
There was a problem hiding this comment.
Same as for Betabarrel: 23 is correct, not 32.
| # network_names_of_all_hosts_created_in_openstack are the ones specified in the inventory for hosts, | ||
| # wich also have the a cloud_flavor specified indicating these machines are created in OpenStack. | ||
| # | ||
| network_names_of_all_hosts_created_in_openstack: "{{ hostvars |
There was a problem hiding this comment.
I love the variable name. Yes, it's a bit long, but quite descriptive 👍
| # Networking. | ||
| # | ||
| host_network_names: "{{ host_networks | map(attribute='name') | flatten | unique }}" | ||
| first_management_network_name: "{{ stack_networks |
There was a problem hiding this comment.
If I understand correctly this picks the "first" management network. Which can be anything from the list. Shouldn't we have variable per network, f.e. main: true or first: true and select that only one? And if none was defined as such, the error would be also helpful.
Or did I misunderstood?
There was a problem hiding this comment.
You understood correctly. It simply picks "a" management network from the list when there are multiple: 'first' depends on the order/sorting; the code could have used last instead and the effect would be the same. The IPs from first_management_network_name are used in /etc/hosts deployed on machines and hence will be used to access a machine based on its hostname. This currently assumes all "management networks" are equally suitable for this purpose. Note this currently only happens on the iRODS machines, which have 2 management networks. If a specific network should be used to create entries in /etc/hosts, then we need an additional attribute/value to select a specific one. The alternative is to introduce a different category. Maybe something like primary management network of which there can be only one and adding additional management networks to a list of secondary management networks. Or ...
There was a problem hiding this comment.
This currently assumes all "management networks" are equally suitable for this purpose.
But if the list of networks changes, the entire playbook should be rerun on all the machines, to change all the network settings.
First network today could not be first network tomorrow. Or last one - doesn't matter which one we look.
Everything can be reshuffled simply by adding another VLAN, as has happened before 😉
If a specific network should be used to create entries in /etc/hosts, then we need an additional attribute/value to select a specific one.
No, I like the fact that the/etc/hostshas all the machines from all the networks defined. This is just a phone book and I prefer that it knows all the citizens. It has been useful before.
There was a problem hiding this comment.
No, I like the fact that the /etc/hosts has all the machines from all the networks defined. This is just a phone book and I prefer that it knows all the citizens. It has been useful before.
Yes, you can list all the machines, but you cannot list all the interfaces of a machine and give them the same name. Let's assume a machine by the name of supernode has 2 interfaces in an internal "management" network:
- 10.0.1.1 in management VLAN1 with subnet 10.0.1.0/24
- 10.0.2.1 in management VLAN2 with subnet 10.0.2.0/24
You can either put in /etc/hosts:
10.0.1.1 supernode
or you can put in /etc/hosts:
10.0.2.1 supernode
If both mangement networks are equally suitable to access the machine it does not matter, which one is used. But you cannot list both like this without creating all kinds of network issues:
10.0.1.1 supernode
10.0.2.1 supernode
If you want to list both interfaces in /etc/hosts only one of them can have the hostname of the machine. The other one would need another name. Something like this could work:
10.0.1.1 supernode
10.0.2.1 supernode_in_vlan2
An IP can have multiple names and aliases, so this would also work:
10.0.1.1 supernode_in_vlan1 supernode
10.0.2.1 supernode_in_vlan2
If you want to assign the name supernode to a specific IP, we need an additional attribute or variable to select a specific IP for /etc/hosts.
Co-authored-by: scimerman <80223690+scimerman@users.noreply.github.com>
…e-of-robots into feature/cocktail Pull from origin
Co-authored-by: scimerman <80223690+scimerman@users.noreply.github.com>
Refactored the first part where OpenStack components are created.
The old
deploy-os_server.ymlcreate-jenkins-server.ymlcreate-docs-server.ymlplaybooks are gone. The had a lot of redundancy and are now replaced by an
openstack.ymlplaybook that uses two new roles:roles/openstack_networkingroles/openstack_computingThe main difference between old and new code:
stack.betabarrelandcopperfist.