Unbind Proposal
by Devan Goodwin
As per meeting this morning I'd like to pitch that we replace the
multiple unbind variants:
- unbind by entitlement ID
- unbind by product ID (actually already gone from API page after
convos with prad)
- unbind by certificate serial
- unbind all
With just:
- unbind by entitlement ID
- unbind all
Consider that a bind creates an actual "entitlement" object and
returns a struct to you as a result, which contains an ID specific to
that entitlement as well as information about the pool it originated
from, and it's product. I think this makes it fairly trivial for
client tools or any integrating application to keep track of the
entitlements for a specific consumer, and they can be queried at any
time.
I think we're all agreed that unbinding by certificate serial and
product ID are both convenience methods, but I think entitlement ID is
easy to use instead so there's little added benefit, and there are a
couple possible future scenarios I'd like to plan for: (1) one
consumer has multiple entitlements for one product, and (2)
entitlements that do not have certificates.
To me it seems best to keep the API as simple and explicit as
possible, provided we're not causing excessive pain for integrating
apps. The same argument could probably be made for unbind all, but I
was thinking it might get ugly in the case of a kickstart where a box
had a huge amount of entitlements, but wanted to retain it's consumer
UUID.
Keep in mind that this is just an API purity question and does not
influence what we actually display to a user, we're not forcing them
to pick an entitlement ID, we can still display their entitlements as
product names and let them choose. This only implies that the client
tools will send the entitlement ID in the background.
Thoughts?
Devan
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
14 years, 3 months
resteasy migration
by jesus rodriguez
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So Justin & I (well mostly Justin) did the resteasy migration. Biggest
change is that the JSON output is different (but more correct).
Jersey generated natural form json but didn't handle lists correctly.
Resteasy uses Jettisons mapped notation but handles the lists better.
This is my JsonTestObject as a natural notation (jersey used):
{"name":"myname","parent":{"name":"parentname","parent":{"name":"parent1"},"stringList":["string2","string3","child"]},"stringList":["string2","string3","child"]}
Where as the mapped notation has the object dictionary inside
another dictionary with a single root element key. The key is
either the value of the XmlRootElement annotation in the class
OR the class name itself:
{'jsontest': {'name': 'now', 'parent': {'name': 'parentname', 'stringList':
['string3', 'string4']}, 'stringList': ['string1', 'string2']}}
JsonTestObject: http://pastie.org/870667
Resteasy still doesn't handle returning a Boolean object though :)
"Could not find MessageBodyWriter for response object of type:
java.lang.Boolean of media type: application/json"
Before we push this to master, we'd like to get the client working against
the resteasy branch and fix up the nosetests which fail right now
because the format is different.
Candlepin Resteasy branch:
http://git.fedorahosted.org/git/candlepin.git/?p=candlepin.git;a=shortlog...
git checkout --track -b resteasy origin/resteasy
jesus
- --
jesus m. rodriguez | jesusr(a)redhat.com
principal software engineer | irc: zeus
red hat systems management | 919.754.4413 (w)
rhce # 805008586930012 | 919.623.0080 (c)
+---------------------------------------------+
| "Those who cannot remember the past |
| are condemned to repeat it." |
| -- George Santayana |
+---------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkuesEIACgkQvJZ57YntiYPIoQCfSd6xedRcqXFim3zRSP3NgXiI
gwsAn1s26KQ1PHCxDMRj3bLXtV/fsSrv
=ivyi
-----END PGP SIGNATURE-----
14 years, 3 months
cucumber
by jesus rodriguez
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Justin,
What I'd like to see is a brief overview (maybe even a Code Show & Tell)
about Cucumber and how to go about writing a test case. Then maybe
each of us could write our own test case using the framework to get a
feel for it. I don't want to commit to moving strictly to Cucumber
until we've all tried it.
- From what I've seen initially it "seems" neat, but I'm not sure I'd
like writing a test case in that non-programming language :) but
then again I don't like most things nowadays so I want others to
try it as well. I will be ok with what the team decides after we've
tried it.
At risk of biasing folks, the nosetests have 2 things going for them:
1) it's python and a lot of us are familiar with it
2) they are similar to how the client will interact with candlepin
so any problems we hit there, the client will hit as well.
jesus
- --
jesus m. rodriguez | jesusr(a)redhat.com
principal software engineer | irc: zeus
red hat systems management | 919.754.4413 (w)
rhce # 805008586930012 | 919.623.0080 (c)
+---------------------------------------------+
| "Those who cannot remember the past |
| are condemned to repeat it." |
| -- George Santayana |
+---------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkuesVEACgkQvJZ57YntiYMXkQCgxlLXkAjBx4vVpnrbz6Y/9cKp
ZNoAn0ut8uaskzg9TO+RJoug/Is63EBl
=svhd
-----END PGP SIGNATURE-----
14 years, 3 months
Running the Javascript rules
by Adam Young
I added a new Constructor to JavascriptEnforcer:
public JavascriptEnforcer(DateSource dateSource, Reader rulesReader,
PreEntHelper preHelper, PostEntHelper postHelper,
ProductServiceAdapter prodAdapter, ScriptEngine jsEngine)
I also left the old one, but changed its implementation to call the new one:
public JavascriptEnforcer(DateSource dateSource, RulesCurator
rulesCurator,
PreEntHelper preHelper, PostEntHelper postHelper,
ProductServiceAdapter prodAdapter) {
this(dateSource, new
StringReader(rulesCurator.getRules().getRules()),
preHelper, postHelper, prodAdapter, new ScriptEngineManager()
.getEngineByName("JavaScript"));
}
However, this type of construction code is really no appropriate a class
like this. Jesus mentioned that he feels the same way about
ProductServiceAdapter, which I will look at in a little bit.
With those changes, I can make a stand alone unit test that runs without
any Hibernate support, at least for calling
public Pool selectBestPool(Consumer consumer, String productId,
List<Pool> pools);
The next piece of trickiness is loading in the Javascript file. For
static deployments, the usual way to find a text file like this is:
URL url =
this.getClass().getClassLoader().getResource("rules/default-rules.js");
InputStreamReader inputStreamReader = new
InputStreamReader(url.openStream());
Which works fine so long as the resource is on the classpath. Thus for
the Junit test, I added a file CLASSPATH extension which was
"target/test/resources". Since it looks like we are regenerating the
.project file from git sources, this might not live across check-ins.
I'm thinkin that if our goal is to make the Javascript something that
the end use is responsible for editing and deploying, we need to provide
the user with a tool to go through the edit-deploy-debug cycle. Are we
planning on doing that as part of the web app? Are we going to allow
the user to deploy multiple .js rules files, and indicate which is the
"live" one?
Both patch and html diff are are attached.
14 years, 3 months
Deleteing consumers and certs
by Adam Young
I should have posted to this list insted of imanage. Sorry for the dup
postings, but I realized that I wouldn't get responses from the other list.
Right now there is a one to one relationship between consumer and
certificate. THe id for the ConsumerIdentityCertificate is the same as
the ID for the consumer. Thus, if we delete the consumer, we should
delete the certificate.
Is this sufficient for revoke?
Part of me thinks that we should never throw away data: once we record
a consumer, we should keep that information and just transform it into a
"inactive" state, but I realize that complicates the logic, and
potentially has an impact on Database size and performance.
14 years, 3 months
Minor API Changes
by Devan Goodwin
Couple tiny API changes to the Pool data structure:
- Renamed pool field maxMembers to "quantity".
- Exposed pool field currentMembers to "consumed" and added to serialized JSON.
Prad this should get you the info you were looking for about how many
entitlements are available. (quantity-current)
Cheers,
Devan
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
14 years, 3 months
