Re: [Spacewalk-devel] something didn't get pushed or commited
On Wed, May 06, 2009 at 11:16:25PM -0400, Jesus M. Rodriguez wrote: > trying to tag spacewalk-proxy-monitoring.spec I noticed the version > was 0.6.4 but > it stated it was 'Not committed yet' > > http://pastebin.com/m623f41b9 > > Not sure what's going on here. Not committed yet means that you have some local change (0.6.2 -> 0.6.4, I assume) in your working copy. -- Jan Pazdziora Senior 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] Re: something funky is going on with building/tagging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 6 May 2009 22:58:27 -0400 "Jesus M. Rodriguez" wrote: > along the same lines, 'tito report' mentioned a problem with the > spacewalk-monitoring-selinux packaging tagging. > When i tried to retag it, I got a messy stack trace. > > http://pastebin.com/m331abf84 > > jesus > > On Wed, May 6, 2009 at 10:47 PM, Jesus M. Rodriguez > wrote: > > I'm seeing weird errors more and more often now with building in > > master. while pushing the branding tags in master. > > > > fatal: Invalid revision range > > ..20840c06cc33f00a9457d271c9eaeb1563ebd494 > > > > thoughts? > > > > jesus > > > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel Author: Jan Pazdziora AuthorDate: Tue May 5 17:22:32 2009 +0200 Commit: Jan Pazdziora CommitDate: Tue May 5 17:22:32 2009 +0200 Automatic commit of package [spacewalk-monitoring-selinux] release [0.6.4-1]. I think it's just a missing git push --tags, the tag doesn't seem to be there. This is breaking in the new auto-changelog stuff so if you ever hit something like this you can just use --no-auto-changelog until we get it fixed up. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkoC1ywACgkQAyHWaPV9my6vPwCgjevMJdaxs4fT/shF7DIZaqRe oywAnjD0jhx7KOdCNXelHiC5sXIQVRDC =E2oM -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: something funky is going on with building/tagging
On Thu, May 07, 2009 at 09:42:16AM -0300, Devan Goodwin wrote: > > Author: Jan Pazdziora > AuthorDate: Tue May 5 17:22:32 2009 +0200 > Commit: Jan Pazdziora > CommitDate: Tue May 5 17:22:32 2009 +0200 > > Automatic commit of package [spacewalk-monitoring-selinux] release > [0.6.4-1]. > > I think it's just a missing git push --tags, the tag doesn't seem to be > there. This is breaking in the new auto-changelog stuff so if you ever > hit something like this you can just use --no-auto-changelog until we > get it fixed up. Ah, sorry about that. Pushed now. -- Jan Pazdziora Senior 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] Channel Name Length
Before we open up this can of worms again look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=459827 (sorry private bug) jesus "Increasing the length of the column probably isn't the right solution. " Is there more to it than that (referring to the can of worms comment, I'm guessing there was a non-documented debate)? I'm not seeing a real reason why increasing the name to match the label size is a bad idea. This has come up twice in BZs now and I just saw it on the satellite mailing list as well. -- Jason Dobies RHN Satellite / Spacewalk RHCE# 805008743336126 Freenode: jdob @ #spacewalk #spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
On Thu, May 07, 2009 at 09:07:13AM -0400, Jason Dobies wrote: >> Before we open up this can of worms again look at this bug: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=459827 (sorry private bug) >> >> jesus > > "Increasing the length of the column probably isn't the right solution. " > > Is there more to it than that (referring to the can of worms comment, > I'm guessing there was a non-documented debate)? I'm not seeing a real > reason why increasing the name to match the label size is a bad idea. > This has come up twice in BZs now and I just saw it on the satellite > mailing list as well. Isn't the main problem here the fact that whatever limit you chose, if the original channel is at or near the limit, the cloned one will be over limit? So the real fix is to - match the textfield length in the WebUI to the column width, whatever that one is; - if the generated name would end up longer, truncate it in such a way that the name is still unique; - when handling the form, verify that the data is indeed shorter or equal the column width. -- Jan Pazdziora Senior 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] Re: something funky is going on with building/tagging
On Thu, May 07, 2009 at 09:42:16AM -0300, Devan Goodwin wrote: [snip] > I think it's just a missing git push --tags, the tag doesn't seem to be > there. This is breaking in the new auto-changelog stuff so if you ever > hit something like this you can just use --no-auto-changelog until we > get it fixed up. > > Devan Ah ok good to know both sides of the problem. -- jesus m. rodriguez| jes...@redhat.com sr. software engineer | irc: zeus rhn satellite & spacewalk | 919.754.4413 (w) rhce # 805008586930012| 919.623.0080 (c) +---+ | "Those who cannot learn from history | | are doomed to repeat it." | | -- George Santayana | +---+ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
Isn't the main problem here the fact that whatever limit you chose, if the original channel is at or near the limit, the cloned one will be over limit? So the real fix is to - match the textfield length in the WebUI to the column width, whatever that one is; - if the generated name would end up longer, truncate it in such a way that the name is still unique; - when handling the form, verify that the data is indeed shorter or equal the column width. That's what I was getting at in my original e-mail, that the truncation is the answer (though based on the other BZ it looks like that's explicitly not the desired approach). The question of the channel name length came up related to this since if Red Hat channels themselves are so close to the limit, customer channels might be as well. Since we give the extra space for labels, why not raise name to match that? -- Jason Dobies RHN Satellite / Spacewalk RHCE# 805008743336126 Freenode: jdob @ #spacewalk #spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
On Thu, May 07, 2009 at 09:07:13AM -0400, Jason Dobies wrote: >> Before we open up this can of worms again look at this bug: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=459827 (sorry private bug) >> >> jesus > > "Increasing the length of the column probably isn't the right solution. " > > Is there more to it than that (referring to the can of worms comment, > I'm guessing there was a non-documented debate)? I'm not seeing a real > reason why increasing the name to match the label size is a bad idea. > This has come up twice in BZs now and I just saw it on the satellite > mailing list as well. I guess the debate was how big is big enough? At what point do we stop? If we make it 256 and we get to cloning a channel that creates a name of 257 what then? We're back in the same place we started? The problem was found because we (Spacewalk) were autogenerating an invalid name that was larger than the db column. So we can make it 256 and still have the same problem. How do we deal with the case where the auto generated name is longer than the allotted space? message to the user that it is too long? truncate? prompt for the name ALWAYS? I'm not really opposed to increasing it, I'm more opposed to increasing the column and simply postponing the problem. -- jesus m. rodriguez| jes...@redhat.com sr. software engineer | irc: zeus rhn satellite & spacewalk | 919.754.4413 (w) rhce # 805008586930012| 919.623.0080 (c) +---+ | "Those who cannot learn from history | | are doomed to repeat it." | | -- George Santayana | +---+ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: something funky is going on with building/tagging
On Thu, May 07, 2009 at 02:47:48PM +0200, Jan Pazdziora wrote: > On Thu, May 07, 2009 at 09:42:16AM -0300, Devan Goodwin wrote: > > > > Author: Jan Pazdziora > > AuthorDate: Tue May 5 17:22:32 2009 +0200 > > Commit: Jan Pazdziora > > CommitDate: Tue May 5 17:22:32 2009 +0200 > > > > Automatic commit of package [spacewalk-monitoring-selinux] release > > [0.6.4-1]. > > > > I think it's just a missing git push --tags, the tag doesn't seem to be > > there. This is breaking in the new auto-changelog stuff so if you ever > > hit something like this you can just use --no-auto-changelog until we > > get it fixed up. > > Ah, sorry about that. Pushed now. Thanks a bunch. jesus -- jesus m. rodriguez| jes...@redhat.com sr. software engineer | irc: zeus rhn satellite & spacewalk | 919.754.4413 (w) rhce # 805008586930012| 919.623.0080 (c) +---+ | "Those who cannot learn from history | | are doomed to repeat it." | | -- George Santayana | +---+ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
On Thu, May 07, 2009 at 03:21:45PM +0200, Jan Pazdziora wrote: > On Thu, May 07, 2009 at 09:07:13AM -0400, Jason Dobies wrote: > >> Before we open up this can of worms again look at this bug: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=459827 (sorry private bug) > >> > >> jesus > > > > "Increasing the length of the column probably isn't the right solution. " > > > > Is there more to it than that (referring to the can of worms comment, > > I'm guessing there was a non-documented debate)? I'm not seeing a real > > reason why increasing the name to match the label size is a bad idea. > > This has come up twice in BZs now and I just saw it on the satellite > > mailing list as well. > > Isn't the main problem here the fact that whatever limit you chose, if > the original channel is at or near the limit, the cloned one will be > over limit? So the real fix is to PRECISELY :) > > - match the textfield length in the WebUI to the column width, > whatever that one is; already done, the problem is we autogenerate the string and generate the HTML with that value. If you tried to type more into the field the browser does the right thing and won't let you. But it WILL accept the string we said should go in there from the rendering side. I put in code to capture this case, and show an error indicating that it has to be no more than 64 (size of column now) and list of valid characters. > - if the generated name would end up longer, truncate it in such a way > that the name is still unique; That was an option, but required to do a query to figure out how to make it unique without resorting to a random(). > - when handling the form, verify that the data is indeed shorter or > equal the column width. It does do that :) -- jesus m. rodriguez| jes...@redhat.com sr. software engineer | irc: zeus rhn satellite & spacewalk | 919.754.4413 (w) rhce # 805008586930012| 919.623.0080 (c) +---+ | "Those who cannot learn from history | | are doomed to repeat it." | | -- George Santayana | +---+ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
I guess the debate was how big is big enough? At what point do we stop? If we make it 256 and we get to cloning a channel that creates a name of 257 what then? We're back in the same place we started? My original intent is getting lost. I'm not suggesting that increasing it is the ultimate solution, but if we have Red Hat channels currently very close to the max, it's possible that customers are getting close as well. As for when we stop, sure, theoretically you could always argue that there could be a longer name, but let's be realistic here. -- Jason Dobies RHN Satellite / Spacewalk RHCE# 805008743336126 Freenode: jdob @ #spacewalk #spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
On Thu, May 07, 2009 at 10:06:37AM -0400, Jason Dobies wrote: >> Isn't the main problem here the fact that whatever limit you chose, if >> the original channel is at or near the limit, the cloned one will be >> over limit? So the real fix is to >> >> - match the textfield length in the WebUI to the column width, >> whatever that one is; >> - if the generated name would end up longer, truncate it in such a way >> that the name is still unique; >> - when handling the form, verify that the data is indeed shorter or >> equal the column width. > > That's what I was getting at in my original e-mail, that the truncation > is the answer (though based on the other BZ it looks like that's > explicitly not the desired approach). > > The question of the channel name length came up related to this since if > Red Hat channels themselves are so close to the limit, customer channels > might be as well. Since we give the extra space for labels, why not > raise name to match that? Ok let's just do this 1) increase the size to something reasonable, say 256 2) ensure that when we autogenerate the name that is > max, we show the user an error message and have them edit the channel name to something shorter that they might like. 3) open a cold one and call it a day. -- jesus m. rodriguez| jes...@redhat.com sr. software engineer | irc: zeus rhn satellite & spacewalk | 919.754.4413 (w) rhce # 805008586930012| 919.623.0080 (c) +---+ | "Those who cannot learn from history | | are doomed to repeat it." | | -- George Santayana | +---+ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
3) open a cold one and call it a day. One step ahead of you. :D -- Jason Dobies RHN Satellite / Spacewalk RHCE# 805008743336126 Freenode: jdob @ #spacewalk #spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] Recognize KVM/QEMU guests as virtual systems
Hi all:
Attached are two patches. The first changes how smbios data is handled
during registration, to send it when the server is created (so that,
similar to xen, it can get free entitlements if appropriate). The second
are the matching server side changes to parse the sent smbios data for
indications that the registering system is a KVM/QEMU guest.
Right now this just sets the guest type as fully virt. It might be nice
to add a third type for KVM/QEMU.
-James
From b57e391c38abd99292d6062b9d258dceeb6f6c32 Mon Sep 17 00:00:00 2001
From: James Bowes
Date: Thu, 7 May 2009 09:48:50 -0400
Subject: [PATCH] Send smbios data in the new_system() call
smbios data has to be sent during or before registration, in case a virt
guest is identified and we want to give it free entitlements.
---
client/rhel/rhn-client-tools/src/bin/rhnreg_ks.py | 10 --
.../src/up2date_client/capabilities.py |6 --
.../rhn-client-tools/src/up2date_client/rhnreg.py | 13 -
.../src/up2date_client/rhnregGui.py| 11 ---
.../rhn-client-tools/src/up2date_client/tui.py | 12
5 files changed, 12 insertions(+), 40 deletions(-)
diff --git a/client/rhel/rhn-client-tools/src/bin/rhnreg_ks.py
b/client/rhel/rhn-client-tools/src/bin/rhnreg_ks.py
index 234412a..e1e6b16 100755
--- a/client/rhel/rhn-client-tools/src/bin/rhnreg_ks.py
+++ b/client/rhel/rhn-client-tools/src/bin/rhnreg_ks.py
@@ -151,16 +151,6 @@ class RegisterKsCli(rhncli.RhnCli):
up2dateErrors.CommunicationError), e:
print "%s" % e.errmsg
sys.exit(1)
-
-# send smbios info to the server
-smbiosData = hardware.get_hal_smbios()
-try:
-rhnreg.sendSmbiosInfo(systemId, smbiosData)
-except AttributeError:
-# Method Not Implemented, continue
-pass
-except:
-print _("Problem sending smbios information.")
# collect hardware info, inluding hostname
if not self.options.nohardware:
diff --git a/client/rhel/rhn-client-tools/src/up2date_client/capabilities.py
b/client/rhel/rhn-client-tools/src/up2date_client/capabilities.py
index 98a4298..3741b4e 100644
--- a/client/rhel/rhn-client-tools/src/up2date_client/capabilities.py
+++ b/client/rhel/rhn-client-tools/src/up2date_client/capabilities.py
@@ -15,7 +15,8 @@ neededCaps = {"caneatCheese": {'version':"21"},
"registration.delta_packages": {'version':"1"},
"registration.remaining_subscriptions": {'version': '1'},
"registration.update_contact_info": {'version': "1"},
- "registration.extended_update_support": {"version" : "1"}}
+ "registration.extended_update_support": {"version" : "1"},
+ "registration.smbios": {"version" : "1"}}
def parseCap(capstring):
value = None
@@ -131,7 +132,8 @@ class Capabilities(UserDict.UserDict):
"registration.update_contact_info" :
'supportsUpdateContactInfo',
"registration.delta_packages" :
'supportsDeltaPackages',
"xmlrpc.packages.extended_profile" :
'supportsExtendedPackageProfile',
- "registration.extended_update_support" :
"supportsEUS"}
+ "registration.extended_update_support" :
"supportsEUS",
+ "registration.smbios" : "supportsSMBIOS"}
for key in capsConfigMap.keys():
self.setConfig(key, capsConfigMap[key])
diff --git a/client/rhel/rhn-client-tools/src/up2date_client/rhnreg.py
b/client/rhel/rhn-client-tools/src/up2date_client/rhnreg.py
index e15bbb2..4e1b3be 100644
--- a/client/rhel/rhn-client-tools/src/up2date_client/rhnreg.py
+++ b/client/rhel/rhn-client-tools/src/up2date_client/rhnreg.py
@@ -18,6 +18,7 @@ import up2dateLog
import rpcServer
import urlparse
import rhnreg_constants
+import hardware
try:
from rhn import rpclib
@@ -421,6 +422,9 @@ def registerSystem(username = None, password = None,
else:
auth_dict["username"] = username
auth_dict["password"] = password
+
+if cfg['supportsSMBIOS']:
+auth_dict["smbios"] = hardware.get_hal_smbios()
s = rhnserver.RhnServer()
if packages == None:
@@ -492,7 +496,10 @@ def registerSystem2(username = None, password = None,
'virt_uuid',
'virt_type',
'channel']
-
+
+if cfg['supportsSMBIOS']:
+other["smbios"] = hardware.get_hal_smbios()
+
s = rhnserver.RhnServer()
if activationKey:
@@ -624,10 +631,6 @@ def sendPackages(systemId, packageList):
s = rhnserver.RhnServer()
s.registration.add_packages(systemId, packageList)
-def sendSmbiosInfo(systemId, smbiosData):
-s = rhnserver.RhnServer()
-s.registration.add_smbios_info(systemId, smbiosData)
-
def sendVirtInfo(systemId):
if support is
Re: [Spacewalk-devel] [PATCH] Recognize KVM/QEMU guests as virtual systems
James Bowes wrote: Hi all: Attached are two patches. The first changes how smbios data is handled during registration, to send it when the server is created (so that, similar to xen, it can get free entitlements if appropriate). The second are the matching server side changes to parse the sent smbios data for indications that the registering system is a KVM/QEMU guest. Right now this just sets the guest type as fully virt. It might be nice to add a third type for KVM/QEMU. -James We've already implemented this as an xmlrpc call in 5.4. This change as I see is to make it part of the 'other' args sent across in the existing registration call. I'll look into it. Thanks, ~ Prad ___ 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
