incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [Apache Bloodhound] Proposals/BEP-0003 modified
Date Thu, 15 Nov 2012 15:15:11 GMT
Hmm.. a very good question. It still represents a proposal rather than 
something that we already agree on. It is not yet clear that the 
proposal will meet our requirements in the form that it takes.

I will need to study the proposal as it evolves before I go with it but 
it is possible we can be able to pick out parts of the proposal that we 
can agree on for early implementation. I guess we'll see how it goes.

Cheers,
Gary

On 15/11/12 12:51, Peter Koželj wrote:
> I am a bit confused here. It was only yesterday that we where still
> discussing the features that multiproduct should bring and today I am
> looking at BEP that already has hints of agreed and rejected solutions and
> other stuff and I am not even certain that we agreed on features yet.
>
> Did I miss something in ML archives?
>
> Peter
>
> On 15 November 2012 08:08, Apache Bloodhound <
> bloodhound-dev@incubator.apache.org> wrote:
>
>> Page "Proposals/BEP-0003" was changed by olemis
>> Diff URL: <
>> https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=7
>> Revision 7
>> Comment: [BEP-0003] Towards an introduction to product environments (not
>> finished)
>> Changes:
>> -------8<------8<------8<------8<------8<------8<------8<------8<--------
>> Index: Proposals/BEP-0003
>> =========================================================================
>> --- Proposals/BEP-0003 (version: 6)
>> +++ Proposals/BEP-0003 (version: 7)
>> @@ -24,27 +24,127 @@
>>
>>   == Motivation ==
>>
>> -Nowadays it is possible to manage multiple projects by creating multiple
>> environments. As a consequence data is scattered across multiple databases
>> and maintenance tasks turn out to be more difficult. Since a long time
>> users have expressed the need for managing multiple ''projects'' in an easy
>> way . In the case of a family of related products it is usually important
>> to have a unified view on the development activity as well as the ability
>> to share common resources among them. Under those circumstances it is
>> convenient to manage multiple products within a single ''Trac'' environment.
>> +Nowadays it is possible to manage multiple projects by creating multiple
>> environments. One notable example is [./MultienvParentDir the
>> multi-environment setup] considered as a reference for this specification.
>> As a consequence data is scattered across multiple databases and
>> maintenance tasks turn out to be more difficult. Since a long time users
>> have expressed the need for managing multiple ''projects'' in an easy way .
>> In the case of a family of related products it is usually important to have
>> a unified view on the development activity as well as the ability to share
>> common resources among them. Under those circumstances it is convenient to
>> manage multiple products within a single ''Trac'' environment.
>>
>>   The term ''project'' is very generic and may be confusing considering the
>> context. Therefore in this specification the word ''product'' is used
>> instead .
>>
>>   == Proposal #proposal
>>
>> -'''TODO'''
>> +In a few words the current proposal tries to reproduce a well-known
>> [./MultienvParentDir multi-environment setup] inside a single enviroment.
>> In this section you'll find the most important details necessary to
>> implement multi-product support. In order to understand the reasons that
>> make this is a valid and reliable specification, please see [#rationale
>> Rationale] below. In order and know more about similar alternatives
>> rejected along the way, please consult [#rejected Rejected ideas] below.
>> +
>> +=== Product environments #product-envs
>> +
>> +The key design mechanism is known as ''product environments'' . Their
>> main goal is to provide components (both in core and those defined by
>> plugins) with a lightweight virtual representation of an isolated
>> environment inside the ''global'' environment when dealing with requests
>> addressed to a resource owned by a product. The following figure
>> illustrates how they work.
>> +
>> +[[Image(Product_environments.png)]]
>> +
>> +If you notice similarities with the
>> [attachment:wiki:Proposals/BEP-0003/MultienvParentDir:Multienv_small.png
>> reference multi-environment setup] it is an intentional design decision.
>> +
>> +=== Product extensions to the trac.env.Environment API #product-env-api
>> +
>> +There is no need to create ''product environments'' explicitly via
>> [TracAdmin trac-admin] commands. Provided that the target product exists in
>> the database, they will be instantiated like shown in the following code
>> snippet. The instance of `trac.env.Environment` representing the global
>> environment will be accessed via `parent_env` attribute. The target product
>> will be available in `product` attribute.
>> +
>> +{{{
>> +#!py
>> +
>> +>>> env
>> +<trac.env.Environment object at 0x7faacb1e9490>
>> +>>> from multiproduct.env import ProductEnvironment
>> +>>> product_env = ProductEnvironment(env, product_prefix)
>> +>>> product_env.parent_env
>> +<trac.env.Environment object at 0x7faacb1e9490>
>> +>>> product_env.product
>> +<multiproduct.model.Product object at 0x35566d0>
>> +
>> +}}}
>> +
>> +Product environments will not be recursive , which means that the
>> following statement will fail
>> +
>> +{{{
>> +#!py
>> +
>> +>>> new_product_env = ProductEnvironment(product_env, product_prefix)
>> +Traceback (most recent call last):
>> +  File "<stdin>", line 1, in <module>
>> +TypeError: Initializer must be called with
>> +    trac.env.Environment instance as first argument
>> +    (got multiproduct.env.ProductEnvironment instance instead)
>> +
>> +}}}
>> +
>> +Instantiating a component involved in multi-product architecture will
>> always return `None`, just like if it was disabled e.g.
>> +
>> +{{{
>> +#!py
>> +
>> +>>> ps = product.api.MultiProductSystem(product_env)
>> +>>> repr(ps)
>> +None
>> +}}}
>> +
>> +''Product environments'' will implement both `trac.core.ComponentManager`
>> and `trac.core.Component` APIs by inheriting most of the properties of the
>> global `trac.env.Environment`, so they will act as wrappers. As a
>> consequence instances will have its own components cache, which means that
>> every active component class will only have a single instance for every
>> product environment.
>> +
>> +The following list explains how product environments will adapt existing
>> environment API while still being compatible with it.
>> +
>> +  - '''[=#product-env-conf] conf''' will contain an
>> +    instance of `trac.conf.Configuration` (or equivalent) setup in
>> +    such a way that it reads product-specific
>> +    settings from a file located at path
>> +    `./conf/product_<product prefix>.ini` relative
>> +    to the global environment's directory and
>> +    inherits globals settings stored in
>> +    `./conf/trac.ini` file. Some exceptions needs to
>> +    be installed in place.
>> +    * '''TODO'''
>> +  - '''[=#product-env-shared_plugins_dir] shared_plugins_dir''' will
>> always be empty . There
>> +    will be no way to deploy plugins for a particular
>> +    product, just enable/disable those installed in
>> +    the global environment.
>> +  - '''TODO'''
>> +
>> +[=#product-env-idem] The following methods and options will behave
>> exactly the same as the corresponding `parent_env`'s methods:
>> ''get_system_info'' , ''components_section'' , '''TODO''' .
>>
>>   == Rationale #rationale
>>
>>   The following is a list of proposed features for multi product support in
>> ''Bloodhound''. Goals related to compatibility are considered in
>> [#backwards-compatibility Backwards compatibility] below. In each case
>> you'll find notes explaining how candidate implementation will solve
>> related issues.
>>
>> +=== Per product ticket workflow #workflow
>> +
>> +Depending on the product, different ticket workflows should be supported.
>> +
>> +=== Per product notifications
>> +
>> +Notifications should be configurable per product.
>> +
>> +=== Per product ticket field configuration
>> +
>> +Components, milestone, version, priority, defaults, custom fields should
>> be configurable per product.
>> +
>> +=== Per product permission scheme #permissions
>> +
>> +Permission scheme is defined by assigning permissions (from a predefined
>> permission list) to specific users or groups. Permission scheme is assigned
>> to a product.
>> +
>> +==== Product roles #roles
>> +
>> +Support for per product user groups. Roles can be used to configure
>> notifications and permissions per product.
>> +
>>   === Product resources namespaces #url-mapping
>>
>> -Product and resource ID should form a two dimensional namespace. The
>> mapping
>> -
>> -Each resource would in addition to current URL scheme also be addressable
>> through the product URL namespace, namely /ticket/<product prefix>/<local
>> ticket id>.
>> +Product and resource ID should form a two dimensional namespace. The
>> mapping should be flexible enough to support the following scenarios .
>> +
>> +  - '''Product path namespace''' : '''TODO'''
>> +  - '''Product sub domain''' : '''TODO'''
>> +  - '''Product sub domain + path namespace''' : '''TODO'''
>> +
>> +'''FIXME''' also be addressable through the product URL namespace, namely
>> /ticket/<product prefix>/<local ticket id>.
>> +
>> +In a multi-product configuration product resources should not be accessed
>> using current global URL scheme (i.e.
>> /path/to/bloodhound/<environment>/<realm>/<id>). '''TODO''' why
?
>>
>>   ==== Tickets #tickets-namespace
>>
>> -Each product would have a separate number sequence for product ticket IDs.
>> +Tickets will keep their absolute ID and will be unique in the context of
>> the global environment. Besides each product would have a separate number
>> sequence for product ticket IDs.
>> +
>> +  '''TODO:''' Implementation details TBD
>>
>>   === Resources moveable between products #migration-resource
>>
>> @@ -54,30 +154,10 @@
>>
>>   By default, search is global. Search and queries should allow search
>> queries to be limited to specific product.
>>
>> -=== Per product ticket workflow #workflow
>> -
>> -Depending on the product, different ticket workflows should be supported.
>> -
>>   === Inter product ticket relations
>>
>>   It should be possible to link tickets from different products.
>>
>> -=== Per product notifications
>> -
>> -Notifications should be configurable per product.
>> -
>> -=== Per product ticket field configuration
>> -
>> -Components, milestone, version, priority, defaults, custom fields should
>> be configurable per product.
>> -
>> -=== Per product permission scheme #permissions
>> -
>> -Permission scheme is defined by assigning permissions (from a predefined
>> permission list) to specific users or groups. Permission scheme is assigned
>> to a product.
>> -
>> -==== Product roles #roles
>> -
>> -Support for per product user groups. Roles can be used to configure
>> notifications and permissions per product.
>> -
>>   === Per product repository #vcs
>>
>>   Each product can have different repository (and type) assigned.
>> @@ -89,6 +169,23 @@
>>   == Backwards Compatibility #backwards-compatibility
>>
>>   The solution has to be compatible with single product solution whenever
>> possible in order to make possible smooth upgrade paths from previous
>> installations. This is particularly important for plugins to work
>> out-of-the-box under the new circumstances or at least to make easier the
>> upgrade development process for hack authors.
>> +
>> +''Product environments'' in proposed multi-product configuration will act
>> as the replacement for sibling environments under common parent directory
>> in [./MultienvParentDir reference multi-environments setup]. They will
>> ensure that the correct translations will be performed for requests
>> addressed to resources owned by a product using the `trac.env.Environment`
>> API as usual. Components will have access to it by reading `self.env`
>> attribute (as usual !!!). All this means that from a component perspective
>> the very same operations will be invoked , thus plugins adaptation to the
>> new conditions will be rather smooth. If plugins do want to know whether
>> they are acting on behalf of a product environment or the global
>> environment then the following conditional statement would be enough
>> +
>> +{{{
>> +#!py
>> +
>> +from trac.env import Environment
>> +from multiproduct.env import ProductEnvironment
>> +
>> +if isinstance(self.env, Environment):
>> +    # Trac environment
>> +elif isinstance(self.env, ProductEnvironment):
>> +    # Product environment ... activate super-powers !
>> +else:
>> +    # Unidentified environment object ... aliens & zombies !
>> +
>> +}}}
>>
>>   == Reference Implementation #reference-implementation
>>
>> -------8<------8<------8<------8<------8<------8<------8<------8<--------
>>
>> --
>> Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003>
>> Apache Bloodhound <https://issues.apache.org/bloodhound/>
>> The Apache Bloodhound (incubating) issue tracker
>>
>> This is an automated message. Someone added your email address to be
>> notified of changes on 'Proposals/BEP-0003' page.
>> If it was not you, please report to .
>>


Mime
View raw message