the rhsm boxes
by Bryan Kearney
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
13 years, 9 months
Java client updated to not use goofy keystores
by Bryan Kearney
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
13 years, 9 months
Product Model
by Bryan Kearney
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
13 years, 9 months
Re: Product Model
by Justin Harris
----- "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
13 years, 9 months
Postgresql Warning
by Devan Goodwin
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
13 years, 9 months
Cucumber and you (or I, as it were)
by Justin Harris
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
13 years, 9 months
Re: Comments on data-export branch
by Justin Harris
----- "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
13 years, 9 months
Comments on data-export branch
by Bryan Kearney
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
13 years, 9 months
Multi Entitle Product Attribute
by Bryan Kearney
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
13 years, 9 months