My 2 cents on this:<div><br></div><div>I can confirm that the bundle feature is quite appreciated in JON, and I therefore feel a bit queasy reading things such as &quot;I&#39;m not sure we need to be concerned with backward compatibility&quot;. Yes, we need, we need to ensure that bundles designed with previous version of RHQ can be deployed safely after the redesign. </div>
<div><br></div><div>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).</div><div><br>
</div><div>This is quite important, because otherwise, it would prevent people from migrating, or worse push people to move away from RHQ. <br><br>On Wednesday, 6 February 2013, Lukas Krejci  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tuesday, February 05, 2013 10:57:51 Jay Shaughnessy wrote:<br>
&gt; On 2/5/2013 7:02 AM, Lukas Krejci wrote:<br>
&gt; &gt; Yes, this needs to be well discussed and I appreciate your comments and<br>
&gt; &gt; the time you&#39;re putting into deciphering my tangled thoughts ;)<br>
&gt; &gt;<br>
&gt; &gt; Before we go into the details on a call, I&#39;d like to clear up the feeling<br>
&gt; &gt; you both seem to have gotten from the wiki page.<br>
&gt; &gt;<br>
&gt; &gt; So far I&#39;ve been dealing with the storage of the new system. To be frank,<br>
&gt; &gt; the storage of bundles is a hack and is duck-taped on to the the content<br>
&gt; &gt; system storage and that&#39;s why I chose content storage nomenclature over<br>
&gt; &gt; the bundle one (and I&#39;d repeat - nomenclature, not the semantics). But<br>
&gt; &gt; that does NOT mean I want to deprecate bundle functionality. I&#39;d say I&#39;m<br>
&gt; &gt; doing quite a reverse. If you look at the new classes like<br>
&gt; &gt; PackageDestination, they closely mimick what bundle subsystem does and<br>
&gt; &gt; that is on purpose - I want to maintain the workflows of the bundle<br>
&gt; &gt; subsystem (even if I use different names for things) while also clearing<br>
&gt; &gt; up the domain model of the whole thing. So while some core concepts of<br>
&gt; &gt; the content subsystem stay - like PackageType and Package - they stay<br>
&gt; &gt; there because they are a) used by the bundle subsystem today, too, and b)<br>
&gt; &gt; because they fit well into the overall scheme.<br>
&gt; It&#39;s true that the Bundle data-model utilizes the content storage<br>
&gt; model.  But what it provides is a clear separation between the<br>
&gt; deployment model (bundles) and the storage model (content).  Given that<br>
&gt; we needed to support both the Content subsystem and the new Bundle<br>
&gt; provisioning system it made sense to use the storage model that already<br>
&gt; existed.<br>
&gt;<br>
<br>
We discussed this at length in a private conversation and I think we came to a<br>
mutual agreement on the matter :) It made sense at the time but was left in a<br>
non-ideal state with regards to interactions with the content subsystem.<br>
<br>
&gt; Now that we want to merge these subsystems I agree that we could merge<br>
&gt; the entities as well, although to be honest, I&#39;m not 100% sure that it<br>
&gt; won&#39;t end up being a little more brittle that way.  We&#39;ll have to see<br>
&gt; how it evolves.<br>
&gt;<br>
<br>
This makes a lot of sense. Maybe we should concentrate on having a clean<br>
representation of the storage without any attached or assumed deployment<br>
requirements (both in the model and in the UI). This then would enable us to<br>
extend this with more, even wilder, deployment mechanisms in the future or on<br>
the other hand use this storage for data without any deployment requirements.<br>
<br>
&gt; I think it&#39;s probably a mistake to deprecate the Bundle nomenclature and<br>
&gt; entities.   This is a popular subsystem with a lot of existing scripting<br>
&gt; already in place at customer sites.  I think what Mazz and I were<br>
&gt; questioning was why you need to make these deprecations in order to<br>
&gt; introduce similar workflow and entities.  By maintaining the Bundle<br>
&gt; terminology and API there would be less upheaval in the overall<br>
&gt; mechanism.  Keeping the API and the GUI, and enhancing them, would be<br>
&gt; preferable, I think.<br>
&gt;<br>
<br>
My concern was that the repo/package storage model is not strictly used for<br>
deployable content. It for example also houses CLI alert scripts. In the light<br>
of this, though, your remark about separating storage and deployment models<br>
makes even more sense.<br>
<br>
&gt; The feedback was to put some time into figuring out whether it&#39;s<br>
&gt; possible to enhance the bundle/provisioning system to encompass the<br>
&gt; needed features of the content system/AS7 patching.  It seems doable and<br>
&gt; not far from what you&#39;re already proposing.  Deprecating all things<br>
&gt; content would be the preferable way to go, I think.  The domain model<br>
&gt; could be changed in one fell swoop or even incrementally, first<br>
&gt; continuing to utilize the content storage model, and later performing a<br>
&gt; merge that allowed the bundle model to encompass<br>
&gt;<br>
&gt; As for the data model, one thing in your proposal is key, and I totally<br>
&gt; agree with it.  The BundleFile concept was a part of the model that<br>
&gt; should not have made it to the final revision.  It was originally put<br>
&gt; there because of an original requirement that individual files in a<br>
&gt; bundle could have semantics that would allow it to be updated<br>
&gt; individually.  Today, in the simpler and more useful model, the files in<br>
&gt; a BundleVersion are fixed.  As such a BundleVersion absolutely can be a<br>
&gt; single file, basically a zip, or basically equivalent to what we call a<br>
&gt; Bundle Distribution File today.<br>
&gt;<br>
&gt; This means a BundleVersion would only have a single PackageVersion<br>
&gt; associated with it.  Keeping the storage model and deployment model<br>
&gt; separate, these two entities could remain (maybe not a bad thing). Or,<br>
&gt; combining the models migrating the PackageVersion into the BundleVersion<br>
&gt; is likely doable, and maintains the BundleVersion entity, which is a<br>
&gt; goal I think we should be going after.<br>
&gt;<br>
&gt; Once a BundleVersion has only one PackageVersion, then it needs only one<br>
&gt; PackageType, and your proposals around PackageType make perfect sense.<br>
&gt; And BundleType can go away.  Again simplifying the model.<br>
&gt;<br>
&gt; I don&#39;t think we need any sort of PackageVersion Hierarchy although I<br>
&gt; may be missing the point in your proposal.  Without that things are more<br>
&gt; simple.<br>
&gt;<br>
<br>
If a BundleVersion was a single PackageVersion, we&#39;d probably not need a<br>
hierarchy. This needs more investigation wrt backwards compatiblity of the<br>
APIs, but if it was a viable option, it would simplify the model greatly.<br>
<br>
&gt; Lastly, and unrelated to the above, the BundleVersionRepo entity was<br>
&gt; never implemented and was a holdover from the earlier feature set. It<br>
&gt; can go away completely no matter what else we do.<br>
&gt;<br>
&gt; &gt; I think one more aspect was important to me when I created this - the<br>
&gt; &gt; bundle subsystem is using the content subsystem for storage so ripping<br>
&gt; &gt; the content domain classes from under the bundles would, IMHO, be a more<br>
&gt; &gt; complex refactoring than doing the way I did. The content classes stay<br>
&gt; &gt; (even if only by name) and are enhanced and the bundle classes still can<br>
&gt; &gt; use these guys without us having to do semantic somersaults in our heads<br>
&gt; &gt; whenever we need to talk about the &quot;old and new&quot; at the same time.<br>
&gt; &gt;<br>
&gt; &gt; But overall I am not too fussed about the naming. If you think we should<br>
&gt; &gt; stick with the bundle naming but you like the overall idea of the unified<br>
&gt; &gt; model then I am the happiest guy in the world - it would be the first<br>
&gt; &gt; time my design would stand your scrutiny :)<br>
&gt; A unified model is the goal.  But the main goal, imo, is to maintain the<br>
&gt; Remote Bundle API as much as possible, if not completely.  I think both<br>
&gt; goals are achievable.  My suggestion is to get the design in place as to<br>
&gt; how Bundle provisioning will encompass content, unify the data model<br>
&gt; only as much as needed in the first pass, and merge storage entities<br>
&gt; into the deployment (bundle) entities only after everything is totally<br>
&gt; clear (perhaps not even in the first release, unless it makes life easier).<br>
&gt;<br>
&gt; Also Wants:<br>
&gt; - Remove Content Sources.<br>
&gt; This is really a mechanism that complicates RHQ and, it seems to me, is<br>
&gt; much better handled externally with scripting as desired by the<br>
&gt; customer.  If we need some sort of hook into the CSP  let&#39;s build that<br>
&gt; in another way, something simple.<br>
&gt;<br>
<br>
+1000<br>
<br>
&gt; - Remove Content Discovery<br>
&gt; This would simplify the path forward, and let&#39;s face it.  This is not a<br>
&gt; very useful feature as is.  Unless it&#39;s going to improve we should get<br>
&gt; rid of it.<br>
<br>
I can see some use for content discovery on the content-backed resources. I.e.<br>
I think it is a good feature to be able to discover and offer download of the<br>
WAR file of a webapp.<br>
<br>
Other types of content discovery, like the list of jars in lib of AS4, are<br>
less useful, I agree. I wouldn&#39;t mind if they went away.<br>
<br>
&gt;<br>
&gt; &gt; Lukas<br>
&gt; &gt;<br>
&gt; &gt; ----- Original Message -----<br>
&gt; &gt;<br>
&gt; &gt;&gt; From: &quot;John Mazzitelli&quot; &lt;<a>mazz@redhat.com</a>&gt;<br>
&gt; &gt;&gt; To: &quot;rhq-devel&quot; &lt;<a>rhq-devel@lists.fedorahosted.org</a>&gt;<br>
&gt; &gt;&gt; Sent: Monday, February 4, 2013 9:42:20 PM<br>
&gt; &gt;&gt; Subject: bundle / content api redesign<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; (This is more for Lukas, but it seems appropriate to discuss over the<br>
&gt; &gt;&gt; rhq-devel ML)<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Lukas,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Jay and I went through the Bundles vs. Content design page,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; <a href="https://docs.jboss.org/author/display/RHQ/Bundles+vs.+Content+-+On+Its+He" target="_blank">https://docs.jboss.org/author/display/RHQ/Bundles+vs.+Content+-+On+Its+He</a><br>
&gt; &gt;&gt; ad<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; In general the ideas sound good.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; However, there are two things I&#39;m questioning:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 1) this is a major re-design/re-implementation - I&#39;m not sure if we<br>
&gt; &gt;&gt; need to be concerned with backward compatibility with the older<br>
&gt; &gt;&gt; content API (i.e. I think we should release this in RHQ 5 timeframe,<br>
&gt; &gt;&gt; the new major release should indicate it contains some backward<br>
&gt; &gt;&gt; incompatible changes with RHQ 4).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 2) (this is the bigger concern), it seems like you deferred to<br>
&gt; &gt;&gt; maintaining the Content/Package API and deprecated the Bundle API.<br>
&gt; &gt;&gt; In my opinion, we should do this in reverse. We should maintain the<br>
&gt; &gt;&gt; Bundle API (merging in the Content/Package API where applicable) and<br>
&gt; &gt;&gt; deprecate the Content/Package API.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Bundles has been a successful feature - more people are using it and<br>
&gt; &gt;&gt; like it (and they are using it successfully for things we didn&#39;t<br>
&gt; &gt;&gt; anticipate) compared to the Content/Package API (few people use it,<br>
&gt; &gt;&gt; and fewer like it :-)<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The Content/Package classes are what needs to be deprecated, not the<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Bundle classes. I would recommend that where you say things like:<br>
&gt; &gt;&gt;     Bundle<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;        @Deprecated NON_ENTITY computed from Package<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     ...<br>
&gt; &gt;&gt;     BundleVersion<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;        @Deprecated NON_ENTITY computed from PackageVersion<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; should instead be flipped like:<br>
&gt; &gt;&gt;     Package<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;        @Deprecated NON_ENTITY computed from Bundle<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     ...<br>
&gt; &gt;&gt;     PackageVersion<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;        @Deprecated NON_ENTITY computed from BundleVersion<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; and things like:<br>
&gt; &gt;&gt;     PackageVersionDeployment NEW CLASS<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;         exact copy of BundleDeployment, which become @Deprecated<br>
&gt; &gt;&gt;         NON_ENTITY<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     ...<br>
&gt; &gt;&gt;     PackageDestination NEW CLASS<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;        copy of BundleDestination, which becomes @Deprecated NON_ENTITY<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; should instead just use the Bundle classes (BundleDeployment,<br>
&gt; &gt;&gt; BundleDestination) and just add data fields to the entities as<br>
&gt; &gt;&gt; necessary.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; We can discuss further as to why Content/Package API is being<br>
&gt; &gt;&gt; retained and Bundle API is being deprecated, but those are my<br>
&gt; &gt;&gt; immediately thoughts.<br>
&gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; rhq-devel mailing list<br>
&gt; &gt;&gt; <a>rhq-devel@lists.fedorahosted.org</a><br>
&gt; &gt;&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/rhq-devel" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/rhq-devel</a><br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; rhq-devel mailing list<br>
&gt; &gt; <a></a></blockquote></div><br><br>-- <br>Romain PELISSE,<br><i>&quot;The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it&quot; -- Terry Pratchett</i><br>
<a href="http://blog.wordpress.belaran.eu/" target="_blank">Belaran ins Prussia (blog)</a>     (... finally up and running !)<br>