<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 5, 2015 at 11:36 AM, Rich Megginson <span dir="ltr"><<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 05/05/2015 12:20 PM, Colleen Murphy
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I'm cross-posting to the dev list since this
conversation should be happening there and is related to another
thread there.</div>
</blockquote>
<br></span>
Ok. I'm not replying puppet-openstack.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">I'm going to top-post a summary and then respond
inline.
<div><br>
</div>
<div>The summary so far is that puppet-openstacklib provides a
way to pass in credentials to an API-driven puppet type via an
auth parameter[1] included in the types like so[2]. The
benefit of this is that a user could create additional API
resources, such as keystone_user, by passing in credentials
directly to the type (presumably via hiera) without having to
read credentials out of keystone.conf. The desire for
something like this was outlined in the initial aviator
blueprint[3] (the openstackclient blueprint[4] changed some of
the design parameters, but not that one).</div>
<div><br>
</div>
<div>self.instances and self.prefetch are class methods provided
by puppet that types and providers typically override. These
methods are unable to read type parameters, as far as I can
tell, because they do not have a specific instance from which
to look up those parameters. In our implementation,
self.instances exists so that the command `puppet resource
keystone_user` works and returns a list of keystone_users, and
we don't use self.prefetch. So, the way the providers are
intended to work right now is: when creating a single
resource, to run a custom 'instances' object method to list
resources and check for existence, which can use
username/password credentials passed in to the resource OR use
username/password credentials set as environment variables OR
fall back to reading admin_token credentials from
keystone.conf, as it always did; when run in `puppet resource`
mode, it runs self.instances which can only use credentials
set as environment variables or read credentials from
keystone.conf since it has no way to accept an auth parameter.</div>
<div><br>
</div>
<div>There are a couple of problems with this approach, one
outlined by Gilles below and another that I'm just noticing.<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 4, 2015 at 8:34 PM,
Gilles Dubreuil <span dir="ltr"><<a href="mailto:gil.dubreuil@gmail.com" target="_blank">gil.dubreuil@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi Colleen,<br>
<br>
The issue is about having to deal with 2 different
code paths because authentication could be optionally
passed to a resource instance where it can't when
dealing with self.instances. <br>
Its creates many complications down the road.<br>
I initially expressed that from a technical OO point
of view, although as you said it doesn't really
matter.<br>
So, let's look at those examples:<br>
<a href="https://review.openstack.org/#/c/178385/3/lib/puppet/provider/keystone.rb" target="_blank">https://review.openstack.org/#/c/178385/3/lib/puppet/provider/keystone.rb</a><br>
<a href="https://review.openstack.org/#/c/178456/6/lib/puppet/provider/keystone_endpoint/openstack.rb" target="_blank">https://review.openstack.org/#/c/178456/6/lib/puppet/provider/keystone_endpoint/openstack.rb</a><br>
<br>
Providers should not have to go through that.<br>
</div>
</blockquote>
<div>That is indeed pretty awful, I had no idea this would
get so complicated when I initially wrote this.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
I don't believe the final implementation will be that bad. I don't
think we have to support v2 any more. We will just assume we always
have enough information to use v3 auth and v3 api. Based on our
discussions here and on IRC, this is possible and is desireable.</div></blockquote><div>Okay. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I'm also noticing what looks like a major flaw in
that the object instances method seems almost entirely
useless. A resource looks up the full list of resources
but only ever stores one[5]. So the goal of replacing
self.prefetch with an object method that had access to
the auth params is just not accomplished at all.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><br>
This is why I think avoiding passing authentication
details in some case (instance) should be avoided.<br>
The authentication is provided by another layer,
basically the environment, whether that comes from.</div>
</blockquote>
<div>Given the added complexity that you pointed out and
the fact that the motivation behind some of that
complexity is moot, I'm inclined to agree. We could
avoid this complexity and be be able to take advantage
of self.prefetch (which should speed up performance) if
we did away with the auth parameter and the methods
needed to accommodate that parameter.</div>
<div><br>
</div>
<div>The modules do not use that auth parameter
themselves, it's intended as an add-on if users wanted
to include extra keystone_user, etc, resources in their
profiles and didn't want to worry about running it on
the keystone node. I rather doubt anyone is actually
using that yet, and I'm curious if anyone has a desire
to keep it around.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
I cannot figure out a use case for having per-resource
authentication parameters. It seems that the likely use case would
be for per-run auth parameters, set via env. or config file.<br>
<br>
However, in openstack.rb self.request - what if self.request were
changed to do the same thing as the instance request method?</div></blockquote><div>self.request and request are basically identical except one is from the instance scope and one is from the class scope, so request would be removed if we abandoned the auth parameter.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>So if the providers could both read a config file
(keystone.conf, glance-api.conf, etc) and read
environment variables for authentication, would that be
desireable?</div>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Yes.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>The auth param can accept a path to an openrc file,
but if we just assumed a certain path we could have the
provider check that for credentials as well.
puppet-openstack_extras happens to place it in
/root/openrc[6].</div>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Yes. It would be nice to have a fallback path if there is no
resource[:auth]['openrc']<br>
<br>
<blockquote type="cite"><span class="">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><br>
Don't get me wrong the new openstacklib is great but
the authentication being different between class and
instances.<br>
Again, the authentication should be the same for the a
whole provider, unconditionally. <br>
Otherwise, sure it works, I don't know how to put it,
honestly, it breaks the spirit of the providers.<br>
<br>
Richm, imcsk8, and I have discussed around that issue
(keystone v2/v3 support) and decided to talk to you
before pushing anything, but we do think this boulder
to be removed.<br>
By doing so we'll be able to move faster.<br>
</div>
</blockquote>
<div>Thanks for doing so. I'm glad we could have this
discussion. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><br>
I'm in time zone UTC+10 - Will try tomorrow morning
for me, arvo for you.<span><font color="#888888"><br>
<br>
Gilles<br>
</font></span></div>
<div>
<div>
-- <br>
<br>
To unsubscribe from this group and stop receiving
emails from it, send an email to <a href="mailto:puppet-openstack+unsubscribe@puppetlabs.com" target="_blank">puppet-openstack+unsubscribe@puppetlabs.com</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">Colleen</div>
<div class="gmail_extra"><br>
</div>
[1] <a href="http://git.openstack.org/cgit/stackforge/puppet-openstacklib/tree/lib/puppet/util/openstack.rb" target="_blank">http://git.openstack.org/cgit/stackforge/puppet-openstacklib/tree/lib/puppet/util/openstack.rb</a></div>
<div class="gmail_extra">[2] <a href="http://git.openstack.org/cgit/stackforge/puppet-keystone/tree/lib/puppet/type/keystone_user.rb#n85" target="_blank">http://git.openstack.org/cgit/stackforge/puppet-keystone/tree/lib/puppet/type/keystone_user.rb#n85</a></div>
<div class="gmail_extra">[3] <a href="https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-aviator-in-module-resources" target="_blank">https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-aviator-in-module-resources</a></div>
<div class="gmail_extra">[4] <a href="https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-openstackclient-in-module-resources" target="_blank">https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-openstackclient-in-module-resources</a></div>
<div class="gmail_extra">[5] <a href="http://git.openstack.org/cgit/stackforge/puppet-keystone/tree/lib/puppet/provider/keystone_user/openstack.rb#n212" target="_blank">http://git.openstack.org/cgit/stackforge/puppet-keystone/tree/lib/puppet/provider/keystone_user/openstack.rb#n212</a></div>
<div class="gmail_extra">[6] <a href="http://git.openstack.org/cgit/stackforge/puppet-openstack_extras/tree/manifests/auth_file.pp#n86" target="_blank">http://git.openstack.org/cgit/stackforge/puppet-openstack_extras/tree/manifests/auth_file.pp#n86</a></div>
</div>
<br>
<fieldset></fieldset>
<br>
</span><pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>