On 09/04/2018 12:59 PM, Balázs Gibizer wrote:
On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes <jaypi...@gmail.com> wrote:
On 09/04/2018 12:17 PM, Doug Hellmann wrote:
Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:
On 09/04/2018 11:44 AM, Doug Hellmann wrote:
Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:
On Tue, 4 Sep 2018, Jay Pipes wrote:
Is there a reason we couldn't have openstack-placement be the
package name?
I would hope we'd be able to do that, and probably should do that.
'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?
That's still a pretty generic name for the top-level import, but I
think
the only real risk is that the placement service couldn't be installed
at the same time as another package owned by someone else that used
that
top-level name. I'm not sure how much of a risk that really is.
You mean if there was another Python package that used the package name
"placement"?
The alternative would be to make the top-level package something like
os_placement instead?
Either one works for me. Though I'm pretty sure that it isn't
necessary. The reason it isn't necessary is because the stuff in the
top-level placement package isn't meant to be imported by anything at
all. It's the placement server code.
What about placement direct and the effort to allow cinder to import
placement instead of running it as a separate service?
I don't know what placement direct is. Placement wasn't designed to be
imported as a module. It was designed to be a (micro-)service with a
REST API for interfacing.
Best,
-jay
__________________________________________________________________________
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
