[openstack-dev] [tripleo] CLI and RHEL registration of overcloud nodes

Ben Nemec openstack at nemebean.com
Mon Aug 31 22:17:47 UTC 2015


On 08/26/2015 11:00 AM, Steven Hardy wrote:
> On Wed, Aug 26, 2015 at 05:28:47PM +0200, Jan Provazník wrote:
>> Hi,
>> although rdomanager-oscplugin is not yet under TripleO it should be soon, so
>> sending this to TripleO audience.
>>
>> Satellite registration from user's point of view is now done by passing
>> couple of specific parameters when running "openstack overcloud deploy"
>> command [1]. rdomanager-oscplugin checks presence of these params and adds
>> additional env files which are then passed to heat and it also generates a
>> temporary env file containing default_params required for rhe-registration
>> template [2].
>>
>> This approach is not optimal because it means that:
>> a) registration params have to be passed on each call of "openstack
>> overcloud deploy"
>> b) other CLI commands (pkg update, node deletion) should implement/reuse the
>> same logic (support same parameters) to be consistent
> 
> I think the problem can be generalized to say that the CLI should never be
> creating environment files internally, and ideally it should also not
> contain any hard-coded hidden internal defaults or anything coupled to the
> template implementation.
> 
> Everything should be provided via -e environment files, exactly like they
> are for python-heatclient, and if we need some fall-back defaults, they
> should be maintained in a defaults.yaml file somewhere, or, just use the
> defaults in the actual heat templates.
> 
> I also think the use of special CLI switches should be discouraged or even
> deprecated, e.g stuffl like --compute-flavor vs just passing
> OvercloudComputeFlavor in an environment file.

+1 to all of this.  There's plenty of precedent for having environment
files with sample defaults in them.  Basically everything in
https://github.com/openstack/tripleo-heat-templates/tree/master/environments
as far as I can tell.

> 
>> This is probably not necessary because registration params should be needed
>> only when creating OC stack, no need to pass them later when running any
>> update operation.
> 
> Note that this all becomes *much* easier with a properly working heat PATCH
> update, which oscplugin is already trying to use:
> 
> https://github.com/rdo-management/python-rdomanager-oscplugin/blob/master/rdomanager_oscplugin/v1/overcloud_deploy.py#L436
> 
> The problem is PATCH updates were only partially implemented in heat for
> Kilo, which I've been trying to fix recently:
> 
> https://bugs.launchpad.net/python-heatclient/+bug/1224828
> 
> The main part needed to avoid needing all the environment files every time
> has now landed:
> 
> https://review.openstack.org/#/c/154619
> 
> We might consider if that's a valid kilo backport, but for upstream TripleO
> this is already available :)
> 
> There are a couple still outstanding (to allow not passing the template on
> update):
> 
> https://review.openstack.org/#/c/205754/
> https://review.openstack.org/#/c/205755/
> 
>> As a short term solution I think it would be better to pass registration
>> templates in the same way as other extra files ("-e" param) - although user
>> will still have to pass additional parameter when using rhel-registration,
>> it will be consistent with the way how e.g. network configuration is used
>> and the "-e" mechanism for passing additional env files is already supported
>> in other CLI commands. "_create_registration_env" method [2] would be
>> updated to generate&add just user's credentials [3] env file - and this
>> would be needed only when creating overcloud, no need to pass them when
>> updating stack later.
> 
> +1, I think making everything consistent via -e parameters makes sense,
> which will then become easier since you'll only have to pass those which
> change on update after the heat stuff mentioned above is available to all
> using the CLI.
> 
> Steve
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list