Re: [Spacewalk-devel] Spacewalk 0.4 update
On Mon, Nov 24, 2008 at 10:07 PM, Partha Aji <[EMAIL PROTECTED]> wrote: > Mike McCune wrote: >> >> Jesus M. Rodriguez wrote: >>> >>> Hey Spacewalk hackers, >>> >>> I'd like to wrap up feature and bug fixing by 12/5 so that we can >>> start the package building process on Monday 12/8 for a release on >>> 12/15. Let me know if this will be a problem. >>> >>> Feature freeze: 12/5 >>> Packages: 12/9 >>> QA freeze: 12/12 >>> Release: 12/15 >>> >> >> I'm thinking since the scope of features in 0.4 is much much larger than >> the previous releases we are going to need to spend more time in testing >> (multiorg and cobbler-koan come to mind) >> >> I'd advocate we instead release a QA build to the public on 12/15 and do >> the final release on say ... 12/22? Or after the break? I realize I'm >> calling for us to be late but it seems rational to me. >> >> Anyone else agree/disagree? >> > +1. The cobbler koan feature will require significant testing w.r.t > provisioning especially. 12/15 release at this point seems a bit too > optimistic IMHO. > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel > >From a community perspective, having 0.4 after the holidays probably isn't a problem. Most people are minimally staffed and don't have a ton of time to try out new things. Also, things working is better than meeting a date. stahnma ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 0.4 update
Mike McCune wrote: Jesus M. Rodriguez wrote: Hey Spacewalk hackers, I'd like to wrap up feature and bug fixing by 12/5 so that we can start the package building process on Monday 12/8 for a release on 12/15. Let me know if this will be a problem. Feature freeze: 12/5 Packages: 12/9 QA freeze: 12/12 Release: 12/15 I'm thinking since the scope of features in 0.4 is much much larger than the previous releases we are going to need to spend more time in testing (multiorg and cobbler-koan come to mind) I'd advocate we instead release a QA build to the public on 12/15 and do the final release on say ... 12/22? Or after the break? I realize I'm calling for us to be late but it seems rational to me. Anyone else agree/disagree? +1. The cobbler koan feature will require significant testing w.r.t provisioning especially. 12/15 release at this point seems a bit too optimistic IMHO. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 0.4 update
Jesus M. Rodriguez wrote: Hey Spacewalk hackers, I'd like to wrap up feature and bug fixing by 12/5 so that we can start the package building process on Monday 12/8 for a release on 12/15. Let me know if this will be a problem. Feature freeze: 12/5 Packages: 12/9 QA freeze: 12/12 Release: 12/15 I'm thinking since the scope of features in 0.4 is much much larger than the previous releases we are going to need to spend more time in testing (multiorg and cobbler-koan come to mind) I'd advocate we instead release a QA build to the public on 12/15 and do the final release on say ... 12/22? Or after the break? I realize I'm calling for us to be late but it seems rational to me. Anyone else agree/disagree? -- Mike McCune mmccune AT redhat.com Engineering | Portland, OR RHN Satellite | 650.567.9039x79248 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: Spacewalk 0.4 update
On Mon, Nov 24, 2008 at 5:46 PM, Jesus M. Rodriguez <[EMAIL PROTECTED]> wrote: > Hey Spacewalk hackers, > > I'd like to wrap up feature and bug fixing by 12/5 so that we can > start the package building process on Monday 12/8 for a release on > 12/15. Let me know if this will be a problem. > > Feature freeze: 12/5 > Packages: 12/9 > QA freeze: 12/12 > Release: 12/15 > > If we can get the features done sooner that would be great. Here's the > roadmap: > https://hosted.fedoraproject.org/spacewalk/roadmap > > We have a number of bugs that need addressing. Please be sure to take > a look at your queue: > http://tinyurl.com/space04 I will need to triage these bugs first. jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 0.4 update
Hey Spacewalk hackers, I'd like to wrap up feature and bug fixing by 12/5 so that we can start the package building process on Monday 12/8 for a release on 12/15. Let me know if this will be a problem. Feature freeze: 12/5 Packages: 12/9 QA freeze: 12/12 Release: 12/15 If we can get the features done sooner that would be great. Here's the roadmap: https://hosted.fedoraproject.org/spacewalk/roadmap We have a number of bugs that need addressing. Please be sure to take a look at your queue: http://tinyurl.com/space04 Sincerely, jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Speedier bulk updates with hibernate
Hi All,
Recently I had been assigned a bz where rescheduling a large number of
failed actions (~5000) would take a very very long time and in the end
would time out for me. Looking at the code it was basically looping
over a set of ServerActions and setting a couple of object attributes
depending on certain conditions, which meant it had to load every
object. I started to go about using a write-mode query in data source,
but there is a better way.
Hibernate update statements:
Which can be executed as so:
public static void rescheduleFailedServerActions(Action action,
Long tries) {
singleton.getSession().getNamedQuery("Action.rescheduleFailedActions")
.setParameter("action", action)
.setParameter("tries", tries)
.setParameter("failed", ActionFactory.STATUS_FAILED)
.setParameter("queued",
ActionFactory.STATUS_QUEUED).executeUpdate();
}
Currently there isn't a useful function like listObjectsByNamedQuery but
I'll probably be adding one soon. The performance seems equivalent to
the raw sql update (~ 2 seconds).
It doesn't look like we've ever used this in our hibernate usage and I'm
not sure how new it is, but it seems to work great!
-Justin
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] multiarch - SSM remove packages issue
I ran into a wall while adding multiarch support to the SSM remove packages flow. Currently, we store the packages the user selects into an rhnSet. When determining on which servers the selected packages exist, the query uses the rhnSet of packages and the set of systems to let the DB do all the heavy lifting. The problem is in the two element approach in rhnSet; there's no room for arch (it's currently holding the name ID and evr ID in the two slots). This keeps me from using rhnSet to hold the packages for that query (I can easily hang on to them in memory with SessionSet). Likewise, an IN clause is probably out for all of the reasons I'm sure we've hit a number of other places. So I'm kinda stuck. Any ideas are appreciated. -- Jason Dobies ([EMAIL PROTECTED]) Senior Software Engineer RHN Satellite & Spacewalk Freenode: jdob @ #spacewalk, #spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Rebuild of packages in Koji - some problems
On Mon, Nov 24, 2008 at 09:34:43AM -0600, Dennis Gilmore wrote: > On Monday 24 November 2008 02:55:30 am Miroslav Suchý wrote: > > Last friday I let rebuild of all packages which has tag in git and has > > not been builded in Koji. Two problems has been found: > > > > perl-DBD-Oracle: > > http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9271 > > I will take care about it. > I thought i fixed it at some point by exporting the path for ORACLE_HOME in > both build and install sections > > > stringtree-json > > http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9307 > > Missing requires for unzip. > > Can you - Jesus or Partha - fix it? > thats missing BuildRequires unzip its not included in the minimal buildroot I can fix this. jesus -- jesus m. rodriguez| [EMAIL PROTECTED] 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] Rebuild of packages in Koji - some problems
On Monday 24 November 2008 02:55:30 am Miroslav Suchý wrote: > Last friday I let rebuild of all packages which has tag in git and has > not been builded in Koji. Two problems has been found: > > perl-DBD-Oracle: > http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9271 > I will take care about it. I thought i fixed it at some point by exporting the path for ORACLE_HOME in both build and install sections > stringtree-json > http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9307 > Missing requires for unzip. > Can you - Jesus or Partha - fix it? thats missing BuildRequires unzip its not included in the minimal buildroot ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Rebuild of packages in Koji - some problems
Last friday I let rebuild of all packages which has tag in git and has not been builded in Koji. Two problems has been found: perl-DBD-Oracle: http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9271 I will take care about it. stringtree-json http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9307 Missing requires for unzip. Can you - Jesus or Partha - fix it? -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] cx_Oracle
4 weeks ago has been released new cx_Oracle in version 4.4.1 I now that Michael tried to replace current version we use (4.2.1) with some 4.3.x version and it did not worked so he gave up. The new version has one important feature and it is forward compatibility with upcoming 5.0. So it may be worth to spend some cycles on making Spacewalk working with cx_Oracle 4.4.1 as it should then work with 5.0. -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
