add more buildv1 features to the roadmap for vetting wrt buildv2

[gabemontero]

/assign @sbose78

Hey @sbose78

Finally got around to submitting updates to the roadmap you started based on some of our initial conversations.

My updates here are based on a feature compare between openshift build v1 and tekton that I did last fall.

As we progress through buildv2 we should look at each of these and decide whether we

• provide some buildv2 analogous flavor of it
• or document why buildv2 is not doing it as part of I'm assuming the inevitable doc openshift build v2 will have as part of helping devs on build v1 migrate

At the time of my evaluation last fall, the conclusion wrt to tekton and each of these was either
a) it was already implemented at the tekton API level
b) could be done via the openness of the tekton API, where pods/containers are exposed along with supporting artifacts like secrets/configmap/volumes/pvcs etc., and "more work" on our end as needed.
c) or at least was on the tekton "roadmap" in as much as upstream features were open

And of course aside from discussion here, we can zero in on this on an upcoming build v2 sync call as you like.

From the openshift devex end, as I've mentioned before, I see us trying to facilitate your consumption of such features via work like obu or similar utilities, repo refactoring, inclusion of the build v2 scenarios in upcoming design work, whatever we come up with that makes sense and is containable.

@pweil- @adambkaplan @siamaksade @bparees ... FYI and of course chime in as needed

[openshift-ci-robot]

Hi @gabemontero. Thanks for your PR.

I'm waiting for a redhat-developer member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign sbose78
You can assign the PR to them by writing /assign @sbose78 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gabemontero]

I would envision this being something buildv2 does solely by leveraging tekton

[gabemontero]

Opened #46

[gabemontero]

I think there are some valuable lessons learned, especially in light of recent build v1 customer activity, as devex has discussed internally along with @bparees, that would should engage with @sbose78 's team on when they are ready to start on this.

Not sure if there is common library logic from buildv1 to share, especially since buildv2 may want to go down a different path than the tar to the build container path buildv1 employs today.

@adambkaplan - initial reaction, this feels like consulting work on our end vs. R&D and/or provided code on our end, but at least warrants discussion on our end

[gabemontero]

I would envision this being something buildv2 does solely by leveraging tekton

[gabemontero]

Opened #48

[gabemontero]

I would envision this being something buildv2 does solely by leveraging tekton

[gabemontero]

See #48 as well

[gabemontero]

I would envision this being something buildv2 does solely by leveraging tekton

[gabemontero]

Opened #49

[gabemontero]

I would envision this being something buildv2 does solely by leveraging tekton

[bparees]

this is setting labels on the output? what's ens? environment variables? if so env variables would be inputs right?

[gabemontero]

yeah this needs to change to Set specified labels on output image ... the ens was a leftover I thought I had deleted prior to branch push / PR creation

[gabemontero]

opened #50

[gabemontero]

https://github.com/tektoncd/triggers already provides this, with more features already IMO, than what we have in buildv1

So I would envision this being something buildv2 does solely by leveraging tekton

[gabemontero]

opened #51

[gabemontero]

I envision devex changes for this @adambkaplan @siamaksade @bparees, updating our existing image change controller and the existing annotation it has for generic k8s object, to include support for both buildv2 and tekton

Certainly we can discuss the pros/cons with @sbose78 of them creating their own controller for buildv2 and this, but IMO the former idea would cost substantially less

[gabemontero]

#52

[gabemontero]

this is suppose to be a tekton feature (though if it has landed I have missed it)

perhaps an opportunity for either DEVEX or APPSVC to contribute upstream @adambkaplan @siamaksade @bparees @sbose78

[gabemontero]

#53

[gabemontero]

believe this is already in tekton .... build v2 would just need to leverage

[gabemontero]

#54

[gabemontero]

doable via tekton today .... just whether buildv2 encapsulates this in the API like buildv1 did

[bparees]

buildv1 didn't really encapsulate it. it just allowed input content to come from an existing image, which you've already covered, and for the push of one image to trigger the build of another, which you've arguably already covered also w/ imagestream triggers

[gabemontero]

ah that's right ... thanks for the clarification. I'll remove this from this table, or a subsequent candidates table if we go down that path, and will refrain from opening an issue for discussion, per that last ask from @siamaksade

[gabemontero]

@adambkaplan as discussed previously IMO DEVEX should either facilitate this with the existing stories or have subsequent ones that make sure our solution is consumable via the buildah binary so buildv2 can leverage

[gabemontero]

I think tekton already has this ... if not, this should driven upstream by devtools or devexp

[gabemontero]

#55

[gabemontero]

again, tekton has ... buildv2 leverages via that

[gabemontero]

#56

[gabemontero]

@adambkaplan another tracking story for devex for consulting and/or provide code libs for this ... perhaps stage this later on after buildv2 matures a little

[gabemontero]

@adambkaplan IMO same story as image cache ... the current CSI plugin choice for mutating annotated pods should work for buildv2 like buildv1 .... then it is a question of any OCM or openshift/builder image changes for buildv1 being pulled into the buildv2 controller

[gabemontero]

@adambkaplan another story for us ... either something like obu grabs the CAs. and injects them as part of the tekton task prior to calling the image builder binary, or we consult buildv2 on updating their controller to create config maps that get auto injected

