A few Carvel tools are required to use the Cloud Native Runtimes (CNR) CLI (ytt, kapp, and kbld). I got some feedback from someone who was going through the Cloud Native Runtimes install process that they had to go through the Mac process of going to System Preferences, Security and Privacy, and click "allow anyway" to be able to open the tools. I know there is some kind of option to get a developer certification for products so that users won't get the security notification before opening Carvel tools, is this something your team has considered? Since we'll have more users coming to the Carvel tools through CNR installation, this is some feedback I wanted to pass on.

Background

We would like to establish a consistent practice for proposals across Carvel so that people know where to look. Proposals are generally used for larger feature requests or for work that spans multiple Carvel tools. After some discussion in Slack, the consensus decision is to have our proposals in a single, shared location. To move this one step further, I'll propose that we use this repo to store our proposals under a top-level proposals dir. Currently, we have been using https://github.com/k14s/design-docs as the home for proposals but this needs to be updated.

Task List

• merge accepted PRs in k14s/design-docs to preserve history
• move issues from k14s/design-docs to this repo
• create a top-level proposals dir in this repo with a README explaining its usage (submitted PR: carvel-dev/carvel-community#20)
• ensure that our proposals process is documented (submitted PR: carvel-dev/carvel-community#20)
• provide a proposals template (submitted PR: carvel-dev/carvel-community#20)
• add links from k14s/design-docs to vmware-tanzu/carvel (waiting to see if we rename the carvel repo)
• archive k14s/design-docs

On the README, a few projects are listed as experimental. What does this mean?

It would be helpful to set clearer expectations for experimental vs established(?) projects. A couple of things to consider are support responsiveness and release frequency.

Once we settle on a definition of experimental. We should clearly label the experimental projects on their README so that users know what to expect.

Describe the problem/challenge you have
See #182 for the overlying why.

Describe the solution you'd like
We should align on a minimal set of metrics for determining our community engagement success.

Anything else you would like to add:
A couple of notes:

• We could consider thinking about this in the SLI/SLO methology. I would recommend keeping the team of maintainers as the primary audience so I would not consider an SLA at this time. Example:
  • 90% of initial response times for new issues on GitHub are two business days or less.
• Consider Slack interrupts and GitHub Issues/PRs. Some examples:
  • Time to initial response in Slack questions on #carvel and #project-carvel.
  • Time to initial response for new Issues on GitHub.
  • Time to close Issues on GitHub.
  • Time to initial response for new PRs on GitHub.
  • Time to close PRs on GitHub.
• This story is only about determining the metrics and the intended success measurement. This story does not include implementing the metrics.

Flag guidelines:

• --dangerous-*
• --*-alpha

Examples of current inconsistencies:

• running kapp produces help msg and error
  • vendir and imgpkg on the other hand just produce error message with list of sub commands
  • ytt and kbld return successfully (since they have root commands registered)

Note: This issue originated from vmware-archive/design-docs#2 but has been moved here as a part of the carvel rename.

Resource matchers are used by rebaseRules, ownershipLabelRules, waitRules, and probably other rules, but only the first two are mentioned under the "Resource matchers" section.

https://carvel.dev/kapp/docs/latest/config/#resource-matchers

Resource matchers (as used by rebaseRules and ownershipLabelRules):

Given the feedback that using the three tools (ytt, kbld, kapp) complicates the workflows for operators that are new to the toolset, we should investigate if we should introduce a cli that combines these tools so the user has the option to avoid interacting with the building blocks but can still interact with the three separate clis if they want

As a user installing Carvel tools on Fedora or Ubuntu (or other OS's not shipped with shasum)
I want to be able to verify the shas of the tools
So that I can use them confidently

Acceptance Criteria

Given I am on an OS that does not have shasum like Fedora
When I run carvel.dev/install.sh
Then It exits successfully
and has verified the downloaded tools against their shas

Notes: Since shasum defaults to using "1", we should default to sha1sum, and if that is not installed use shasum.

Describe the problem/challenge you have
Running install.sh on Fedora 27+:

#16 1.266 + install
#16 1.266 + set -euo pipefail
#16 1.266 + dst_dir=/opt/kubernetes/bin
#16 1.266 ++ command -v wget
#16 1.267 + '[' -x '' ']'
#16 1.267 + dl_bin='curl -s -L'
#16 1.267 + shasum -v
#16 1.268 Missing shasum binary
#16 1.268 + echo 'Missing shasum binary'
#16 1.268 + exit 1

Describe the solution you'd like
Be a bit more resilient to differences in distros.

Instead of erroring out, consider a small set of checksum tools and detect one that is present and use it.

Anything else you would like to add:
Users many not always be able to / want to install these kinds of utility tools as part of their installation of Carvel tools.

(Thanks to @GrahamDumpleton for pointing this issue out)

Describe the problem/challenge you have
See #182 for they overlying why.

Describe the solution you'd like
Create a way to track the metrics defined in #183.

• Ability to see what the metrics are over time (such as the past week, past month, past quarter).

Anything else you would like to add:
Try to keep this lightweight (i.e. we don't need to build out a dashboard if an easier solution exists).

What steps did you take:
on OS X, MacBook Air (M1, 2020)... big sur
probably an easy fix, just need to support arm64 i think in the brew publication process?

GOOS=darwin GOARCH=arm64 go build -o  ...

brew install ytt kbld kapp imgpkg kwt vendir
==> Installing ytt from vmware-tanzu/carvel
==> Downloading https://github.com/vmware-tanzu/carvel-ytt/releases/download/v0.36.0/ytt-darwin-arm64
==> Downloading from https://github-releases.githubusercontent.com/173207060/7e47b79b-a02d-48f2-87b5-604

What happened:
looks like the 64 intel brew is the only one supported?

######################################################################## 100.0%
🍺  /opt/homebrew/Cellar/ytt/v0.36.0: 3 files, 12.4MB, built in 2 seconds
==> Installing kbld from vmware-tanzu/carvel
kbld: The x86_64 architecture is required for this software.
Error: An unsatisfied requirement failed this build.

What did you expect:
carvel would install on an m1 mac...

(edit: add summary of issues to implement this.)

Related work:

• carvel-dev/kbld#143
• carvel-dev/imgpkg#221
• carvel-dev/kapp#292
• carvel-dev/vendir#100
• build and publish ARM64 versions of ytt binary
• carvel-dev/kwt#28
• install.sh — when on an ARM64, install ARM64 version of binaries.
• #228

Describe the problem/challenge you have
Since the Package Management APIs have been released, we want to broadcast this information to grow our userbase.

Describe the solution you'd like
Write a blog post that describes why we developed these APIs and how they work.

Work to be done:

• Draft the blog post
  • Include a link to the hosted tutorial in the blog post
  • Embed the recorded video demo
• Tweet about the blog post
• Add a website banner to carvel.dev directing to the blog post

What the right way to report security issues with this project?

Are you using Carvel?

If you are using any of the Carvel tools, first we would like to Thank You. Our goal is to grow the community, improve Carvel and help each other.

The purpose of this issue

We are always interested in finding out who is using Carvel, what attracted you to using the tool suite, how we can listen to your needs, and, if you are interested, help promote your organization.

• We have people reaching out to us asking, who uses Carvel in production?
• We’d like to listen to what you would like to see in Carvel and your scenarios.
• We'd like to help promote your organization and work with you.

What we would like from you

Submit a comment in this issue to include the following information, which would then also get included into the ADOPTERS.md file in this repo for others to see:

• Your organization or company
• Link to your website
• Your country
• Your contact info to reach out to you: blog, email, Kubernetes Slack workspace handle, or Twitter (at least one).
• What is your scenario for using Carvel?
• Are you running you application in testing or production?
• Attach a PNG version of your logo to your comment. Name the image file something that reflects your company (e.g., if your company is called Acme, name the image acme.svg).

If you have any questions please Email Us.

Organization/Company: 
Website: 
Country: 
Contact: 
Usage scenario: 
Status: Production // Testing

Describe the problem/challenge you have
The community engagement (i.e. responsiveness) expectations of maintainers are unclear. We want to ensure that Carvel is an inclusive and responsive community but also need to balance how we allocate our time. This leads to confusion about how quickly maintainers should respond to incoming requests and can lead to prioritization challenges (such as should I prioritize issue triaging or feature development?).

How

...

Describe the problem/challenge you have
We have improved Carvel's website significantly with the new redesign. However, one of the feedbacks that we have heard regularly is that we need clear messaging on Carvel's website. As more prospective users come to the website who are not familiar with any of the tools, it gets challenging for them to understand why Carvel exists and what problems it is trying to solve on a higher level.

When they see a list of tools on the homepage, it can be a cognitive load to go through each tool and learn about them separately which might discourage them to explore more.

Describe the solution you'd like
Some thoughts/ideas that we have heard so far:

• Clear messaging on what is Carvel and what problems it solves.
  • Focus on the why more than the how.
  • It's not possible to talk about each tool and its value. So focus on the top 1-3 values.
• For someone new to carvel, they need to learn why it exists and how it can help as an integrated suite
  • Have a user journey and talk about how Carvel can be used
• For someone familiar, they can use the current landing page
• Everyone will want to know why it’s different from Helm
  • How can Helm users use Carvel?
  • What does Carvel do better and how can they work together?
• Have an image that shows how these tools are integrated

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

A community-facing description so that folks understand how to read our GitHub Project. They should be able to understand the following:

• what we're working on right now
• what our upcoming work is
• what work is unplanned but available for community contributions

Tasks:

• Add description of our ZenHub board
• Ensure that all repos' README link to the ZH board and this description page

Describe the problem/challenge you have
The Carvel team recently received feedback that the example groups 'Overlays' and 'Getting Started' felt hidden on the ytt playground. Users rarely found these examples on their own. These ytt playground examples are great resources for those learning/using ytt.

Listing the current feedback from community meeting:

• Tabs don't look like the classic tab, it is difficult to see which examples belong to which group and is not clear which groups are open.
• the current example being displayed is not highlighted
• Having a default of a collapsed example set naturally hides these examples from users - which is not our goal.
• Some example titles do not entirely describe the contents of the example. Adding a search ability to look through each example's contents, or adding searchable tags to examples could help users find what they want.

Describe the solution you'd like
During the 5/3/21 community meeting, the Carvel team identified three major improvements:

1. Place the different example sections in a vertical alignment
   
2. When navigating to the playground, have all sections expanded by default, and highlight the background of the expanded sections to look like those example belong to their corresponding example group
   
3. The example that is currently loaded should be highlighted and emphasized (see URL and purple highlighting)
   

Anything else you would like to add:
These screenshots were produced using inspect element, thus they only reflect the spirit of the desired changes. Please use your own judgement/VMware guidelines when implementing the design.

I would like to propose a new tool to the carvel ecosystem: A windows bolt on command line tool, that you can add to any cluster-api (or non cluster-api based) cluster. For lack of a better name, id call this wanzu to start.

The functionality of this tool would include:

• Building windows images and uploading them to various clouds as ISOs.
• Bolting 'windows' nodes on to a CluterAPI cluster (wrapper to clusterctl/ powered by ytt templates)
• Validating a windows cluster with a few simple smoke tests (wrapper to e2e.test)

I have no idea wether the carvel ecosystem supports proposals, but... in case it does, that's my pitch :) !

Why

Our website currently lacks a clear way to access and organize top-level, shared documentation that relates to the Carvel project as a whole rather than an individual tool. Duplicating documentation across many projects is tedious and difficult to maintain. This story is to explore ways that we could introduce a shared documentation structure.

As a carvel.dev visitor
I want to be able to find information that pertains to the whole project rather than an individual tool (e.g. project governance model, how to contribute, community guidelines, workflows that span multiple tools)
So that I can learn about the suite holistically.

Things to consider:

• how do we avoid confusing people about the shared docs vs individual tool docs
  • we want to prevent having multiple Documentation links on one screen (such as one at a top-level and one at a nested tool-level) since that may be confusing
• take a look at how other projects with multiple sub-projects handle this for inspiration (such as argo, flux).

Acceptance Criteria

A proposal/charter (or better yet, stories) is captured that explains how we could better structure our website's documentation so that we can include both top-level, shared documentation and individual tool's documentation.

Notes

• there currently is a Shared Docs structure but it doesn't have a direct link to it, you need to navigate through the Community page to get there.

Why

We want to create a consistent experience for visitors to carvel.dev. Currently, we have external links (e.g. link to GitHub repo) that follow those link within the current tab creating a disjointed experience of our website and losing the "reminder" to continue on the website. To fix this, we would like to have all external links open a new tab.

As a carvel.dev visitor
I want external links to open in new tabs
So that I can preserve the carvel.dev experience and be reminded to browse the website further.

Acceptance Criteria

Given the website is updated
When I click an external link (i.e. a link that directs a visitor away from the website)
Then I am directed to that link in a new tab.

Notes

• any html links may need to updated to include the target attribute
• Looks like this could be pretty easy with Hugo: https://discourse.gohugo.io/t/external-links-in-new-tab/5311

Describe the problem/challenge you have
On carvel.dev's home page, the only "highlighted" tool that doesn't link to its own page is kapp-controller. Currently, it links to kapp-controller's GitHub repo. This creates confusion because kapp-controller's GH docs are falling outdated because kapp-controller's website docs are updated. However, you can navigate to kapp-controller's website docs directly but this creates a weird/sub-par experience.

This feels timely as ongoing kapp-controller work will likely drive more traffic to this.

Describe the solution you'd like

• When I click on kapp-controller from the carvel.dev homepage, it directs me to kapp-controller's site.
• When I navigate kapp-controller's GH docs, I don't find outdated documentation (this could be accomplished in a separate issue).

Tasks:

• Complete kapp-controller website
• Cleanup kapp-controller's GitHub docs

we should add instructions on how people can propose projects to carvel, if theres a way.

Why

With the addition of linting tools, we should continue adding on additional linters to assure better code quality. Some of the more important linters we can add are deadcode/unused. These linters help detect unused code in go projects.

As part of enabling these linters, we should also remove any unused source code from kapp, imgpkg, kbld, and ytt.

As a Carvel maintainer
I want linters enabled that check for unused code
So that I can avoid confusion/having to maintain code that is not being used

Acceptance Criteria

Scenario:

Given I run the linter.sh script for the repos listed above
Then I see no violations from (deadcode) or (unused)

Additional Infomation

• The linters can be enabled by adding the deadcode and unused under the enable property of the .golangci.yml file as shown here.

Sourced from: carvel-dev/ytt#272

This is hopefully not too large of a CSS change. We're already adding and removing a class to our body when the fullscreen button is clicked, so we should be able to make a more specific selector for the playground-wrapper than the one in use (giving it priority) by incorporating the playground-expanded class.

Carvel is missing a doc outlining who the maintainers are and any key stakeholders. Need to create doc and add to main repo then link out to within all tools' repos.

Context

• We've moved our git repos from the k14s org to the vmware-tanzu org.
• The module path of a project to match that of the GitHub repo where it lives.
• ⚠️ We will rename the module names of all our tools; this is a breaking change for those who are depending on our tools as libraries/modules.

(mentioned in vmware-tanzu/carvel-kapp-controller#48.)

As a Developer using one or more Carvel tools as a module dependency
I want to know about the module rename ahead of time
And be clear about what I need to do to accommodate it
So that smoothly continue to enjoy using these tools instead of wasting time (and frustration) associated with discovering the source of a problem I didn't expect.

Acceptance Criteria

📘 Documentation

When I review the developer notes (e.g. docs/dev.md) for ${tool}
Then I see a note about the module rename.
And I'm more like to understand what changed.

__

📣 Advanced Notice

Given I'm on a team known to use ${tool} as a module dependency
When The module rename occurs
Then I am aware of it, shortly after it occurs
And I'm clear what I need to do to proactively accommodate the rename.

__

🌟 New Dependency

Given I am not yet using a Carvel tool as a module
When I name it as a new dependency in my project and use it

$ go get github.com/vmware-tanzu/carvel-${tool}

Then I successfully get that dependency (i.e. I see it in my go.mod)
And I can import packages from that module

__

🏚 → 🏠 Migrating/Upgrading

Given I am already using a Carvel tool as a module
When I follow the instructions "upgrade" to the next version (which contains the module rename)
Then I successfully get the new dependency (i.e. I see it updated in my go.mod)
And I can continue to import packages from that module in my own code

Resources

• Go Modules reference
  • Finding a repository for a module path

Describe the problem/challenge you have
When trying to navigate to the docs, I get a 404 at carvel.dev/ytt/docs/. It then only offers me the ability to return to the main carvel.dev site or a "page not found support site".

Instead, the correct link for ytt's docs is
carvel.dev/ytt/docs/latest

Describe the solution you'd like
I'd like a simple redirect from /docs to /docs/latest for all of our tools. I don't think we should need our users to remember "if I want the latest docs I need to explicitly write it." Instead, I think we should make the assumption that not providing a version implies they want the latest docs, and give the user something useable, not a generic "page not found".

Alternatively, I'd like to see a directory of our docs versions if we want to make the assumption that the user doesn't know which version they want.

In kapp-controller docs, there are some examples of using kbld during templating like below:

- kbld:
    paths:
    - "-"
    - ".imgpkg/images.yml"

If you have kbld config in an overlay as an intermediary (a more advanced use case), it will sometimes override the images.yml. To avoid this, it is suggested to use the paths ordering with kbld shown below:

- kbld:
    paths:
    - .imgpkg/images.yml
    - '-'

It might be helpful to suggest this ordering in our docs to help users avoid this experience.

Acceptance Criteria

• Add The New Stack's blog post to carvel.dev/blog

Describe the problem/challenge you have

• Keynote on Carvel will be delivered during KubeCon NA and we want visitors to Carvel homepage to easily find it.

Describe the solution you'd like

• Add banner saying, 'We are presenting a keynotet at [KubeCon + CloudNative North America 2021!]'
• Link banner to a blog post that details out more information about the upcoming keynote.

Context

In Java ecosystem, JReleaser make the release process very easy yet powerful :

• Checksums
• Multiple Packaging Options
• Publish Packages
• Helps in communication : twitter, ...

The main idea would to use the same kind of tool for the release process.

Proposal

Use Goreleaser to make release process even more efficient and effortless (docker bundle creation, scoop, ...). Still the site is a .com : note sure it's an Open Source product ;-(

Related stuff

See Dependabot proposal, cf #158

What steps did you take:
[A clear and concise description steps and yaml files that can be used to reproduce the problem.]
in root account: get -O- https://carvel.dev/install.sh | bash
What happened:
[A small description of the result or the yaml that was generated]
installing ytt...
main: line49 /tmp/ytt: permission denied
What did you expect:
[A description of what was expected and the yaml that should have been generated]
install kapp in ubuntu os

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

Environment:
ubuntu 20.04.

• ytt version (use ytt --version): ytt failed to instal
• OS (e.g. from /etc/os-release):ubuntu 20.04.1

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

As per carvel-001 — Maintain Documentation proposal.

compare to:

• helm
• kubectl --prune
• pulumi

@a-peek4 commented on Fri Apr 02 2021

A few Carvel tools are required to use the Cloud Native Runtimes (CNR) CLI (ytt, kapp, and kbld). I got some feedback from someone who was going through the Cloud Native Runtimes install process that they had to go through the Mac process of going to System Preferences, Security and Privacy, and click "allow anyway" to be able to open the tools. I know there is some kind of option to get a developer certification for products so that users won't get the security notification before opening Carvel tools, is this something your team has considered? Since we'll have more users coming to the Carvel tools through CNR installation, this is some feedback I wanted to pass on.

@aaronshurley commented on Fri Jul 09 2021

@a-peek4 Thank you for surfacing this! We have known about this "undesirable" experience but haven't yet explored solutions. This issue will make sure that we keep this on our radar. I'm going to rename this issue to make it more generic and less CNR-specific. Please let us know if you have any urgency behind this request.

Currently, the kapp-controller webpage features a small demo video shown here. The PackageRepository shown in the video features sample Packages (i.e. simple-app.corp.com).

However, changing this to showcase a repository with more meaningful Packages (e.g. cert-manager) would help users better understand kapp-controller. Using the simple-app Package isn't the perfect illustration of kapp-controller's capabilities.

The asciinema video is maintained here in the carvel repo. There should also be some discussion about what PackageRepository to use in the video.

@joaopapereira commented on Tue Mar 09 2021

A proposal based on the following issues:
carvel-dev/imgpkg#60
carvel-dev/kbld#79

@cppforlife commented on Thu Apr 08 2021

one late constraint ill throw that i just thought of... we should ensure that registry replication can be used with this feature. ie if bundle that uses images.location gets replicated to a different registry, ideally images.location should work in the context of that new registry (assuming that all relevant dependent images were also replicated).

@jorgemoralespou commented on Tue Apr 13 2021

Is there a way to capture in the ImagesLock file (or in a resulting file) the result of the copy so that it can be tracked? Source image, destination image and strategy used on copy.?

@braunsonm commented on Wed Jun 23 2021

Any update on this? Would still be great to see.

Describe the problem/challenge you have
We recently updated the issue triage process to publicly define the process and to make prioritization decisions more transparent. Additionally, this updated process introduced a new set of priority labels which use a new label format: <category>/<category-option (ex: priority/important-soon.

In order to bring all of our primary repos into alignment with this new process, we should ensure that our labels are updated and sufficient.

The primary audience for these changes is the maintainers since we use the labels for triaging and prioritization.

Describe the solution you'd like
Acceptance Criteria:

1. The primary repos have a consistent set of labels and github-actions are updated to reflect them

Anything else you would like to add:

• The priority labels should already be in our primary repos.
• We could use this time to align on the dashes vs spaces argument. The latest context on why dashes are preferred is because it better supports the slash-separated schema and follows how k8s uses labels.
• Using k8s as inspiration, perhaps we update our triage-related labels (such as needs-triage,triage/accepted, or kind/*).

Context

Currently bumping dependencies is a manual process. This can result in having old dependencies making it harder / costly to bump in the future.

Description

Automate bumping dependencies. dependabot is one approach to consider

• ytt
• kapp
• kbld
• imgpkg
• kapp-controller
• vendir

Steps to reproduce

1. visit any of the tools on carvel.dev
2. See the image tiles oddly on wide screens

Expected

Image is fixed, doesn't overlap with text and doesn't repeat

Actual

image overlaps text and repeats

Notes

• the carvel.dev page does this correctly using background-size: cover

Context

I'm maintaining Carvel chocolatey packages, but recently Chocolatey guidelines ask to provide the logo url as a CDN content :

Hi,
The iconUrl should be switched from github raw to a CDN as requested from the previous version: https://docs.chocolatey.org/en-us/create/create-packages#package-icon-guidelines

Thanks, TheCakeIsNaOH

Consequence

As long as I can't provide the the requested url, my packages cannot be validated anymore, preventing me from pushing latest updates.

Requested Action

• Provide me the CDN url of carvel logo

Actual workaround

Use https://statically.io/convert/

Resources

Packages :

• ytt
• kbld
• kapp
• vendir
• imgpkg

Create a blog highlighting kapp exists annotation.

@aaronshurley commented on Tue Mar 02 2021

Flag guidelines:

• --dangerous-*
• --*-alpha

Examples of current inconsistencies:

• running kapp produces help msg and error
  • vendir and imgpkg on the other hand just produce error message with list of sub commands
  • ytt and kbld return successfully (since they have root commands registered)

Note: This issue originated from vmware-archive/design-docs#2 but has been moved here as a part of the carvel rename.

Describe the problem/challenge you have
Want to be able to deploy a new version of the ytt playground backend without having to bug Dmitriy about it.

Describe the solution you'd like
Since we're hosting our docs at Netlify and Netlify also hosts AWS Lambdas under their "Functions" feature, seems like that would be a great alternative.

Anything else you would like to add:
Functions configured here: https://app.netlify.com/sites/carvel/functions (and there are links to docs from there)

Implementation Notes and context

See this public document for context.

Recommended next things to try:

• Modify the current function to use a Handler and a APIGatewayProxyResponse This is based purely on a hunch that the netlify docs say that a function MUST contain a handler function, but ours does not exactly. That could be a reason the function is not recognized. May also require work to combine our current 2 binary build into a single binary.
• Don't use Netlify. We have a working AWS lambda function code that doesn't work on Netlify. Can we get an AWS or Google account and just use that?
• Rewrite the ytt playground function in WASM or javascript. Netlify should be able to recognize a javascript function easier. It is not clear if even as a javascript function if the current 2 binary approach will work.

The incomplete work in progress:

• Most recent branch uses vendir to dynamically include and build carvel-ytt lambda and copy the 2 binaries to the default netlify/functions folder. Doesn't work, netlify does not recognize the binaries and deploy them. https://github.com/vmware-tanzu/carvel/pull/428

• The work for combining the ytt lambda into a single binary is on this branch (unclear if it is working, but it compiles): https://github.com/vmware-tanzu/carvel-ytt/tree/website-no-ytt-binary

Important details:

• Golang functions don't get deployed locally. You must use Netlify deploy previews that are created in a PR to recognize and deploy golang functions that are compatable with netlify. The netlify-cli (netlify dev command) will not recognize golang functions ever (using netlify-cli 10.1.0).
• The command to build locally is netlify build --context development. This will run the [build] step in the netlify.toml file. Note: the PR deploy preview actually runs the [context.deploy-preview] step.
• A working example of a golang function getting deployed to netlify is at.. This commit shows that with a simple function. Note: you will have to recreate a PR with this commit to see the deploy preview since the history in netlify doesn't stick around. Visit it at <deployurl>/.netlify/functions/playground.
• Golang precompiled binaries don't work. It doesn't appear that placing golang function binaries directly in the neltify/functions folder works. It appears that golang functions must be built by netlify.
  • This is based on the data that a deploy preview PR where netlify built the binaries worked, but another PR that commited the same binary directly did not recognize any functions.
• Zip file golang functions don't work. Placing the function binaies in a zip file and in the netlify/functions folder misrecognizes them as a Node function. It does see the function, and deploys it, however when you visit it it yeilds an error.
• Netlify docs can't be trusted. Much of the documentation for go lambda functions for netlify is slightly incorrect or just wrong.
• Once a solution is working think about this. There are some copied SCSS files in both the Carvel-ytt repo and the Carvel repo for styling the playground. It would be cool if the solution could get rid of the duplication (not required).

Netlify Functions:

• has three deployment modes:
  • auto-detect — Netlify scans the "Functions Folder" for source files and builds automatically
  • custom-build — configure a command (in netlify.toml) to build the functions from source
  • pre-built binary — commit the pre-built binary (i.e. zip file) to the site repo.
• by default the "Functions Folder" is ./netlify/functions
• functions map from ./<functions-folder>/<function-name>/{main.go,<function-name>.go,main.zip} to https://carvel.dev/.netlify/functions/<function-name>

DNS config:

• today, the playground templating is sent to get-ytt.io/template
• when configured through Netlify, this will become carvel.dev/.netlify/functions/template

Possible logistic approaches

• Approach 1: Build the ytt playground lambda from source (meaning that we're not committing binaries to a git repo)
• Approach 2: Download lambda function during build (publish lambda as release artifact, and then fetch and deploy it during the website build)

The work that was done for Approach 1: Build the ytt playground lambda from source

• Add vmware-tanzu/carvel-ytt to vmware-tanzu/carvel via vendir
• Add build script to netlify.toml that builds ytt in addition to the site build command (i.e. hugo --gc --minify)
  • This script builds the lambda and copies it to netlify/functions
  • (doesn't work) Verify locally that it is recognized by running netlify build --context development
• (doesn't work as is) Deploy the function
• Ensure that our Netlify build image is using Go 1.17
• Change the endpoint the playground currently uses (get-ytt.io/template) to the function endpoint probably (https://carvel.dev/netlify/functions/template)
• Use the CSS from git submodule ytt repo (playground) (see comment, below) instead of copying it.
• ...

Signifigant progress was made to do the above on PR . HOWEVER, Netlify does not recognize the lambda binaries for a unknown reason, so this work was set down.

Why

We would like to try a Community meeting format on February 1st suggested by Jonas and Nanci where we review upcoming work and leave space for the community to voice their opinions. In order to review upcoming work in a public way, we want to have a backlog view that the community can see.

Using the proposal from this hackmd doc, create the MVP GitHub Project.

As Community member or maintainer in our Community Meeting
**I want ** to see the issues from last weeks iteration in the public backlog
**So that ** I can see what work was done in the last iteration

As Community member or maintainer in our Community Meeting
**I want ** to see the issues that are planned for the next iteration in the public backlog
**So that ** I can see and discuss the work that is planned for the next iteration

Acceptance Criteria

Scenario: Public Backlog
Given I am interested in the Carvel project
When I visit the Carvel public backlog
Then I see the current and previous iterations issues

Notes:

• Some of the stories that in the current iteration and planned for the next iteration do not yet have issues associated with them. Please create these issues if they don't exist. For the previous iteration, coordinate with the Community Meeting facilitator to see what exactly they are planning to cover and do those.
• Please update the proposal document as you implement this story

Note: This is an epic issue.

Why

We want to ensure that Carvel is easily understood, trusted, and approachable so that potential users know what they can expect from the project.

How

The immediate things we'd like to improve:

1. https://github.com/vmware-tanzu/carvel/issues/495
2. https://github.com/vmware-tanzu/carvel/issues/517
3. https://github.com/vmware-tanzu/carvel/issues/58

This issue is to track transferring the Chocolatey repositories from their current home in adriens GitHub to a single repository in the vmware-tanzu org. This applies to ytt, imgpkg, kbld, kapp, and vendir.

This issue has a discussion on steps to get the repos transferred. Quoted below:

The current thinking is:

1. We create a repository in vmware-tanzu called carvel-chocolatey-packages
2. The separate chocolatey repos you're maintaining now are pull requested in (this helps us for legal reasons relating to the CLA)
3. You will be added to the repository as a maintainer
4. We will add or accept contributions adding automation to the specific tooling repos that will trigger on release and commit and push an update to the chocolatey repo.