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: [Apache Bloodhound] Proposals/BEP-0003 modified
Date Thu, 15 Nov 2012 12:51:45 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message