[gabemontero]

#57

[gabemontero]

same basic notions as with global proxy @adambkaplan

[gabemontero]

#58

[gabemontero]

this is an interesting one (and I still have a question mark here) .... perhaps first a broad discussion with @sbose78 , @adambkaplan, @bparees, @siamaksade, and myself just the assess the current landscape

[gabemontero]

#59

[siamaksade]

While this list of features is valuable for comparison, I'm not sure it is accurate to project this list as the feature set that Build v2 will be addressing.

Could we keep this list separate from the roadmap and as a feature comparison between Build v1 and v2? To serve as a source for cherry-picking and adding features to Build v2 as needed and as we get feedback on it

[bparees]

While this list of features is valuable for comparison, I'm not sure it is accurate to project this list as the feature set that Build v2 will be addressing.

i view this list as the critical features from builds v1 that we would want to see in builds v2 because they have proven valuable to our users and use cases, it is not an exhaustive list of things builds v1 supports.

but by all means if you want to make the case that one or more of them is unnecessary let's have that discussion sooner rather than later.

[siamaksade]

i view this list as the critical features from builds v1 that we would want to see in builds v2 because they have proven valuable to our users and use cases, it is not an exhaustive list of things builds v1 supports.

I understand that they were critical for build v1. However we need to revisit what the use-case was at the time, validate if it is still a relevant use-case now, if users are solving it in other ways, and if they are aligned with the goals of builds v2. Some I can see immediately that are still relevant like global proxy and some have doubts for example chaining builds. So I my suggestions is to discuss them one by one and make a decision on adding to the roadmap .

[bparees]

I understand that they were critical for build v1. However we need to revisit what the use-case was at the time, validate if it is still a relevant use-case now,

as i said, they have proven valuable to our users and use cases,

some have doubts for example chaining builds.

as i noted in the PR, there actually is no explicit support(api) for chained builds in buildsv1, "chained builds" is a capability that is achieved by the combination of other features (image input, image triggering), both of which i think we can agree are features we do need in builds v2.

so yes, we can remove that from the list, but not because it's not important anymore in v2, but because it wasn't a thing in v1 either. (and tekton provides equivalent functionality with its stages)

[siamaksade]

What is the use-case for image input? or for configmap and secrets?

Triggering is also something I'd like to revisit given that pipelines already provide that capability. Same goes for Parallel vs. serial execution.

[bparees]

What is the use-case for image input?

"i have an image with existing dependency binaries, tools, etc that i need to use during my build. I do not want to/can not to layer on top of that existing image"

or for configmap

i need to control build behavior on a per buildconfig basis, i do not want to put this config in my git repo because the repo is used by many buildconfigs.

and secrets?

i have content i don't want to put in my github repo but i need to use it during a build (such as maven credentials)

[bparees]

Triggering is also something I'd like to revisit given that pipelines already provide that capability. Same goes for Parallel vs. serial execution.

yes... tekton provides it. and builds v2 needs to expose it. that doesn't mean buildsv2 has to reimplement it.

[siamaksade]

@bparees I don't think this PR is a good format to discuss these items. Makes is very difficult to follow.

@gabemontero could you add a separate issue for each of those features to discuss separately?

[gabemontero]

@siamaksade - my assumption was that github issues and/or jiras would get opened to discuss these items in detail as @sbose78 team got to the point where they were ready to take them on.

And that his table here was a super concise and easy to consume report of what had been tackled to date and what might get tackled in the future. Or at least considered and then either taken on or dropped.

Creating separate issues is fine, and I will do that momentarily.

But to NOT have some level of correlation with this table would be unfortunate, as one then has to start querying github for open features, perhaps with certain labels, etc. etc. to get "the report". I at least am not a big fan of github's capabilities for this type of querying. But I may be in the minority here.

How about this slight adjustment to your request:

• create separate github issues for each item here, to carry on any "type from your keyboard" discussions
• I keep the entries in this table, but each entry text is also a link to the associated github issue, and that the item is "TBD for official inclusion" in the road map ...
• or a separate table right below with titled something like "candidates for inclusion in the roadmap"

Thoughts ?

[gabemontero]

OK I've opened issues for all the items I added to the current table @siamaksade

Do please let me know about my suggestion to have some form of "candidate" items in a table on this page vs. having to query for issues in github.

[gabemontero]

Opened #48

[gabemontero]

See #48 as well

[gabemontero]

Opened #49

[gabemontero]

opened #50

[gabemontero]

opened #51

[gabemontero]

#55

[gabemontero]

#56

[gabemontero]

#57

[gabemontero]

#58

[gabemontero]

#59

[siamaksade]

Thank you @gabemontero

I suggest we close this PR and work off the GitHub issues. The ones that get determined are relevant in the context of builds v2, should get added back into the features table. Merging this PR implies incorrectly that all these features will be added at some point.

[gabemontero]

As part of closing the PR @siamaksade I'd like a label .... something like roadmap or buildv1compare that we can add to the issues I just opened, to enable a query for tracking.

I don't have auth in this repo to do this.

@sbose78 can you craft a label for us?

thanks everyone