+1 & -1. I believe CLI also uses this 'colo' thing. Before any updates, my thought would be someone with full understanding of falcon should take time to analyze the impact.
> On 09-Jan-2015, at 11:12 pm, Seetharam Venkatesh <[email protected]> > wrote: > > Lets remove what is not necessary - cluster is what should be qualified > IMO. Colo is logical. > >> On Fri, Jan 9, 2015 at 3:27 AM, Ajay Yadav <[email protected]> wrote: >> >> Hi, >> >> 1. Processes and feeds operate at a cluster level but when we operate on >> instance command we have to give colo. >> 2. In falcon some commands use clusters e.g. entity-summary, and some >> feed instance commands also accept a *sourceClusters* option (by the way >> this is not documented) while many instance commands use colo e.g. >> schedule command >> 3. I can find the current colo but I can't find the current cluster for >> a process instance. So in a single colo multi cluster setup how do >> I(user/developer) disambiguate single process instance if there is no >> cluster option. >> >> >> Do we need to be aware of colocation of the two clusters? If yes, then do >> the benefits outweigh the confusion and other overhead like extra code? I >> have heard about some legacy reasons to do so but I am not sure if there >> are any currently relevant reasons as well. Would like to hear everyone's >> thoughts on this. >> >> >> >> Regards >> Ajay Yadava > > > > -- > Regards, > Venkatesh > > “Perfection (in design) is achieved not when there is nothing more to add, > but rather when there is nothing more to take away.” > - Antoine de Saint-Exupéry
