Open Stack

On 08/22/2012 02:54 PM, Mark McLoughlin wrote:
> Hi Duncan,
> 
> On Wed, 2012-08-22 at 13:29 -0700, Duncan McGreggor wrote:
>> On Wed, Aug 22, 2012 at 1:04 PM, Thierry Carrez <thierry at openstack.org> wrote:
>>> Jason Kölker wrote:
>>>> On Wed, 2012-08-22 at 17:20 +0200, Thierry Carrez wrote:
>>>>> Monty Taylor wrote:
>>>>>> On 08/21/2012 10:19 AM, Mark McLoughlin wrote:
>>>>>>> Hey,
>>>>>>>
>>>>>>> On Tue, 2012-08-21 at 09:45 -0600, Monty Taylor wrote:
>>>>>>>> Hey all!
>>>>>>>>
>>>>>>>> I'd like to request a FFE for the following:
>>>>>>>>
>>>>>>>> https://review.openstack.org/#/c/11027/
>>>>>
>>>>> So I looked a bit more deeply into this, and I'm not really convinced.
>>>>>
>>>>> First, this comes out of nowhere with no blueprints / discussion, with
>>>>> first patch proposed even after Folsom-3 was pushed.
>>>>
>>>> Using entry_points was discussed at the Folsom summit. I agree with the
>>>> rest of the sentiment though, better to wait for grizzly.
>>>
>>> Yeah, I also realized after posting that one of the patches was actually
>>> posted before FF :) I guess the decision boils down to *why* this needs
>>> to be in Folsom rather than in early Grizzly, and I wish changes had
>>> been submitted a few weeks earlier so that we didn't have to lose time
>>> over that review/discussion/decision :)

Yeah - Sorry about that... I uploaded before the FF, but then vish had a
good feedback that the code should really go into openstack-common. Of
course, there's a lag there... so yeah, I lost the race. Sorry - doing
actual operational patches against Nova is a new process for me - I'll
be better about it in the future.

>> At DeamHost, we're developing against Folsom and will be releasing a
>> Folsom-based product. If this change makes it in for Folsom, this will
>> save us considerable work via an improved development process. Within
>> the larger context of the community at large we may be only one team
>> of devs, but I'd imagine that with a team as senior as ours, there
>> will be other Python hackers out there who will appreciate the
>> methodology represented by this change and the benefits of having it
>> in place for Folsom-based projects.

Same here - I have two different projects coming up that want to deploy
a folsom-based openstack, but want to have drivers that did not make it
in to Folsom (this is actually the reason why the work started so late-
it wasn't particularly personally necessary until it became clear that
FF wasn't going to be hit on the other drivers)

> Could you elaborate on what this new methodology is and how it will save
> you considerable work? Honestly totally non-obvious to me, I'm afraid.

If this lands, then I can apt-get/yum install folsom openstack, then I
can apt-get/yum install the non-landed additional driver that itself is
written against openstack in a fairly seamless manner. That means that
the driver code can live, not as a patch to folsom nova, but as a legit
add-on project. Then - when grizzly comes out and the driver code
_lands_ the config references that would have been deployed to use the
driver via the entrypoint name will not have to change in the config
files, because they'll be using entrypoint names and not python library
path indications.

Sorry on process, but I'll say that, like Duncan, it'll make a couple of
different deployment scenarios nicer for me too - but consider me
appropriately chastised for timing. Fully grokked.

Monty