Migration management operation - open questions

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Migration management operation - open questions

Miroslav Novak
Hi,

we have a few questions related to correct behavior of the :migrate operation for following subsystems:
- JBoss Web to Undertow [1]
- HornetQ to Apache ActiveMQ Artemis [2]
- jacorb to iiop-openjdk [3]

Part of it was already clarified on wildfly-dev list [4] but there are still unspecified topics related to work flow and expected results of migration operation. We summarized them into following questions:

1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?

2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
-- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?

3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
-- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?

4. What should happen if some other subsystem is expecting definition of element in new migrated configuration but it's not there after migration?
-- For example ejb subsystem has by default "activemq-ra" as default resource adapter for MDBs and migrated Artemis subsystem will not contain it.

5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime  the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?

6. Should the extensions for old subsystems be left in configuration after migration?

7. Should the :migrate operation return reload-required header?

Thank you,
Mirek

[1] https://issues.jboss.org/browse/EAP7-326
[2] https://issues.jboss.org/browse/EAP7-327
[3] https://issues.jboss.org/browse/EAP7-328
[4] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003841.html
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Brian Stansberry
Thanks for raising these questions here.

On 8/7/15 1:26 AM, Miroslav Novak wrote:

> Hi,
>
> we have a few questions related to correct behavior of the :migrate operation for following subsystems:
> - JBoss Web to Undertow [1]
> - HornetQ to Apache ActiveMQ Artemis [2]
> - jacorb to iiop-openjdk [3]
>
> Part of it was already clarified on wildfly-dev list [4] but there are still unspecified topics related to work flow and expected results of migration operation. We summarized them into following questions:
>
> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?
>

I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this
part. Ideally this would be covered somewhere in
https://docs.jboss.org/author/display/WFLY10/Documentation. The intent
is all three of these have common semantics.

The biggest thing is these ops all require that the target process is
running in --admin-only mode.

> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?
>

The migrate operation is used to migrate a valid configuration. What you
describe is an invalid configuration, as the needed socket-binding is
not present.

The migration operation should not remove external configuration (e.g.
remove a socket-binding), as the ability to determine what other uses
there may be in the overall config for that config is beyond the scope
of the migration op handler.

> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>

I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
handler for the web subsystem migrate op) it looks to be adding a
security realm.

> 4. What should happen if some other subsystem is expecting definition of element in new migrated configuration but it's not there after migration?
> -- For example ejb subsystem has by default "activemq-ra" as default resource adapter for MDBs and migrated Artemis subsystem will not contain it.
>

Just to clarify, the default is hornetq-ra.

Jeff Mesnil should reply to this. I believe this may be a situation
where we change the default value of a management attribute and then use
a transformer to ensure slaves running previous versions still see
hornetq-ra if the attribute value is not explicitly set.

> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime  the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?
>

I think the op should fail (not just warn) if the subsystem cannot be
properly migrated.

That said, we need to be careful about having the scope of the handlers
grow too large, forcing handlers for one subsystem to be tightly coupled
to the implementation details of other subsystems or the kernel. Your
questions 2-4 relate to this kind of scope question. If the coupling
between different parts of the system starts to get too deep, IMO it
starts to move beyond the intended scope of these operations and into
the realm of higher level tools like Red Hat's Windup tool. It's a
judgement call but my feeling is what the handlers are currently doing
(e.g. the stuff I mention in my answer to #2) is reasonable.

> 6. Should the extensions for old subsystems be left in configuration after migration?
>

In a domain, yes. The migration of a subsystem in one profile does not
mean the extension is unavailable for use in another profile.

I don't have a strong opinion about this in standalone.

I do suspect there may be a technical barrier to removing the extension
though. If so I doubt we'll do it in WildFly 10.

> 7. Should the :migrate operation return reload-required header?
>

The migrate operations function by executing operations to add and
remove resources. If those operations themselves put the process in
reload-required, then the header will be returned. If not, it won't.

The migrate operations all require that the process be running in
--admin-only mode. So I would not expect the outcome to be a need to put
the process in reload-required. Most likely that outcome would be a bug.
We use reload-required when changes to the persistent configuration
cannot be reflected in existing running services, but in --admin-only
there are no running services associated with these subsystems.



--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Ladislav Thon
Brian, thanks for answering. I'll clarify some qustions below (and I
hope that others from our team will join too).

>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?
>>
>
> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this
> part. Ideally this would be covered somewhere in
> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent
> is all three of these have common semantics.
>
> The biggest thing is these ops all require that the target process is
> running in --admin-only mode.

This is mostly about clarifying what should I do before starting the new
server in --admin-only.

In standalone -- am I supposed to copy snippets from old standalone.xml
to new standalone.xml?

In domain -- uh oh, sorry, I don't really know, maybe this is somehow
connected to the ability of newer domain controller to manage older servers?

>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?
>>
>
> The migrate operation is used to migrate a valid configuration. What you
> describe is an invalid configuration, as the needed socket-binding is
> not present.

So if the migration approach is to "copy all required snippets from old
configuration to the new one", I have to copy all dependencies (e.g.
socket bindings) too. Makes sense, though maybe we had a different
situation in mind here that I can't recollect now... :-(

