Lukas,
(note: I wrote most of this before the presentation last Friday, so
some of it is answered or dated. Just posting it to get the thread
moving... -Jay)
Looking at the latest revision of the wiki. The design is
progressing well. I'm definitely liking the emphasis on migrating
to a Bundle-centric approach and the drive for simplifying the
deployment and storage models while also making things more robust.
A couple of questions/comments:
* The move to Repo-based content authz seems like a good idea that
will map well to the current Group-based resource authz. And
therefore should be easily adapted/understood by users (and us).
* I'm a little confused by the unique constraint on
(Package.name,Repo) where Package-Repo is ManyToMany. That would
mean I could have different distinct Packages with the same name, in
different repos. But I could also have the same Package in
different Repos. How will I be able to identify a test.war in
different repos as being the same app, or different apps with the
same name? This does prevent two different test.war apps in the
same repo, which may make sense, but actually maybe it's too
restrictive.
Keeping this ManyToMany is probably a good idea as it is analogous
to the Resource-Group relationship wrt Repo-based authz. But then
you may need to keep and re-purpose Package.classification as
something that can further identify a Package. Name may not be
enough. The same is true of resources, to identify a resource you
can't go by name, the "classifier" is ancestry.
* +1 to removal of ContentSource, we'll need to work out the details
of the CSP feature
* +1 to removal of PackageCategory
* +1 to deprecation/removal of PackageType
* With respect to the PackageVersion changes:
** +1 to removing architecture. Does this mean we can also kill
off the rhq_architecture table?
** I get why you don't want displayName. But you may want to make
this a redundant, immutable field, set to the package name. Not
sure, but it may be helpful to not have to join with Package to get
the name.
** +1 to removing displayVersion, not sure I see a reason for this,
either.
** +1 to removing MD5 if we can. Maybe it was the only digest we
could get for certain remote content? I don't know.
** license_name, license_version? These aren't mentioned, can we
get rid of them?
* Mime types:
** +1 to the approach, I think this will be very good as the
underlying mechanism for moving the model forward.
** I'm not sure the mime-type determination approach can work like
it does for bundle types. It can only work if only one server plugin
can determine a mime-type, right? Is this going to be true? Maybe
it is , I'm just asking.
* With respect to Content discovery, you say: "...The latter
point is useful for content discovered in the plugins using the
Content API (that don't end up in any repo), because it will allow
for two "mywebapp.war:1.0" to coexist in the database, each coming
from different resource". This content
without a Repo, what is it "attached" to? How is it
tracked/removed/accessed?
* Bundle Consequences:
* We need better terminology for "normal bundle" and "content
bundle". I don't know what it should be but it should likely
reflect that some bundles are
file-system/generic/bundle-distribution-file-zip/bundle-plugin-deployed
and others are [mime-]typed/resource-type-plugin-deployed.
** I think I prefer just adding to the Configuration wrapped by the
existing ResourceTypeBundleConfiguration to absorb the
<content> stuff. As opposed to introducing
BundleDestinationDefinition. It already exists and Configuration is
super-flexible for making additions. Or, perhaps introduce a
BundleDestinationDefinition pojo that can be retrieved via
ResourceTypeBundleConfiguration (like getDestinationDefinitions()).
** The diagram indicated that the Bundle name is derived from
package, is that right?
** Overall I'm still absorbing the proposed changes here. The loss
of BundleType for a Bundle is something that makes sense given that
the Bundle will already have a mime-type.
* Can we
simplify Repo stuff? Do we really need a Repo-Resource
relationship?
* Can we also eliminate all of the Advisory stuff?