Statically onboarded services vNext change proposal. #3322
Replies: 1 comment
-
@1000TurquoisePogs The answer is that we don't need that and as such we will remove the text from the breaking changes. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Can someone describe this item on the zowe.org/vnext page:
Statically onboarded services needs to do it via modifying the zowe.yaml and adding a directory outside of the zowe to read the files from
zss is one such thing, yet we've made no changes so far. what do we need to do
Jakub Balhar
That's a good question. For zss we should probably take the same approach as for zosmf and as such it should be part of the zowe workspace.
For other services the expectation is that the .yml definitions of static services won't be added to the zowe workspace.
There will be some directory within the system that they specify within zowe.yaml from which the definitions will be loaded.
Madeleine Dudek
So there is the zowe.extensionDirectory where the launching Zowe server finds extensions, reads their manifest, finds their apiml static definition template, creates a proper .yaml with environment variables ... and then adds that to another external directory that needs to be specified in zowe.yaml? Is that the plan?
Jakub Balhar
zowe.extensionDirectory should just work, I will need to validate with Sean, it's possible that we missed some interaction between the App Framework Extensions and Static Onboarding.
@Sean Grady
It seems like we should be adding the zowe.extensionDirectory automatically to the static definition directories.
The goal of this change is to make sure people aren't unnecessarily changing the Zowe workspace itself. (edited)
Sean Grady
in zowe v2, zwe startup code will read every component manifest (core or extension, doesnt matter) and if it finds a static definition file within the component's install directory, it will copy (with substitutions for things like hostname) it into the workspace. the content ends up in the workspace by automation not by user.
is this changed in v3 or is this just confusing to me because it said to do something to "zowe.yaml", whereas the v2 behavior does not involve the zowe.yaml, it involves manifest.yaml
Jakub Balhar
It seems like a topic to discuss then, as there may be some unintended confusion here
Sean Grady
currently, https://github.com/zowe/zss/blob/v2.x/staging/manifest.template.yaml + https://github.com/zowe/zss/blob/v2.x/staging/apiml-static-reg.yaml.template are consumed by zowe startup, here:
https://github.com/zowe/zowe-install-packaging/blob/v3.x/staging/bin/libs/component.ts#L392-L420
(note, thats the v3 branch)
so, im wondering if anything changed at all or if this was just a lingering v2 note?
(https://openmainframeproject.slack.com/archives/CC5UUL005/p1708610581806019?thread_ts=1708542065.965679&cid=CC5UUL005)
There is no change in technology for V3, the goal was to deprecate specific behavior, but based on what you are saying this may be a wrong course of action
Sean Grady
well keep me posted on what to do but it seems like the documentation https://docs.zowe.org/stable/extend/extend-apiml/onboard-static-definition was not aware that this automation takes place
it says:
Add the fully qualified zFS path of your YAML file to ZWE_STATIC_DEFINITIONS_DIR in zowe.yaml.
A) To hold your YAML file outside of the instance directory, add ZWE_STATIC_DEFINITIONS_DIR variable to the zowe.environments section of zowe.yaml. Append the fully qualified zFS path of the YAML file to the ZWE_STATIC_DEFINITIONS_DIR variable. You may specify multiple zFS paths, separating each path by a semicolon.
B) To place your YAML file within the instance directory, copy your YAML file to the ${zoweInstanceDir}/workspace/api-mediation/api-defs directory.
but really B) shouldn't be done, because B) is automatic by zwe itself when using manifest.yaml 🙂
and that makes A) questionable - why manual steps when we have automation?
docs.zowe.orgdocs.zowe.org
Onboarding a REST API without code changes required | Zowe Docs
As a user of Zowe™, onboard an existing REST API service to the Zowe™ API Mediation Layer without changing the code of the API service. This form of onboarding is also refered to as, "static onboarding". (59 kB)
https://docs.zowe.org/stable/extend/extend-apiml/onboard-static-definition
Jakub Balhar
Yeah, it looks like this, as such we are probably going to change this.
Beta Was this translation helpful? Give feedback.
All reactions