Age | Commit message (Collapse) | Author | Files | Lines |
|
According to OpenStack admin is the network for pxe boot and mgmt is the
network for OpenStack services to communicate. We were using both in XCI
indistinctly
Change-Id: I3959e767098ac2be7161a5e84735fde9ab129784
Signed-off-by: Manuel Buil <mbuil@suse.com>
|
|
Change our idf to be more aligned with lf's idf. Adapt
dynamic_inventory.py to the change
Change-Id: Ib8f6d1684a00a8eb5ae06d5d04d308d4325cd444
Signed-off-by: Manuel Buil <mbuil@suse.com>
|
|
We are configuring static IPs in the various nodes but we don't do
anything for DNS assuming that DNS is being configured by another
entity. However, the IDF file already contains DNS information for us
so we should use that instead. Moreover, we update the IDF file to use
the gateway as DNS instead of the Google one in order to make it more
usable on restricted networks.
Change-Id: Ieba58ec9558080a1296e204c4f99bae859e9daef
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
The kubespray installer contains one inventory per flavor. We can get
rid of these files and use the dynamic inventory similar to OSA.
Moreover, we extend the dynamic inventory to read additional group
variables per flavor if necessary. This way we can still pass additional
information to inventory on per-flavor basis. This also fixes a typo
in the 'IDF' file. We also need to bump Ansible for kubespray since the
version we were using is having troubles with dynamic inventories.
Change-Id: Ic58101555f81aec5fee3c193608440aa89bbe445
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
Each installer has its own Ansible groups so we need record such
information separately. Moreover, we need to add 'flavor' information
to the IDF so we know which hosts belong to what flavor. This also
fixes the kubernetes installer type to be 'kubespray' instead of 'k8s'
Finally, we extend the IDF to also set appropriate hostnames for the
nodes.
Change-Id: I52b20908ad927840e0b38fba96be8faf6da2b52d
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
this is a proposition of self sufficient PDF/IDF to describe the POD
where XCI is running.
The PDF [Pod Description File] is describing the physical
level of the POD where XCI will run the installer. It lists servers and
their description (CPU/RAM/DISK/NICS)
The IDF [Installer Description File] is describing how the installers
will use the POD. 2 sections are today important in this IDF:
- idf.net_config is describing the network topology
- xci section is set to describe how common steps (network, nfs,
ceph,...) of XCI will use the pod.
Another section of IDF idf.[installer], curretnly empty, will
contain all pod specificities that are linked to an installer (osa,
kolla, k8s,...) and not shared with the others.
Those 2 files are describing the vitual pod as it is already
deployed by the XCI. Those default files can be replaced by the ones
describing the target pod (done manually or with the CI). It would then
be to the install process to take into account these files (to be done).
Change-Id: I3dcbd965f8c84b03d34eb0fd68599d7bec402dbd
Signed-off-by: Blaisonneau David <david.blaisonneau@orange.com>
|