Re: [wildfly-dev] Management operation for legacy subsystem migration

Conversion between subsystems is fairy staightforward as they are very similiar. The problem is that the jacorb subsystem, from which :migrate operation is executed, has also a compatibility subsystem role. What is more it behaves differently in standalone and domain mode. Standalone subsystem emulates jacorb and as a result of that it checks that all properties can be emulated - it they can't the server won't start. On the other hand domain controller does not reject properties as it may send them to hosts with jacorb subsystem. So migrate operation in standalone mode works the way Jeff describe it but the "rinse and repeat" stage is moved to server startup. It has a runtime though. Migrate operation in domain mode requires discussion. Point 3 does not apply to iiop - no data is moved. -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Original Message ----- From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; To: wildfly-dev(a)lists.jboss.org Sent: Wednesday, April 29, 2015 4:58:07 PM Subject: Re: [wildfly-dev] Management operation for legacy subsystem migration On 4/29/15 9:00 AM, Jeff Mesnil wrote: I don't see why this needs to be a requirement. In the jacorb case, it will be violated, as the jacorb subsystem can run as a kind of "compatibility subsystem", delegating to the iiop-openjdk runtime services as long as the config doesn't specify any settings that can't be translated. +1 for server It would be very nice to say the same for the DC, but it's worth discussing. Requiring the DC to be in admin-only creates a fair bit of usability downside. The whole domain reacts when the DC goes away. Once we have automatic failover of the DC, it may result in the failover DC taking over, introducing other problems. (Ken Wills -- this is one to think about in general re: DC failover.) It's possible we could allow a migration to happen on a profile where there aren't any servers running. The basic domain rollout behavior would allow this without any change. If the HCs allowed the migrate op to run, and then it gets rolled out to any affected servers, the servers will reject the op (as they aren't admin-only.) So the op will be rolled back. (Except in an extreme corner case where the user specifies a rollout plan that says all servers can fail.) +1 There needs to be validation as to whether the extension is already present; if so skip the add. This is an edge case on a server but is fairly likely on a DC, where the extension may be used in profile-new, and now the users wants to migrate the subsystem in profile-old. Also, we're going to need to change how the "composite" op works, as including an extension=foo:add in the same composite as steps that touch its subsystems won't work. There's a JIRA for this, but JIRA doesn't seem to be responding at the moment. There's a workaround for that issue if necessary; just have the migrate op add a step that deals with the extension add and then a next step with the composite. The return value should be the same regardless of the value of that attribute. Ops have single return value description. We need to be careful about RBAC. This basically amounts to one op that then convinces the server to do a whole bunch of other stuff. A simple thing there is to just mark the op as sensitive. That's conservative but inelegant. I don't think that's necessary though. The return value from this op is a bunch of steps. That provides a lot of data the user may not be authorized to see. But, to provide that data, you're going to do a lot of reads, and the access control layer will reject the reads if the user is not authorized. So the user shouldn't be able to use this to see data they shouldn't. As for writes, if the users isn't authorized to do the writes, then they will fail. Oh, I should have read the whole thing before starting to reply! Sounds good. We need to think in general about the domain case. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev