[tripleo] Deprecating tripleo-heat-templates firstboot

Alex Schultz aschultz at redhat.com
Thu May 28 22:58:02 UTC 2020


On Tue, May 26, 2020 at 3:34 PM Steve Baker <sbaker at redhat.com> wrote:
>
>
> On 27/05/20 5:30 am, Harald Jensås wrote:
> > On Tue, 2020-05-26 at 11:32 +1200, Steve Baker wrote:
> >> Soon nova will be switched off by default on the undercloud and all
> >> overcloud deployments will effectively be deployed-server based
> >> (either provisioned manually or via the baremetal provision command)
> >>
> >> This means that the docs for running firstboot scripts[1] will no
> >> longer work, and neither will our collection of firstboot scripts[2].
> >> In this email I'm going to propose what we could do about this
> >> situation and if there are still unresolved issues by the PTG it
> >> might be worth having a short session on it.
> >>
> > If we had gone the other way around, and done the Heat Stack with
> > "dummy" server resources before deploying baremetal we could have done
> > this seamless, i.e passed these cloud-configs based on the stack to the
> > baremetal provisioning yaml's extention you mention below. But that
> > train departed, long ago ...
> Also this still wouldn't have handled the manual provisioning deployed
> server case.
> > Do we need to add some deprecation and/or validation? Something that
> > ensure we stop the deployment in case one of the resources
> > OS::TripleO::NodeAdminUserData, OS::TripleO::NodeTimesyncUserData,
> > OS::TripleO::NodeUserData or OS::TripleO::{{role.name}}::NodeUserData
> > is defined in the resource registry, with a pointer to docs on how to
> > move it to the baremetal provisioning yaml, or extraconfig.
>
> I think if OS::TripleO::*Server: is not mapped to OS::Nova::Server then
> the deployment should halt with a message if OS::TripleO::NodeUserData
> or OS::TripleO::{{role.name}}::NodeUserData are mapped to something
> other than userdata_default.yaml
>
> As for OS::TripleO::NodeTimesyncUserData, it looks like this functionality is duplicated by deployment/timesync/chrony-baremetal-ansible.yaml which is mapped to OS::TripleO::Services::Timesync and included in every role, but NodeTimesyncUserData was added recently to handle some early config timestamp issues:
>
> https://opendev.org/openstack/tripleo-heat-templates/commit/eafe3908535ec766866efb74110e057ea2509c45
> https://bugs.launchpad.net/tripleo/+bug/1776869
>
> Maybe this becomes less of an issue with no other config tasks happening at first boot, I've tagged in Alex for his thoughts. One option could be to enable and configure chrony during overcloud-full image build, then document how to disable it or change the ntp servers in cloud-config?
>

Since we configure NTP/chrony during the host_prep_tasks phase so that
should be sufficient now. The original issue that we were attempting
to fix with that was the read-only errors out of docker. We later
learned that that issue was likely caused by a docker-puppet.py issue
where we copied files that we read-only mounted. It's likely safe to
delete this however, I would say it might be beneficial to include
basic ntp or hwclock functionality in the new provision system on the
off chance a user needs to do those prior to any configurations on the
host.  I believe we've cleaned up the ordering of things within the
regular deployment now such that this firstboot is no longer required.

> >> The baremetal provisioning implementation already uses cloud-init
> >> cloud-config internally for user creation and key injection[3] so I'm
> >> going to propose an enhancement the the baremetal provisioning yaml
> >> format so that custom cloud-config instructions can be included
> >> either inline or as a file path.
> >>
> > ++
> >
> >> I think it is worth going through each firstboot script[2] and
> >> deciding what its fate should be (other than being deprecated in
> >> Ussuri):
> >>
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/conntectx3_streering.yaml
> >>
> >> This has no parameters, so it could be converted to a standalone
> >> cloud-config file, but should it? Can this be achieved with kernel
> >> args? Does it require a reboot anyway, and so can be done with
> >> extraconfig?
> >>
> > Maybe this could be done using this module in ansible instead:
> > https://docs.ansible.com/ansible/latest/modules/modprobe_module.html#modprobe-module
> >
> >>
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/os-net-config-mappings.yaml
> >>
> >> I'm not sure why this is implemented as first boot, it seems to
> >> consume the parameter NetConfigDataLookup and transforms it to the
> >> format os-net-config needs for the file /etc/os-net-
> >> config/mapping.yaml. It looks like this functionality should be moved
> >> to where os-net-config is actually invoked, and the
> >> NetConfigDataLookup parameter should be officially supported.
> >>
> > I agree, I have been thinking about moving this for a while actually.
> >
> >>
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_dev_rsync.yaml
> >>
> >> I suggest deleting this and including a cloud-config version in the
> >> baremetal provisioning docs.
> >>
> > +1
> >
> >>
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_heat_admin.yaml
> >>
> >> Delete this, there is already an abstraction for this built into the
> >> baremetal provisioning format[4]
> >>
> >>
> > +1
> >
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_root_password.yaml
> >>
> >> Delete this and include it as an example in the baremetal
> >> provisioning docs.
> >>
> >>
> > +1
> >
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_timesync.yaml
> >>
> >> Maybe this could be converted to an extraconfig/all_nodes script[5],
> >> but it would be better if this sort of thing could be implemented as
> >> an ansible role or playbook, are there any plans for an extraconfig
> >> mechanism which uses plain ansible semantics?
> >>
> >>
> >>
> >> cheers
> >>
> >> [1]
> >> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/extra_config.html#firstboot-extra-configuration
> >>
> >> [2]
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot
> >>
> >> [3]
> >> https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/ansible_plugins/modules/metalsmith_instances.py#L286
> >>
> >> [4]
> >> https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/ansible_plugins/modules/metalsmith_instances.py#L132
> >>
> >>
> >> https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/ansible_plugins/modules/metalsmith_instances.py#L145
> >>
> >> [5]
> >> https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/extraconfig/all_nodes
>




More information about the openstack-discuss mailing list