Re: [Spacewalk-devel] spacewalk.qa.redhat.com & spacewalk.stage.redhat.com - expiring soon
Hey Girish, On Tue, Sep 11, 2018 at 12:59 AM Girish Patil wrote: > Hi Grant, > > Is the certificate "yum.spacewalkproject.org" belongs to your project? > Since URL: yum.spacewalkproject.org is redirected to " > https://copr-be.cloud.fedoraproject.org/archive/spacewalk/"; and moved to " > copr.fedorainfracloud.org". Can this be removed from our records? > yum.spacewalkproject.org is 'out in the wild' in many places. My understanding is that, even though it's just a redirect to the final location in COPR, it needs a valid SSL cert in order for HTTPS attempts to connect to it to get far enough to get the 302 and end up in the right place. So, we will continue to need that cert to be up-to-date. Thanks for checking! G > > On Mon, Sep 10, 2018 at 7:00 PM, Vikas Kumar wrote: > >> Thanks for follow up here. >> >> On Mon, Sep 10, 2018 at 9:25 AM, Grant Gainey wrote: >> >>> Hey Girish, >>> >>> On Mon, Sep 10, 2018 at 1:17 AM Girish Patil wrote: >>> >>>> Hi Grant, >>>> >>>> I have found your details from "INC0446278" request raised for >>>> spacewalk.. I would like to inform you that "spacewalk.qa.redhat.com & >>>> spacewalk.stage.redhat.com" certificates are going to expiry by 4th >>>> October 2018. Can you please confirm are you still using these >>>> certificates.. >>>> >>> >>> Wow - ok, those haven't actually been used since early-days of >>> Spacewalk. And with spacewalk.redhat.com now just a redirect to github, >>> they're not needed at all. >>> >>> Wherever those systems are, they can be decommissioned. spacewalk.qa >>> seems to be already gone, I get "ping: spacewalk.qa.redhat.com: No >>> address associated with hostname", but spacewalk.stage still responds: >>> >>> ~ $ ping spacewalk.stage.redhat.com >>> PING spacewalk.stage.redhat.com (10.24.205.15) 56(84) bytes of data. >>> 64 bytes from >>> origin-www-stage-redhat-com.vserver.stage.ext.phx2.redhat.com >>> (10.24.205.15): icmp_seq=1 ttl=249 time=46.3 ms >>> >>> Looks like spacewalk.stage is a vhost on www.stage.redhat.com that can >>> be removed. >>> >>> G >>> -- >>> Grant Gainey >>> Principal Software Engineer, Red Hat Satellite >>> >> >> > > > -- > Regards, > Girish > +91-9004756636 > -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk.qa.redhat.com & spacewalk.stage.redhat.com - expiring soon
Hey Girish, On Mon, Sep 10, 2018 at 1:17 AM Girish Patil wrote: > Hi Grant, > > I have found your details from "INC0446278" request raised for spacewalk.. > I would like to inform you that "spacewalk.qa.redhat.com & > spacewalk.stage.redhat.com" certificates are going to expiry by 4th > October 2018. Can you please confirm are you still using these > certificates.. > Wow - ok, those haven't actually been used since early-days of Spacewalk. And with spacewalk.redhat.com now just a redirect to github, they're not needed at all. Wherever those systems are, they can be decommissioned. spacewalk.qa seems to be already gone, I get "ping: spacewalk.qa.redhat.com: No address associated with hostname", but spacewalk.stage still responds: ~ $ ping spacewalk.stage.redhat.com PING spacewalk.stage.redhat.com (10.24.205.15) 56(84) bytes of data. 64 bytes from origin-www-stage-redhat-com.vserver.stage.ext.phx2.redhat.com (10.24.205.15): icmp_seq=1 ttl=249 time=46.3 ms Looks like spacewalk.stage is a vhost on www.stage.redhat.com that can be removed. G -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] EOL Jakarta Packages in Spacewalk
Hi Andrew, On Tue, Apr 10, 2018 at 2:04 PM, Danis, Andrew (CONTR) < andrew.da...@hq.doe.gov> wrote: > Good Afternoon Spacewalk Team, > > Regarding these packages: > > jakarta-oro-2.0.8-16.el7.noarch > jakarta-commons-httpclient-3.1-16.el7_0.noarch > > Are these being supported with security patches by red hat? I see fixes as > of 2013/2014 for CVE-2014-3577 and 2013-1571 but according to the Jakarta > project page it has been EOL since 2010. > Looking at the specfile changelogs, jakarta-oro fixed 2013-1571 in 0:2.0.8-14 : === * Fri Jun 28 2013 Mikolaj Izdebski - 0:2.0.8-14 - Rebuild to regenerate API documentation - Resolves: CVE-2013-1571 === and jakarta-commons-httpclient was released specifically to address CVE-2014-3577 : === * Tue Aug 12 2014 Michal Srb - 1:3.1-16 - Fix MITM security vulnerability - Resolves: CVE-2014-3577 === G -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] "Tracing a page" link broken on Wiki
Laurence, Eric, On Mon, Feb 19, 2018 at 1:05 PM, Eric Herget wrote: > Hi Laurence, > > It looks like this page might have gotten skipped during the move from > fedorahosted.org to the github wiki. During the conversion, all Trac > related pages were skipped. Since this particular page starts with "trac" > it appears to have also gotten skipped. > > I didn't find this page in waybackmachine, so we will need to see if we > can find a copy from when we did the conversion to github wiki and try to > resurrect this page. > > Laurence, great catch. Eric, that's exactly what happened. Please open a BZ for this. > I re-extracted this page from the last Trac database backup., using trac2github, and committed it to the wiki - it's visible now. No need for a BZ (altho no worries if you've already opened one!) Thanks for the heads-up! G > Thank you, > > Eric > > > > On 02/19/2018 04:14 AM, Laurence Rochfort wrote: > >> Hi guys, >> >> FYI, the "Tracing a page" on the github wiki is broken; it just returns >> you >> to the wiki home page. >> >> https://github.com/spacewalkproject/spacewalk/wiki/TracingaPage >> >> Cheers, >> Laurence. >> >> Laurence Rochfort | Principal Oracle Linux Developer >> Phone: +44 118 924 5629 | Mobile: +44 7867 908 605 >> Oracle Linux >> >> Building 520, Oracle Parkway | Reading | Berkshire | RG6 1RA | United >> Kingdom >> >> ___ >> Spacewalk-devel mailing list >> Spacewalk-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/spacewalk-devel >> > > > -- > Eric Herget | Senior Software Engineer > Red Hat Satellite > > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel > -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk wiki has a new home!
Hey folks, The Spacewalk wiki has been hosted at https://fedorahosted.org/spacewalk/wiki/WikiStart since the project began. However, time and infrastructure needs march ever on, and fedorahosted.org is going to be retired (as in, turned off) at the end of February. (You can read about it here - https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/ ) Rather than add to Spacewalk's support-infrastructure, we've migrated the wiki from the Trac instance at fedorahosted, to the Wiki-tab in Spacewalk's Github project: https://github.com/spacewalkproject/spacewalk/wiki This seemed to make the most sense - github is where the Spacewalk code repository moved in 2013, and this puts the project's documentation back next to its code again. Along the way, we needed to migrate from Trac-Markup, to Github's Markdown-Markup. There were A LOT of pages to migrate, and we wanted to preserve history and authorship as much as possible, so we wrote a tool[1] to automate a big chunk of the changes. Transforming wiki markup from one (ambiguous, exception-driven) format to another, is...exciting. There is plenty of cleanup work to do, to make everything pretty - but what we have is in reasonable shape, and definitely usable. (Except for tables - a number of those were actually broken in Trac, in ways that resulted in...some ugly pages post-transform. Fun!) I have marked a few of the top-level pages in Trac with a gigantic DEPRECATED banner, with pointers to our new home. Please update any bookmarks you have - Fedora Infrastructure will redirect the top-level URL to the new location for some time after fedorahosted.org is turned off, but that won't last forever. Next steps include figuring out the process for taking bugs (PRs?) against the wiki. Github assumes that the wiki will be edited in-place, just as we do with Trac today. If we can figure out a reasonable way to take PRs against it, it'll make it easier for the community to contribute, without opening the wiki up to link-spam and driveby vandalism (which does happen, by the way - it's the reason the Trac pages were locked down last year) At any rate - take the new wiki out for a drive, let us know what you think. Have a good weekend, Grant [1] you can find the migration tool here: https://github.com/ggainey/tracwiki2githubwiki -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk/wiki is going to need a new home
Hello folks, The Fedora Infrastructure folks are planning on sunsetting the 'fedorahosted.org' domain and associated services in February of next year, as described in this blog post: https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/ The Spacewalk codebase was moved off of fedorahosted.org to GitHub in 2014 - but our Trac wiki is still hosted there. So, we need to move. While I like Trac as a markup language, 'markdown' has become pretty standard these days. One proposal for dealing with this is to convert the wiki to markdown, and move it to https://github.com/spacewalkproject/spacewalk - that would get the code and the wiki in the same place again. There are a number of trac-to-markdown projects on github, but the ones I've found so far assume all you want is the most-current version of your Trac pages. Whatever we end up doing, I'd like to preserve the Trac site's history - it can be useful, as a maintainer, to know what's changed, when, and by whom! Preserving version history makes the conversion process a bit more tedious, but that's what scripting is for. The process would end up looking something like * Export the existing Trac DB * Extract all versions of all pages * Convert Trac-markup to markdown (sed is your friend) * Commit each version of each page seperately * Push the whole result up to github.com/spacewalkproject/spacewalk That's just one proposal. This email is to solicit ideas/proposals from y'all, on where to move, and what the desired end-state is. We have a few months to get this done - but we're thinking that shooting for having the wiki settled in its new home by mid-December would be good, so we can have at least a few months of having the old location still exist but be only pointers to the new one, and for tracking down as many external/documentation links as we can. Thoughts, anyone? Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] SPACEWALK-2.3: spacewalk-repo-2.3.3 incorrect
[top-posting, ugh] OK folks, a fixed spacewalk-repo-2.3-4 is now available for EL6, EL7, F20, and F21. Please let us know if/as you run into further issues. Have fun with 2.3! Grant - Original Message - > Hey Spacewalkers, > > Currently in the > > http://yum.spacewalkproject.org/2.3/** > > repositories, spacewalk-repo-2.3.3 is signed with the -2014 RPM key (correct) > but references the -2015 key (INcorrect). We will have this fixed no later > than end-of-day tomorrow, East Coast/US time. > > In the meantime, if you are trying to install/update Spacewalk-2.3 and seeing > this: > > === > Downloading Packages: > warning: rpmts_HdrFromFdno: Header V4 RSA/SHA1 Signature, key ID 066e5810: > NOKEY > Retrieving key from > http://yum.spacewalkproject.org/RPM-GPG-KEY-spacewalk-2015 > > > The GPG keys listed for the "Spacewalk" repository are already installed but > they are not correct for this package. > Check that the correct key URLs are configured for this repository. > === > > you can: > > a) wait till we send an all-clear tomorrow, or > b) edit your /etc/yum.repos.d/spacewalk.repo and set gpgcheck=0 > > while we work on cleaning up. > > Thanks to Charles Derek May for spotting this and letting us know so quickly! > > Grant > -- > Grant Gainey > Principal Software Engineer, Red Hat Satellite > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel > -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] SPACEWALK-2.3: spacewalk-repo-2.3.3 incorrect
Hey Spacewalkers, Currently in the http://yum.spacewalkproject.org/2.3/** repositories, spacewalk-repo-2.3.3 is signed with the -2014 RPM key (correct) but references the -2015 key (INcorrect). We will have this fixed no later than end-of-day tomorrow, East Coast/US time. In the meantime, if you are trying to install/update Spacewalk-2.3 and seeing this: === Downloading Packages: warning: rpmts_HdrFromFdno: Header V4 RSA/SHA1 Signature, key ID 066e5810: NOKEY Retrieving key from http://yum.spacewalkproject.org/RPM-GPG-KEY-spacewalk-2015 The GPG keys listed for the "Spacewalk" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. === you can: a) wait till we send an all-clear tomorrow, or b) edit your /etc/yum.repos.d/spacewalk.repo and set gpgcheck=0 while we work on cleaning up. Thanks to Charles Derek May for spotting this and letting us know so quickly! Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] SPACEWALK-2.3: RHEL5 spacewalk-client repository works now
Hey Spacewalkers, The SPACEWALK-2.3 RHEL5 client RPMs are now signed with a key that is compatible with RHEL5 (RPM-GPG-KEY-spacewalk-2015) If you were affected by https://bugzilla.redhat.com/show_bug.cgi?id=1212416 then you will want to install the new version of the spacewalk-client-repo.rpm: # rpm -Uvh http://yum.spacewalkproject.org/2.3-client/RHEL/5/x86_64/spacewalk-client-repo-2.3-3.el5.noarch.rpm Or, you may import the new public-key directly: # wget http://yum.spacewalkproject.org/RPM-GPG-KEY-spacewalk-2015 # rpm --import RPM-GPG-KEY-spacewalk-2015 Apologies for any inconvenience, and Happy Spacewalking! Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] SPACEWALK-2.3: Problem with RHEL5 client repo
Hey Spacewalkers, There is a problem reported with the new SPACEWALK-2.3 release, and *RHEL5-clients*. If you look at https://bugzilla.redhat.com/show_bug.cgi?id=1212416 you can see the issue - the GPG-key used to sign this release is not compatible with RHEL5's GPG infrastructure. To address this, we are going to create a new (RHEL5-compatible) signing-key and re-sign the RHEL5-client-repo only. That new key will then be used going forward for all of SPACEWALK-2.4. Apologies for any inconvenience, and thanks to Peter Bieringer for catching it so quickly. Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 2.3 has been released
Support - Removal Notice The Spacewalk team has dropped code for Solaris clients and the Monitoring component of Spacewalk. Anyone currently using either of these capabilities will need to consider alternatives for their needs prior to upgrading to 2.3. User community, reporting issues To reach the user community with questions and ideas, please use mailing list spacewalk-l...@redhat.com . On this list, you can of course also discuss issues you might find when installing or using Spacewalk, but please do not be surprised if we ask you to file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Spacewalk with more details or full logs. Thank you for using Spacewalk. -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] SPACEWALK-2.3 branch has been created
In preparation for Spacewalk 2.3 relase, a SPACEWALK-2.3 branch has been created in Spacewalk github repository: https://github.com/spacewalkproject/spacewalk/tree/SPACEWALK-2.3 Note that this branch is NOT "ready for prime time" yet; I will send a followup email when we have build-issues straightened out. G -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] A note on the new home of translations
Hey folks, Last year, Fedora moved from using Transifex to manage translations for its projects, to the open-source Zanata project. Our translations live in Fedora's Zanata instance (as of 2014-DEC). We have two projects: Spacewalk Backend - for the python/client gettext translations, which can be found at https://fedora.zanata.org/project/view/spacewalk-other Spacewalk Web UI - for the Java XLIFF translations, which can be found at: https://fedora.zanata.org/project/view/spacewalk-frontend In each project, you'll see locked versions for each release of Spacewalk, and a master version. When a new release is prepared, a new version is cloned from master and locked. Any translations can be added to the master version. Feel free to pick a language and translate away! Grant (PS - if you find we've lost translations in the move, please let me know so I can make repairs. Thanks!) -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Release Prep for Spacewalk 2.3!
- Original Message - > The bug 1121219 ( spacewalk-common-channels does not contains spacewalk22-* > channels ) could also be included in this release > > As the file involved in this bug will have to be changed in any way to > include version 2.3, fix this bug is simple > > In addition to versions 2.2 and 2.3 of Spacewalk, would also be interesting > to include the Fedora 21 on /etc/rhn/spacewalk-common-channels.ini Updated the BZ - changes are already in place and will be part of 2.3 Thanks for pointing out the BZ! Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Release Prep for Spacewalk 2.3!
- Original Message - > yes, the overall status of nighly is quite good and I am running it > successfully > in parallel to an RHEL 6 spacewalk 2.2 installation. > Thx everyone :) Always good to hear :) > But the following bugs should be considered for 2.3 release: > > RHEL7 related: > Bug 1169674 - SWnightly@RHEL7: Error: Package: > spacewalk-taskomatic-2.3.94-1.el7.noarch Requires: cglib < 2.2 > Bug 1205167 - Move files shared between osad and osa-dispatcher to its own > package > > Upgrade path: > Bug 1205113 - obsoleted spacewalk-monitoring packages are not removed on > upgrade > > Bug: > Bug 1205108 - No Config diffs shown in webui on recent 2.3/nightly Great - specific responses are awesome. Will investigate if we can get these in before we branch. Thanks, Grant > > Best regards > Patrick > > -- > Lobster SCM GmbH, Hindenburgstraße 15, D-82343 Pöcking > HRB 178831, Amtsgericht München > Geschäftsführer: Dr. Martin Fischer, Rolf Henrich -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Release Prep for Spacewalk 2.3!
Hey folks, It has been a while since Spacewalk 2.2 went out, and we think the current state of -nightly is a reasonable release-candidate for Spacewalk 2.3. Over the next week or so we will be doing a lot of testing and release-work. If anyone would like to help with testing/verification/QE, that would be wonderful - there are a lot of changes, and more eyes is always good. The list of BZs that need QE attention is: https://bugzilla.redhat.com/buglist.cgi?bug_status=ON_QA&classification=Community&list_id=3336542&product=Spacewalk&query_format=advanced I will wait to create the SPACEWALK-2.3 branch in git until after we've had a chance to review automation failures and see successful installation and upgrade testing. Once the branch is created, there is still a lot of release-nanny work to be done, but we are working towards having 2.3 be 'official' Real Soon Now . Thanks for everyone's help and contributions! Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk, 2.3, and Translations
Hey folks, Back in December, the localization tool used for Spacewalk changed from Transifex to fedora.zanata.org, along with everything else Fedora-related. At that time, the initial load of the SW L10N files was done for us by the folks in Fedora-infrastructure. The way Spacewalk is built, we have two kindsOf localization technologies in play. For the web-UI, we have XLIFF files (look for StringResource_en_US.xml for an example). And for the backend and clients, we use gettext's .po files. As a result, when our project was moved from Transifex, it was created in fedora.zanata.org as the 'spacewalk' project, with two 'versions' - 'spacewalk-frontend' and 'spacewalk-other'. The problem with this, is that those really aren't versions, those should be separate *projects*, which are *versioned* as spacewalk releases are cut. To manage translations, what we should have is a spacewalk-frontend and spacewalk-other project, inside of which there is one version for each SW release. The process, did we have such a setup, would be something like this (to match the code-release process): Project: spacewalk-frontend Version: master <-- All changes get pushed here Version: 2.3 <-- State of translations as of the release of 2.3, plus backported chgs if any Version: 2.2 <-- State of translations as of the release of 2.2, plus backported chgs if any ... Translations/new sources being made for the next release are pushed into version-master. When it became time to release 2.4, the most-current-state of translations would be pushed into spacewalk-frontend with a version of 2.4. I'd like to get this unravelled as part of the upcoming SW2.3 release. Anybody on the list have thoughts on this, or major objections? Let me know please! Thanks, Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Merging the bootstrap-css branch
- Original Message - > On 05/11/13 23:07, Grant Gainey wrote: > > Honestly, if we could get the checkstyle fixes and a first pass at The > > PXT Problem, I think we'd be good to go. We need more eyes, to flush > > out the edge-case problems. Thoughts? Grant > > > Great! > > * We will do a checkstyle fix before the merge then. > * I also may do the majority of the the gif -> icon conversion because > it touches so many jsp's that it will be better to do it now. It is > almost done (map, icons and the conversion tool, we have basically to > run it) > > About the pxt, we will put the port in another sprint in a month for > now, and we will have minimum 3 developers working on it for those two > weeks. We can tackle the perl List widget there. > Even with that sprint, some work will continue, as our designer/frontend > developer will continue adapting the port to SUSE Manager, details will > continue to be fixed and we may get lot of work done even before the > next sprint. > > On the other hand, we already ported the JUnit testcases for the tag as > well, but I suggest to commit them after the merge. > > We will jump now directly to checkstyle and the icons and ping the team > when we are done for the first pull. Ok for you? Sounds good to me, will make sure the rest of the crew doesn't have any major reservations. Exciting times! :) G ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Merging the bootstrap-css branch
Hey Duncan! We've had a fair amount of discussion here, and a number of folk playing with the current state of the branch. - Original Message - > > Hi astronauts > > We would like to start discussing a merge of the bootstrap-css branch. > As you may know, the name is very technology specific but the work has a > wider goal in mind. In case you haven't followed it, we prepared a blog > post: > > http://duncan.mac-vicar.com/2013/10/30/modernizing-spacewalks-user-interface/ > > So what is the state of the work? > > [x] Layout > [x] Java widgets (Nav, Toolbar, List) > [x] Perl layout > [x] Forms > [x] Prototype -> jQuery port > [x] Fontawesome icon infrastructure > [x] Spacewalk "black theme" > > Right now there is stuff we would like to fix grouped in various areas: > > [ ] Perl data list > [ ] Port all icons .gif -> fonticon > [ ] Hidden cosmetic details in pages we haven't seen yet. > [ ] JSP tags testcases [ ] Checkstyle is unhappy [ ] What about remaining PXT? While there's clearly work to do, everyone is on-board with merging as long as things *work*, even if they're still ugly. The problem with checkstyle is that it fails all our automated testing, so we wouldn't even get to junit issues. We'd also like to discuss plans for dealing with the remaining PXT pages. Getting them all converted wouldn't hold up a merge - but discussing and creating a plan for a final conversion, and who would do which pieces of it, would be important. > - The perl data list is in our TODO list. > - For the port of all .gif icons we still need to draw some replacements > and this may be an ongoing task. We are then building an equivalence map > and will use the a tool we wrote to aid on the conversion to do a > translation once the map is completed: > https://github.com/dmacvicar/spacewalk-ui-porting > (We also are using this tool to help us sanitize the html, port styles, > etc). > - Hidden cosmetic details is something that will popup as we find issues > and get feedback > - The testcases are WIP. You have seen with previous patches that we > care about the Java test cases because we are running them, and > therefore we will work on this. > > Right now having a branch is blocking another features where we want to > make use of the new css infrastructure and components, therefore it is > our wish to do a first merge as soon as possible. This does not mean > that we will stop working on it, but that we want to do the merges in > stages. Also, I would really love to have other people gving feedback, > contributing, learning and improving the new look&feel. Strong agreement. Merge, and start letting people open bugs as they find L&F issues. > I would like to discuss the previous open items. Which ones would be a > requisite for a 1st stage merge, which ones could be delayed to a second > merge in some weeks from now. Honestly, if we could get the checkstyle fixes and a first pass at The PXT Problem, I think we'd be good to go. We need more eyes, to flush out the edge-case problems. Thoughts? Grant ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch proposal: try-wrapping XMLRPC serialization code
- Original Message - > On 10/01/2013 10:58 PM, Grant Gainey wrote: > > I decided there *had to* be a better way to do this - and I found one! > > Great! > > > More Eyes would be great. > > Actually, Taskomatic classes were left out (probably overlooked). I > added them in commit c29e22. Outstanding - I *knew* I'd miss something, hence the "more eyes" - good catch! > Apart from that, changes look good and also all tests pass tests here > as well. Awesome - I love it when a plan comes together :) G > > Thanks a lot! > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > ___ > 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] Patch proposal: try-wrapping XMLRPC serialization code
Hey Silvio, - Original Message - > Hi, > > We had a downstream bug that boiled down to an uncaught exception in > XMLRPC serialization code (a class implementing XmlRpcCustomSerializer). > > AFAIU at the moment any uncaught exception from by the serialize() is > basically ignored, "digested" by the redstone library and not added to > any log or error output, making it quite hard to find out issues. I > would like to add some code to add some exception details to the error log. > > You can easily reproduce the bug on basically any Spacewalk version by > adding a line like this: > > throw new NullPointerException(); > > to ServerSerializer.serialize(), then calling via API any XMLRPC method > that returns a server. > > Proposed solution would be to try-wrap all serialize() methods in the > application, which is the only way I can think of to handle those > exceptions in Spacewalk code, since this problem really stems from > redstone. Creating a superclass is unfortunately not an option because > the serialize() method signature can change. > > Any feedback or better idea is welcome. In case this is really the only > viable solution, would you accept such a patch? I decided there *had to* be a better way to do this - and I found one! See commit 1fddc7359c54dcfae38505c55a6074144685e2f5 - built an abstract base class, refactored[1] the FooSerializer classes to extend it, and made SerializerFactory less dumb (and smaller!) I've tested a number of random API calls, and the serialization JUnits pass, but More Eyes would be great. Also, RhnXmlRpcCustomSerializer.serialize() could probably do something better in terms of logging. Let me know what you think! G [1] Between sed and Eclipse, *nothing* is safe :) > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > ___ > 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] [patch] bugzilla 1009657 - fixes spacewalk-hostname-rename issue when postgres and oracle are installed
- Original Message - > If a user has both postgres and oracle installed on their satellite system > and they try to run a spaceawlk-hostname-rename, that will fail with > /var/lib/pgsql/data is missing. Use "service postgresql initdb" to initialize > the cluster first. > even with > db_backend = oracle > in the rhn.conf file. > > Attached is a patch that modies the /usr/bin/spacewalk-hostname-rename file > when it is checking /etc/init.d/oracle and /etc/init.d/postgresql files to > check for whichever you have from $(spacewalk-cfg-get db_backend). Added as commit 9b8d187b93fc4c2145fc0f723f2203e0940f9126, spacewalk-utils-2.1.17-1 Thanks for your contribution! Grant > > Thanks > Pete > ___ > 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] [PATCH] ProvisionVirtualizationWizardActionTest: preconditions
- Original Message - > Hi, > > We found out that ProvisionVirtualizationWizardActionTest was failing > for a couple of reasons, at least in our environment. > > Firstly, some preconditions were missing: a test server did not > necessarily have a base channel, and it missed an entitlement to comply > with the action's ACL (see patch comment). > > Secondly, the test would really pass only if the test server mentioned > above actually had the virtualization tools package installed, otherwise > the action would add a second, non-blocking, help action message and > fail. I added some code so that no failure occurs in that case. > > See attached patch. Looks good - commit 72ab7782fd4b34d3adc8574e5b9f43bcf7ac3e79 Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] SystemEntitlementsSetupActionTest: do not assume Org has virtualization entitlement
- Original Message - > SystemEntitlementsSetupActionTest was failing in our environment, as the > tested Org missed a virtualization entitlement. > > The proposed attached patch fixes the problem. commit c9b4477aadb9eff33befc91d079e47b1a8bbefa2 Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] VirtualGuestsActionTest: do not rely on translation messages
- Original Message - > VirtualGuestsActionTest had some localized messages hardcoded in > English, I removed them to actually look up their value from > LocalizationService. > > See attached patch. commit ff4f40accefe349c122301b9b44572cfa479bff2 Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] Add support for uploaded files in mocked requests, fix CryptoKeyCreateActionTest
- Original Message - > Hi, > > In our environment we noticed that CryptoKeyCreateActionTest was > failing. AFAIU, failure was due to the fact that the mocked request did > not have the uploaded file in it, that is, it was not a multipart request. > > In order to fix that I added some code to support multipart requests in > RhnPostMockStrutsTestCase (patch 008). Code is a little convoluted > because the API required an extra class, yet I prefer > RhnPostMockStrutsTestCase to be self-contained - other solutions are > possible if you particularly dislike the proposed implementation. This > is of course reusable in other cases where mocking an uploaded file is > needed. > > Patch 009 adds code to insert an (empty) uploaded key in > CryptoKeyCreateActionTest and this allowed the action to complete. I > also noticed that for whatever reason the "crypto.key.nokey" action > error is never issued, since CryptoKeyCreateAction extends > BaseCryptoKeyEditAction with isContentsRequired() always returning true, > so I removed that assertion as well. Yeah, some of this is breakage due to code changing, I think. Having tests that run clean, tho, should help with keeping them that way. commit b15a5187a643decf77dad025030f82987501bd54 Thanks for contributing! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] OrgSoftwareSubscriptionsActionTest: always create test channel families
- Original Message - > In OrgSoftwareSubscriptionsActionTest, a test channel family is > correctly set up for a test method but not in another. I simply moved > common initialization code in setUp(). > > See attached patch. commit 6796a8be523752b212173c0ce4f14106a8d63f97 Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > > ___ > 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] [PATCH] MethodsSetupActionTest: do not assume that method command exists
- Original Message - > See attached patch. commit 365c1834aa451aba3fb039f93034828dd2063c78 Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] KickstartScriptActionTest: missing parameters added
- Original Message - > Apparently some form parameters were missing and the test failed, at > least in our environment. > > See attached patch. commit 12233d90d130eb739d80fbd53eb7c9dfc6493af7 Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] SystemHandlerTest: do not rely on hardcoded sequence ids
- Original Message - > SystemHandlerTest was failing in our environment and, AFAIU, it expects > that the underlying database will always return 1 as the id of a > persisted test object. This is normally not the case, as the value is > taken from a sequence and there is no code to ensure it is reset before > the test, so I simply relaxed that condition accordingly. > > See attached patch. commit bf05d8e0c6811a6bfed7f6c49091a56cabf8513d , I rolled this in with the cobbler-commits inadvertently. Thanks for the contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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] [PATCH] junit tests: do not rely on Cobbler
- Original Message - > Hi, > > We propose some patches to avoid the junit testsuite to depend on > Cobbler. With those, we are able to run all the tests using only a > database instance seeded with the latest schema version. Details: commit bf05d8e0c6811a6bfed7f6c49091a56cabf8513d > - patch 17 calls setupTestConfiguration() on KickstartDataTest before > calling other members of the same class which, as far as I understand, > is the correct approach here; > - patch 18 does the same in SystemHandlerTest, which also used other > methods from KickstartDataTest; > - patch 19 adds code to mock the Cobbler connection in SystemManagerTest. > > About patch 19: we noticed that most tests where Cobbler was required > were failing because they called SystemManager.deleteServer(). That > method used to remove a system from the database only, but later (in > 2011) a patch was added to call Cobbler to delete the system from there > as well. Test code was never updated for Cobbler so it only checks > database and objects, so I think it makes sense to just use a mocked > connection to avoid the Cobbler exception on a test system that will > never be in Cobbler anyway. > > Comments welcome! We collided on this one - I was in the middle of dealing with some of the same issues :) I pitched mine and kept yours, you were further along. Thanks for contributing! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] junit tests: some logging cleanups
- Original Message - > Hi, > > As previously discussed the new logging feature requires calling > LoggingFactory.clearLogId() at the beginning of each transaction, and > there were some places in test code where that was missing. > > I confirm that the latest patches from Grant actually covered most > cases, I could only find four more and I am attaching a patch to fix > them as well. > > Note: at the moment we haven't looked into main application code yet. commit a418f0b69493ce0a20bb90bb56d51364041a2cc3 Note: I made an additional change to SatScrubberTest to clearLogId() when cleaning up users as well. Thanks for your contribution! G > > This ends this patch batch, hopefully, as we were finally able to run > all the tests successfully, at least on Postgres :-) > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > > > ___ > 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] [PATCH] AuthFilterTest: mocked request object updated
- Original Message - > AuthFilterTest was failing in our setup, apparently because the mocked > request object was missing some methods that were added after the test > itself was written. I added those methods and now it passes. > > See attached patch. commit e459215dcd574d01af7771de7d7a50f6a5a75acc Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] MasterHandlerTest: handle getDefaultMaster exceptions
- Original Message - > Hi, > > If I understand code correctly MasterHandlerTest is about testing that > some methods can or cannot be called by administrators and regular > users. IssMaster objects are created ad-hoc for testing, and one of them > is "flagged" and "unflagged" as default during the tests themselves. The > only problem is the very first call to getDefaultMaster(): since none of > the test IssMaster objects has been flagged as default yet, the call may > or may not throw exceptions depending on the previous state. > > The attached patch simply ignores such exception for the very first call. commit abe60ece5e469c3a5508f12f9f55ef00d472e561 Just fyi - the goal of the initial getDefaultMaster() call, was to be able to put it back post-test, so that we didn't change the state of the spacewalk instance we're running against (which was, when this test was written, my dev-instance :) ) Tempted to just yank the get/reset code entirely - but not this commit. Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] TestUtils: use the same temporary filename for the same file
- Original Message - > Hi, > > The attached patch fixes a previous contribution of mine to > transparently get resources either from the filesystem or from a jar > file. When accessing a file from a jar that files gets decompressed in a > temporary location which name was generated at random for each call. > This however did not work with all the tests - NavTest.testCache(), for > example, expected a file name not to change between calls. The proposed > implementation will stick to the same temporary file name as long as the > requested file name (and path) stays the same, thereby fixing NavTest > when run from a jar. Nice catch - commit cc6bc6798fea402ba0597c1b47a51cb27fb1664e Thanks for contributing! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] ActivationKeyHandlerTest: expect correct exceptions
- Original Message - > ActivationKeyHandlerTest expected InvalidEntitlementException where > actually FaultException gets thrown. I updated the testcase. > > See attached patch. commit 96276437a1fce3ba1f1acb3930f6f0d85d20cbfd Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] RequestContext.buildPageLink: force parameter ordering
- Original Message - > Hi, > > I noticed that buildPageLink() uses a HashMap to keep track of query > string parameters. While this is perfectly okay from a web application > point of view, it makes testing a little more difficult and in > particular, RequestContextTest could break because it implicitly relies > on key ordering. > > In the attached patch I propose using a TreeMap instead, which produces > a reliable ordering. commit da246692162aca79b92942582a18205960db1b4a I made a small change - using a TreeMap doesn't require changing the type of the variable to SortedMap, the rest of the code is still happy using Map methods. Thanks for the contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > > ___ > 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] [PATCH] VirtualGuestsActionTest: do not rely on query string parameter ordering
- Original Message - > Hi, > > The attached patch relaxes an assertion condition not to require a > certain query string parameter order, which was in fact not respected in > our test environment. commit e101391876ab21505ec080b4af29f5feb5caeb6b Thanks for contributing! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] OrgHandlerTest: don't depend on a channel family with free entitlement slots
- Original Message -
> OrgHandlerTest apparently required an official Red Hat channel family
> with free slots:
>
> /**
> * Lookup an official Red Hat channel family with free slots.
> * Fail the test if none can be found.
> [...]
> private ChannelFamily lookupRedHatChannelFamily() { [...] }
>
> Actually, this is a precondition not necessarily true in any instance,
> and IMO test code should take care of setting up and tearing down such a
> channel since it is needed to run tests. The attached patch adds some
> setup code to do that.
Concur - commit f0b8a56fa4f3c1f4aafa83f2fe80aebf3590df3d
Thanks for your contribution!
G
>
> Regards,
> --
> Silvio Moioli
> SUSE LINUX Products GmbH
> Maxfeldstraße 5, 90409 Nürnberg Germany
>
>
>
> ___
> 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] [PATCH] DownloadActionTest: do not assume file to be downloaded exists
- Original Message - > See attached patch. commit 24bbc79a3bdf7c73e6a6d27760177a1d78264fef Thanks for the contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > ___ > 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] [PATCH] Frontend monitoring tests: ensure a Monitoring Scout exists
- Original Message - > Hi, > > In some frontend tests it is assumed that at least one Monitoring Scout > exists, and those tests will fail if there is none. > > The proposed attached patch creates a test Monitoring Scout before any > operation that requires one, thus eliminating this precondition. commit b335b1ad0443bad88e14956cf0495c61966c3be6 Thanks for your contribution! G > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > > ___ > 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] pltcl question
- Original Message - > On 09/11/2013 02:28 PM, Jan Pazdziora wrote: > > Which for typical web application request handling is what you want, > > isn't it? The whole request processing is one transaction and > > releasing it gives you nice cleanup. > > It is, except for a very few cases of "commit-in-the-middle". > > > Does it happen in our code base? > > I confirm that in most cases, and in particular all cases we observed > until now, this only happens in test code. Make sure you check latest code - I submitted a number of changes in the last day or so to address *exactly* the "need to reset for logging after a commit" in the testcases. I'm sure there are still a few places, but it's better now... G ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] VirtualizationEntitlementsManagerTest fixes
- Original Message - > On 09/09/2013 08:29 AM, Silvio Moioli wrote: > > I attached two patches: > > Patches updated to apply cleanly after Grant's commits. > > I apologize for the double post. No problem - added as commit - 21199a55fda8ecd893947dbad90b5cbff6328585 Thanks for your contribution! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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] [PATCH] rhn.manager tests: do not assume an Org admin exists
- Original Message - > See attached patch. I modified the patch somewhat - as written, it *always* adds a (new) org-admin when it may not have to. UserTestUtils.ensureOrgAdminExists(Org) is now cleaned up, and UTU.ensureSatelliteOrgAdminExists() calls it. commit 6e276ee26989d8246b61b726afcaf48ecef2302c Thanks for your contribution! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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] [PATCH] Proposal to remove QuartzTest
- Original Message - > Hi, > I stumbled upon com.redhat.rhn.taskomatic.core.test.QuartzTest and I > think it is safe to delete it. It doesn't look like a unit test at all: > > - it only tests Quartz code, basically no Spacewalk code is involved; > - there is only one assertion, and it is about the > Config.getNamespaceProperties, not Quartz; > - test name seems meaningless; > - AFAIU, it requires slf4j, commons-pool and commons-dbpc to run, while > no other test does; > - it requires some special configuration not present in rhn.conf and > normally generated on-the-fly by > com.redhat.rhn.taskomatic.core.SchedulerKernel (not used in this class, > though). Concur with the above. > I believe this is a temporary class created during development and then > forgot. Well...ok, I'll be charitable and believe that as well :) > I attached a patch to delete it. commit 3634559947c2e1575aaa42da395cb02af27af1fa Thanks for contributing! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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] [PATCH] MonitoringManagerTest: missing super.setUp() call added
- Original Message - > See attached patch. commit a549568dd1a0d12aad605c5610e8cb8a5015c886 Thanks for contributing! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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] [PATCH] UserManagerTest: don't rely on hardcoded default time zone
- Original Message - > UserManagerTest relied on a default "America/New_York" time zone, I > removed the hardcoded string replacing it with > UserFactory.getDefaultTimeZone(). > > See attached patch. commit 4cba00f46447a5808e20ddc299c88a4335c08d6d Thanks for contributing! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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] [PATCH] ConfigureSatelliteCommandTest: do not rely on HashMap key ordering
- Original Message - > I noticed that ConfigureSatelliteCommandTest makes an assertion that > depends on a HashMap key ordering, it was changed it to a SortedMap to > guarantee repeatability. > > See attached patch. commit 59aafcf1a04208e67ea6a664052087fe266de32b Thanks for contributing! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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] [PATCH] UpdateErrataCacheCommand: log an error when orgId is incorrect
- Original Message - > So, what is the motivation of this change? > (The only scenario I can imagine is, that the errata cache event will be > queued and its organization gets deleted before the background errata cache > action gets executed.) Exactly so. Because of the way the tests run, esp on a fast multi-core machine, we fill the logs with NPEs. In the normal workflow, the window where this patch would be useful is very very *very* small - but it does still exist. And in the general case, the patch is harmless. I vote we take it, it cleans up a mess in the test-logs and doesn't hurt the regualr-use-path at all. G > > > Regards, > -- > Tomas Lestach > Red Hat Satellite Engineering, Red Hat > > > - Original Message - > > From: "Silvio Moioli" > > To: spacewalk-devel@redhat.com > > Sent: Monday, September 9, 2013 8:27:56 AM > > Subject: [Spacewalk-devel] [PATCH] UpdateErrataCacheCommand: log an error > > when orgId is incorrect > > > > See attached patch. > > > > Previously a NPE would be generated, but since the stack trace is not > > very useful as it can only go back until run(), it only polluted test > > outputs. I think that logging the error makes more sense in this > > case. > > > > Regards, > > -- > > Silvio Moioli > > SUSE LINUX Products GmbH > > Maxfeldstraße 5, 90409 Nürnberg Germany > > > > > > > > ___ > > 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 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] AdvDataSourceTest: do not rely on test execution order
Hi Silvio, - Original Message - > Hi, > I noticed that AdvDataSourceTest relies on method ordering, and this can > sometimes break tests. In fact we noticed that method call ordering is > different in our OpenJDK 7 configuration between the commandline Ant > launcher and the Eclipse launcher, resulting in failed tests in the > former case but not in the latter. > > More specifically, oneTimeSetup() inserts a row in adv_datasource and > testDelete() will fail if it does not find it. On the other hand, > testStressedElaboration() will fail if it finds it, because > row.getTestColumn() is null for that test line. > > The proposed patch simply executes the whole setup and teardown for each > test, since that ensures tests do not depend on each other and does not > hurt performance significantly. > > The patch has been tested both on Oracle and Postgres databases. Patch committed as d0571da5d62d65334ba4b58639eb1a6339e57fa5 Thanks for the contribution! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > ___ > 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] [PATCH] ChannelTest: do not assume a proxy channel family exists
Hi Silvio, - Original Message - > Hi, > > Here is another simple patch to avoid having a proxy channel family set > up in order to run ChannelTest. Accepted as commit 4fe6deb81b5328af52a7180676a91ccab1dffee1 Thanks for your contribution! Grant > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > ___ > 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] [PATCH] UserFactoryTest: avoid failure if there are no users
Hey Silvio, - Original Message - > On 08/28/2013 07:42 PM, Grant Gainey wrote: > > Fixing the tests to be more explicit and less reliant on "typical setups" > > is, at least in my opinion, always a good thing. > > I am glad to hear that, as at the moment that's exactly what I am doing! > > I attach three patches that go just in that direction. Pushed as commit 1687c3536eb9c8b312a3e3005335fcbff177a315 Thanks for the contribution! Grant > > 001 - TestUtils: don't assume that tests are run from a .class directory > (we run them from rhn.jar); > 002 - ChannelFactoryTest: don't assume there are any existing channels; > 003 - HostBuilder: use ServerFactoryTest methods to build virtualized > hosts/guests to drop assumptions of having virtualization channels with > appropriate packages available. Since this varies some methods semantics > a bit (produced servers now have a base channel and consume > entitlements), patch tests using that class accordingly > (ServerFactoryTest and VirtualizationEntitlementsManagerTest). Also, add > a couple of methods to UserTestUtils and ServerTestUtils to ease > implementation, where appropriate. > > Comments are always welcome, I look forward in contributing similar > patches also in the future. > > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > ___ > 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] [PATCH] UserFactoryTest: avoid failure if there are no users
- Original Message - > Hello, > We are currently in the process of overhauling our test infrastructure > downstream, and among other things we are trying to run upstream Java > unit tests in order to spot regressions. > > We noticed that some of the tests, for example > UserFactoryTest.testSatelliteHasUsers() or ChannelTest.testIsProxy(), > have some "special" preconditions that have to be met in order to run > successfully (respectively: having one registered user and a channel > family with label "rhn-proxy"). While these conditions are usually very > broad, we would like to keep setup activities needed to run the tests to > a minimum. Ideally, the whole test suite should pass when running > against a database which only has a current, freshly installed, copy of > the schema. > > We propose to add those missing preconditions as we find them, see for > example the attached patch for UserFactoryTest.testSatelliteHasUsers(). > Is that approach acceptable to you, do you see major issues with it? Sounds like a fine idea. This patch added as commit ec2fc829ff5af9479b0fdeecf0481f3c553e4a43 > How do you usually run tests, do you use a CI environment? Yes, QE runs the tests nightly. > How do you handle tests that require components outside the Java and > database environment, such as KickstartDataTest that requires Cobbler > installation? In a lot of ways, the "unit" tests really aren't "unit" at all - they're really system-integration-tests that use Junit as a framework. Reasons for this range from reasonable (e.g., satellite is a "cover" over a federation of services - so pretty much any change having to do with server-profiles will throw exceptions if Cobbler isn't around) to "less reasonable" (keeping a test encapsulated with proper use of mock-objects can be a pain, and over the years expediency has won :) ) As we trip over examples of the latter, we try to fix the tests to make fewer assumptions; there is, alas, plenty of work left to do. Fixing the tests to be more explicit and less reliant on "typical setups" is, at least in my opinion, always a good thing. Thanks for the commit! Grant > Regards, > -- > Silvio Moioli > SUSE LINUX Products GmbH > Maxfeldstraße 5, 90409 Nürnberg Germany > > > ___ > 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
[Spacewalk-devel] Adventures in Koji, or, "Why Isn't That Build Released Yet, ggainey?!?"
Hey folks,
Applied the ISS chg to spacewalk-nightly/1.9/1.8, along with a fix to get
pylint to hush up about JanP's fix.
Nightly and 1.9 build in koji fine.
1.8, however, I can't get kicked off, with the error below.
I have some family commitments tonight that I can't move, so I'm not going to
be able to get back to this till tomorrow AM. At that point, will work on
fixing 1.8, and then signing the RPMs and releasing this fix for 1.8 and 1.9.
Also - Cliff - did I end up being stuck with access to the package-signing key?
I can't remember, and I have to run. If not, will need someone with key-auth
to sign for us.
(If I *do* have signing-access, then I think we all need to step back and think
about what a terrible, terrible idea that is... ;) )
See everyone tomorrow,
G
===
(SPACEWALK-1.8) ~/git/spacewalk/backend $ tito release --all
Will release to the following targets: koji
Checking for tag [spacewalk-backend-1.8.86-1] in git repo
[ssh://ggai...@git.fedorahosted.org/git/spacewalk.git/]
Releasing to target: koji
Working in:
/tmp/spacewalk-build/release-spacewalk-backend-9e6fc53958a0e90d89a824cea83d0b36257349a1sZKjc8
Building release in Koji...
Submitting build with: koji -c ~/.koji/spacewalk-config build --nowait
spacewalk-1.8-rhel5
git://git.fedorahosted.org/git/spacewalk.git/#spacewalk-backend-1.8.86-1
## ERROR
Error running command: koji -c ~/.koji/spacewalk-config build --nowait
spacewalk-1.8-rhel5
git://git.fedorahosted.org/git/spacewalk.git/#spacewalk-backend-1.8.86-1
Status code: 256
Command output: Warning: the pkgurl option is obsolete
Usage: koji build [options] target
(Specify the --help global option for a list of other help options)
koji: error: Destination tag spacewalk-1.8-rhel5 is locked
Traceback (most recent call last):
File "/usr/bin/tito", line 23, in
CLI().main(sys.argv[1:])
File "/usr/lib/python2.7/site-packages/tito/cli.py", line 94, in main
return module.main(argv)
File "/usr/lib/python2.7/site-packages/tito/cli.py", line 628, in main
scratch=self.options.scratch)
File "/usr/lib/python2.7/site-packages/tito/release.py", line 966, in release
self._koji_release()
File "/usr/lib/python2.7/site-packages/tito/release.py", line 1048, in
_koji_release
KojiReleaser._koji_release(self)
File "/usr/lib/python2.7/site-packages/tito/release.py", line 1011, in
_koji_release
self._submit_build("koji", koji_opts, koji_tag)
File "/usr/lib/python2.7/site-packages/tito/release.py", line 1062, in
_submit_build
output = run_command(cmd)
File "/usr/lib/python2.7/site-packages/tito/common.py", line 217, in
run_command
raise Exception("Error running command")
Exception: Error running command
(SPACEWALK-1.8) ~/git/spacewalk/backend $
===
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] avoid link-jars task when executing make-eclipse-project
Hi there Silvio, - Original Message - > Hi, > I noticed that the make-eclipse-project Ant task in build.xml depends > on link-jars, which as far as I understand should not be needed. This > could result in errors when a developer wants to produce the Eclipse > project files even if he/she doesn't have all dependencies set up > correctly (eg. because they are available, but in other locations). > > I attached a simple patch that removes the dependency. Good idea! However, I'd like to not change the existing default behavior. What do think about the attached patch instead? Thanks, Grant diff --git a/java/build.xml b/java/build.xml index 1431394..6077bb6 100644 --- a/java/build.xml +++ b/java/build.xml @@ -61,8 +61,8 @@ - - + @@ -70,6 +70,11 @@ + + + + @@ -929,6 +934,11 @@ delete from rhnChannel where label like 'ChannelLabel%'; + ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
