Re: [Spacewalk-devel] What do I do with all those potential bugzillas ?
On Wed, Jul 21, 2010 at 11:17:57PM +0200, Jerome Fenal wrote: still ongoing on my Perl OO API for Spacewalk/Satellite, I have collected quite a few glitches during development (unit test helps here). As the number is growing, I'm getting a bit concerned of not taking care of those... :) You can find those here : http://github.com/jfenal/RHNC/blob/master/Bugzillas.txt Do you want me to open a bugzilla for each of those, or may I Yes, one bugzilla per issue, please. It is easier for people to pick one small thing and create and submit patch than to work with mega-bugzilla that lists multiple issues. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Suggestions for sysdate, for PostgreSQL?
On Wed, Jul 21, 2010 at 06:21:04PM -0400, Tom Lane wrote: Jan Pazdziora jpazdzi...@redhat.com writes: what are our possibilities for handling sysdate in PostgreSQL. Isn't s/sysdate/current_timestamp/g a good solution? That's standards compliant, unlike sysdate. I wouldn't dare to do that en masse. It's a different type -- timestamp instead of date, so it has different precision, and I'm not sure if the arithmetic is exactly the same. But you are right, we could just change that one-by-one, verifying any side effect of the change, as we keep hitting the sysdate errors. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Migrating systems
- 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
Re: [Spacewalk-devel] Migrating systems
On Thu, Jul 22, 2010 at 5:32 PM, Tomas Lestach tlest...@redhat.com wrote: - 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 Hi Tomas OK, I'll leave the subscriptions and entitlements for now, but I'd like to revisit it later. My perspective is that Satellite/Spacewalk exists to make management easier. Stripping the entitlements and subscriptions (esp on virt platforms) potentially means a lot of extra work for sys admins. Just my $0.02 :) CC -- RHCE#805007969328369 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Fri, Jul 09, 2010 at 07:37:48PM -0400, Tom Lane wrote: That page mentions that you can't install on RHEL5 because RHEL5's version of postgresql is too old (8.1). While that's true, as of now we are shipping postgresql84 for RHEL5, which provides 8.4.x. So if anyone cares about testing on RHEL5, it should be sufficient to change the dependencies to reference postgresql84 instead of Thanks for the pointer. I've now changed the documentation to yum install -y 'postgresql-server 8.4' which seems to do the right thing both on Fedora 12 and RHEL 5. So the setup is usable on RHEL 5 / CentOS 5 as well. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Migrating systems
Might I suggest having a look at using the activation key(s) in the new org?? It might be useful, if feasable. - Original Message - From: Colin Coe colin@gmail.com To: spacewalk-devel@redhat.com Sent: Thursday, July 22, 2010 5:44:17 AM Subject: Re: [Spacewalk-devel] Migrating systems On Thu, Jul 22, 2010 at 5:32 PM, Tomas Lestach tlest...@redhat.com wrote: - 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 Hi Tomas OK, I'll leave the subscriptions and entitlements for now, but I'd like to revisit it later. My perspective is that Satellite/Spacewalk exists to make management easier. Stripping the entitlements and subscriptions (esp on virt platforms) potentially means a lot of extra work for sys admins. Just my $0.02 :) 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
Re: [Spacewalk-devel] Migrating systems
Colin Coe 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 I love this - really I do. But, can you make it a check box for user to select if they want to do this. Custom child channels would be the most obvious way this would break, or fact that the other org does not have say enough provisioning entitlements. Further, adding this to the API call would be great also (but I won't push you - users can script this easily today using other API calls to query subscriptions before move then re-apply via API calls post migration). The error message handling for failure cases need to be clean and easy to understand why the move failed before the user re-trys. Cliff 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. Thanks CC ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Migrating systems
chuck.rens...@comcast.net wrote: Might I suggest having a look at using the activation key(s) in the new org?? It might be useful, if feasable. During initial development of the system migrate API we considered activation key usage, but did not implement this. The reason being that activation key logic for entitlements and subscriptions is all in the python backend code. The API and new WebUI that Colin is working on is in Java. We would either need to re-create/duplicate a whole bunch of activation key logic or somehow call to the python code with systemid and activationkey, plus re-activation key to apply to system in new Org. In short, not as easy as it would seem. Activation key usage is a clean solution for concerns about other org entitlements, since Org B's orgadmin would provide an activatoin key to Org A's orgadmin to use during the migration, in other words, there was communication going on by both Org admin's before the migration occurred and no one is surprised :) Multi-Org, with trusts was a very interesting internal discussion on topics of us not assuming departments (org admin's) talk to each other and how much we allow for easy abuse or not. We also have to ensure we do not leak data from one org to another which the other org should not know about. Sat Admin roles see brief information on all orgs and their entitlement usage/allocations and sets up trusts for orgs. Org Admins manage their orgs in self contained private worlds. We have to make sure that these lines are not blurred. :) Cliff. - Original Message - From: Colin Coe colin@gmail.com To: spacewalk-devel@redhat.com Sent: Thursday, July 22, 2010 5:44:17 AM Subject: Re: [Spacewalk-devel] Migrating systems On Thu, Jul 22, 2010 at 5:32 PM, Tomas Lestach tlest...@redhat.com wrote: - 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.
Re: [Spacewalk-devel] Migrating systems
It was just a thought, but, it really doesn't sound worth it. - Original Message - From: Cliff Perry cpe...@redhat.com To: spacewalk-devel@redhat.com Sent: Thursday, July 22, 2010 11:22:59 AM Subject: Re: [Spacewalk-devel] Migrating systems chuck.rens...@comcast.net wrote: Might I suggest having a look at using the activation key(s) in the new org?? It might be useful, if feasable. During initial development of the system migrate API we considered activation key usage, but did not implement this. The reason being that activation key logic for entitlements and subscriptions is all in the python backend code. The API and new WebUI that Colin is working on is in Java. We would either need to re-create/duplicate a whole bunch of activation key logic or somehow call to the python code with systemid and activationkey, plus re-activation key to apply to system in new Org. In short, not as easy as it would seem. Activation key usage is a clean solution for concerns about other org entitlements, since Org B's orgadmin would provide an activatoin key to Org A's orgadmin to use during the migration, in other words, there was communication going on by both Org admin's before the migration occurred and no one is surprised :) Multi-Org, with trusts was a very interesting internal discussion on topics of us not assuming departments (org admin's) talk to each other and how much we allow for easy abuse or not. We also have to ensure we do not leak data from one org to another which the other org should not know about. Sat Admin roles see brief information on all orgs and their entitlement usage/allocations and sets up trusts for orgs. Org Admins manage their orgs in self contained private worlds. We have to make sure that these lines are not blurred. :) Cliff. - Original Message - From: Colin Coe colin@gmail.com To: spacewalk-devel@redhat.com Sent: Thursday, July 22, 2010 5:44:17 AM Subject: Re: [Spacewalk-devel] Migrating systems On Thu, Jul 22, 2010 at 5:32 PM, Tomas Lestach tlest...@redhat.com wrote: - 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
[Spacewalk-devel] java db connection changes
So in order to use Michael's new connection code, you'll need to add a variable to rhn.conf: hibernate.connection.driver_proto=jdbc:log:oracle.jdbc.driver.OracleDriver:oracle:thin Michael originally wrote it to only use the oci driver, but i've added support for the thin as well, since i'm not sure we'll be able to use the oci driver. -Justin ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacecmd will be in next version of Spacewalk
Hey Miroslav, I picked up reviewing spacecmd for Fedora 13. My review fu isn't that great, but I figured this isn't a really complicated package anyway. Hope this helps. Regards, Maxim Burgerhout ma...@wzzrd.com GPG Fingerprint EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A 2010/7/19 Miroslav Suchý msu...@redhat.com: Those of you who watch commits can notice that spacecmd landed to Spacewalk git repo. Aron Parsons (apars...@redhat.com) will be primary owner of this component. If you want to see this package in Fedora and Epel, grab this review: https://bugzilla.redhat.com/show_bug.cgi?id=616120 Despite of @redhat.com in Aron email, he is not part of RHN Satellite team and he is 3rd person from general Spacewalk community who deserved direct write access source code! Congrats! I'm happy to see our developer community is growing. -- Miroslav Suchy Red Hat Satellite Engineering ___ 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
Re: [Spacewalk-devel] Migrating systems
Colin Coe wrote: Hi Cliff After Tom's comments, I thought I'd hold off and consider it more. RE the checkbox, I thought I'd display the check box to do this only if it was the Sat admin as one org admin has no visibility of whats happening in a different org. Can I ask if there is any chance of this webUI change making it into RHN Sat v5.4? I figured there was probably still time as the API call migrateSystems (not migrating Xen hosts) was listed as a block for v5.4? This work was sponsored by one of my clients who will be doing a lot of migrations. I'm sure we can keep it in consideration. Cliff. PS - Email communication via more private channels with known NDA for a customer to allow us to share Satellite release schedules, scope and will likely allow me to give a more specific answer than a public list reply. CC ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