> The migration operation should not remove external configuration (e.g.
> remove a socket-binding), as the ability to determine what other uses
> there may be in the overall config for that config is beyond the scope
> of the migration op handler.

Sure.

>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>
>
> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
> handler for the web subsystem migrate op) it looks to be adding a
> security realm.

This is probably the right thing to do, but we wanted to be sure. We've
seen some possible problems with this (e.g. name collisions), so we
thought that it's better to ask :-)

>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime  the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?
>>
>
> I think the op should fail (not just warn) if the subsystem cannot be
> properly migrated.

I can agree both with this and with the other approach of "it's probably
easier for the user to fixup the new subsystem then it is to repeatedly
alter the old subsystem until you get something that will convert" [1].

[1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html

The idea here is that if the :migrate operation can see a possible
problem, then the problem must be reported during :migrate and not only
when the migrated server is started for the first time. Of course I
agree with

> That said, we need to be careful about having the scope of the handlers
> grow too large, forcing handlers for one subsystem to be tightly coupled
> to the implementation details of other subsystems or the kernel. Your
> questions 2-4 relate to this kind of scope question. If the coupling
> between different parts of the system starts to get too deep, IMO it
> starts to move beyond the intended scope of these operations and into
> the realm of higher level tools like Red Hat's Windup tool. It's a
> judgement call but my feeling is what the handlers are currently doing
> (e.g. the stuff I mention in my answer to #2) is reasonable.

and my opinion here is that the :migrate operation should detect any
possible problems that stem from the configuration of the old subsystem
(e.g. an attribute in the old subsystem allowed values A|B|C, but the
new subsystem only allows A|B). Problems caused elsewhere (socket
bindings, other subsystems, ...) can be deferred to server startup.

The key here is to agree on this :-)

>> 6. Should the extensions for old subsystems be left in configuration after migration?
>>
>
> In a domain, yes. The migration of a subsystem in one profile does not
> mean the extension is unavailable for use in another profile.
>
> I don't have a strong opinion about this in standalone.
>
> I do suspect there may be a technical barrier to removing the extension
> though. If so I doubt we'll do it in WildFly 10.

I think we're fine with leaving them there, this was just to clarify.

>> 7. Should the :migrate operation return reload-required header?
>>
>
> The migrate operations function by executing operations to add and
> remove resources. If those operations themselves put the process in
> reload-required, then the header will be returned. If not, it won't.
>
> The migrate operations all require that the process be running in
> --admin-only mode. So I would not expect the outcome to be a need to put
> the process in reload-required. Most likely that outcome would be a bug.
> We use reload-required when changes to the persistent configuration
> cannot be reflected in existing running services, but in --admin-only
> there are no running services associated with these subsystems.

Makes sense, thanks.

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Tomaž Cerar-2
In reply to this post by Brian Stansberry

On Mon, Aug 10, 2015 at 5:08 PM, Brian Stansberry <[hidden email]> wrote:

In a domain, yes. The migration of a subsystem in one profile does not
mean the extension is unavailable for use in another profile.

I don't have a strong opinion about this in standalone.


Standalone shouldn't boot in non admin mode with legacy extensions, as they are only allowed to run in host controller and in admin mode.
At least that is the contract of AbstractLegacyExtension that all deprecated / legacy extensions extend(ed)

Recently(as part of adding :migrate op) some of legacy extensions ware changed back to not use AbstractLegacyExtension,
but that was probably just because we haven't defined in what the lifecycle they should run given that they have migrate operation defined.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Brian Stansberry
In reply to this post by Ladislav Thon
On 8/10/15 10:59 AM, Ladislav Thon wrote:

> Brian, thanks for answering. I'll clarify some qustions below (and I
> hope that others from our team will join too).
>
>>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?
>>>
>>
>> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this
>> part. Ideally this would be covered somewhere in
>> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent
>> is all three of these have common semantics.
>>
>> The biggest thing is these ops all require that the target process is
>> running in --admin-only mode.
>
> This is mostly about clarifying what should I do before starting the new
> server in --admin-only.
>
> In standalone -- am I supposed to copy snippets from old standalone.xml
> to new standalone.xml?
>
> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
> connected to the ability of newer domain controller to manage older servers?
>

The intent here was not to let people start with a new standard config
shipped by us and then use these ops to import stuff from a previous
config. The expectation is they are starting with their existing config
and changing it.

It's possible they'll want to start with some sort of a hybrid, i.e.
take our new standard config, then bring their own stuff in, and then
let us migrate parts. If so the user is responsible for creating that
initial hybrid. If some other tooling helps them with that, all the
better, but that's out of scope for these ops.

