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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ 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