[JIRA] (JENKINS-58970) Backwards compatibility broken with version 2.3.0 for KV1

0 views
Skip to first unread message

bksaville@gmail.com (JIRA)

unread,
Aug 16, 2019, 3:39:03 PM8/16/19
to jenkinsc...@googlegroups.com
Brian Saville created an issue
 
Jenkins / Bug JENKINS-58970
Backwards compatibility broken with version 2.3.0 for KV1
Issue Type: Bug Bug
Assignee: Peter Tierno
Components: hashicorp-vault-plugin
Created: 2019-08-16 19:38
Priority: Critical Critical
Reporter: Brian Saville

The latest release is great that it adds support for KV2 secret storage, but it also breaks backwards compatibility. We have many users of Jenkins with their own Jenkinsfiles in various repositories (~300 different references in different places). Instead of requiring the engineVersion: 1 parameter, I would like this to be treated as the default value to preserve the previous behavior.

I'm happy to put together a patch for this, and likely will soon here.
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

bksaville@gmail.com (JIRA)

unread,
Aug 16, 2019, 3:44:02 PM8/16/19
to jenkinsc...@googlegroups.com
Brian Saville updated an issue
Change By: Brian Saville
The latest release is great that it adds support for KV2 secret storage, but it also breaks backwards compatibility. We have many users of Jenkins with their own Jenkinsfiles in various repositories (~300 different references in different places). Instead of requiring the {{engineVersion: 1}} parameter, I would like this to be treated as the default value to preserve the previous behavior.
- I'm happy to put together a patch for this, and likely will soon here. -
Here is a patch to change this: https://github.com/jenkinsci/hashicorp-vault-plugin/pull/40

I realize that the newer vault library uses 2 as the default, but I still think preserving the previous behavior is the easiest path forward.  If you do not like this solution, I could probably also code something up that allows an admin to set the default version globally in Jenkins so we can do it just on our instance and it doesn't affect anyone else.

josephp90@gmail.com (JIRA)

unread,
Aug 19, 2019, 6:00:02 PM8/19/19
to jenkinsc...@googlegroups.com
Joseph Petersen commented on Bug JENKINS-58970
 
Re: Backwards compatibility broken with version 2.3.0 for KV1

You can already specify the engine version.

jacob.truman@gmail.com (JIRA)

unread,
Aug 19, 2019, 6:05:02 PM8/19/19
to jenkinsc...@googlegroups.com

Joseph Petersen I think Brian Saville is suggesting that you should not have to specify the engine version to maintain existing functionality.

josephp90@gmail.com (JIRA)

unread,
Aug 19, 2019, 6:09:03 PM8/19/19
to jenkinsc...@googlegroups.com

I'd disagree with changing the default, let me come up with a different solution

bksaville@gmail.com (JIRA)

unread,
Aug 19, 2019, 11:08:02 PM8/19/19
to jenkinsc...@googlegroups.com

Joseph Petersen, Jacob Truman is absolutely right, I would like to not have to change any existing workflow scripts since many of them are outside of our control. I would argue that the default has already been changed with 2.3.0 and should be set to 1 to match the previous behavior, but I can understand completely if you don't want to do it that way. I would quite happy with a solution that let me set the default version system wide (perhaps in the global configuration options?) so that individual teams/users don't have to update their scripts to have it continue working with v1 engine versions.

Thanks!

bksaville@gmail.com (JIRA)

unread,
Aug 19, 2019, 11:14:01 PM8/19/19
to jenkinsc...@googlegroups.com

You work fast Joseph Petersen, this is exactly what I was looking for, thanks! Any idea on timeline for the next release?

josephp90@gmail.com (JIRA)

unread,
Aug 20, 2019, 12:21:02 AM8/20/19
to jenkinsc...@googlegroups.com
Joseph Petersen started work on Bug JENKINS-58970
 
Change By: Joseph Petersen
Status: Open In Progress

josephp90@gmail.com (JIRA)

unread,
Aug 20, 2019, 12:39:01 AM8/20/19
to jenkinsc...@googlegroups.com

v2.3.1 should be in the update center shortly

josephp90@gmail.com (JIRA)

unread,
Aug 20, 2019, 12:40:02 AM8/20/19
to jenkinsc...@googlegroups.com
Joseph Petersen resolved as Fixed
 