>>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
>>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?
>>>
>>
>> The migrate operation is used to migrate a valid configuration. What you
>> describe is an invalid configuration, as the needed socket-binding is
>> not present.
>
> So if the migration approach is to "copy all required snippets from old
> configuration to the new one", I have to copy all dependencies (e.g.
> socket bindings) too. Makes sense, though maybe we had a different
> situation in mind here that I can't recollect now... :-(
>
>> The migration operation should not remove external configuration (e.g.
>> remove a socket-binding), as the ability to determine what other uses
>> there may be in the overall config for that config is beyond the scope
>> of the migration op handler.
>
> Sure.
>
>>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>>
>>
>> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
>> handler for the web subsystem migrate op) it looks to be adding a
>> security realm.
>
> This is probably the right thing to do, but we wanted to be sure. We've
> seen some possible problems with this (e.g. name collisions), so we
> thought that it's better to ask :-)
>

It's a good question. They all are. :)

What WebMigrateOperation does is create a synthetic realm name by
starting with a base name and adding a digit, looping and incrementing
the digit until it finds a name that doesn't collide.

>>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime  the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?
>>>
>>
>> I think the op should fail (not just warn) if the subsystem cannot be
>> properly migrated.
>
> I can agree both with this and with the other approach of "it's probably
> easier for the user to fixup the new subsystem then it is to repeatedly
> alter the old subsystem until you get something that will convert" [1].
>
> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html
>
> The idea here is that if the :migrate operation can see a possible
> problem, then the problem must be reported during :migrate and not only
> when the migrated server is started for the first time. Of course I
> agree with

Good point. I'll let Jason and the guys who actually wrote these respond
further.

The idea of warning is problematic. Management ops return a result or a
failure, not a result + a warning. We can of course warn in the server
log, but I think it's dangerous to reply with a success result and then
count on the possibly-remote user to notice a server log message.

If we don't warn but fail it certainly makes sense for these handlers to
defer failing as long as possible and gather up all problems into one
failure message.

>
>> That said, we need to be careful about having the scope of the handlers
>> grow too large, forcing handlers for one subsystem to be tightly coupled
>> to the implementation details of other subsystems or the kernel. Your
>> questions 2-4 relate to this kind of scope question. If the coupling
>> between different parts of the system starts to get too deep, IMO it
>> starts to move beyond the intended scope of these operations and into
>> the realm of higher level tools like Red Hat's Windup tool. It's a
>> judgement call but my feeling is what the handlers are currently doing
>> (e.g. the stuff I mention in my answer to #2) is reasonable.
>
> and my opinion here is that the :migrate operation should detect any
> possible problems that stem from the configuration of the old subsystem
> (e.g. an attribute in the old subsystem allowed values A|B|C, but the
> new subsystem only allows A|B). Problems caused elsewhere (socket
> bindings, other subsystems, ...) can be deferred to server startup.
>
> The key here is to agree on this :-)
>

I agree with that.

>>> 6. Should the extensions for old subsystems be left in configuration after migration?
>>>
>>
>> In a domain, yes. The migration of a subsystem in one profile does not
>> mean the extension is unavailable for use in another profile.
>>
>> I don't have a strong opinion about this in standalone.
>>
>> I do suspect there may be a technical barrier to removing the extension
>> though. If so I doubt we'll do it in WildFly 10.
>
> I think we're fine with leaving them there, this was just to clarify.
>
>>> 7. Should the :migrate operation return reload-required header?
>>>
>>
>> The migrate operations function by executing operations to add and
>> remove resources. If those operations themselves put the process in
>> reload-required, then the header will be returned. If not, it won't.
>>
>> The migrate operations all require that the process be running in
>> --admin-only mode. So I would not expect the outcome to be a need to put
>> the process in reload-required. Most likely that outcome would be a bug.
>> We use reload-required when changes to the persistent configuration
>> cannot be reflected in existing running services, but in --admin-only
>> there are no running services associated with these subsystems.
>
> Makes sense, thanks.
>
> LT
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

jtgreene
Administrator

> On Aug 10, 2015, at 11:33 AM, Brian Stansberry <[hidden email]> wrote:
>
> On 8/10/15 10:59 AM, Ladislav Thon wrote:
>> Brian, thanks for answering. I'll clarify some qustions below (and I
>> hope that others from our team will join too).
>>
>>>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?
>>>>
>>>
>>> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this
>>> part. Ideally this would be covered somewhere in
>>> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent
>>> is all three of these have common semantics.
>>>
>>> The biggest thing is these ops all require that the target process is
>>> running in --admin-only mode.
>>
>> This is mostly about clarifying what should I do before starting the new
>> server in --admin-only.
>>
>> In standalone -- am I supposed to copy snippets from old standalone.xml
>> to new standalone.xml?
>>
>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
>> connected to the ability of newer domain controller to manage older servers?
>>
>
> The intent here was not to let people start with a new standard config
> shipped by us and then use these ops to import stuff from a previous
> config. The expectation is they are starting with their existing config
> and changing it.
>
> It's possible they'll want to start with some sort of a hybrid, i.e.
> take our new standard config, then bring their own stuff in, and then
> let us migrate parts. If so the user is responsible for creating that
> initial hybrid. If some other tooling helps them with that, all the
> better, but that's out of scope for these ops.
>
>>>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
>>>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?
>>>>
>>>
>>> The migrate operation is used to migrate a valid configuration. What you
>>> describe is an invalid configuration, as the needed socket-binding is
>>> not present.
>>
>> So if the migration approach is to "copy all required snippets from old
>> configuration to the new one", I have to copy all dependencies (e.g.
>> socket bindings) too. Makes sense, though maybe we had a different
>> situation in mind here that I can't recollect now... :-(
>>
>>> The migration operation should not remove external configuration (e.g.
>>> remove a socket-binding), as the ability to determine what other uses
>>> there may be in the overall config for that config is beyond the scope
>>> of the migration op handler.
>>
>> Sure.
>>
>>>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>>>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>>>
>>>
>>> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
>>> handler for the web subsystem migrate op) it looks to be adding a
>>> security realm.
>>
>> This is probably the right thing to do, but we wanted to be sure. We've
>> seen some possible problems with this (e.g. name collisions), so we
>> thought that it's better to ask :-)
>>
>
> It's a good question. They all are. :)
>
> What WebMigrateOperation does is create a synthetic realm name by
> starting with a base name and adding a digit, looping and incrementing
> the digit until it finds a name that doesn't collide.
>
>>>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime  the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?
>>>>
>>>
>>> I think the op should fail (not just warn) if the subsystem cannot be
>>> properly migrated.
>>
>> I can agree both with this and with the other approach of "it's probably
>> easier for the user to fixup the new subsystem then it is to repeatedly
>> alter the old subsystem until you get something that will convert" [1].
>>
>> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html
>>
>> The idea here is that if the :migrate operation can see a possible
>> problem, then the problem must be reported during :migrate and not only
>> when the migrated server is started for the first time. Of course I
>> agree with
>
> Good point. I'll let Jason and the guys who actually wrote these respond
> further.

