[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing

2008-08-28 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626522#action_12626522
 ] 

henrib edited comment on SOLR-725 at 8/28/08 4:30 AM:
-

added remaining operations and their mappings in CoreAdminRequest;
added specific tests to check refCount / number of aliases are kept in sync;
minor modifications so calling close is usually performed outside of the 
synchronized block on cores (to reduce contention).
change:
unloadCore is now a *core* operation, it unloads the core (removes all its 
aliases thus really closes/unloads the core);
unaliasCore is an *alias* operation and only removes the alias.


  was (Author: henrib):
added remaining operations and their mappings in CoreAdminRequest;
added specific tests to check refCount / number of aliases are kept in sync;
change:
unloadCore is now a *core* operation, it unloads the core (removes all its 
aliases thus really closes/unloads the core);
unaliasCore is an *alias* operation and only removes the alias.

  
 CoreContainer/CoreDescriptor/SolrCore cleansing
 ---

 Key: SOLR-725
 URL: https://issues.apache.org/jira/browse/SOLR-725
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Henri Biestro
 Attachments: solr-725.patch, solr-725.patch, solr-725.patch


 These 3 classes and the name vs alias handling are somewhat confusing.
 The recent SOLR-647  SOLR-716 have created a bit of a flux.
 This issue attemps to clarify the model and the list of operations. 
 h3. CoreDescriptor: describes the parameters of a SolrCore
 h4. Definitions
 * has one name
   ** The CoreDescriptor name may represent multiple aliases; in that 
 case, first alias is the SolrCore name
 * has one instance directory location
 * has one config  schema name
 h4. Operations
 The class is only a parameter passing facility
 h3. SolrCore: manages a Lucene index
 h4. Definitions
 * has one unique *name* (in the CoreContainer)
 **the *name* is used in JMX to identify the core
 * has one current set of *aliases*
 **the name is the first alias
 h4. Name  alias operations
 * *get name/aliases*: obvious
 * *alias*: adds an alias to this SolrCore
 * *unalias*: removes an alias from this SolrCore
 * *name*: sets the SolrCore name
 **potentially impacts JMX registration
 * *rename*: picks a new name from the SolrCore aliases
 **triggered when alias name is already in use
 h3. CoreContainer: manages all relations between cores  descriptors
 h4. Definitions
 * has a set of aliases (each of them pointing to one core)
 **ensure alias uniqueness.
 h4. SolrCore instance operations
 * *load*: makes a SolrCore available for requests
 **creates a SolrCore
 **registers all SolrCore aliases in the aliases set
 **(load = create + register)
 * *unload*: removes a core idenitified by one of its aliases
 **stops handling the Lucene index
 **all SolrCore aliases are removed
 * *reload*: recreate the core identified by one of its aliases
 * *create*: create a core from a CoreDescriptor
 **readies up the Lucene index
 * *register*: registers all aliases of a SolrCore
   
 h4. SolrCore  alias operations
 * *swap*: swaps 2 aliases
 **method: swap
 * *alias*: creates 1 alias for a core, potentially unaliasing a 
 previously used alias
 **The SolrCore name being an alias, this operation might trigger 
 a SolrCore rename
 * *unalias*: removes 1 alias for a core
 **The SolrCore name being an alias, this operation might trigger 
 a SolrCore rename
 *  *rename*: renames a core
 h3. CoreAdminHandler: handles CoreContainer operations
 * *load*/*create*:  CoreContainer load
 * *unload*:  CoreContainer unload
 * *reload*: CoreContainer reload
 * *swap*:  CoreContainer swap
 * *alias*:  CoreContainer alias
 * *unalias*: CoreContainer unalias
 *  *rename*: CoreContainer rename
 * *persist*: CoreContainer persist, writes the solr.xml
 **stauts*: returns the status of all/one SolrCore

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing

2008-08-27 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626209#action_12626209
 ] 

henrib edited comment on SOLR-725 at 8/27/08 10:51 AM:
--

bq. A rename with null is a bad usecase . We should not allow it

rename is a package private method that is called when we unalias a core from 
its name, asking it to pick a new one from its aliases.
However, is there is no alias to that core, the core has no way to name itself 
anymore but it may still be serving requests; thus the 'null' to indicate that 
case.
I'd expect this to be rare but the case exists nevertheless.

  was (Author: henrib):
bq. A rename with null is a bad usecase . We should not allow it

rename is a package private method that is called when we unalias a core from 
its name, asking it to pick a new one from its aliases.
However, is there is no alias to that core, the core has no way to name itself 
anymore but it may still be serving requests.
I'd expect this to be rare but the case exists nevertheless.
  
 CoreContainer/CoreDescriptor/SolrCore cleansing
 ---

 Key: SOLR-725
 URL: https://issues.apache.org/jira/browse/SOLR-725
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Henri Biestro
 Attachments: solr-725.patch


 These 3 classes and the name vs alias handling are somewhat confusing.
 The recent SOLR-647  SOLR-716 have created a bit of a flux.
 This issue attemps to clarify the model and the list of operations. 
 h3. CoreDescriptor: describes the parameters of a SolrCore
 h4. Definitions
 * has one name
   ** The CoreDescriptor name may represent multiple aliases; in that 
 case, first alias is the SolrCore name
 * has one instance directory location
 * has one config  schema name
 h4. Operations
 The class is only a parameter passing facility
 h3. SolrCore: manages a Lucene index
 h4. Definitions
 * has one unique *name* (in the CoreContainer)
 **the *name* is used in JMX to identify the core
 * has one current set of *aliases*
 **the name is the first alias
 h4. Name  alias operations
 * *get name/aliases*: obvious
 * *alias*: adds an alias to this SolrCore
 * *unalias*: removes an alias from this SolrCore
 * *name*: sets the SolrCore name
 **potentially impacts JMX registration
 * *rename*: picks a new name from the SolrCore aliases
 **triggered when alias name is already in use
 h3. CoreContainer: manages all relations between cores  descriptors
 h4. Definitions
 * has a set of aliases (each of them pointing to one core)
 **ensure alias uniqueness.
 h4. SolrCore instance operations
 * *load*: makes a SolrCore available for requests
 **creates a SolrCore
 **registers all SolrCore aliases in the aliases set
 **(load = create + register)
 * *unload*: removes a core idenitified by one of its aliases
 **stops handling the Lucene index
 **all SolrCore aliases are removed
 * *reload*: recreate the core identified by one of its aliases
 * *create*: create a core from a CoreDescriptor
 **readies up the Lucene index
 * *register*: registers all aliases of a SolrCore
   
 h4. SolrCore  alias operations
 * *swap*: swaps 2 aliases
 **method: swap
 * *alias*: creates 1 alias for a core, potentially unaliasing a 
 previously used alias
 **The SolrCore name being an alias, this operation might trigger 
 a SolrCore rename
 * *unalias*: removes 1 alias for a core
 **The SolrCore name being an alias, this operation might trigger 
 a SolrCore rename
   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing

2008-08-26 Thread Noble Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635
 ] 

noble.paul edited comment on SOLR-725 at 8/26/08 12:04 AM:
---

bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow 
your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use 
ALIAS . The usecase is this. I wish to start core and ensure that it is 
initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Nobody has a compelling usecase for that. 
*  Because of this feature some very useful methods are implemented 
inconsistently. As Yonik says core should be independent of how it is named . 
But as things stand we are removing some commonly useful methods for a feature 
which does not have a usecase. 

OK. Now that we already have ALIAS as a feature I propose the following 
behavior ,

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the 
core container. The only command that should change a core's name should be SWAP
* An ALIAS command *must not* succeed if the new name is already registered for 
another core. If a user wish to do so UNLOAD that core , or if it is an alias 
UNALIAS that name before trying this.
* The solr.xml core tag must keep the name as the primary name. We can add an 
extra attribute 'alias' which can take multiple names. This is already 
discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But 
it must not be able to remove the primary name.
* SolrQueryRequest should have a method to let handlers know through which 
alias this request is made

  was (Author: noble.paul):
bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't 
follow your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use 
ALIAS . The usecase is this. I wish to start core and ensure that it is 
initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Nobody has a compelling usecase for that. 
*  Because of this feature some very useful methods are implemented 
inconsistently. As Yonik says core should be independent of how it is named . 
But as things stand we are removing some commonly useful methods for a feature 
which does not have a usecase. 

OK. Now that we already have ALIAS as a feature I propose the following 
behavior ,

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the 
core container. The only command that should change a core's name should be SWAP
* An ALIAS command *must not* succeed if the new name is already registered for 
another core. If a user wish to do so UNLOAD that core , or if it is an alias 
UNALIAS that name before trying this.
* The solr.xml core tag must keep the name as the primary name. We can add an 
extra attribute 'alias' which can take multiple names. This is already 
discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But 
it must not be able to remove the primary name.
  
 CoreContainer/CoreDescriptor/SolrCore cleansing
 ---

 Key: SOLR-725
 URL: https://issues.apache.org/jira/browse/SOLR-725
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Henri Biestro
 Attachments: solr-725.patch


 These 3 classes and the name vs alias handling are somewhat confusing.
 The recent SOLR-647  SOLR-716 have created a bit of a flux.
 This issue attemps to clarify the model and the list of operations. 
 h3. CoreDescriptor: describes the parameters of a SolrCore
 h4. Definitions
 * has one name
   ** The CoreDescriptor name may represent multiple aliases; in that 
 case, first alias is the SolrCore name
 * has one instance directory location
 * has one config  schema name
 h4. Operations
 The class is only a parameter passing facility
 h3. SolrCore: manages a Lucene index
 h4. Definitions
 * has one unique *name* (in the CoreContainer)
 **the *name* is used in JMX to identify the core
 * has one current set of *aliases*
 **the name is the first alias
 h4. Name  alias operations
 * *get name/aliases*: obvious
 * *alias*: adds an alias to this SolrCore
 * *unalias*: removes an alias from this SolrCore
 * *name*: sets the SolrCore name
 **potentially impacts JMX registration
 * *rename*: picks a new name from the SolrCore aliases
 **triggered when alias name is already in use
 h3. 

[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing

2008-08-26 Thread Noble Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635
 ] 

noble.paul edited comment on SOLR-725 at 8/26/08 12:07 AM:
---

bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow 
your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use 
ALIAS . The usecase is this. I wish to start core and ensure that it is 
initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Whose usecases are not ver clear
*  Because of this feature some very useful methods are implemented 
inconsistently. As Yonik says core should be independent of how it is named . 
But as things stand we are removing some commonly useful methods 

OK. Now that we already have ALIAS as a feature I propose the following 
behavior ,

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the 
core container. The only command that should change a core's name should be SWAP
* An ALIAS command *must not* succeed if the new name is already registered for 
another core. If a user wish to do so UNLOAD that core , or if it is an alias 
UNALIAS that name before trying this.
* The solr.xml core tag must keep the name as the primary name. We can add an 
extra attribute 'alias' which can take multiple names. This is already 
discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But 
it must not be able to remove the primary name (use UNLOAD to do that).
* SolrQueryRequest should have a method to let handlers know through which 
alias this request is made

  was (Author: noble.paul):
bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't 
follow your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use 
ALIAS . The usecase is this. I wish to start core and ensure that it is 
initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Nobody has a compelling usecase for that. 
*  Because of this feature some very useful methods are implemented 
inconsistently. As Yonik says core should be independent of how it is named . 
But as things stand we are removing some commonly useful methods for a feature 
which does not have a usecase. 

OK. Now that we already have ALIAS as a feature I propose the following 
behavior ,

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the 
core container. The only command that should change a core's name should be SWAP
* An ALIAS command *must not* succeed if the new name is already registered for 
another core. If a user wish to do so UNLOAD that core , or if it is an alias 
UNALIAS that name before trying this.
* The solr.xml core tag must keep the name as the primary name. We can add an 
extra attribute 'alias' which can take multiple names. This is already 
discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But 
it must not be able to remove the primary name.
* SolrQueryRequest should have a method to let handlers know through which 
alias this request is made
  
 CoreContainer/CoreDescriptor/SolrCore cleansing
 ---

 Key: SOLR-725
 URL: https://issues.apache.org/jira/browse/SOLR-725
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Henri Biestro
 Attachments: solr-725.patch


 These 3 classes and the name vs alias handling are somewhat confusing.
 The recent SOLR-647  SOLR-716 have created a bit of a flux.
 This issue attemps to clarify the model and the list of operations. 
 h3. CoreDescriptor: describes the parameters of a SolrCore
 h4. Definitions
 * has one name
   ** The CoreDescriptor name may represent multiple aliases; in that 
 case, first alias is the SolrCore name
 * has one instance directory location
 * has one config  schema name
 h4. Operations
 The class is only a parameter passing facility
 h3. SolrCore: manages a Lucene index
 h4. Definitions
 * has one unique *name* (in the CoreContainer)
 **the *name* is used in JMX to identify the core
 * has one current set of *aliases*
 **the name is the first alias
 h4. Name  alias operations
 * *get name/aliases*: obvious
 * *alias*: adds an alias to this SolrCore
 * *unalias*: removes an alias from this SolrCore
 * *name*: sets the SolrCore name
 **potentially impacts JMX registration
 * *rename*: picks a new name from the SolrCore 

[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing

2008-08-26 Thread Noble Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625976#action_12625976
 ] 

noble.paul edited comment on SOLR-725 at 8/26/08 10:28 PM:
---

bq.Which ones? Is it something that impacts solr-561 somehow?
Sorry for not being clear. The widely used methods getName() in SolrCore and 
CoreDescriptor is what I am referring to .


The symlink method is least invasive . The reason being , getName() is far more 
useful than the alias feature itself (think of JMX cores are identified by 
name. and there are more places )  . Using this approach we get all the 
benefits of  alias and we lose nothing. 
Moreover the implementation is easy



  was (Author: noble.paul):
bq.Which ones? Is it something that impacts solr-561 somehow?
Sorry for not being clear. The widely used methods getName() in SolrCore and 
CoreDESCRIPTORis what I am referring to .


The symlink method is least invasive . The reason being , getName() is far more 
useful than the alias feature itself (think of JMX cores are identified by 
name. and there are more places )  . Using this approach we get all the 
benefits of  alias and we lose nothing. 
Moreover the implementation is easy


  
 CoreContainer/CoreDescriptor/SolrCore cleansing
 ---

 Key: SOLR-725
 URL: https://issues.apache.org/jira/browse/SOLR-725
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Henri Biestro
 Attachments: solr-725.patch


 These 3 classes and the name vs alias handling are somewhat confusing.
 The recent SOLR-647  SOLR-716 have created a bit of a flux.
 This issue attemps to clarify the model and the list of operations. 
 h3. CoreDescriptor: describes the parameters of a SolrCore
 h4. Definitions
 * has one name
   ** The CoreDescriptor name may represent multiple aliases; in that 
 case, first alias is the SolrCore name
 * has one instance directory location
 * has one config  schema name
 h4. Operations
 The class is only a parameter passing facility
 h3. SolrCore: manages a Lucene index
 h4. Definitions
 * has one unique *name* (in the CoreContainer)
 **the *name* is used in JMX to identify the core
 * has one current set of *aliases*
 **the name is the first alias
 h4. Name  alias operations
 * *get name/aliases*: obvious
 * *alias*: adds an alias to this SolrCore
 * *unalias*: removes an alias from this SolrCore
 * *name*: sets the SolrCore name
 **potentially impacts JMX registration
 * *rename*: picks a new name from the SolrCore aliases
 **triggered when alias name is already in use
 h3. CoreContainer: manages all relations between cores  descriptors
 h4. Definitions
 * has a set of aliases (each of them pointing to one core)
 **ensure alias uniqueness.
 h4. SolrCore instance operations
 * *load*: makes a SolrCore available for requests
 **creates a SolrCore
 **registers all SolrCore aliases in the aliases set
 **(load = create + register)
 * *unload*: removes a core idenitified by one of its aliases
 **stops handling the Lucene index
 **all SolrCore aliases are removed
 * *reload*: recreate the core identified by one of its aliases
 * *create*: create a core from a CoreDescriptor
 **readies up the Lucene index
 * *register*: registers all aliases of a SolrCore
   
 h4. SolrCore  alias operations
 * *swap*: swaps 2 aliases
 **method: swap
 * *alias*: creates 1 alias for a core, potentially unaliasing a 
 previously used alias
 **The SolrCore name being an alias, this operation might trigger 
 a SolrCore rename
 * *unalias*: removes 1 alias for a core
 **The SolrCore name being an alias, this operation might trigger 
 a SolrCore rename
   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing

2008-08-25 Thread Noble Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635
 ] 

noble.paul edited comment on SOLR-725 at 8/25/08 10:51 PM:
---

bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow 
your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use 
ALIAS . The usecase is this. I wish to start core and ensure that it is 
initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Nobody has a compelling usecase for that. 
*  Because of this feature some very useful methods are implemented 
inconsistently. As Yonik says core should be independent of how it is named . 
But as things stand we are removing some commonly useful methods for a feature 
which does not have a usecase. 

OK. Now that we already have ALIAS as a feature I propose the following 
behavior ,

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the 
core container. The only command that should change a core's name should be SWAP
* An ALIAS command *must not* succeed if the new name is already registered for 
another core. If a user wish to do so UNLOAD that core , or if it is an alias 
UNALIAS that name before trying this.
* The solr.xml core tag must keep the name as the primary name. We can add an 
extra attribute 'alias' which can take multiple names. This is already 
discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But 
it must not be able to remove the primary name.

  was (Author: noble.paul):
bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't 
follow your logic. You give an example of using core alias

My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use 
ALIAS . The usecase is this. I wish to start core and ensure that it is 
initialized properly . If it does I wish to replace that with another core .  

My concern here , 
*  We have added a feature called ALIAS 
*  Nobody has a compelling usecase for that. 
*  Because of this feature some very useful methods are implemented 
inconsistently. As Yonik says core should be independent of how it is named . 
But as things stand we are removing some commonly useful methods for a feature 
which does not have a usecase. 

OK. Now that we already have ALIAS as a feature I propose the following behavior

* let the getName() methods remain as is. 
* An ALIAS *must not* rename a core. It should just add another mapping in the 
core container. The only command that should change a core's name should be SWAP
* An ALIAS command should not succeed if the new name is already registered for 
another core. 
* The solr.xml core tag must keep the name as the primary name. We can add an 
extra attribute 'alias' which can take multiple names. This is already 
discussed in SOLR-350. 
* UNALIAS command can be added . It can just remove an ALIAS if it exists . But 
it must not be able to remove the primary name.
  
 CoreContainer/CoreDescriptor/SolrCore cleansing
 ---

 Key: SOLR-725
 URL: https://issues.apache.org/jira/browse/SOLR-725
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Henri Biestro
 Attachments: solr-725.patch


 These 3 classes and the name vs alias handling are somewhat confusing.
 The recent SOLR-647  SOLR-716 have created a bit of a flux.
 This issue attemps to clarify the model and the list of operations. 
 h3. CoreDescriptor: describes the parameters of a SolrCore
 h4. Definitions
 * has one name
   ** The CoreDescriptor name may represent multiple aliases; in that 
 case, first alias is the SolrCore name
 * has one instance directory location
 * has one config  schema name
 h4. Operations
 The class is only a parameter passing facility
 h3. SolrCore: manages a Lucene index
 h4. Definitions
 * has one unique *name* (in the CoreContainer)
 **the *name* is used in JMX to identify the core
 * has one current set of *aliases*
 **the name is the first alias
 h4. Name  alias operations
 * *get name/aliases*: obvious
 * *alias*: adds an alias to this SolrCore
 * *unalias*: removes an alias from this SolrCore
 * *name*: sets the SolrCore name
 **potentially impacts JMX registration
 * *rename*: picks a new name from the SolrCore aliases
 **triggered when alias name is already in use
 h3. CoreContainer: manages all relations between cores  descriptors
 h4. Definitions
 * has a set of aliases (each of them pointing to one core)
 **ensure alias uniqueness.
 h4. SolrCore instance operations
 *