incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: Approach to track of plugin upgrades WAS: svn commit: r1437357 - /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct/api.py
Date Tue, 29 Jan 2013 06:47:31 GMT
On 28 January 2013 19:27, Olemis Lang <olemis@gmail.com> wrote:

> On 1/28/13, Jose Angel Franco Navarro <jangel.franco@gmail.com> wrote:
> > Hi Peter and Olemis,
>
> :)
>
> I'm getting rid of top-posting
>
> > 2013/1/28, Peter Koželj <peter@digiverse.si>:
> >> I got a bit confused with the wording so would like to clarify:
> >>
> >> 1. Plugin should have one or one per component
> >> BaseEnvironmentSetupParticipant correct (as not one per version)?
> >
> > 1. Each plugin would have a single specialization of
> > BaseEnvironmentSetupParticipant. The idea is to change the class that
> > now implements IEnvironmentSetupParticipant to make her extend
> > BaseEnvironmentSetupParticipant and provide the required methods.
> >
>
> The code snippet in here might help to understand the whole idea .
>
>
> https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0005#reference-implementation
>
> So plugin developers are free to implement a single component
> responsible for updating the database and environment or multiple
> components . The BEP is only about the reusable framework to abstract
> the interactions needed to carry out upgrades .
>
> >> 2. The BaseEnvironmentSetupParticipant::get_db_setup_contributors()
> >> speaks
> >> of db scripts but actual upgrades are contained in modules. Should this
> >> actually be get_upgrade_modules()?
> >
> > 2. I would rather prefer to change the docstring, not to limit the
> > scope of the function in the future.
> >
> [...]
>
> I'm +0 about this . I'd just suggest to be consistent and keep source
> code readable .
>
> >> 3. What is the benefit of having new tables separate from the free db
> >> upgrades?
> >
> > 3. The benefits would be code reuse and higher testability of the
> > environment upgrade. Once the algorithm to create the schema is
> > stable, the plugins only provide data structures properly filled.
> > Repetitive code to create the tables is placed in a single place and
> > plugins only provide what is variable (their schema information).
> >
>
> I also add that it's helpful because there are well-know recovery
> strategies to deal with failures at table creation time . OTOH , while
> performing free upgrades (... and notice that I did not say *free db
> upgrades* considering the fact that other side effects outside DB are
> allowed as well in that particular case) it is much more difficult to
> recover from an error condition . Summarizing , it is possible to try
> free upgrades only after asserting that no issues regarding DB tables
> will be found .
>
> >> 4. If we have special support for db upgrades, have you considered
> having
> >> something for ini files as well (I imagine plugins will be adding
> >> new/updating configuration entries as well)
> >>
> >
> > 4. Not evaluated till now, contributions accepted ;-)
>
> In advance I would not do so . My reasoning is the following
>
> At initial plugin installation there should be no strong reason for
> setting options explicitly . The «right» approach is to provide
> default=... keyword arg in option definition and let the configuration
> subsystem to fall back to this value at run-time . There's no need to
> add a new entry in ini files to make related option work .
>
> Later on , while performing incremental upgrades site admins might
> have already set the values they want , and IMO the upgrade process
> should not be messing around and conflict with explicit admins
> decisions .
>
> Anyway , if someone provides a use case , I could change my mind on
> the subject . We could add that later too if it proves to be really
> useful .
>

Sometimes there just isn't sensible default value and admin just has to
fill in the blanks.
The second case would be when plugins comes to a point where configuration
reorganization is needed
and upgrade can use the old config values to enumerate new ones
automatically.
But I would agree that this two rare cases alone do not justify a framework
for this.


>
> --
> Regards,
>
> Olemis.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message