Change By: Joseph Petersen
Status: In Progress Resolved
Assignee: Peter Tierno Joseph Petersen
Resolution: Fixed
Released As: https://github.com/jenkinsci/hashicorp-vault-plugin/releases/tag/hashicorp-vault-plugin-2.3.1

bksaville@gmail.com (JIRA)

unread,
Aug 20, 2019, 10:49:02 AM8/20/19
to jenkinsc...@googlegroups.com
Brian Saville commented on Bug JENKINS-58970
 
Re: Backwards compatibility broken with version 2.3.0 for KV1

Tried it out this morning, and works great. Thanks for the quick turnaround on this!

davdumas@gmail.com (JIRA)

unread,
Aug 20, 2019, 2:20:02 PM8/20/19
to jenkinsc...@googlegroups.com

I am quite concerned that when enabling v2 in configuration (at any level), if K/V engine v2 is not enabled in Vault after upgrading from v1, not a single explicit error shows up in both Jenkins & Vault logs, secret is retrieved with no data and envVars are not set:

```No such property: testing for class: groovy.lang.Binding```

davdumas@gmail.com (JIRA)

unread,
Aug 20, 2019, 2:21:02 PM8/20/19
to jenkinsc...@googlegroups.com
David Dumas edited a comment on Bug JENKINS-58970

josephp90@gmail.com (JIRA)

unread,
Aug 20, 2019, 2:29:02 PM8/20/19
to jenkinsc...@googlegroups.com

David Dumas I know for a fact it will throw an error.

Could you share more information on what you're trying to attempt? Since without further details I have no chance of helping you.

davdumas@gmail.com (JIRA)

unread,
Aug 20, 2019, 2:44:03 PM8/20/19
to jenkinsc...@googlegroups.com

1) Updated Hashicorp Vault from 0.9.6 to 1.0+

2) Updated plugin from 2.1.1 to 2.3.1 (bumps Java vault driver 2.0.0 to 4.0.0)

Result: nothing was working anymore without an explicit error message and engine v2 was set by default globally (Jenkins configured with CasC 1.27)

Possible fixes I used:

  • explicitly set engine v1 usage in CasC
  • upgrade existing version 1 kv store to version 2 kv store with CLI command
     vault kv enable-versioning secret/
    I don't know if there is a way to have an explicit error when trying to use API v2 on a K/V engine v1, but it might save users from troubles

davdumas@gmail.com (JIRA)

unread,
Aug 20, 2019, 2:46:03 PM8/20/19
to jenkinsc...@googlegroups.com
David Dumas edited a comment on Bug JENKINS-58970
1) Updated Hashicorp Vault from 0.9.6 to 1.0+

2) Updated plugin from 2.1.1 to 2.3.1 (bumps Java vault driver 2.0.0 to 4.0.0)

Result: nothing was working anymore without an explicit error message and engine v2 was set by default globally (Jenkins configured with CasC 1.27)

Possible fixes I used:
* explicitly set engine v1 usage in CasC

* upgrade existing version 1 kv store to version 2 kv store with CLI command
 vault kv enable-versioning secret/

 I don't know if there is a way to have an explicit error when trying to use API v2 on a K/V engine v1, but it might save users from troubles

bksaville@gmail.com (JIRA)

unread,
Aug 20, 2019, 3:03:03 PM8/20/19
to jenkinsc...@googlegroups.com

David Dumas, this sounds like a new problem unrelated to the actual problem fixed in this one, does that sound right? I could see how the summary might lead you to think it's the same issue, but the real problem for us is that the default engine version was 2 for everything instead of 1.

davdumas@gmail.com (JIRA)

unread,
Aug 20, 2019, 3:11:01 PM8/20/19
to jenkinsc...@googlegroups.com

Yes, maybe I should create a new issue, my intent was to discuss that setting a default engine version does not prevent issues or show explicit errors when trying to use engine v2 on v1 (or v1 on v2)

josephp90@gmail.com (JIRA)

unread,
Mar 7, 2020, 1:08:26 AM3/7/20
to jenkinsc...@googlegroups.com
Joseph Petersen assigned an issue to Joseph Petersen
 
Change By: Joseph Petersen
Assignee: Joseph Petersen (old)
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages