Building Candlepin in Brew using Mead
by Adam Young
Mike Bonnet was good enough to spend a couple of hours with me getting
me up to speed on what he is doing with Mead. The short of it is that
he has a middle grouind between mavne repository fetching and JPackage
for building Maven based projects.
In order to take advantage of it, we have one of two choices.
1. Move Candlepin over to maven
2. Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of
the MySpec RPMS I built. We could selectively use them if we desire.
I like option 2, although I might not be able to see it through. In
order to do this, we have to close the loop on buildr doing local
repository builds. As I can see it this means modifying the -r
localbuild option such that, once the localbuild script has modified the
remote and local repository values, they can no longer be modified by
the buildfile. I think I can make this happen, I'll let you know. It
might take an additional patch to buildr.
We also need to hack the emma code inside of buildr to not try and
download emma from a remote repository.
Once that is done, Mike needs to provide an extension to the command
line interface to brew: something like brew-buildr, and then modify how
that calls brew such that it knows to do a buildr -r localbuild type
build. The localbuild file will be something that he controls as part
of the mead/brew system, and that will manage the repos used to build
candlepin.
13 years, 11 months
Re: cert-fte-candlepin.devlab.redhat.com updated
by Justin Harris
----- "Justin Harris" <jharris(a)redhat.com> wrote:
> ----- "Bryan Kearney" <bkearney(a)redhat.com> wrote:
>
> > On 05/28/2010 03:16 AM, Chris Alfonso wrote:
> > > The candlepin proxy and it services have been redeployed:
> > >
> > > candlepin: .15-1.git.54dd76e11771e0b09e19342aba6585fd73f0bcd2
> > > candlepin-util (it services):
> > 4ea5a4a5b8ef7d5344ba36fdcd3879fb8e4e9607
> > >
> > >
> > > If you're paying any attention to this email, you'll notice the
> > > installed candlepin rpm is a tito test build. We wanted to make
> > sure
> > > we got the latest changes on there for subscribe by pool and by
> > > product.
> > >
> > > The bind by product, pool, and regtoken are now functional. The
> > bind
> > > by product takes an engineering product id (what people have
> > referred
> > > to as a hash). There isn't a good way to know what those ids are
> > > without looking at a product cert or by looking in the database.
> > Our
> > > team can help out with the test scenarios by looking up the ids
> if
> > > needed (for the cli testing).
> > >
> > > Let me know if you have any questions.
> > >
> > > Thanks,
> > >
> > > Chris
> > Thanks Chris. Jharris.. I saw the prodID code went in yesterday.
> Can
> > we
> > use that code to gen up product ids from the IT data?
>
> Yeah I don't see why not, but there's only one way to find out...
Actually, on second thought, this will not work. I had to add a method for product cert creation
to the product service adapter, and as IT is using their own implementation, they will not get this for free.
With a little copy-paste technology they probably could have it working fairly quickly though...
>
> >
> > -- bk
> >
> > _______________________________________________
> > candlepin mailing list
> > candlepin(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/candlepin
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
13 years, 11 months
Re: cert-fte-candlepin.devlab.redhat.com updated
by Bryan Kearney
On 05/28/2010 03:16 AM, Chris Alfonso wrote:
> The candlepin proxy and it services have been redeployed:
>
> candlepin: .15-1.git.54dd76e11771e0b09e19342aba6585fd73f0bcd2
> candlepin-util (it services): 4ea5a4a5b8ef7d5344ba36fdcd3879fb8e4e9607
>
>
> If you're paying any attention to this email, you'll notice the
> installed candlepin rpm is a tito test build. We wanted to make sure
> we got the latest changes on there for subscribe by pool and by
> product.
>
> The bind by product, pool, and regtoken are now functional. The bind
> by product takes an engineering product id (what people have referred
> to as a hash). There isn't a good way to know what those ids are
> without looking at a product cert or by looking in the database. Our
> team can help out with the test scenarios by looking up the ids if
> needed (for the cli testing).
>
> Let me know if you have any questions.
>
> Thanks,
>
> Chris
Thanks Chris. Jharris.. I saw the prodID code went in yesterday. Can we
use that code to gen up product ids from the IT data?
-- bk
13 years, 11 months
Eventing stuff
by Bryan Kearney
I pulled it down, and it looked good. Based on a quick call this
morning, I would like to articulate the events we would like to have.
You can see it at [1]. Please make any comments, concerns.
and some additional access points. I assuming something like:
/consumers/{uuid}/atom
/owners/{uuid}/atom
-- bk
[1] https://fedorahosted.org/candlepin/wiki/Events
13 years, 11 months
what's new in jackson
by James Bowes
I pushed out some changes to the jackson branch last night which:
- make objects serialized as json use human readable datetimes
- allow you to configure pretty printed json via the
candlepin.pretty_print=<boolean> config value (looks awesome in the
logs for debugging, if i do say so myself)
- use either jackson or jaxb annotations for reading/writing objects,
prefering the jackson ones, if present.
These are done by making our own jax-rs JsonProvider and twiddling the
jackson configuration. In the process of writing this I found out that
we could really do it with the provider provided (heh) by RestEasy or
Jackson without subclassing, but I still do think the provider will be
the place to do input validation, so I went ahead and made the class.
-James
13 years, 11 months
Hand off
by Adam Young
Time to hand off the ongoing work on buildr and JPackage for Candlepin
here's the deal.
https://bugzilla.redhat.com/show_bug.cgi?id=588406 contains the review
for rubygem-buildr. All of the depdencies are in separate RPMs, and are
posted for review in bugzilla, as dependencies of this bug.
rubygem-rubyzip is pretty close to complete. The bug report is here:
https://bugzilla.redhat.com/show_bug.cgi?id=588474
The install steps for the other gems are going to look similar. Most of
the code in %install is dealing with rpmlint issues, and has been based
on the work done in rubygem-libxml, which was started by Matthew Kent
<mailto:mkent@magoazul.com>. Matthew's approach is more mature than
what I was doing, so I abandoned mine in favor of his. This gem isn't
needed for buildr, but is used in many of the pom2rpm scripts and else
where.
If you really want to get Candlepin to build with RHEL5 and Fedora>11,
you will prboably need to extract the dependencies out into something
that buildfile then includes, as you will need different version numbers
for each. I'd suggest scrubbing the dependency list and seeing if there
are some that you can drop. I suspect that the various methods of doing
json should and can be compined into a single approach, and you can drop
the other rpms. I think there is real value in the guice and resteasy
rpms, and these will make a valuable addition to Fedora.
Getting Candlepin to build in buildr or even Maven with JPackage is
going to take a lot of finesse. I was able to get successful builds on
F12 by building certain RPMS by hand, installing others from JPackage
and sometimes forcing something through (rpm -i --nodeps ). The fewer
packages you have to force through this way, the better.
If you can automatically generate a minimal pom.xml file for Mead, that
is probably your easiest approach to doing a Koji based build. While it
might be gratifying to make buildr work that way, I'd almost suggest
putting that off until you get teh JPAckage issues ironed out. buildr
and JPAckage are related issues, but they can be attacked in Parallel,
and might benefit by having multiple members of the team address them,
as the overall solution will be better in the long run.
I'll maintain the candlepin and buildr repons on my fedorapeople site
for the time being. Eventually, I'll want to reclaim them. If they are
going to have long tails, please get them moved to the Fedora candlepin
website if possible.
Looking forward to Candlepulp.
13 years, 11 months
Hand off
by Adam
Time to hand off the ongoing work on buildr and JPackage for Candlepin
here's the deal.
https://bugzilla.redhat.com/show_bug.cgi?id=588406 contains the review
for rubygem-buildr. All of the depdencies are in separate RPMs, and are
posted for review in bugzilla, as dependencies of this bug.
rubygem-rubyzip is pretty close to complete. The bug report is here:
https://bugzilla.redhat.com/show_bug.cgi?id=588474
The install steps for the other gems are going to look similar. Most of
the code in %install is dealing with rpmlint issues, and has been based
on the work done in rubygem-libxml, which was started by Matthew Kent
<mailto:mkent@magoazul.com>. Matthew's approach is more mature than
what I was doing, so I abandoned mine in favor of his. This gem isn't
needed for buildr, but is used in many of the pom2rpm scripts and else
where.
If you really want to get Candlepin to build with RHEL5 and Fedora>11,
you will prboably need to extract the dependencies out into something
that buildfile then includes, as you will need different version numbers
for each. I'd suggest scrubbing the dependency list and seeing if there
are some that you can drop. I suspect that the various methods of doing
json should and can be compined into a single approach, and you can drop
the other rpms. I think there is real value in the guice and resteasy
rpms, and these will make a valuable addition to Fedora.
Getting Candlepin to build in buildr or even Maven with JPackage is
going to take a lot of finesse. I was able to get successful builds on
F12 by building certain RPMS by hand, installing others from JPackage
and sometimes forcing something through (rpm -i --nodeps ). The fewer
packages you have to force through this way, the better.
If you can automatically generate a minimal pom.xml file for Mead, that
is probably your easiest approach to doing a Koji based build. While it
might be gratifying to make buildr work that way, I'd almost suggest
putting that off until you get teh JPAckage issues ironed out. buildr
and JPAckage are related issues, but they can be attacked in Parallel,
and might benefit by having multiple members of the team address them,
as the overall solution will be better in the long run.
I'll maintain the candlepin and buildr repons on my fedorapeople site
for the time being. Eventually, I'll want to reclaim them. If they are
going to have long tails, please get them moved to the Fedora candlepin
website if possible.
Looking forward to Candlepulp.
13 years, 11 months
Better json through jackson
by James Bowes
All:
I've pushed out a new branch for some fiddling I did on Friday night to
move from jettison for json reading/writing to jackson. IMO jackson
creates much nicer json. Here's what a consumer looks like:
== OLD ==
{"consumer" : {
"name" : "my consumer",
"type" : {"label" : "system" }
}
}
== NEW ==
{"name" : "my consumer",
"type" : "system"}
Through nicer json, we get nicer client code (fewer redundant
variable/key names).
Another cool think about jackson is it can generate json schema, which
I've hooked up in a few cases to the ApiCrawler.
Before bringing this into master, I'd like to:
* make sure the java client speaks new json
* come up with a convention for variable names in json. I'd like to do:
endDate => end_date, as I think the underscore looks more jsonic.
enforce this convention.
* Create our own json reader/writer so we can configure jacksons
settings for:
* Use "YYYY-MM-DDTHH:MM:SS-04:00" for datetime, rather than seconds
since the epoch
* allow a configurable toggle for json pretty printing (great for
debugging)
* Have the hooks in place for input validation (do after merge)
* Check for any concessions we made with jettison re base64 encoding or
int to string conversion, and elimnate them.
* consider dropping xml support, or consider using jaxb annotations for
jackson.
I've also got patches for the python code locally, for when we switch.
Comments?
-James
13 years, 11 months
