Open Stack

On 27/11/13 10:59 +0000, Mark McLoughlin wrote:
>On Wed, 2013-11-27 at 11:50 +0100, Flavio Percoco wrote:
>> On 26/11/13 22:54 +0000, Mark McLoughlin wrote:
>> >On Fri, 2013-11-22 at 12:39 -0500, Doug Hellmann wrote:
>> >> On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco <flavio at redhat.com> wrote:
>> >> >    1) Store the commit sha from which the module was copied from.
>> >> >    Every project using oslo, currently keeps the list of modules it
>> >> >    is using in `openstack-modules.conf` in a `module` parameter. We
>> >> >    could store, along with the module name, the sha of the commit it
>> >> >    was last synced from:
>> >> >
>> >> >        module=log,commit
>> >> >
>> >> >        or
>> >> >
>> >> >        module=log
>> >> >        log=commit
>> >> >
>> >>
>> >> The second form will be easier to manage. Humans edit the module field and
>> >> the script will edit the others.
>> >
>> >How about adding it as a comment at the end of the python files
>> >themselves and leaving openstack-common.conf for human editing?
>>
>> I think having the commit sha will give us a starting point from which
>> we could start updating that module from.
>
>Sure, my only point was about where the commit sha comes from - i.e.
>whether it's from a comment at the end of the python module itself or in
>openstack-common.conf

And, indeed you said 'at the end of the python files'. Don't ask me
how the heck I misread that.

The benefit I see from having them in the openstack-common.conf is
that we can register a `StrOpt` for each object dynamically and get
the sha using oslo.config. If we put it as a comment at the end of the
python file, we'll have to read it and 'parse' it, I guess.

>
>> It will mostly help with
>> getting a diff for that module and the short commit messages where it
>> was modified.
>>
>> Here's a pseudo-buggy-algorithm for the update process:
>>
>>     (1) Get current sha for $module
>>     (2) Get list of new commits for $module
>>     (3) for each commit of $module:
>>         (3.1) for each modified_module in $commit
>>             (3.1.1) Update those modules up to $commit (1)(modified_module)
>>         (3.2) Copy the new file
>>         (3.3) Update openstack-common with the latest sha
>>
>> This trusts the granularity and isolation of the patches proposed in
>> oslo-incubator. However, in cases like 'remove vim mode lines' it'll
>> fail assuming that updating every module is necessary - which is true
>> from a git stand point.
>
>This is another variant of the kind of inter-module dependency smarts
>that update.py already has ... I'd be inclined to just omit those smarts
>and just require the caller to explicitly list the modules they want to
>include.
>
>Maybe update.py could include some reporting to help with that choice
>like "module foo depends on modules bar and blaa, maybe you want to
>include them too" and "commit XXX modified module foo, but also module
>bar and blaa, maybe you want to include them too".

But, if we get to the point of suggesting the user to update module
foo because it was modified in commit XXX, we'd have everything needed
to make it recursive and update those modules as well.

I agree with you on making it explicit, though. What about making it
interactive then? update.py could ask users if they want to update
module foo because it was modified in commit XXX and do it right away,
which is not very different from updating module foo, print a report
and let the user choose afterwards.

(/me feels like Gollum now)

I prefer the interactive way though, at least it doesn't require the
user to run update several times for each module. We could also add a
`--no-stop` flag that does exactly what you suggested.

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131127/79fc7663/attachment.pgp>