bundle / content api redesign

Lukas Krejci lkrejci at redhat.com
Tue Feb 5 15:46:32 UTC 2013


On Tuesday, February 05, 2013 10:15:13 Jay Shaughnessy wrote:
> Off-List
> 
> On 2/5/2013 7:02 AM, Lukas Krejci wrote:
> > Yes, this needs to be well discussed and I appreciate your comments and
> > the time you're putting into deciphering my tangled thoughts ;)
> > 
> > Before we go into the details on a call, I'd like to clear up the feeling
> > you both seem to have gotten from the wiki page.
> > 
> > So far I've been dealing with the storage of the new system. To be frank,
> > the storage of bundles is a hack and is duck-taped on to the the
> I'm sorry, but I take offense to the repeated use of the word "hack"
> with respect to the Bundle data model.  It was actually the result of
> many revisions, with input from many parties, and an evolving set of
> requirements.  I agree that all that revision may have been somewhat
> detrimental to the finished product but it is far from a mess.  It's
> actually a clear separation of the storage model and the deployment model.
> 
> Anyway, I'll write more On-list.
> 

I didn't mean to offend you. I can see how we came to that design and I don't 
try to blame anyone for it. 

I just think that repurposing the storage of the content subsystem for bundles 
was not a good idea (and I can blame only myself for not shouting about it 
when we were implementing bundles), because the usage patterns of a repository 
is totally different from the usage pattern of a bundle, yet they both are the 
same thing (from content subsystem point of view). This then makes for very 
confusing situations (at least in the UI), where you can see bundles as 
repositories in the Repository view and you can even add/remove packages from 
it. Is it the right thing to do? Am I supposed to use this repo? Is this the 
right way to use it? All these questions come to mind of the user that we 
don't answer well, IMO (removing a package won't probably work because of FK 
constraints on the bundle side, but the UI will happily offer that 
possibility).

So while the design is very solid from bundle subsystem point of view and has 
proven itself very usable, the content subsystem suffered greatly from it. If 
we weren't using the content subsystem for anything else, then I wouldn't 
consider this a deficiency but we are - CLI alert scripts are stored in repos 
for one and we also get requests for more granular authz on bundles, which the 
repositories actually provide. Therefore I think it would be (almost) equally 
bad to get rid of the concept of a repository in favor of unstructured list of 
bundles.

I am sorry if what I said offended you, I hope I explained my reasons for 
calling bundle storage a "hack" above. It is too strong a word which I used 
trying to point out the obvious mismatch between how bundles and content use 
and understand a repository. A mismatch which I think we don't do a good job 
explaining or hiding to/from the users.

> >   content system storage and that's why I chose content storage
> >   nomenclature over the bundle one (and I'd repeat - nomenclature, not
> >   the semantics). But that does NOT mean I want to deprecate bundle
> >   functionality. I'd say I'm doing quite a reverse. If you look at the
> >   new classes like PackageDestination, they closely mimick what bundle
> >   subsystem does and that is on purpose - I want to maintain the
> >   workflows of the bundle subsystem (even if I use different names for
> >   things) while also clearing up the domain model of the whole thing. So
> >   while some core concepts of the content subsystem stay - like
> >   PackageType and Package - they stay there because they are a) used by
> >   the bundle subsystem today, too, and b) because they fit well into the
> >   overall scheme.> 
> > I think one more aspect was important to me when I created this - the
> > bundle subsystem is using the content subsystem for storage so ripping
> > the content domain classes from under the bundles would, IMHO, be a more
> > complex refactoring than doing the way I did. The content classes stay
> > (even if only by name) and are enhanced and the bundle classes still can
> > use these guys without us having to do semantic somersaults in our heads
> > whenever we need to talk about the "old and new" at the same time.
> > 
> > But overall I am not too fussed about the naming. If you think we should
> > stick with the bundle naming but you like the overall idea of the unified
> > model then I am the happiest guy in the world - it would be the first
> > time my design would stand your scrutiny :)
> > 
> > Lukas
> > 
> > ----- Original Message -----
> > 
> >> From: "John Mazzitelli" <mazz at redhat.com>
> >> To: "rhq-devel" <rhq-devel at lists.fedorahosted.org>
> >> Sent: Monday, February 4, 2013 9:42:20 PM
> >> Subject: bundle / content api redesign
> >> 
> >> (This is more for Lukas, but it seems appropriate to discuss over the
> >> rhq-devel ML)
> >> 
> >> Lukas,
> >> 
> >> Jay and I went through the Bundles vs. Content design page,
> >> 
> >> https://docs.jboss.org/author/display/RHQ/Bundles+vs.+Content+-+On+Its+He
> >> ad
> >> 
> >> In general the ideas sound good.
> >> 
> >> However, there are two things I'm questioning:
> >> 
> >> 1) this is a major re-design/re-implementation - I'm not sure if we
> >> need to be concerned with backward compatibility with the older
> >> content API (i.e. I think we should release this in RHQ 5 timeframe,
> >> the new major release should indicate it contains some backward
> >> incompatible changes with RHQ 4).
> >> 
> >> 2) (this is the bigger concern), it seems like you deferred to
> >> maintaining the Content/Package API and deprecated the Bundle API.
> >> In my opinion, we should do this in reverse. We should maintain the
> >> Bundle API (merging in the Content/Package API where applicable) and
> >> deprecate the Content/Package API.
> >> 
> >> Bundles has been a successful feature - more people are using it and
> >> like it (and they are using it successfully for things we didn't
> >> anticipate) compared to the Content/Package API (few people use it,
> >> and fewer like it :-)
> >> 
> >> The Content/Package classes are what needs to be deprecated, not the
> >> 
> >> Bundle classes. I would recommend that where you say things like:
> >>     Bundle
> >>     
> >>        @Deprecated NON_ENTITY computed from Package
> >>     
> >>     ...
> >>     BundleVersion
> >>     
> >>        @Deprecated NON_ENTITY computed from PackageVersion
> >> 
> >> should instead be flipped like:
> >>     Package
> >>     
> >>        @Deprecated NON_ENTITY computed from Bundle
> >>     
> >>     ...
> >>     PackageVersion
> >>     
> >>        @Deprecated NON_ENTITY computed from BundleVersion
> >> 
> >> and things like:
> >>     PackageVersionDeployment NEW CLASS
> >>     
> >>         exact copy of BundleDeployment, which become @Deprecated
> >>         NON_ENTITY
> >>     
> >>     ...
> >>     PackageDestination NEW CLASS
> >>     
> >>        copy of BundleDestination, which becomes @Deprecated NON_ENTITY
> >> 
> >> should instead just use the Bundle classes (BundleDeployment,
> >> BundleDestination) and just add data fields to the entities as
> >> necessary.
> >> 
> >> We can discuss further as to why Content/Package API is being
> >> retained and Bundle API is being deprecated, but those are my
> >> immediately thoughts.
> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list