----- "Colin Coe" <colin....@gmail.com> wrote: > On Thu, Jul 22, 2010 at 11:42 AM, Colin Coe <colin....@gmail.com> > wrote: > > Yay! It works, systems can be migrated via the webUI. > > > > The only problem is that all entitlements get stripped (management, > > provisioning, etc) and software channel memberships are lost also. > > Given I'm doing the migration by calling > > "MigrationManager.migrateServers(user, toOrg, serverList);" I'm > > thinking that the problem is in the MigrationManager code. Does > that > > sound right or is it more likely to be my code? > > > > Thanks > > > > CC > > > > I've done some hacking in > 'code/src/com/redhat/rhn/manager/org/MigrationManager.java' and added > functionality to preserve and then restore: > - base software channel > - child software channels > - entitlements > > Is this OK to apply to the git tree? I ask as I'm wondering if this > was considered but rejected for business or logic reasons.
Hey Colin, I didn't know we have an API for system migration! :-) First, when you mentioned migration of system between two orgs, I was a bit afraid because of entitlements, all the tables we have to touch and all the stuff. Not trivial. But when you've mentioned MigrationManager, I found out, we already support it! :-)) I checked the MigrationManager code very quick and I'd most probably take it as is - like you said - all the entitlements get stripped - and I'd say it's good. The thing is you do not know, if the new org has any free entitlements, the system could use (or let's say - there's a free management entitlement, but not a provisioning one). Also regarding software channel entitlements - you do not know, if there're some free. And combinations - if there's a free base channel entitlement, but no free child channel entitlements - what will you do - fail? pass? Maybe what would we do in case the base channel of the system is a custom channel? not support?/fail? just strip entitlements? Of course, we can check all these before the operation, but would we refuse the system migration just because there's custom channel missing in the new org? There's of course a chance to do as much a possible - so if an entitlement is available, just reserve it, if a channel is visible in the new org and there's a free entitlement, just subscribe to it, otherwise skip it. But I'd like to prevent such a procedure - because there's not a defined end state - nobody would now what passed, what not and why. And that's the reason I agree with stripping the entitlements and not touching channel subscriptions. Another possibility is to offer a few checkboxes to the user - something like - if a system had a provisioning entitlement and there's a free provisioning entitlement in the new org, offer a checkbox to the user if the system shall be entitled in the new org. And fail the whole operation, if it one of the sub-operations failed. But - most probably - to have the checkboxes only for the satellite admin, because the org admin of one org shouldn't touch the (channel)/entitlements of another org, because he cannot be org admin of two organizations. The situation is complex and we have to suppose org admin of the previous org, org admin of the new org and satellite admin are three different people (that may not know each other) and it's the org admin, who wants to set up the migrated system in his org and way. That's my opinion. Anyway - introducing system migration in webUI is a very good idea! But even a simpler solution could be a very good one. :-) Regards, Tomas > > Thanks > > CC > > -- > RHCE#805007969328369 > > _______________________________________________ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
