candlepin July 2010

candlepin@lists.fedorahosted.org

9 participants
18 discussions

the rhsm boxes
by Bryan Kearney 26 Jul '10

26 Jul '10

I had assumed that the rhsm boxes were as follows: 1) (Top) Those that match your hardware and installed products. 2) (Bottom) Those that match your hardware but not installed _or_ compatible with your hardware. 3) (Hidden) Those incompatible In the current implementation, if you have a 10 socket machine, and a 2 socket subscription then the subscription will be in the 3rd box. Does this seem correct? The reason is that we use warnings for both architecture and for socket mismatches. Does this seem correct? I wonder if arch should be an error, and we move warnings to the second box? -- bk

1 0

Java client updated to not use goofy keystores
by Bryan Kearney 23 Jul '10

23 Jul '10

I was hitting some client bugs, and the java client was failing because of the new keystore format. I pushed a change that it now uses the PEM encoded Crt file. The new config file should look like: serverURL=https://localhost:8443/candlepin/ candlepinCertificate=/etc/candlepin/certs/candlepin-ca.crt BTW... if you haave ever thought the Calendar API sucks for java.. you should look at the SSL API. Good G*D. -- bk

1 0

Product Model
by Bryan Kearney 23 Jul '10

23 Jul '10

I am scanning the product model (attached). Couple of Questions: - what is multiplier on the product? - content carries a vendor.. should that also be on the product? - On the product_content table, what are flexentitlement and physicalentitlement? - I see a join table at cp_product_cp_product_attribute AND a FK from cp_product_attribute to cp_product. Which is correct? -- bk

4 8

Re: Product Model
by Justin Harris 22 Jul '10

22 Jul '10

----- "Bryan Kearney" <bkearney(a)redhat.com> wrote: > On 07/22/2010 12:54 PM, Justin Harris wrote: > > > > ----- "Bryan Kearney"<bkearney(a)redhat.com> wrote: > > > >> On 07/22/2010 11:59 AM, Devan Goodwin wrote: > >>> On Thu, Jul 22, 2010 at 10:46 AM, Bryan > Kearney<bkearney(a)redhat.com> > >> wrote: > >>>> I am scanning the product model (attached). > >>>> > >>>> Couple of Questions: > >>>> > >>>> - what is multiplier on the product? > > > > This is how many entitlements are added to the entitlement pool per > single subscription. It allows for e.g. "Dev Tools 25 pack" - which > would have a multiplier of 25. > > > > Remind me, this is not an attribute why? It boils down to a design decision - the rule of thumb we have been going with is this: attributes are used only by the javascript rules, and anything needed by the java engine lies directly on the model. In this case, the engine actually applies the multiplier, so we put it on the model. > > -- bk

1 0

Postgresql Warning
by Devan Goodwin 22 Jul '10

22 Jul '10

If you're using a Postgresql DB, it appears to be a bad idea to use jpa.config.hibernate.hbm2ddl.auto=create in your /etc/candlepin/candlepin.conf. I think this is only updating your schema if possible, so if the db has existing schema it will not necessarily be properly updated after changes. The result can be partially functional deployments that fail in strange ways. It should work ok for in-memory HSQLDB deployments. For Postgresql, I recommend commenting out this line in candlepin.conf, and using GENDB=1 with your deploy command to rebuild the db. This will destroy it completely and rebuild. Cheers, Devan -- Devan Goodwin <dgoodwin(a)rm-rf.ca> http://rm-rf.ca

2 1

Cucumber and you (or I, as it were)
by Justin Harris 21 Jul '10

21 Jul '10

