Caps api remove capability #211

Merged
merged 13 commits into from Dec 3, 2015

Conversation

Projects
None yet
4 participants
Contributor

zyga commented Dec 2, 2015

This depends on #208

zyga added some commits Dec 2, 2015

Add caps.Repository.Capability()
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Add DELETE /1.0/capabilities/{name} REST API
This method removes one capability.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Add client.RemoveCapability()
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Add "snap remove-cap" command
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Refresh translation template
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
caps/repo.go
+// Capability finds and returns the Capability with the given name or nil if it
+// is not found.
+func (r *Repository) Capability(name string) *Capability {
+ return r.caps[name]
@chipaca

chipaca Dec 2, 2015

Member

locking?

@zyga

zyga Dec 2, 2015

Contributor

Ah, good catch!

@zyga

zyga Dec 2, 2015

Contributor

Fixed, had to push with --force because I had some junk staged for an unrelated discussion. Nothing in the "past" above has changed. I've only added the two locking patches below.

zyga added some commits Dec 2, 2015

Fix test for client.RemoveCapability
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Add locking to caps.Repository.Type
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Add locking to caps.Repository.Capability
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
client/caps.go
- var result map[string]map[string]Capability
- if err := json.Unmarshal(rsp.Result, &result); err != nil {
- return nil, fmt.Errorf("cannot obtain capabilities: failed to unmarshal response: %v", err)
+ switch rsp.Type {
@niemeyer

niemeyer Dec 3, 2015

Contributor

This can use the same if err := rsp.err(); err != nil trick mentioned in the underlying branch.

@zyga

zyga Dec 3, 2015

Contributor

Done

+ "type": "sync",
+ "result": { }
+ }`
+ err := cs.cli.RemoveCapability("n")
@niemeyer

niemeyer Dec 3, 2015

Contributor

As mentioned in the other branch, would this test pass if the whole body is replaced by return nil?

@zyga

zyga Dec 3, 2015

Contributor

Done

Contributor

niemeyer commented Dec 3, 2015

A couple of comments, but LGTM. Please wait for @chipaca.

zyga added some commits Dec 3, 2015

Simplify error handling in client.RemoveCapability()
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Improve tests for client.RemoveCapability()
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Improve test for client.Capabilities()
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Improve test for client.AddCapability()
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
+func (client *Client) RemoveCapability(name string) error {
+ errPrefix := "cannot remove capability"
+ var rsp response
+ if err := client.do("DELETE", fmt.Sprintf("/1.0/capabilities/%s", name), nil, &rsp); err != nil {
@mvo5

mvo5 Dec 3, 2015

Collaborator

Do we need to be concerned about quoting here? I assume the anser is no, but I would like to be confirmed

@zyga

zyga Dec 3, 2015

Contributor

Hmm, in theory the client can send anything and the server won't care. Capability names are constrained to identifier-like names.

Do you suggest that we use %q there?

Collaborator

mvo5 commented Dec 3, 2015

LGTM

mvo5 added a commit that referenced this pull request Dec 3, 2015

@mvo5 mvo5 merged commit 83acb8f into snapcore:master Dec 3, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.08%) to 66.576%
Details

@zyga zyga deleted the zyga:caps-api-remove-capability branch Feb 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment