-
Notifications
You must be signed in to change notification settings - Fork 253
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
"mirage describe" should reflect configured state of the unikernel #713
Comments
I don't frequently use We don't describe |
Relevant discussion from the list is here: https://lists.xenproject.org/archives/html/mirageos-devel/2016-12/msg00011.html I think the conclusion on the list was that in the configured case For key discovery from an end user point of view that should be something like |
/cc @Drup |
this is still broken... |
some logging output in functoria leads to:
I suspect it has to be in this code let partial = match full_eval with
| Some true -> false
| Some false -> true
| None -> not (Cache.present cached_context)
in
Config'.eval ~with_required:false ~partial context config where the merged context is passed in, but nevertheless as target For some unknown reason, the read Another abnormality is that maybe @Drup has an idea... |
I think this should now be fixed with the HEAD version of functoria, which should be compatible with the HEAD version of mirage when #849 is merged. |
849 is now merged; what are the release dependencies? |
@yomimono: I guess functoria needs to be released first and then mirage. Or I didn't understand your question :-) |
That is what I meant! Thanks. |
I don't think this is fixed as of mirage 3.0.5. Configuring the network example with
|
Hum Indeed. I think I just checked that "configure -> build" was working as expected and assumed it would work for |
@Drup do you remember why you separated the |
@samoht Honestly, I don't remember. Maybe I just forgot to do it. Having eval/eval_cache separate was useful for handling failure, iirc. |
Do you remember which case of failures? I will try to add some tests, so keen to test the failure modes as well. |
With the changes in #703 and followup in mirage/functoria#85 the Mirage
describe
subcommand should show the configured state of the unikernel rather than the "default" state, i.e. reflect any keys persisted from a previous run ofmirage configure
.Also, this subcommand currently accepts all the standard mirage options, including
-t
. Does that serve any useful use-case? If not then the command should behave identically tobuild
following mirage/functoria#85, i.e. error out ifconfigure
has not been run first, not accept any configuration keys and only display the configured state.@hannesm @yomimono @samoht Please comment on what the best behaviour with regard to the new workflow is here.
The text was updated successfully, but these errors were encountered: