New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide an error message in case GCP ZONE is not set and exit, also fix styles for kfctl.sh #1888
Conversation
…ix styles for kfctl.sh
We should not enforce users to use us-east1-d which we only need for testing. |
/assign @jlewi |
/retest |
@jlewi looks like we never parsed
and we failed. |
scripts/kfctl.sh
Outdated
@@ -137,6 +140,10 @@ if [ "${COMMAND}" == "init" ]; then | |||
shift | |||
PROJECT=$1 | |||
;; | |||
--zone) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have only one way to explicitly set zone? e.g. if we set it as a command line argument then we should not set it using an environment variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlewi Sure, but we are already doing same practice for --platform
, PLATFORM
, --project
, PROJECT
, --email
and EMAIL
so I thought that's kind of expected pattern here 🙂
Let me know what you think. But if we are taking one out in the favor of other I would choose to keep --zone
over environment variable.
Let me know your thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm in favor of moving things to flags.
… specific flags per review if they are not found under gcloud config
@@ -49,13 +49,64 @@ createEnv() { | |||
echo KUBEFLOW_DOCKER_REGISTRY=registry.aliyuncs.com >> ${ENV_FILE} | |||
;; | |||
gcp) | |||
PROJECT=${PROJECT:-$(gcloud config get-value project 2>/dev/null)} | |||
while [[ $# -gt 0 ]]; do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this.
Do you think we could support the syntax?
--name value
as well as
--name=value
That could be a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can @jlewi , I just have to put more logic to cover both scenarios 🙂
Feel free to file the ticket and describe it the way we want it to be done and assign it to me and I'll pick it up after this one.
But first let's get the tests fixed🤞
Looks good other than failing test. |
--platform) | ||
shift | ||
PLATFORM=$1 | ||
mkdir -p ${DEPLOYMENT_NAME} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you move the mkdir and other commands here and execute them as part of command line processing as opposed to executing them after command line parsing is done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because this DEPLOYMENT_NAME
is really only used by gcp
specific init
calls and Also I needed to be inside that directory to make createEnv $*
call and then later parse args.
So mkdir
needs to be called either here or within createEnv
function. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I"m still not following.
Should the instructions
mkdir -p ${DEPLOYMENT_NAME}
cd ${DEPLOYMENT}
createEnv
be executed for all platforms not just GCP?
The directory ${DEPLOYMENT_NAME} is used as the top level directory for all the Kubeflow related config (e.g. env.sh) so I don't think its GCP specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you're passing the command line arguments back to createEnv and then reparsing them there to persist them.
Can we just set a dictionary of environment variables here and then pass that to createEnv? That seems a little cleaner then parsing command line arguments in two places. We can also avoid putting logic in the argument parsing case statements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean do the whole arg parsing business here, and then pass them to createEnv
with the parsed values?
We can but do we want that in this PR or a subsequent PR.
I was thinking of doing one PR to just go over all the shell scripts and enhance path detection, format and style, enhance user messages specially during failures and that sort of thing.
Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that's what I meant. Specifically; I'd like to do flag parsing in a single location. Otherwise we will likely have problems later on because we update one location but not the other.
I'm ok with doing this in a follow on PR as long as you think you can to it in the next week or so. I'll LGTM this with a hold. If you want to submit this first and fix command line parsing later just remove the hold.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jlewi
I'll do the next PR sooner than later this week.
I'll file a ticket and go from there.
.gitignore
Outdated
@@ -37,6 +37,8 @@ examples/.ipynb_checkpoints/ | |||
|
|||
**/.ipynb_checkpoints | |||
|
|||
# env.sh generated by kfct.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kfctl.sh
Missing .sh
/hold (see comment and decide whether to remove the hold) |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jlewi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…ix styles for kfctl.sh (kubeflow#1888) * Provide an error message in case GCP ZONE is not set and exit, also fix styles for kfctl.sh * Provide an error message in case GCP ZONE is not set and exit, also fix styles for kfctl.sh * provide zone info for kfctl_test.jsonnet as well * Add parameter option for --zone * Move the GCP specific flags up under GCP env creation, mandate gcloud specific flags per review if they are not found under gcloud config * source env.sh prior to calling gcpInitProject * move check for SKIP_INIT_PROJECT back to main * Minor style fix * Fix the missing ENVs during deploy and adding env.sh to .gitignore * Attempt to make kfct.sh executable * Fix a typo in .gitignore per review feedback
* We want to enable the stackdriver monitoring agents by default. This allows pod logs to be fetched by pod label which is very valuable. * To enable this we need to use the v1beta1 API for GKE https://cloud.google.com/kubernetes-engine/docs/reference/api-organization#beta * Remove the field CLUSTER_VERSION from kfctl.sh This was added in kubeflow#1888 but it doesn't look like it was actually being use to set the CLUSTER_VERSION; it looks like cluster-version is set in the deployment manager config cluster-kubeflow.yaml Related to kubeflow#1757
* We want to enable the stackdriver monitoring agents by default. This allows pod logs to be fetched by pod label which is very valuable. * To enable this we need to use the v1beta1 API for GKE https://cloud.google.com/kubernetes-engine/docs/reference/api-organization#beta * Remove the field CLUSTER_VERSION from kfctl.sh This was added in #1888 but it doesn't look like it was actually being use to set the CLUSTER_VERSION; it looks like cluster-version is set in the deployment manager config cluster-kubeflow.yaml Related to #1757
…ix styles for kfctl.sh (kubeflow#1888) * Provide an error message in case GCP ZONE is not set and exit, also fix styles for kfctl.sh * Provide an error message in case GCP ZONE is not set and exit, also fix styles for kfctl.sh * provide zone info for kfctl_test.jsonnet as well * Add parameter option for --zone * Move the GCP specific flags up under GCP env creation, mandate gcloud specific flags per review if they are not found under gcloud config * source env.sh prior to calling gcpInitProject * move check for SKIP_INIT_PROJECT back to main * Minor style fix * Fix the missing ENVs during deploy and adding env.sh to .gitignore * Attempt to make kfct.sh executable * Fix a typo in .gitignore per review feedback
* We want to enable the stackdriver monitoring agents by default. This allows pod logs to be fetched by pod label which is very valuable. * To enable this we need to use the v1beta1 API for GKE https://cloud.google.com/kubernetes-engine/docs/reference/api-organization#beta * Remove the field CLUSTER_VERSION from kfctl.sh This was added in kubeflow#1888 but it doesn't look like it was actually being use to set the CLUSTER_VERSION; it looks like cluster-version is set in the deployment manager config cluster-kubeflow.yaml Related to kubeflow#1757
fixes #1697
This change is