I was simply voicing an opinion at the time. I think the conversation ended at that point, and I didn’t feel strongly enough about it raise it again.

>
> The idea of warning is problematic. Management ops return a result or a
> failure, not a result + a warning. We can of course warn in the server
> log, but I think it's dangerous to reply with a success result and then
> count on the possibly-remote user to notice a server log message.

Right my thinking was the result would be the migration status. The actual migration is the actions it takes. Granted, a major challenge is that all of this work happens in a composite.




--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Brian Stansberry
On 8/10/15 3:23 PM, Jason Greene wrote:

>
>> On Aug 10, 2015, at 11:33 AM, Brian Stansberry <[hidden email]> wrote:
>>
>> On 8/10/15 10:59 AM, Ladislav Thon wrote:
>>> Brian, thanks for answering. I'll clarify some qustions below (and I
>>> hope that others from our team will join too).
>>>
>>>>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?
>>>>>
>>>>
>>>> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this
>>>> part. Ideally this would be covered somewhere in
>>>> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent
>>>> is all three of these have common semantics.
>>>>
>>>> The biggest thing is these ops all require that the target process is
>>>> running in --admin-only mode.
>>>
>>> This is mostly about clarifying what should I do before starting the new
>>> server in --admin-only.
>>>
>>> In standalone -- am I supposed to copy snippets from old standalone.xml
>>> to new standalone.xml?
>>>
>>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
>>> connected to the ability of newer domain controller to manage older servers?
>>>
>>
>> The intent here was not to let people start with a new standard config
>> shipped by us and then use these ops to import stuff from a previous
>> config. The expectation is they are starting with their existing config
>> and changing it.
>>
>> It's possible they'll want to start with some sort of a hybrid, i.e.
>> take our new standard config, then bring their own stuff in, and then
>> let us migrate parts. If so the user is responsible for creating that
>> initial hybrid. If some other tooling helps them with that, all the
>> better, but that's out of scope for these ops.
>>
>>>>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
>>>>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?
>>>>>
>>>>
>>>> The migrate operation is used to migrate a valid configuration. What you
>>>> describe is an invalid configuration, as the needed socket-binding is
>>>> not present.
>>>
>>> So if the migration approach is to "copy all required snippets from old
>>> configuration to the new one", I have to copy all dependencies (e.g.
>>> socket bindings) too. Makes sense, though maybe we had a different
>>> situation in mind here that I can't recollect now... :-(
>>>
>>>> The migration operation should not remove external configuration (e.g.
>>>> remove a socket-binding), as the ability to determine what other uses
>>>> there may be in the overall config for that config is beyond the scope
>>>> of the migration op handler.
>>>
>>> Sure.
>>>
>>>>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>>>>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>>>>
>>>>
>>>> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
>>>> handler for the web subsystem migrate op) it looks to be adding a
>>>> security realm.
>>>
>>> This is probably the right thing to do, but we wanted to be sure. We've
>>> seen some possible problems with this (e.g. name collisions), so we
>>> thought that it's better to ask :-)
>>>
>>
>> It's a good question. They all are. :)
>>
>> What WebMigrateOperation does is create a synthetic realm name by
>> starting with a base name and adding a digit, looping and incrementing
>> the digit until it finds a name that doesn't collide.
>>
>>>>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime  the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?
>>>>>
>>>>
>>>> I think the op should fail (not just warn) if the subsystem cannot be
>>>> properly migrated.
>>>
>>> I can agree both with this and with the other approach of "it's probably
>>> easier for the user to fixup the new subsystem then it is to repeatedly
>>> alter the old subsystem until you get something that will convert" [1].
>>>
>>> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html
>>>
>>> The idea here is that if the :migrate operation can see a possible
>>> problem, then the problem must be reported during :migrate and not only
>>> when the migrated server is started for the first time. Of course I
>>> agree with
>>
>> Good point. I'll let Jason and the guys who actually wrote these respond
>> further.
>
> I was simply voicing an opinion at the time. I think the conversation ended at that point, and I didn’t feel strongly enough about it raise it again.
>