Upon doing some work in the cucumber tests, it struck me that there were a lot of inconsistencies in the way tests were being put together, as well as confusion in the semantics of a lot of the Given/When/Then blocks. So I have a few proposals to make around cucumber patterns (Feel free to disagree/call me an idiot): * We drop the usage of the word 'I' entirely - we have too make different actors and types to really know who 'I' is. Is it the user, or the consumer they just registered? If a user registers two consumers, then 'I' can refer to different consumers depending on the context. * Refer to each actor or entity by a name - this name can then look a global hash table for that type to get the reference. Here is an example: Given an owner "Rackspace" exists And a user "bill" exists under owner "Rackspace" When user "bill" registers a consumer "virt11" Then consumer "virt11" has a type of "system" The main idea is that the entities are identified more explicitly, which IMO makes the implementation easier as well as the test a bit more readable to understand everything that is involved in the scenario. * We do not couple the features files to the ruby files under step_definitions - instead I propose that we have a ruby file that deals with a particular entity. So there would be an entitilement.rb, pool.rb, etc. Not entirely sure if this will work very cleanly, but the cucumber author has specifically said that coupling features and step_definitions is an anti-pattern to be avoided, and it makes sense that this practice kind of kills DRY. * Each step_definition would be responsible for keeping track of entities created on the candlepin instance and will clean up after itself in an After block - these all execute after a test has completed, but I'm not sure if this will introduce ordering issues if a lot of these need to be executed. I think that if we can all get on the same page around some best practices that work for candlepin, it will (hopefully) make writing functional tests less painful for everyone. So let me know if you guys think this is a good idea or not... - Justin

3 7

Re: Comments on data-export branch
by Justin Harris 19 Jul '10

19 Jul '10

