Open Stack

On 09/04/2018 01:17 PM, Balázs Gibizer wrote:
> On Tue, Sep 4, 2018 at 7:01 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 09/04/2018 12:59 PM, Balázs Gibizer wrote:
>>> On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes <jaypipes at 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.
> 
> In Vancouver we talked about allowing cinder to import placement as a 
> library. See https://etherpad.openstack.org/p/YVR-cinder-placement L47

I wasn't in YVR, which explains why I's never heard of it. There's a 
number of misconceptions in the above document about the placement 
service that don't seem to have been addressed. I'm wondering if its 
worth revisiting the topic in Denver with the Cinder team or whether the 
Cinder team isn't interested in working with the placement service?

-jay