candlepin July 2011

candlepin@lists.stg.fedorahosted.org

6 participants
12 discussions

[PATCH] - BZ#713164 - Strange phrases at pt_BR translation ">>>>> Contexto inserido pelo KBabel, não traduza:yes"
by Marcelo Moreira de Mello 09 Aug '11

09 Aug '11

Hello, This patch fixes some strange phrases on pt_BR translation. Thank you! Cheers, Marcelo Moreira de Mello -- Marcelo Moreira de Mello RHCA RHCSS RHCVA Software Maintenance Engineer/SEG gpg id: 2048R/FDB110E5 gpg fingerprint: 3BE7 EF71 4DD7 6812 D309 8F18 BD42 D095 FDB1 10E5

2 4

Distributor Type on the ConsumerType
by Bryan Kearney 03 Aug '11

03 Aug '11

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

3 6

Packaging suggestions
by Bryan Kearney 01 Aug '11

01 Aug '11

Suggestion on this bz: https://bugzilla.redhat.com/show_bug.cgi?id=717052 put an rm command in %preun run subcription-manager-clean in %preun echod "Pound sand" thoughts? -- bk

3 4

Eliminating UnsupportedOperationExceptions in adapters
by James Bowes 22 Jul '11

22 Jul '11

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

2 1

Import Config Option
by Devan Goodwin 21 Jul '11

21 Jul '11

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

2 2

Fwd: Re: [Pulp-list] Candlepin and Certificate Revocation
by Bryan Kearney 21 Jul '11

21 Jul '11

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

2 2

Candlepin and Certificate Revocation
by Bryan Kearney 21 Jul '11

21 Jul '11

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

2 3

new cpc tips page
by Jesus M. Rodriguez 20 Jul '11

20 Jul '11

Trying to figure out how to register a fake client to test with, I gave cpc client a try. It's not trivial :) So I started a tips page. Feel free to add more as you find them. https://fedorahosted.org/candlepin/wiki/cpctips jesus

1 0

Fwd: [katello-devel] Dates in the url
by Bryan Kearney 18 Jul '11

18 Jul '11

Thoughts? -- bk -------- Original Message -------- Subject: [katello-devel] Dates in the url Date: Mon, 18 Jul 2011 14:45:31 -0400 From: Bryan Kearney <bkearney(a)redhat.com> To: Katello-devel(a)redhat.com Are any of the katello or pulp urls using dates? We have a bug in candlepin where the caller is expcting to pass in an ISO 8601 date but candlepin is expecting an xsd string: http://books.xmlschemata.org/relaxng/ch19-77049.html I am trying to decid if is worth changing it. -- bk _______________________________________________ katello-devel mailing list katello-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/katello-devel

2 2

Rounding Out Activation Keys
by Devan Goodwin 18 Jul '11

18 Jul '11

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

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

candlepin July 2011