Ok. Well, it's in the Beta implemented as "fail if there is a problem."
If anyone wants to change that, it's pretty much speak now or never.

>>
>> The idea of warning is problematic. Management ops return a result or a
>> failure, not a result + a warning. We can of course warn in the server
>> log, but I think it's dangerous to reply with a success result and then
>> count on the possibly-remote user to notice a server log message.
>
> Right my thinking was the result would be the migration status. The actual migration is the actions it takes. Granted, a major challenge is that all of this work happens in a composite.
>

That could work.

We also have a "describe-migration" op, for which the result is the list
of ops to take to do the migration yourself. (It doesn't actually do the
migration.) If we wanted some sort of "migration status" result for the
"migrate" op we'd need to change the structure of the
"describe-migration" result as well to additionally include that info.
The two should be consistent about this.

When you talk about "composite" are you referring to the not multi-step
nature of how these ops actually internally do the migration? If so
I don't think dealing with those other steps is practical. The only
thing we could warn about would be stuff the migration handler itself
identifies. If then there is some problem that occurs when executing the
add/remove steps the migration handler runs, I don't think it's
practical to do anything but fail.

>
>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Stuart Douglas
In reply to this post by Brian Stansberry

> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>

I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
handler for the web subsystem migrate op) it looks to be adding a
security realm.

Yes, at the moment I do create new security realms, and also add the IO subsystem with a default config if it is not already present. The names for the security realm will be jbossweb-migration-security-realm(n), where n is the lowest number that does not result in a name collision.

Stuart 

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

jtgreene
Administrator

On Aug 10, 2015, at 5:23 PM, Stuart Douglas <[hidden email]> wrote:


> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>

I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
handler for the web subsystem migrate op) it looks to be adding a
security realm.

Yes, at the moment I do create new security realms, and also add the IO subsystem with a default config if it is not already present. The names for the security realm will be jbossweb-migration-security-realm(n), where n is the lowest number that does not result in a name collision.


As an example of the fail-or-warn question, unless I am reading the code wrong, it looks like things which don’t have a mapping (e.g. tomcat valves) are ignored. Should the migration op fail if one is used, or should it return a warning?

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Stuart Douglas
I don't think it should fail, imagine how frustrating that would be from a users perspective, as the only course of action they have is to delete the relevant resource and try again. It would be much more user friendly IMHO to just let the op complete and then they can fix up any issues, they will still end up in the same situation, just with less work on their part.

Stuart



On Tue, 11 Aug 2015 at 10:40 Jason Greene <[hidden email]> wrote:

On Aug 10, 2015, at 5:23 PM, Stuart Douglas <[hidden email]> wrote:


> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>

I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
handler for the web subsystem migrate op) it looks to be adding a
security realm.

Yes, at the moment I do create new security realms, and also add the IO subsystem with a default config if it is not already present. The names for the security realm will be jbossweb-migration-security-realm(n), where n is the lowest number that does not result in a name collision.


As an example of the fail-or-warn question, unless I am reading the code wrong, it looks like things which don’t have a mapping (e.g. tomcat valves) are ignored. Should the migration op fail if one is used, or should it return a warning?

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Ladislav Thon
I agree 100% with a single note: before "they can fix up any issues",
they have to know that there are issues. If the :migrate operation knows
that there will be issues (e.g. valves present in the old subsystem), it
would be _very nice_ if it provided a warning :-) The earlier is the
user aware of [possible] issues, the better.

I believe that the :migrate operations _could_ return these warnings in
the operation result, but since Brian thinks that this is problematic,
I'll have to leave the details up to you, guys :-)

LT

On 11.8.2015 04:05, Stuart Douglas wrote:

> I don't think it should fail, imagine how frustrating that would be from
> a users perspective, as the only course of action they have is to delete
> the relevant resource and try again. It would be much more user friendly
> IMHO to just let the op complete and then they can fix up any issues,
> they will still end up in the same situation, just with less work on
> their part.
>
> Stuart
>
>
>
> On Tue, 11 Aug 2015 at 10:40 Jason Greene <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>>     On Aug 10, 2015, at 5:23 PM, Stuart Douglas
>>     <[hidden email] <mailto:[hidden email]>>
>>     wrote:
>>
>>
>>         > 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>>         > -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>         >
>>
>>         I'll let Stuart respond to this. Looking at the
>>         WebMigrateOperation (the
>>         handler for the web subsystem migrate op) it looks to be adding a
>>         security realm.
>>
>>
>>     Yes, at the moment I do create new security realms, and also add
>>     the IO subsystem with a default config if it is not already
>>     present. The names for the security realm will
>>     be jbossweb-migration-security-realm(n), where n is the lowest
>>     number that does not result in a name collision.
>>
>
>     As an example of the fail-or-warn question, unless I am reading the
>     code wrong, it looks like things which don’t have a mapping (e.g.
>     tomcat valves) are ignored. Should the migration op fail if one is
>     used, or should it return a warning?
>
>     --
>     Jason T. Greene
>     WildFly Lead / JBoss EAP Platform Architect
>     JBoss, a division of Red Hat
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Ladislav Thon
In reply to this post by Brian Stansberry
Inline.

