Skip to content
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

Runtime configuration wizard: existing runtime configuration information is "lost" #883

Closed
ptitzler opened this issue Aug 20, 2020 · 3 comments · Fixed by #885
Closed

Runtime configuration wizard: existing runtime configuration information is "lost" #883

ptitzler opened this issue Aug 20, 2020 · 3 comments · Fixed by #885
Assignees
Milestone

Comments

@ptitzler
Copy link
Member

Follow-up to #847

I had created a runtime configuration with an earlier version of Elyra. Opening the configuration using the dev build that includes above PR the name and description in that configuration is not displayed:

image

@ptitzler
Copy link
Member Author

The existing metadata file content (with confidential information manually changed)

$ cat kfp_dev_instance.json 
{
  "display_name": "KFP dev instance",
  "metadata": {
    "api_endpoint": "http:/myhost.mydomain.com:31380/pipeline",
    "cos_endpoint": "http://myhost.mydomain.com:31671",
    "cos_username": "minio",
    "cos_password": "minio999",
    "cos_bucket": "bucketname"
  },
  "schema_name": "kfp"
}

@ajbozarth
Copy link
Member

So I kinda tracked down the source of this issue. After I noticed it also existed on older (previously working) commits I tried installing an older version of lab and that fixed it. So some change between lab 2.2.4 and 2.2.5 broke that specific part of elyra for some reason.

@ajbozarth
Copy link
Member

I tracked down what I believe to be the issue. The most recent lab release (v2.2.5) updated it's yarn.lock and @blueprintjs/core was set to the latest release (v3.31.0). This cause use problems because any lab dependency version will override elyra's version (afaik that's just a side effect of how node modules are handled in lab). The new release of @blueprintjs/core included a fix palantir/blueprint#4266 that added support for async to InputGroup, this new async support broke our async update that occurs after we fetch the metadata from the api. Though I'm unsure of why it broke, I do know that the issue was that we created that field of the form prior to the api call returning, and when updating it was using the previous value rather than the new one from the api. This can be "solved" by waiting to add them field until after the async call. I'll have a PR shortly

@ajbozarth ajbozarth self-assigned this Aug 21, 2020
ajbozarth added a commit to ajbozarth/elyra that referenced this issue Aug 21, 2020
The latest release of JupyterLab updated to the latest release
of blueprintjs core, which included an async bugfix for
`InputGroup` which broke how our async update interacts with fields.
Causing any already rendered `InputGroup` to not update it value
on an async call to `uodate()` such as the one we do after calling
the metadata api.

I solved this by making the rendering of the display_name field
conditional on the existance of an inital value, just like we
already do with the other fields.

Fixes elyra-ai#883
lresende pushed a commit that referenced this issue Aug 24, 2020
The latest release of JupyterLab updated to the latest release
of blueprintjs core, which included an async bugfix for
`InputGroup` which broke how our async update interacts with fields.
Causing any already rendered `InputGroup` to not update it value
on an async call to `update()` such as the one we do after calling
the metadata API.

I solved this by making the rendering of the display_name field
conditional on the existence of an initial value, just like we
already do with the other fields.

Fixes #883
@lresende lresende added this to the 1.1.0 milestone Aug 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants