S-RAMP: Remove the ability to update artifact content?

[brmeyer]

In [SRAMP-541] Consider removing artifact/content updates - JBoss Issue Tracker, we're discussing possibly removing the ability to update an artifact's content (not its metadata) entirely.  It's currently problematic and partially implemented.  Some of the main concerns involve what to do with derived artifacts and their user-added metadata, as well as relationships.  If the primary artifact content is updated, the derived artifacts/relationships would also need updated/replaced.

http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/cs01/part2-atom-binding/s-ramp-v1.0-cs01-part2-atom-binding.html#_Toc377548234

That part of the S-RAMP spec states that PUTs are the only way to update artifacts (POST can be for creation only).  But, PUTs are restricted: "only used to update an existing Atom entry document." When it says "Atom entry", to me that signifies metadata-only, not the actual artifact content.  So, at best, the spec is vague and updating artifact content is optional.  At worst, allowing it actually violates the spec entirely.

So, I'm advocating we remove it.  But, I'm definitely interested in hearing any points I might be overlooking!

[sbunciak]

Hi, I have couple of additional questions:

1. How is S-RAMP going to handle maven uploads of artifacts with the same GAV ? It will fail? I would assume that they should be overridden.

2. Is there going to be some versioning support, once the artifact content update is removed?

3. Since this is a minor release, wouldn't this break backwards compatibility (in FSW)?

[jorgemoralespou_2]

Hi,

I agree with Stefan. Are all the artifacts that are meant to be uploaded to DTGov already Final. If there is a bug in an artifact, is there a need to deploy a new version, so in that case:

• S-Ramp should avoid or have different way of managing Final releases versus Snapshots. Policies can be enforced on type of artifacts (like nexus does) so a final artifact can never be redeployed and a snapshot version can be.
• DTGov should have the ability to manage this (with different workflows to pre-release (snapshosts) vs released (Final) artifacts)
• If backward compatibility is broken, provide a migration path to upgrade from version to version, but don't stop implementing required features with this argument, as current adoption is low, and the sooner the better.

Cheers,

[brmeyer]

Hey guys, thanks for the questions!

S-RAMP was not intended to be a tool for use during artifact development -- ie, SNAPSHOT support.  Support for SNAPSHOT versions is something that, as of 0.5.0.Final, is disabled by default and must be explicitly enabled in the config.

In 0.5.0.Final, if SNAPSHOT support is enabled, we are considering the timestamp (included on the jar filename) as a part of the GAV.  So, if, for example, your CI is deploying SNAPSHOTS to S-RAMP, each new version of the artifact technically creates a completely new artifact (the timestamp gives it uniqueness), rather than updating.  However, note that we don't currently automatically create the timestamp if it's not on the jar filename, but we'll add that soon.

> If there is a bug in an artifact, is there a need to deploy a new version

I'd view it like Nexus.  Once an artifact is in the repo, it's final.  If a bug is found, it should be taken care of by a new minor/micro release.  Thoughts?

> Is there going to be some versioning support, once the artifact content update is removed?

Auditing support is still necessary for artifact metadata updates.

> Since this is a minor release, wouldn't this break backwards compatibility (in FSW)?

Upstream, this targets 0.6 (not the current 0.5), but I get the point.  I've typically viewed < 1.0.0 releases as a bit different than normal minor releases, but that's a good question.  I tend to agree with Jorge's point.  But, I suppose deprecating w/ warning logs is an option until 1.0.

[jorgemoralespou_2]

Hi Brett,

I suppose that we should be flexible to let organizations decide when the artifact is final. Some prefer to go through some development while others prefer to mark them final after all the testing. Of course this is not nexus, but will store artifacts in a similar way, but as nexus, snapshots represent a view of the artifact in a early stage but it is treated as the same artifact.

While if you think the Jenkins way, every build should be trackable for every version of any artifact.

I see dtgov should be a mix of both and allow to define workflows flexible to fit every organization, and not limiting them, otherwise it will be not easily adopted.

My opinion.

[eric.wittmann]

In 0.5.0.Final, if SNAPSHOT support is enabled, we are considering the timestamp (included on the jar filename) as a part of the GAV.  So, if, for example, your CI is deploying SNAPSHOTS to S-RAMP, each new version of the artifact technically creates a completely new artifact (the timestamp gives it uniqueness), rather than updating.  However, note that we don't currently automatically create the timestamp if it's not on the jar filename, but we'll add that soon.

I think this is the most important part and should be repeated, which I will do.    When snapshots are enabled in s-ramp, each snapshot is an entirely new artifact.  So the change to no longer allow updating of content doesn't impact this functionality.

[sbunciak]

I'm perfectly ok with the fact that each snapshot deployment is a new artifact. My point is that users won't be able to update e.g. pure Text Document (*.txt, *.doc). Afaik, S-RAMP is supposed to be a general repository for all enterprise artifacts (not just a maven repo). I suppose this includes storing planning/design documents, as well. So, once a PM/BA deploys a shared document to S-RAMP no one will be able to modify it? Please correct me in my point of view if it is incorrect.

[brmeyer]

Found this buried somewhat in the S-RAMP foundation spec:

"Documents which have a Derived Model associated with them cannot be updated in the repository.  They must be removed and republished."

So, we have to at least remove the capability if the document has any derived content.

Stefan raises an interesting point.  If a document has no derived content (and no extended artifacts), updating it is technically easier.  However, you could still delete it, then re-upload using the original UUID (entirely possible and required by the spec).

One pain point for delete/re-upload path is that the spec also states that any document that's the target of a relationship cannot be deleted.  So, if a user defines relationships targeting the document to be "updated", the user would also have to delete/re-create the relationships.

[brmeyer]

Stefan's last point is definitely a good one.  Eric and I discussed more today I think we're in agreement that updateContent needs to be kept.  However, the restrictions within it need to be tightened, as the spec states.  I'll take a look at creating a ruleset.  Thanks very much for the discussion -- very helpful.