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?