My 2 cents on this:

I can confirm that the bundle feature is quite appreciated in JON, and I therefore feel a bit queasy reading things such as "I'm not sure we need to be concerned with backward compatibility". Yes, we need, we need to ensure that bundles designed with previous version of RHQ can be deployed safely after the redesign. 

Adapting the any CLI scripts, if needed, using should also not be a daunting task, and fully documented (ie if a method signatures changes, we should document stating how to replace it).

This is quite important, because otherwise, it would prevent people from migrating, or worse push people to move away from RHQ. 

On Wednesday, 6 February 2013, Lukas Krejci wrote:
On Tuesday, February 05, 2013 10:57:51 Jay Shaughnessy wrote:
> 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.
>

We discussed this at length in a private conversation and I think we came to a
mutual agreement on the matter :) It made sense at the time but was left in a
non-ideal state with regards to interactions with the content subsystem.

> 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.
>

This makes a lot of sense. Maybe we should concentrate on having a clean
representation of the storage without any attached or assumed deployment
requirements (both in the model and in the UI). This then would enable us to
extend this with more, even wilder, deployment mechanisms in the future or on
the other hand use this storage for data without any deployment requirements.

> 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.
>

My concern was that the repo/package storage model is not strictly used for
deployable content. It for example also houses CLI alert scripts. In the light
of this, though, your remark about separating storage and deployment models
makes even more sense.

> 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.
>

If a BundleVersion was a single PackageVersion, we'd probably not need a
hierarchy. This needs more investigation wrt backwards compatiblity of the
APIs, but if it was a viable option, it would simplify the model greatly.

> 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.
>

+1000

> - 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.

I can see some use for content discovery on the content-backed resources. I.e.
I think it is a good feature to be able to discover and offer download of the
WAR file of a webapp.

Other types of content discovery, like the list of jars in lib of AS4, are
less useful, I agree. I wouldn't mind if they went away.

>
> > Lukas
> >
> > ----- Original Message -----
> >
> >> From: "John Mazzitelli" <mazz@redhat.com>
> >> To: "rhq-devel" <rhq-devel@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@lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >
> > _______________________________________________
> > rhq-devel mailing list
> >


--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
Belaran ins Prussia (blog)     (... finally up and running !)