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

Forcing EVE to use V1 API while #16 is getting fixed #17

Merged
merged 1 commit into from
May 5, 2020
Merged

Conversation

rvs
Copy link
Contributor

@rvs rvs commented May 5, 2020

This also simplifies the handshake between EVE and Adam (especially for the embedded case)

@rvs rvs requested a review from deitch May 5, 2020 00:24
Copy link
Contributor

@deitch deitch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get what you are trying to do, but I don't think this goes in adam itself, or at least not yet. Let's keep all of the "embedded" stuff in the eve-embedded.sh script, and we can look at a single change that puts all of it in a separate command or option in adam after

scripts/eve-embedded.sh Show resolved Hide resolved
}

// FIXME: this is going away as part of fixing https://github.com/lf-edge/adam/issues/16
err = ioutil.WriteFile(path.Join(configDir, "Force-API-V1"), []byte{}, 0644)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these not go into eve-embedded.sh rather than here? This /config/Force-API-V1 file is only in the embedded context, and only makes sense to eve itself.

I don't object to adding some capabilities to adam itself, so that we can eventually get rid of eve-embedded.sh (I was thinking about it, actually), but let's not put them in in an unstructured way. This whole thing can be done in a single cp command and a single echo command in eve-embedded.sh

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it actually has to go everywhere -- not just into embedded. Otherwise there's absolutely no way for us to signal to the user that this needs to be somehow handed over to EVE via its config.

In fact, that the whole point of Adam generating an EVE config -- it needs to have a way to signal of what options need to be there for it to actually function.

Hence I think it actually belongs here -- the only other alternative @deitch is to completely drop this EVE configuration generation -- 'cuz it really has to be complete or it needs to be dropped.

The thing we don't want it to be is misleading -- that's the worst option of all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adam already was writing out an eve-compatible config to a local directory when run in adam server mode. Right. In that case, this makes sense.

@rvs
Copy link
Contributor Author

rvs commented May 5, 2020

I get what you are trying to do, but I don't think this goes in adam itself, or at least not yet. Let's keep all of the "embedded"

Well, but the problem is -- its not just embedded. Eden folks ran into issue here as well. Like I said -- we need to make sure that Adam either generates all config knobs that need to be given to EVE for it to actually function.

OR

We need to completely drop EVE config generation from Adam.

For now -- I'd prefer option #1

Copy link
Contributor

@deitch deitch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Good explanations.

@rvs rvs merged commit acfb407 into lf-edge:master May 5, 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 this pull request may close these issues.

2 participants