bundle / content api redesign

Jay Shaughnessy jshaughn at redhat.com
Tue Feb 5 15:57:51 UTC 2013



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 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.
It's true that the Bundle data-model utilizes the content storage 
model.  But what it provides is a clear separation between the 
deployment model (bundles) and the storage model (content).  Given that 
we needed to support both the Content subsystem and the new Bundle 
provisioning system it made sense to use the storage model that already 
existed.

Now that we want to merge these subsystems I agree that we could merge 
the entities as well, although to be honest, I'm not 100% sure that it 
won't end up being a little more brittle that way.  We'll have to see 
how it evolves.

I think it's probably a mistake to deprecate the Bundle nomenclature and 
entities.   This is a popular subsystem with a lot of existing scripting 
already in place at customer sites.  I think what Mazz and I were 
questioning was why you need to make these deprecations in order to 
introduce similar workflow and entities.  By maintaining the Bundle 
terminology and API there would be less upheaval in the overall 
mechanism.  Keeping the API and the GUI, and enhancing them, would be 
preferable, I think.

The feedback was to put some time into figuring out whether it's 
possible to enhance the bundle/provisioning system to encompass the 
needed features of the content system/AS7 patching.  It seems doable and 
not far from what you're already proposing.  Deprecating all things 
content would be the preferable way to go, I think.  The domain model 
could be changed in one fell swoop or even incrementally, first 
continuing to utilize the content storage model, and later performing a 
merge that allowed the bundle model to encompass

As for the data model, one thing in your proposal is key, and I totally 
agree with it.  The BundleFile concept was a part of the model that 
should not have made it to the final revision.  It was originally put 
there because of an original requirement that individual files in a 
bundle could have semantics that would allow it to be updated 
individually.  Today, in the simpler and more useful model, the files in 
a BundleVersion are fixed.  As such a BundleVersion absolutely can be a 
single file, basically a zip, or basically equivalent to what we call a 
Bundle Distribution File today.

This means a BundleVersion would only have a single PackageVersion 
associated with it.  Keeping the storage model and deployment model 
separate, these two entities could remain (maybe not a bad thing). Or, 
combining the models migrating the PackageVersion into the BundleVersion 
is likely doable, and maintains the BundleVersion entity, which is a 
goal I think we should be going after.

Once a BundleVersion has only one PackageVersion, then it needs only one 
PackageType, and your proposals around PackageType make perfect sense.  
And BundleType can go away.  Again simplifying the model.

I don't think we need any sort of PackageVersion Hierarchy although I 
may be missing the point in your proposal.  Without that things are more 
simple.

Lastly, and unrelated to the above, the BundleVersionRepo entity was 
never implemented and was a holdover from the earlier feature set. It 
can go away completely no matter what else we do.

>
> 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 :)
A unified model is the goal.  But the main goal, imo, is to maintain the 
Remote Bundle API as much as possible, if not completely.  I think both 
goals are achievable.  My suggestion is to get the design in place as to 
how Bundle provisioning will encompass content, unify the data model 
only as much as needed in the first pass, and merge storage entities 
into the deployment (bundle) entities only after everything is totally 
clear (perhaps not even in the first release, unless it makes life easier).

Also Wants:
- Remove Content Sources.
This is really a mechanism that complicates RHQ and, it seems to me, is 
much better handled externally with scripting as desired by the 
customer.  If we need some sort of hook into the CSP  let's build that 
in another way, something simple.

- Remove Content Discovery
This would simplify the path forward, and let's face it.  This is not a 
very useful feature as is.  Unless it's going to improve we should get 
rid of it.

>
> 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+Head
>>
>> 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



More information about the rhq-devel mailing list