[jboss-as7-dev] rollout plans

[Brian Stansberry]

I was chatting with Jason and he had a good idea.

In domain.xml

<rollout-plans>
    <plan-configs name="plans-x" sha1="xxxxxx"/>
    <fs-plan-configs path="plans-y.xml"
          relative-to="path-to-var/jbossas"/>
</rollout-plans>

The former we'd store in the content repo; the latter would be external.

The domain API would just provide load and store methods. (For the 
"fs-plan-config" case perhaps just load if we don't want to deal with 
the possibility of not being able to write.)

The tools are responsible for any manipulation of the plans; they just 
send the DMR back to the HC for storage.

My assumption was each "(fs-)plan-configs" item could include multiple 
plans.

Basically this just formalizes the contract for how plan files are 
stored and uses the domain content repo as a readily available store 
(one that replicates so its usable if another HC takes over as master or 
if the client is only making host level changes to a slave HC.)

On 12/6/11 9:50 AM, Alexey Loubyansky wrote:
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat