Skip to content

Updates schema for simplified calling convention #70

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

Merged
merged 13 commits into from
May 9, 2016
Merged

Conversation

mpeck
Copy link
Contributor

@mpeck mpeck commented May 5, 2016

This removes the enforcing and execution fields from the command schema and adds a requirement for rules. In order to support version 2 to some extent I added a new module, Spanner.Config.Upgrader that attempts to upgrade version 2 bundles to version 3. It will abort with an error if the bundle it is trying to upgrade contains a once command.

This also changes the validator's return signature a bit. It will return {:ok, config} like before in the success case but now will also return {:warning, config, warnings} if the bundle was upgraded. warnings of course contains a list of warning messages encountered during the upgrade. The failure case changed a bit as well, now we return {:error, errors, warnings}, errors containing the list of errors and warnings containing the list of warnings in the case of an attempted upgrade.

Since the return signature changed we will also need to update cog and cogctl at merge.

resolves operable/cog#623

@mpeck mpeck added the review label May 5, 2016
@kevsmith
Copy link
Member

kevsmith commented May 6, 2016

Is this ready for review? I wasn't sure if there were changes pending based on our conversation this morning.

@mpeck
Copy link
Contributor Author

mpeck commented May 6, 2016

Hey @kevsmith, sorry I missed your message. This is ready for review now. I implemented the bits that we talked about this morning.

cog_bundle_version:
type: number
enum:
- 2
Copy link
Member

Choose a reason for hiding this comment

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

This seemed a little weird. Are we running v2 configs through the v3 schema after upgrading?

Copy link
Member

Choose a reason for hiding this comment

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

The plan @mpeck and I discussed on Friday was to auto-convert v2 compliant configs if the commands are already multi calling convention since converting a non-enforcing command is simply generating a rule when command is foo:bar allow.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, we should just need the 3 here.

@vanstee
Copy link
Member

vanstee commented May 9, 2016

@mpeck Looks good. Do we end up showing the warnings to users in cogctl?

@vanstee
Copy link
Member

vanstee commented May 9, 2016

Ah found the warnings that are emitted for the question above.

{:error, errors, []}
end
end
def validate(config) do
Copy link
Member

Choose a reason for hiding this comment

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

I think the following would be a bit clearer:

@current_config_version 3
@old_config_version @current_config_version - 1

def validate(%{"cog_bundle_version" => @current_config_version}) do
. . .
end
def validate(%{"cog_bundle_version" => @old_config_version}=config) do
  case try_convert(config) do
    {:ok, converted} ->
      validate(converted)
    {:error, errors} ->
      {:error, errors, []}
  end
end
def validate(_) do
  {:error, "Not a valid command config"}
end

end
# Gets triggered when we have an old bundle config to validate
# Upgrader will return an error if the bundle is not upgradable
def validate(config) do
Copy link
Member

Choose a reason for hiding this comment

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

Why not put the N-1 version number explicitly here? Makes the intent much more obvious, imo.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are two things that we could error on here. 1) If an old bundle version is specified and 2) if no bundle version is specified. To me it felt cleaner for the upgrader to contain that logic. Then we don't have error messaging for the same basic thing spread over multiple modules. But I'm not super passionate about that. If you think it's clearer to have it here I can move those bits.

@kevsmith
Copy link
Member

kevsmith commented May 9, 2016

Modulo my question on the latest round of commits I'm +1 to merge

@mpeck mpeck force-pushed the peck/update-schema branch from de4175e to 178563f Compare May 9, 2016 18:42
@mpeck mpeck merged commit 178563f into master May 9, 2016
@mpeck mpeck removed the review label May 9, 2016
@mpeck mpeck deleted the peck/update-schema branch May 9, 2016 19:02
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.

bundle config cleanup
3 participants