>> This is mostly about clarifying what should I do before starting the new
>> server in --admin-only.
>>
>> In standalone -- am I supposed to copy snippets from old standalone.xml
>> to new standalone.xml?
>>
>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
>> connected to the ability of newer domain controller to manage older servers?
>>
>
> The intent here was not to let people start with a new standard config
> shipped by us and then use these ops to import stuff from a previous
> config. The expectation is they are starting with their existing config
> and changing it.

So this is in some ways the most important part of this discussion :-)

I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10
Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension
'org.jboss.as.threads' is not supported on servers running this version."

Removed the extension, started again, failed with "Unexpected element
'{urn:jboss:domain:threads:1.1}subsystem'" (of course!).

Removed the "threads" subsystem, started again, failed with two error
messages related to the "datasources" and "ejb3" subsystems.

Is this the intended workflow? I didn't get further, because I somehow
get a feeling that patching the new default configuration with relevant
bits from the old one will be easier when only a handful of changes in
the configuration were made, and probably on-par when the configuration
changes were more involved. Of course it's just a feeling, but the first
impression is important too :-)

> It's possible they'll want to start with some sort of a hybrid, i.e.
> take our new standard config, then bring their own stuff in, and then
> let us migrate parts. If so the user is responsible for creating that
> initial hybrid. If some other tooling helps them with that, all the
> better, but that's out of scope for these ops.

Of course, no question about that.

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Stuart Douglas


On Tue, 11 Aug 2015 at 17:59 Ladislav Thon <[hidden email]> wrote:
Inline.

>> This is mostly about clarifying what should I do before starting the new
>> server in --admin-only.
>>
>> In standalone -- am I supposed to copy snippets from old standalone.xml
>> to new standalone.xml?
>>
>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
>> connected to the ability of newer domain controller to manage older servers?
>>
>
> The intent here was not to let people start with a new standard config
> shipped by us and then use these ops to import stuff from a previous
> config. The expectation is they are starting with their existing config
> and changing it.

So this is in some ways the most important part of this discussion :-)

I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10
Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension
'org.jboss.as.threads' is not supported on servers running this version."

Removed the extension, started again, failed with "Unexpected element
'{urn:jboss:domain:threads:1.1}subsystem'" (of course!).

Removed the "threads" subsystem, started again, failed with two error
messages related to the "datasources" and "ejb3" subsystems.

These are bugs. EJB and datasources are still very much supported, I am going to look into this. 

Stuart

 

Is this the intended workflow? I didn't get further, because I somehow
get a feeling that patching the new default configuration with relevant
bits from the old one will be easier when only a handful of changes in
the configuration were made, and probably on-par when the configuration
changes were more involved. Of course it's just a feeling, but the first
impression is important too :-)

> It's possible they'll want to start with some sort of a hybrid, i.e.
> take our new standard config, then bring their own stuff in, and then
> let us migrate parts. If so the user is responsible for creating that
> initial hybrid. If some other tooling helps them with that, all the
> better, but that's out of scope for these ops.

Of course, no question about that.

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Brian Stansberry
In reply to this post by Ladislav Thon
On 8/11/15 1:39 AM, Ladislav Thon wrote:

> I agree 100% with a single note: before "they can fix up any issues",
> they have to know that there are issues. If the :migrate operation knows
> that there will be issues (e.g. valves present in the old subsystem), it
> would be _very nice_ if it provided a warning :-) The earlier is the
> user aware of [possible] issues, the better.
>
> I believe that the :migrate operations _could_ return these warnings in
> the operation result, but since Brian thinks that this is problematic,
> I'll have to leave the details up to you, guys :-)
>

It can be done, and IMHO must be done if the handler is ignoring aspects
of the migrated configuration. It just means altering the format of the
result of both the "migrate" and "describe-migration" operations.

The "warnings" can only be for items identified by the migration op
handler directly. If any of the various add/remove ops that that handler
tells the controller to execute fail, then the overall result will be a
failure. That is, no attempt to hack into the handling of those ops and
convert that kind of failure into a "warn".

I propose the following format for the "result" field of the migrate
operation response:

{
   "migration-warnings"=>[
     "WFXXX1234: the blah is blah",
     "WFXXX2345: the foo is barred"
    ]
}

For "describe-migration":



{
  "migration-warnings"=>[
   "WFXXX1234: the blah is blah",
   "WFXXX2345: the foo is barred"
  ],
  "migration-operations=>[
   { an operation },
   { another operation}
  ]
}

The value of the "migration-operations" field would be the same as the
overall result value currently produced by these ops.

> LT
>
> On 11.8.2015 04:05, Stuart Douglas wrote:
>> I don't think it should fail, imagine how frustrating that would be from
>> a users perspective, as the only course of action they have is to delete
>> the relevant resource and try again. It would be much more user friendly
>> IMHO to just let the op complete and then they can fix up any issues,
>> they will still end up in the same situation, just with less work on
>> their part.
>>
>> Stuart
>>
>>
>>
>> On Tue, 11 Aug 2015 at 10:40 Jason Greene <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>>      On Aug 10, 2015, at 5:23 PM, Stuart Douglas
>>>      <[hidden email] <mailto:[hidden email]>>
>>>      wrote:
>>>
>>>
>>>          > 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>>>          > -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>>          >
>>>
>>>          I'll let Stuart respond to this. Looking at the
>>>          WebMigrateOperation (the
>>>          handler for the web subsystem migrate op) it looks to be adding a
>>>          security realm.
>>>
>>>
>>>      Yes, at the moment I do create new security realms, and also add
>>>      the IO subsystem with a default config if it is not already
>>>      present. The names for the security realm will
>>>      be jbossweb-migration-security-realm(n), where n is the lowest
>>>      number that does not result in a name collision.
>>>
>>
>>      As an example of the fail-or-warn question, unless I am reading the
>>      code wrong, it looks like things which don’t have a mapping (e.g.
>>      tomcat valves) are ignored. Should the migration op fail if one is
>>      used, or should it return a warning?
>>
>>      --
>>      Jason T. Greene
>>      WildFly Lead / JBoss EAP Platform Architect
>>      JBoss, a division of Red Hat
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Brian Stansberry
In reply to this post by Ladislav Thon
On 8/11/15 2:59 AM, Ladislav Thon wrote:

> Inline.
>
>>> This is mostly about clarifying what should I do before starting the new
>>> server in --admin-only.
>>>
>>> In standalone -- am I supposed to copy snippets from old standalone.xml
>>> to new standalone.xml?
>>>
>>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
>>> connected to the ability of newer domain controller to manage older servers?
>>>
>>
>> The intent here was not to let people start with a new standard config
>> shipped by us and then use these ops to import stuff from a previous
>> config. The expectation is they are starting with their existing config
>> and changing it.
>
> So this is in some ways the most important part of this discussion :-)
>
> I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10
> Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension
> 'org.jboss.as.threads' is not supported on servers running this version."
>
> Removed the extension, started again, failed with "Unexpected element
> '{urn:jboss:domain:threads:1.1}subsystem'" (of course!).
>
> Removed the "threads" subsystem, started again, failed with two error
> messages related to the "datasources" and "ejb3" subsystems.
>
> Is this the intended workflow? I didn't get further, because I somehow
> get a feeling that patching the new default configuration with relevant
> bits from the old one will be easier when only a handful of changes in
> the configuration were made, and probably on-par when the configuration
> changes were more involved. Of course it's just a feeling, but the first
> impression is important too :-)
>

Yes, that's the intended workflow, in terms of migration tooling the
WildFly will provide.

I think it makes sense to look into how we can ease pain as much as
possible though. Things that fail, we should see if they can be made to
not fail.

For example, an empty threads subsystem is meaningless, so if the tread
subsystem parser is running in a server and it sees the element is empty
it could just basically become a no-op and not install the subsystem
instead of registering an pointless subsystem that will just fail.


>> It's possible they'll want to start with some sort of a hybrid, i.e.
>> take our new standard config, then bring their own stuff in, and then
>> let us migrate parts. If so the user is responsible for creating that
>> initial hybrid. If some other tooling helps them with that, all the
>> better, but that's out of scope for these ops.
>
> Of course, no question about that.
>
> LT
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Easing migration beyond the migration ops

Brian Stansberry
I've changed the title of this branch of the thread to better reflect
this part of the topic. Plus to make it stand out more. :)

More below.

On 8/11/15 10:11 AM, Brian Stansberry wrote:
> On 8/11/15 2:59 AM, Ladislav Thon wrote:
>> Inline.
>>
>>>> This is mostly about clarifying what should I do before starting the
>>>> new
>>>> server in --admin-only.
>>>>

I think it makes sense to make a requirement that the user should not
have to do anything before starting in --admin-only.

IOW, any logic we have that rejects something on a server should not do
so in --admin-only. Instead it should log a WARN advising what the user
should do to correct the config. For example, "To correct this, remove
the cmp subsystem." The user can then do that if they wish.

In normal running mode if the config specifies things we cannot support
then failing is appropriate. (There may be odd cases where for obscure
stuff we decide to warn and not fail, but generally we'd fail.)

>>>> In standalone -- am I supposed to copy snippets from old standalone.xml
>>>> to new standalone.xml?
>>>>
>>>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
>>>> connected to the ability of newer domain controller to manage older
>>>> servers?
>>>>
>>>
>>> The intent here was not to let people start with a new standard config
>>> shipped by us and then use these ops to import stuff from a previous
>>> config. The expectation is they are starting with their existing config
>>> and changing it.
>>
>> So this is in some ways the most important part of this discussion :-)
>>
>> I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10
>> Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension
>> 'org.jboss.as.threads' is not supported on servers running this version."
>>
>> Removed the extension, started again, failed with "Unexpected element
>> '{urn:jboss:domain:threads:1.1}subsystem'" (of course!).
>>
>> Removed the "threads" subsystem, started again, failed with two error
>> messages related to the "datasources" and "ejb3" subsystems.
>>
>> Is this the intended workflow? I didn't get further, because I somehow
>> get a feeling that patching the new default configuration with relevant
>> bits from the old one will be easier when only a handful of changes in
>> the configuration were made, and probably on-par when the configuration
>> changes were more involved. Of course it's just a feeling, but the first
>> impression is important too :-)
>>
>
> Yes, that's the intended workflow, in terms of migration tooling the
> WildFly will provide.
>
> I think it makes sense to look into how we can ease pain as much as
> possible though. Things that fail, we should see if they can be made to
> not fail.
>
> For example, an empty threads subsystem is meaningless, so if the tread
> subsystem parser is running in a server and it sees the element is empty
> it could just basically become a no-op and not install the subsystem
> instead of registering an pointless subsystem that will just fail.
>

This would be a specific behavior beyond the general behavior that I
talk about early in this post. It could happen regardless of --admin-only.

There are other "legacy only" subsystems (cmp and jaxr) that also allow
an "empty" config. But I don't think this behavior is appropriate for
those. Those subsystems differ from "threads" in that even an empty
config affects server (i.e. deployment processing) behavior.

>
>>> It's possible they'll want to start with some sort of a hybrid, i.e.
>>> take our new standard config, then bring their own stuff in, and then
>>> let us migrate parts. If so the user is responsible for creating that
>>> initial hybrid. If some other tooling helps them with that, all the
>>> better, but that's out of scope for these ops.
>>
>> Of course, no question about that.
>>
>> LT
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Migration management operation - open questions

Ladislav Thon
In reply to this post by Brian Stansberry
Inline.

>> I believe that the :migrate operations _could_ return these warnings in
>> the operation result, but since Brian thinks that this is problematic,
>> I'll have to leave the details up to you, guys :-)
>>
>
> It can be done, and IMHO must be done if the handler is ignoring aspects
> of the migrated configuration.

100% agreed.

> It just means altering the format of the
> result of both the "migrate" and "describe-migration" operations.
>
> The "warnings" can only be for items identified by the migration op
> handler directly. If any of the various add/remove ops that that handler
> tells the controller to execute fail, then the overall result will be a
> failure. That is, no attempt to hack into the handling of those ops and
> convert that kind of failure into a "warn".

I think this is expected and I'm fine with it.

> I propose the following format for the "result" field of the migrate
> operation response:
>
> {
>    "migration-warnings"=>[
>      "WFXXX1234: the blah is blah",
>      "WFXXX2345: the foo is barred"
>     ]
> }

The "result" field currently contains a name and version of newly
created subsystem, which should probably be preserved:

[standalone@localhost:9990 /] /subsystem=jacorb:migrate
{
    "outcome" => "success",
    "result" => [("iiop-openjdk" => "1.0.0")]
}

> For "describe-migration":
>
>
>
> {
>   "migration-warnings"=>[
>    "WFXXX1234: the blah is blah",
>    "WFXXX2345: the foo is barred"
>   ],
>   "migration-operations=>[
>    { an operation },
>    { another operation}
>   ]
> }
>
> The value of the "migration-operations" field would be the same as the
> overall result value currently produced by these ops.

Sounds good.

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Easing migration beyond the migration ops

Ladislav Thon
In reply to this post by Brian Stansberry
> I think it makes sense to make a requirement that the user should not
> have to do anything before starting in --admin-only.

This would be best.

However, if there's not enough time to do everything requried, then I
believe that low-risk things like "remove the threads extension and the
threads subsystem" could be left to the user (provided that they are
documented).

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Easing migration beyond the migration ops

Tomaž Cerar-2

On Wed, Aug 12, 2015 at 9:18 AM, Ladislav Thon <[hidden email]> wrote:

However, if there's not enough time to do everything requried, then I
believe that low-risk things like "remove the threads extension and the
threads subsystem" could be left to the user (provided that they are
documented).


I think we could ease the threads subsystem migration.
For most cases threads subsystem configuration is empty as it was just present
in our default config as <subsystem xmlns="urn:jboss:domain:threads:1.x"/>

We can change parser that in case that only empty config is present it wont
add the subsystem at all, this should ease the migration for users migrating default configurations.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Easing migration beyond the migration ops

Brian Stansberry
In reply to this post by Ladislav Thon
On 8/12/15 2:18 AM, Ladislav Thon wrote:

>> I think it makes sense to make a requirement that the user should not
>> have to do anything before starting in --admin-only.
>
> This would be best.
>
> However, if there's not enough time to do everything requried, then I
> believe that low-risk things like "remove the threads extension and the
> threads subsystem" could be left to the user (provided that they are
> documented).
>

I expect we can do what's needed. At least for the standard configs we
shipped, which are easily to load and thereby find problems.

https://github.com/wildfly/wildfly-core/pull/953 is a big (and quite
simple) step.

> LT
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123