Open Stack

On Tue, Jun 19, 2018 at 9:17 AM, Jiří Stránský <jistr at redhat.com> wrote:
> On 19.6.2018 16:29, Lars Kellogg-Stedman wrote:
>>
>> On Tue, Jun 19, 2018 at 02:18:38PM +0100, Steven Hardy wrote:
>>>
>>> Is this the same issue Carlos is trying to fix via
>>> https://review.openstack.org/#/c/494517/ ?
>>
>>
>> That solves part of the problem, but it's not a complete solution.
>> In particular, it doesn't solve the problem that bit me: if you're
>> changing puppet providers (e.g., replacing
>> provider/keystone_config/ini_setting.rb with
>> provider/keystone_config/openstackconfig.rb), you still have the old
>> provider sitting around causing problems because unpacking a tarball
>> only *adds* files.
>>
>>> Yeah I think we've never seen this because normally the
>>> /etc/puppet/modules tarball overwrites the symlink, effectively giving
>>> you a new tree (the first time round at least).
>>
>>
>> But it doesn't, and that's the unexpected problem: if you replace the
>> /etc/puppet/modules/keystone symlink with a directory, then
>> /usr/share/openstack-puppet/modules/keystone is still there, and while
>> the manifests won't be used, the contents of the lib/ directory will
>> still be active.
>>
>>> Probably we could add something to the script to enable a forced
>>> cleanup each update:
>>>
>>>
>>> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/deploy-artifacts.sh#L9
>>
>>
>> We could:
>>
>> (a) unpack the replacement puppet modules into a temporary location,
>>    then
>>
>> (b) for each module; rm -rf the target directory and then copy it into
>>    place
>>
>> But! This would require deploy_artifacts.sh to know that it was
>> unpacking puppet modules rather than a generic tarball.
>>
>>> This would have to be optional, so we could add something like a
>>> DeployArtifactsCleanupDirs parameter perhaps?
>>
>>
>> If we went with the above, sure.
>>
>>> One more thought which just occurred to me - we could add support for
>>> a git checkout/pull to the script?
>>
>>
>> Reiterating our conversion in #tripleo, I think rather than adding a
>> bunch of specific functionality to the DeployArtifacts feature, it
>> would make more sense to add the ability to include some sort of
>> user-defined pre/post tasks, either as shell scripts or as ansible
>> playbooks or something.
>>
>> On the other hand, I like your suggestion of just ditching
>> DeployArtifacts for a new composable service that defines
>> host_prep_tasks (or re-implenting DeployArtifacts as a composable
>> service), so I'm going to look at that as a possible alternative to
>> what I'm currently doing.
>>
>
> For the puppet modules specifically, we might also add another
> directory+mount into the docker-puppet container, which would be blank by
> default (unlike the existing, already populated /etc/puppet and
> /usr/share/openstack-puppet/modules). And we'd put that directory at the
> very start of modulepath. Then i *think* puppet would use a particular
> module from that dir *only*, not merge the contents with the rest of
> modulepath, so stale files in /etc/... or /usr/share/... wouldn't matter
> (didn't test it though). That should get us around the "tgz only adds files"
> problem without any rm -rf.
>

So the described problem is only a problem with puppet facts and
providers as they all get loaded from the entire module path. Normal
puppet classes are less conflict-y because it takes the first it finds
and stops.

> The above is somewhat of an orthogonal suggestion to the composable service
> approach, they would work well alongside i think. (And +1 on
> "DeployArtifacts as composable service" as something worth investigating /
> implementing.)
>

-1 to more services. We take a Heat time penalty for each new
composable service we add and in this case I don't think this should
be a service itself.  I think for this case, it would be better suited
as a host prep task than a defined service.  Providing a way for users
to define external host prep tasks might make more sense.

Thanks,
-Alex

> Jirka
>
>
> __________________________________________________________________________
> 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