----- "Ajay Kumar" <ajaykumarns(a)gmail.com> wrote: > Please find my comments/suggestions below: > > 1.RulesImporter.java{#42} new BufferedReader(..) is instantiated and > not used after that(perhaps forgot to clean it up?) > > 2. LinkedList used instead of ArrayList - This is more of a general > comment. I have noticed that LinkedList is used in a lot of places > within candlepin and it is my understanding that LinkedList is very > slow than ArrayList and most folks use ArrayList unless there is high > memory constraint. This really depends on the use case - there is a reason that both implementations are included. If all you are really doing is adding to a collection and then looping over the whole thing, then LinkedList is perfectly reasonable and probably preferred, as adding elements to a LinkedList can be more efficient overall if you exceed the size of the underlying array in an ArrayList, as it will need to allocate a new array and copy all of the elements over. However, if you need to access elements by their index, then by all means use an ArrayList, because afaik the LinkedList implementation has to traverse the list from the head in order to access the element. > > 3, logged.debug/info used without guard statements. Again, this is > more of a general statement(lot of occurrences within candlepin). > logging without guard statements makes the code run slower. I suggest > that we migrate our logging statements to slf4j framework. Migrating > to slf4j gives us the following advantages > i) You don't have to use guard statements at all. > for example, if you want to log > if(logger.isDebugEnabled()) > logger.debug("loading entitlements for > consumer: " + consumer.getId()) //log4j > } > In slf4j, you write. > logger.debug("loading entitlements for > consumer: {}", consumer.getId()) //slf4j > > Note that the log statements look cleaner and also you don't > have to write guard statements. If debug is not enabled, slf4j does > not perform template substitution. So no performance impact. > > ii) slf4j is not a separate logging framework. It delegates log > calls to either log4j/java's util.logger/ logback etc... So, we can > continue to configure our logging formats in log4j / change the > backend logging framework anything else. > iii) No extra jars to add - hibernate already uses slf4j. > iv) template substitution. > and more... > what say you? > > 4. Can we make the 'buf len' Exporter#addFilesToArchive and > Importer#extractArchive configurable? I have personally seen > performance benefits when the buf len is more than 1024. Again this > depends on the underlying file system etc.. Perhaps should we move > all > zip handling code into separate utility classes?(they are private > methods right now) > > 5. I am seeing this pattern lot of times within our code {More of a > general statement.. applies to all code within candlepin} > mapping id to entity. Converting Set<Entity> => Map<Id, > Entity>. Because all the domain objects inherit from > AbstractHibernateObject,(all inherit getId from this class) can we > have a general utility method to take of this mapping ? > > 6. Should Importer#loadExport be renamed to Importer#loadImport? > > 7. In my personal opinion the > i) *Exporter.java classes seem to be just delegating call to > jackson's ObjectMapper#writeValue. Do we really need these classes? I > can understand using these classes if jackson's classes were not > exposed but rather used within these classes.(encapsulating > dependency) > ii) *Importer.java seem to just delegate to jackson's > ObjectMapper#readValue and set id to null. Again, do we need this > abstraction? In my opinion, the store method should be moved to > curator level as it is replicating store functionality. > > 8. I also believe Exporter and Importer.java seem to bear lot of > heavy > weight... In my opinion, > > *) We could have an OwnerImporter/Exporter which would take > care of importing all entities within an owner and > -> handing down consumer import/export to > ConsumerImporter/Exporter... > -> handing down Entitlement import/export to > EntitlementImporter/Exporter > > and so on.. something like a chain of responsibilities. > > 9. Again this is more of a general comment. I have seen that we are > using rules engine within the code to restrict access/etc.. In my > opinion rules implementation could be moved into a separate AOP > layer/code. > > 10. The existing AOP code which uses annotation to restrict access to > db does not seem to cache the class -> annotation relationship. I > believe if this is done, we will see a lot of performance > improvements. > > On Fri, Jul 2, 2010 at 2:24 PM, Bryan Kearney <bkearney(a)redhat.com> > wrote: > > Exporting: > > > > - I assume that signing ill be added to the export, and verification > to > > the import? > > - Does the use of process builder / tmp directories mean we can not > run > > in a J2EE container? > > - Where do you make the split between putting code into hte > exporter > > methods and the exporter? > > - I see "MKT" around the code. Can we do a "hasProductCert" check > instead. > > - Are hte product ids stored, or re-generated? > > - We will need the cert and json for the entitlement. > > - Can we throw an export eventin there? > > > > Importing: > > - Consumer becomes owner. > > - I assume a second path will be to look for updates.. this code > appears > > to be create only.l > > _______________________________________________ > > candlepin mailing list > > candlepin(a)lists.fedorahosted.org > > https://fedorahosted.org/mailman/listinfo/candlepin > > > > > > -- > with regards > Ajay Kumar.N.S > http://www.linkedin.com/in/ajaykumarns > _______________________________________________ > candlepin mailing list > candlepin(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/candlepin

2 1

Comments on data-export branch
by Bryan Kearney 19 Jul '10

19 Jul '10

Exporting: - I assume that signing ill be added to the export, and verification to the import? - Does the use of process builder / tmp directories mean we can not run in a J2EE container? - Where do you make the split between putting code into hte exporter methods and the exporter? - I see "MKT" around the code. Can we do a "hasProductCert" check instead. - Are hte product ids stored, or re-generated? - We will need the cert and json for the entitlement. - Can we throw an export eventin there? Importing: - Consumer becomes owner. - I assume a second path will be to look for updates.. this code appears to be create only.l

2 1

2 wiki pages to keep up2date
by Bryan Kearney 16 Jul '10

16 Jul '10

Folks: Please make sure to keep the following wiki pages up2date. The QE group is using them for test planning and development: https://fedorahosted.org/candlepin/wiki/API Has the current API for candlepin https://fedorahosted.org/candlepin/wiki/ProductAttributes Has a list of the valid product attributes we support If folks can think of ways to automate the upkeep, I am all for it. -- bk

1 0

Multi Entitle Product Attribute
by Bryan Kearney 16 Jul '10

16 Jul '10

Quick Question.. looking at the set of supported product attributes at [1] we have one called multi-entitle. What does that do? Is it: (A) I can subscribe to a quantity greater that one in a single entitlement? (B) I can have 2 entitlements for a consumer? Thanks! -- bk

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

candlepin July 2010