If no solution file exists, VS will create one in the project root.

Adding a solution file will prevent one from being created as well as provide an additional option for opinionated configuration.

Individual app workload.yaml files have the incorrect app.kubernetes.io/part-of label causing issues with live view.

As part of the initiative to remove non developer persona based configuration files from the accelerators, this enhancement removes the installation of the RabbitMQ operator as well as configuration to create cluster instance classes and RBAC roles. Instead it will included instructions to create the RabbitMQ instance using the Tanzu CLI dynamic provisioning features and the preinstalled Bitnami services and ClusterInstance classes.

There have been requests for Where For Dinner to be more polyglot. Currently it supports the following languages

• ReactJS for Front End UI
• Java/Spring for all other backend services.

This enhancement will provide an alternative to the crawler application in the form of a python web application. It will also include an accelerator option to toggle between current Java/Spring implementations and alternate service implementations written in other languages. For backward compatibility, the default option will continue to use Java/Spring for all backend services.

We should prompt for storage class name since that could vary by cluster and apply it to the postgres.yaml file

  storageClassName: standard

Currently the workload.yaml replacement for the build env value ends up as an integer

  build:
    env:
      - name: BP_JVM_VERSION
        value: 17

This should be a string or the Kubernetes API will reject the resource.

The Steeltoe sample app title should be "Steeltoe Weather Forecast" but is instead "C# Weather Forecast".

To reproduce, fetch app root, e.g.:

$ http http://<APP>/ | grep '<title>'
    <title>C# Weather Forecast</title>

Expected:

$ http http://<APP>/ | grep '<title>'
    <title>Steeltoe Weather Forecast</title>

The TAP 1.5 version of where for dinner submits the wrong redirect URL to AppSSO when attempting to log in. This is causing an error in AppSSO in that it doesn't recognized the URL as a registered redirect URL. This appears to be something introduced in Spring Boot 3.0.4.

While generating from either weatherforecast-csharp or weatherforecast-steeltoe, one of the required params is an application name.

Although defaulted to 'Sample', a user may modify this to a different value - e.g. weatherforecast-steeltoe. This application name affects the following generated files:

generated from weatherforecast-steeltoe accelerator:

• https://github.com/Mpluya/weatherforecast-steeltoe/blob/3d91ae3b32b94ada4cf337c41ed89e06d56d203c/WeatherForecast.cs#L1
• https://github.com/Mpluya/weatherforecast-steeltoe/blob/3d91ae3b32b94ada4cf337c41ed89e06d56d203c/Controllers/WeatherForecastController.cs#L3

These 2 cs files are syntactically incorrect to a C# compiler.

This request is to either:

• add validation to the application name before generating accelerator artifacts
  or
• massage the application name input to be syntactically correct in C#

Where For Dinner will support configuration options to utilize the optional TAP Spring Cloud Gateway package instead of the OSS gateway deployment. This will include:

• Gateway instance creating
• Mapping and route configuration
• Ingress configuration
• Links to documentation that include optional TLS configuration
• Single logout URL configuration for OSS and TAP Spring Cloud Gateway

The name in the catalog-info.yaml file should match the accelerator name so someone using the defaults to generate a project could use this file to register the component with the Backstage catalog.

metadata:
  name: sample-app

This applies to weatherforecast-csharp and weatherforecast-steeltoe samples.

All samples are moving to the new VMware Tanzu OSS repo - https://github.com/vmware-tanzu/application-accelerator-samples

We need to add the app-sso-starter sample from https://github.com/sample-accelerators/tanzu-java-web-app in a directory named appsso-starter-java.

Tasks for updating each sample:

• Add/Change license file to MIT-0 license (same as in the root of this repo)
• Update paths in README and workload.yaml files to point to this repo using main branch and the subPath of the new directory.

Notes for VMware contributors:

• see https://github.com/vmware-tanzu/application-accelerator-samples/blob/main/CONTRIBUTING.md
• must be member of vmware-tanzu org to avoid CLA issues - https://cla.vmware.com/employee
• sign commits
  • To acknowledge the Developer Certificate of Origin (DCO), sign your commits by adding Signed-off-by: John Doe [email protected] to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. If you set your user.name and user.email git config values, you can sign your commit automatically with git commit -s.

To get it going for use in intellij demo I had to change a few things.

• portforward in the Tiltfile is 1025 whereas the actual port seems to be 1026 (as per the workload.yml)
• the name of the gateway sub-project is wrong in Tiltfile. It is using spring-smtp-gateway throughout, but the actual name is just smtp-gateway. I had to basically do a search replace in there to fix it.
• the pod selectors in both Tiltfiles are wrong and needed to be changed to these:

k8s_resource('smtp-gateway', port_forwards=["1026:1026"],
    extra_pod_selectors=[{'carto.run/workload-name': 'smtp-gateway'}])

k8s_resource('smtp-sink', port_forwards=[],
    extra_pod_selectors=[{'carto.run/workload-name': 'smtp-sink'}])

I am not sure this is actually 100% correct too (maybe it selects too many pods, such as build pods, instead of just run pods). But what is in the file currently, selecting based on serving.knative.dev/service doesn't work at all. Presumably this is because of the workload type being server and worker and so they don't actually result in creation of any knative services (as a web type workload would do).

The tanzu-java-web-app sample vendors the mvnw, mvnw.cmd, and .mvn/wrapper/maven-wrapper.properties files.

Unfortunately, this makes it quite a bit less intuitive to deploy this application inside of an airgapped installation. Specifically, the maven-wrapper.properties file contains URLs that refer to locations on the open internet:

distributionUrl=https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.1/apache-maven-3.8.1-bin.zip
wrapperUrl=https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1.jar

Users trying to deploy this app into an airgapped environment will just see an unexplained connection timeout error when their app is being built by the Tanzu Java buildpack. Specifically, the buildpack is trying to call into mvnw, which then is referencing these addresses on the public internet.

The Java Buildpack (specifically, the Maven Buildpack) is capable of installing Maven dependencies without needing for this mvnw file or its configuration to be checked in.

As a resolution, we've recommended to users attempting to deploy this application into offline environments remove the above listed files. Would we consider doing the same here in the canonical sample repo?

See #46 for Git repo rewrite support

Release engineering has requested a simple API in a Where For Dinner service so they can validate changes occurring in the inner loop process.

The availability service will implement a simple application version API that can be queried via a simple REST client. This will allow them to be able to validate changes to the API implementation using tools like curl.

All backstage selector annotations are pointing to "hungryman" instead of the individual apps.

The tap-workload fragment is meant to be used with the repo creation feature.
It expects values provided by TAP-GUI (bsGitRepository and bsGitBranch) that use a special format for the url which should be considered an implementation detail of TAP-GUI and subject to change.

The README, although advocating to not use the fragment "directly", mentions repoUrl as an option. It is not. This is a computed value.

The java-rest-service accelerator has some options that depend on the selected database type.
For example databasePostgresMonitoringClass should only be shown if the database type is postgres.

This functionality is currently broken, and all options from spring-boot-postgresql and spring-boot-mysql show regardless of the database type that has been selected.

See #46 for Git repo rewrite support

See the .tanzuignore file in the tap-initialize fragment - https://github.com/vmware-tanzu/application-accelerator-samples/blob/main/fragments/tap-initialize/.tanzuignore

All samples with a workload.yaml file should have this.

It is recommended to use ResourceClaim to allow the database to be creatred in a different namespace from where the app is runnig.

This does change the workflow a bit and must be documented in the instructions.

The branch for the “secure” option of the ui app is “sucure-ui” which does not exist in this repo. This option is marked as experimental and is not part of the default deployment. The “main” branch can still be used for the secure option, the ui app will just not present a login button (It should automatically go to the main screen). We should update the branch to “main” for now when the secure option is selected.

The label apps.tanzu.vmware.com/has-tests can't have a boolean value, must be a string.

Change

• java-rest-service/config/workload-api-provider.yaml
• java-rest-service/config/workload-basic.yaml
• java-server-side-ui/config/workload.yaml

to use:

metadata:
  labels:
    apps.tanzu.vmware.com/has-tests: "true"

All samples are moving to the new VMware Tanzu OSS repo - https://github.com/vmware-tanzu/application-accelerator-samples

We need to add the weatherforecast-csharp and weatherforecast-steeltoe samples from https://github.com/sample-accelerators/tanzu-java-web-app in a directories named weatherforecast-csharp and weatherforecast-steeltoe.

Tasks for updating each sample:

• Add/Change license file to MIT-0 license (same as in the root of this repo)
• Update paths in README and workload.yaml files to point to this repo using main branch and the subPath of the new directory.

Notes for VMware contributors:

• see https://github.com/vmware-tanzu/application-accelerator-samples/blob/main/CONTRIBUTING.md
• must be member of vmware-tanzu org to avoid CLA issues - https://cla.vmware.com/employee
• sign commits
  • To acknowledge the Developer Certificate of Origin (DCO), sign your commits by adding Signed-off-by: John Doe [email protected] to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. If you set your user.name and user.email git config values, you can sign your commit automatically with git commit -s.

Unauthenticated access to repo.spring.io/release will be rejected starting January 26

See: https://spring.io/blog/2022/12/14/notice-of-permissions-changes-to-repo-spring-io-january-2023

Hey maintainers! I was recently surprised to see my steeltoe-weatherforecast accelerator failing to apply upon tilt up. Seems like the reason is that the --update-strategy flag is only recognized by the latest version of the tanzu cli apps plugin (0.10.0).

I'm not sure that this is a fixable phenomenon (makes sense that --update-strategy is a good feature to include), but maybe tanzu apps v 0.10.0 could at least be called out as a dependency somewhere? (I didn't see it in any docs -- maybe I missed it?)

All accelerators except hungryman and spring-smtp-gateway are updated to use the tap-workload fragment. The excluded two are multi-module projects which require usage of subPath property. This property currently isn't supported.

We should either support this in the tap-workload fragment or create a new fragment that supports modifying the subPath removing the first level of the path - subPath: hungryman/hungryman-search -> subPath: hungryman-search

There Where For Dinner application has needs for the following:

• AppSSO 2.0.0 updates for deprecated features. Specifically the issuerURI has been deprecated and will no be supported in future updates. The accelerator needs to use the tls.disabled: false technique as described in the AppSSO migration guide and remove the field for the issuerURI
• A Redis cache option (vs a simple in memory cache) has been available but no utilized. This enhancement will add a Redis instance to the application when selected by the accelerator and enable the implementation in the search-proc service.
• The search crawler service has been available for some time, but not utilized. This enhancement adds the crawler service to the application stack.

Need to remove instances of "Whitelist" from the smtp gateway application. Will replace with "Safelist"

Cloud events are no longer working in where for dinner in TAP 1.4.

Update Spring Boot version to the latest 2.7.x version.

Update to use latest snakeyaml dependency.

Review README for java-rest-service.

The README mentions Tekton Pipeline but there is no config/test-pipeline.yaml file generated.

Add "Hungryman" and "Spring SMTP Gateway" samples.

Tasks for each sample:

• Add/Change license file to MIT-0 license (same as in the root of this repo)
• Update paths to point to this repo

Notes for VMware contributors:

• see https://github.com/vmware-tanzu/application-accelerator-samples/blob/main/CONTRIBUTING.md
• must be member of vmware-tanzu org to avoid CLA issues - https://cla.vmware.com/employee
• sign commits
  • To acknowledge the Developer Certificate of Origin (DCO), sign your commits by adding Signed-off-by: John Doe [email protected] to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. If you set your user.name and user.email git config values, you can sign your commit automatically with git commit -s.

The angular-frontend sample is missing the catalog file in catalog/catalog-info.yaml and also could need an iconUrl in accelerator.yaml

Set <java.version>8</java.version> property to 11 and test the accelerator.

Workload type in the workloads.yaml file in the individual project directories used for live update is still listed as tcp and queue. This does not affect the deployment instructions as they use the workloads.yaml file in the config/developer directory which has the correct workload type. TCP and queue should still be updated to the correct workload types in the individual workload/project directories.

Affected accelerator: angular-frontend accelerator from TAP 1.5.0-rc.13

When the Single Sign-on option is left unchecked, the generated code doesn't compile. There are some imports/references to authorization and user-profile that linger around, but those folders are excluded for non-SSO version.

See sample errors when running build or start scripts:

It would be nice if the accelerator transform(s) took care of those imports too.

Change "Hungryman" to "Where for Dinner" in regular text

Change "hungryman" to "where-for-dinner" in paths and command examples

Update iconUrl to use the image from https://iconduck.com/illustrations/105890/restaurant

Tiltfile should be included in text replacement of sample-app

The C# deployed apps should respond to the endpoint/swagger, but instead return 404.

Errant apps:

• weatherforecast-csharp
• weatherforecast-steeltoe

Where For Dinner support for dynamically provisioning and consumption of the following service

• Tanzu MySQL
• Tanzu and OSS RabbitMQ
• Bitnami Redis

Add validation for options that can't be left blank when exposing API endpoint. This applies to the java-rest-service accelerator.

Not sure if the API entity processor should accept empty system, other entities like service components seem to allow leaving system blank.

Left system blank and see this error in the tap-gui server logs:

{
  "ts": "2022-09-18T17:00:37.730Z",
  "level": "warn",
  "meta": {
    "type": "plugin",
    "plugin": "catalog",
    "service": "backstage",
    "entity": "api:default/customer-profile-34.139.6.200.nip.io"
  },
  "msg": "Processor BuiltinKindsEntityProcessor threw an error while validating the entity api:default/customer-profile-34.139.6.200.nip.io; caused by TypeError: /spec/system must be string - type: string"
}

Describe the bug
After cloning the steeltoe-weatherforecast accelerator to a Windows OS, running tilt up fails by default, raising a "path not found" error:

Successfully loaded Tiltfile (3.024ms)
   sample-app â"‚ 
   sample-app â"‚ Initial Build
   sample-app â"‚ STEP 1/1 â€" Deploying
   sample-app â"‚      Running cmd: tanzu apps workload apply -f config/workload.yaml --update-strategy replace --debug --live-update --local-path . --source-image your-registry.io/project/steeltoe-weatherforecast-source --build-env BP_DEBUG_ENABLED=true --namespace default --yes  > /dev/null  && kubectl get workload sample-app --namespace default -o yaml
   sample-app â"‚      The system cannot find the path specified.
   sample-app â"‚ 
   sample-app â"‚ ERROR: Build Failed: apply command exited with status 1

To Reproduce
Steps to reproduce the behavior:

1. Open the steeltoe-weatherforecast accelerator in Windows
2. Invoke tilt up from the root project directory

Expected behavior
tilt up command to succeed.

Additional context

• This error goes away after removing the OUTPUT_TO_NULL_COMMAND from the default Tiltfile's apply_cmd string.
• > NUL might be a suitable Windows equivalent to > /dev/null

Import all fragments from https://github.com/sample-accelerators/fragments

The fragments should all be in their own sub-directory under a fragments directory.

Fragments to include

• fragments/app-sso-client
• fragments/java-version
• fragments/live-update
• fragments/spring-boot-app-sso-auth-code-flow
• fragments/tap-initialize
• fragments/tap-workload

Tasks for each fragment:

• Update/add README.md file documenting how to create the Fragment resource and how use the fragment in an accelerator, this includes changing any repo references to use this new repo.
• Add/Change license file to MIT-0 license (same as in the root of this repo)

Notes for VMware contributors:

• see https://github.com/vmware-tanzu/application-accelerator-samples/blob/main/CONTRIBUTING.md
• must be member of vmware-tanzu org to avoid CLA issues - https://cla.vmware.com/employee
• sign commits
  • To acknowledge the Developer Certificate of Origin (DCO), sign your commits by adding Signed-off-by: John Doe [email protected] to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. If you set your user.name and user.email git config values, you can sign your commit automatically with git commit -s.

We need to rename hungryman sample and change icon

suggested icon:
https://iconduck.com/illustrations/105890/restaurant