Distributor Type on the ConsumerType
by Bryan Kearney
Today, there is one type which is allowed to do exports.. it is the
"Candlepin" type. We have gotten the request to support more than one
distributor type. Anyone mind putting a boolean on that type which is
"is distributor", and changing the logic so that it checks that instead
of the type iteself?
-- bk
12 years, 8 months
Eliminating UnsupportedOperationExceptions in adapters
by James Bowes
Hi all:
While working on the katello related auth bits, I got annoyed by having
to throw UnsupportedOperationException from all of the methods, and
started looking at how we might refactor to replace those with multiple
interfaces for our adapters.
In summary, the UserServiceAdapter interface defines a number of calls
to perform CRUD operations on users (and roles). The default adapter,
which stores users in candlepin's db, implements all of the methods. The
katello adapter implements _none_ of them (all of the auth logic is
handled in katello, before a call reaches candlepin). The adapter used
by rhn.redhat.com does not implement creation/deletion. Any
unimplemented calls throw UnsupportedOperationExceptions. Other adapters
follow the same pattern (in particular, the ProductServiceAdapter).
Current practice is to have a caller be aware of which methods might not
be implemented, and have them catch the exception and notify the api
user as appropriate. Not all callers do this; its understandably hard to
keep track of this convention's usage. In actual deployments, the REST
endpoints that expose apis which hit these conditionally implemented
methods are masked off via proxies, or responded to by katello, etc.
If your deployment does not have an adapter that responds to the create
user call, you don't expose POST /candlepin/users.
For a POC, i've taken the ProductServiceAdapter and ripped out all of
the methods that wouldn't be in the rhn.redhat.com adapter into a new
interface, WriteableProductServiceAdapter (I love the name, too). In the
main code base, the DefaultProductServiceAdapter just implements both
interfaces.
Going further up the stack, REST operations that use the new
WriteableProductServiceAdapter calls get moved to
WriteableProductResource (but are still exposed under /products, at the
same urls).
Lastly, the guice calls to bind() both the new interface and the new
resource are put into their own guice module, StandaloneConfig, which is
not read by default at candlepin startup (you must tell candlepin to
load it via the module.config config directive). If StandaloneConfig is
read at startup, then candlepin will respond to product creation rest
calls; if not, then the client will get a 404.
My hope is that we can do the same for all adapters: pull out any calls
that are commonly not implemented, put them under their own interface,
and extract out a new resource. For each deployment style, we can then
write a new guice module that will be responsible for loading the
implementations of all adapters they use, and the common resource
frontends as applicable (to make it clear, WriteableProductResource
would be the same code across all deployment types, it might just not be
used at all, if they don't implement the required adapter).
Please have a look at the adaptergate branch and let me know what you
think of this approach. Is it uglier than the current style? Do we want
to change the exposed urls or have them always exist, but just throw
errors?
Lastly, even if we don't use this, it's kind of a neat POC of how we
could do 'plugins' to provide api extensions.
-James
12 years, 9 months
Import Config Option
by Devan Goodwin
candlepin.importer.fail_on_unknown Can now be set to "true" or "false"
in your candlepin.conf. By default it's true and we'll continue
erroring out if something is wrong. I think this is opposite of what
we said in planning but thought was it will almost surely be forgotten
and go out the door in the wrong state, and now we have something we
can give anyone who hits troubles.
Let me know if anyone feels strongly we should leave it permissive for
now and I'll switch it.
I have not yet tested it functionally, only in unit tests with a quick
and easy check which I think covers all object mappers used during the
import process. May look into how to reproduce manually tomorrow but
it could be tricky.
Cheers,
Devan
12 years, 9 months
Fwd: Re: [Pulp-list] Candlepin and Certificate Revocation
by Bryan Kearney
James.. thoughts?
-- bk
-------- Original Message --------
Subject: Re: [Pulp-list] Candlepin and Certificate Revocation
Date: Thu, 21 Jul 2011 11:55:46 -0400
From: Bryan Kearney <bkearney(a)redhat.com>
To: Jason L Connor <jconnor(a)redhat.com>
CC: pulp-list(a)redhat.com
On 07/21/2011 11:24 AM, Jason L Connor wrote:
> Disclaimer: I haven't done any work with Candlepin integration or even
> our certificate based authorization. So this email is going to be a
> bunch of "thinking out loud", if you will.
>
> It looks like the functionality is boiling down to batch vs single
> certificate revocation.
well.. batch transmission of data, still checking per request to pulp
>
> In either case I prefer standards compliance over non-, so I don't like
> the custom option.
>
+1
> I guess it's a trade off of how fine-grained, time-wise, we want
> certificate revocation to be vs. how much do we want to talk over the
> network.
I think we can live with daily, or perhaps every 6 hours or so.
>
> I like the batch operation (CRL) as it doesn't need to check the status
> of a certificate with candlepin at the same time as fielding a request
> from a client. However, depending on how often the revocation list is
> generated, the information pulp has at any given time for a certificate
> may be out of date.
>
> If we can keep the time granularity on certificate revocation
> sufficiently coarse or we're willing to live with sufficiently short
> periods of time in which we have dated certificate information, I think
> this solution is the best.
>
> If we cannot, we should move to OCSP.
I am fine with CRL if you guys are. Lemme check with the thumbslug folks.
-- bk
_______________________________________________
Pulp-list mailing list
Pulp-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
12 years, 9 months
Candlepin and Certificate Revocation
by Bryan Kearney
Cross posting to pulp and candlepin lists. I apologize in advance.
I am looking at how candlepin needs to communicate certificate
revocation. The two main consumers I know of for this data are pulp (as
part of katello) and thumbslug. In both cases, pulp and thumbslug are
emitting a CDN interface and need to verify if a certificate presented
to them are accurate.
There are three main options that I have seen. Basic pros and cons
below. I am looking for feedback from both camps as which they would
prefer. I would like to agree on one model to limit testing issues.
Certificate Revocation Lists (CRL)
==================================
Candlepin generates CRLs which are read by Pulp/Thumbslug. Files are
regenerated every X hours and need to be refreshed.
Pros:
(1) Candlepin does this already!
(2) Standards compliant
Cons:
(1)As the tools are horzontally scaled, we need to design out how
(1.1) Handle candlepin is on many machines
(1.2) Handle when pulp/thumbslug is on different machines from candlepin
Online Certificate Status Protocol (OCSP)
=========================================
An OCSP responder exists which can return a yes/no for certificates.
Pros:
(1) Standards Compliant
(2) Should solve the cross machine issues
Cons:
(1) More work for Candlepin
(2) May need to implementing a "mirror list" type solution for finding
candlepin
Custom Wire Protocol
====================
Same model as OCSP, but custom protocol.
Pros:
(1) Should be easier to implement than OCSP
(2) Should resolve the cross machine issues
Cons:
(1) Same as OCSP
Comments from folks?
-- bk
12 years, 9 months
Rounding Out Activation Keys
by Devan Goodwin
Questions:
- Should we change the straight activation key to pool relationship.
>From what I heard the other day it's not just a relation to a pool,
but will also require a quantity, which probably implies some kind of
intermediary object.
- Could an activation key ever reference a product rather than a specific pool?
- Is there anything else our activation keys will need to do?
- What restrictions should be placed on activation key text? I'm a fan
of the alpha-numeric + "-" and "_" for things like this.
- Are we expecting these to be operational at the end of this sprint?
Or just that you can pass them in during registration but nothing will
happen.
Thanks,
Devan
12 years, 9 months
