Re: [jboss-as7-dev] rollout plans

Then we are changing the domain configuration, i.e. extending it, to include the rollout plans, right? Alexey On 12/06/2011 04:10 PM, Brian Stansberry wrote: > Let's go with 1) unless Heiko has some idea how to persist the state > client side in a reasonable manner. I think a requirement is there has > to be an option for sharing the persistent state between users. That can > be done with the CLI by having them point to the same file. It's not so > straightforward with a browser. > > On 12/5/11 5:06 PM, Alexey Loubyansky wrote: >> I would propose two choices to consider for now: >> >> 1. Rollout plans included in the domain management model. >> >> Pros: >> - they are stored in one location and are managed using the existing >> domain management api; >> - they are based on the server group names that are defined in the >> domain config, so keeping them next to each other is an advantage, >> separating them will increase the chance of inconsistencies between the >> two; >> - all tools will benefit from the same config. >> >> Cons: >> - this data does not really belong to the domain configuration, it's a >> convenience config for users to perform operations; >> - they are shared among users, meaning they are not personalized for a >> specific user but for all of them. >> >> 2. Keep it to the client, i.e. each tool will keep it's own config per >> user (or per tool setup). >> >> The Pros and Cons above change their signs here. >> >> These are two edge options. They could be combined. For now though, I'd >> implement one of them. >> >> Alexey >> >> On 12/05/2011 07:33 PM, Brian Stansberry wrote: >>> I'll look for both of you in #jboss-as7 when get in tomorrow AM. If >>> you're there it's faster to chat. (If not it's ok; I'm not setting up a >>> formal meeting here.) Or feel free to ping me before then if either of >>> you notice we're all in the room. >>> >>> On 12/5/11 5:50 AM, Alexey Loubyansky wrote: >>>> I don't think it makes sense to invent another protocol. >>>> >>> >>> For sure. >>> >>>> Well, now it gets kind of closer to the domain management model. >>>> Which I >>>> wanted to avoid originally, since it's an additional user data. But if >>>> we are talking about a general config, it naturally becomes shared >>>> between the users. From this point of view, it might make sense to >>>> include them in the model. >>>> >>> >>> It doesn't *have* to be that way, e.g. the operations behind a rollout >>> plan could include a param for the storage location. But that gets >>> really nasty pretty fast. It basically reduces the API for managing >>> these to "load" and "save"; no fine grained changes would be possible >>> without a lot of ugliness. And users would need understand what >>> filesystem locations the server can see etc. >>> >>> A possibility is another config file in domain/configuration for these, >>> but that just adds complexity with no clear benefit. An HC would >>> have to >>> know what the config file is at boot or its no different than making >>> the >>> user specify what the storage location is with any request. >>> >>> We could support storing these in both a jboss-cli.xml and in >>> domain.xml. The latter would be the only option for console users; the >>> former could be used for stuff a CLI user doesn't need/want to share. >>> There's a potential name conflict issue the CLI would need to deal with >>> though. >>> >>>> If we go that way, it might also make sense to include support for >>>> referencing a stored rollout plan from the DMR operation request. >>>> >>> >>> Agreed. That could just be another header variant, e.g. >>> >>> "operation-headers" => { >>> "named-rollout-plan" => "planA" >>> } >>> >>> as an alternative to >>> >>> >>> "operation-headers" => { >>> "rollout-plan" => { ... the details ... } >>> } >>> >>>> Alexey >>>> >>>> On 12/05/2011 12:38 PM, Heiko Braun wrote: >>>>> >>>>> >>>>> I don't have anything yet. As for sharing API/Interfaces: >>>>> >>>>> Ideally this would become a DMR operation/resource to work on. >>>>> That's at >>>>> least how we'd integrate at the moment and I think it would make the >>>>> most sense to keep it that way. Unless something forces us to move to >>>>> custom protocol. >>>>> If we stick to DMR, then actual service API/Impl doesn't matter that >>>>> much. >>>>> >>>>> >>>>> So the question is: What shared protocol do we use? DMR is something >>>>> both the CLI and Console already use. A custom protocol would need to >>>>> have a reasonable HTTP mapping in order to work with the console. >>>>> >>>>> On Dec 5, 2011, at 12:32 PM, Alexey Loubyansky wrote: >>>>> >>>>>> Which means we could also share an api interface/impl. >>>>> >>>>> -- >>>>> >>>>> Heiko Braun >>>>> Senor Software Engineer >>>>> JBoss by Red Hat >>>>> http://about.me/hbraun >>>>> >>>>> >>>>> >>>>> >>> >>> > >