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

many: support 'system' nickname in interfaces #5080

Merged
merged 10 commits into from
May 22, 2018

Conversation

bboozzoo
Copy link
Contributor

@bboozzoo bboozzoo commented Apr 23, 2018

The series add support for system nickname in interface endpoints and commands. It is possible to connect/disconnect/list interfaces using system, eg:

$ snap interface opengl
name:    opengl
summary: allows access to OpenGL stack
plugs:
  - ohmygiraffe
slots:
  - system
$ diff -up <(snap interfaces core) <(snap interfaces system)
--- /proc/self/fd/11    2018-04-23 14:04:10.598886193 +0200
+++ /proc/self/fd/12    2018-04-23 14:04:10.598886193 +0200
@@ -11,7 +11,7 @@ Slot                       Plug
 :browser-support           -
 :camera                    -
 :classic-support           -
-:core-support              core:core-support-plug
+:core-support              system:core-support-plug
 :cups-control              -
 :dcdbas-control            -
 :desktop                   -
$ snap disconnect system:opengl
$ snap connect ohmygiraffe:opengl system

To preserve the API stability of snapd, the system nickname is silently accepted in operations that modify connections. However, endpoints that return connections/interfaces will not output system by default and instead use core. This is because the daemon cannot tell whether the client is aware of the nickname or not. For simplicity, snap will stransform core to system in snap interfaces output when system was passed in command line. snap interface OTOH uses system by default in its output.

When handling requests that act on something, make sure to accept snap nicknames
seamlessly. When returning data on GET requests, do not apply the nicknames so
as to not break the API stability.

Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
@codecov-io
Copy link

codecov-io commented Apr 24, 2018

Codecov Report

Merging #5080 into master will decrease coverage by <.01%.
The diff coverage is 86.66%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5080      +/-   ##
==========================================
- Coverage   79.01%   79.01%   -0.01%     
==========================================
  Files         488      489       +1     
  Lines       36477    36597     +120     
==========================================
+ Hits        28823    28917      +94     
- Misses       5369     5388      +19     
- Partials     2285     2292       +7
Impacted Files Coverage Δ
cmd/snap/cmd_interfaces.go 85.45% <100%> (+1.45%) ⬆️
snap/info.go 79.93% <100%> (+0.52%) ⬆️
daemon/api.go 75.83% <57.14%> (+0.18%) ⬆️
cmd/snap/cmd_interface.go 79.54% <75%> (ø) ⬆️
cmd/snap/main.go 59.47% <0%> (-3.34%) ⬇️
overlord/ifacestate/handlers.go 59.65% <0%> (-0.43%) ⬇️
interfaces/ifacetest/backend.go 0% <0%> (ø) ⬆️
client/client.go 79.32% <0%> (ø) ⬆️
cmd/snap/cmd_sandbox_features.go 86.66% <0%> (ø)
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0deb41f...70b0589. Read the comment docs.

Copy link
Contributor

@stolowski stolowski left a comment

Choose a reason for hiding this comment

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

First pass.

@@ -100,19 +121,20 @@ func (x *cmdInterfaces) Execute(args []string) error {
}
// The OS snap is special and enable abbreviated
// display syntax on the slot-side of the connection.
if slot.Snap == "core" || slot.Snap == "ubuntu-core" {
if slot.Snap == "core" || slot.Snap == "ubuntu-core" || slot.Snap == snap.Nickname("core") {
Copy link
Contributor

Choose a reason for hiding this comment

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

We have a growing number of places that do check like this, I wonder if it's time for a helper.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

AFAICT this is the only place where all 3 options appear.

ok = wantedSnap == slot.Connections[i].Snap
if !ok && wantedSnap == snap.Nickname(slot.Connections[i].Snap) {
askedWithNick = true
ok = true
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the above checks could use a helper:
matches, askedWithNick := isWantedSnap(snapname)
and the helper would internaly check nickaname as well.

Copy link
Contributor

@niemeyer niemeyer left a comment

Choose a reason for hiding this comment

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

Looks reasonable. Just a few points:

fmt.Fprintf(w, ":%s\t", slot.Name)
} else {
fmt.Fprintf(w, "%s:%s\t", slot.Snap, slot.Name)
fmt.Fprintf(w, "%s:%s\t", maybeAsNickname(slot.Snap, askedWithNick), slot.Name)
Copy link
Contributor

Choose a reason for hiding this comment

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

Doesn't feel like we gain much from varying here based on the snap. Just feels more magic, which isn't necessarily good. In fact, the case for core, which is the system snap and the only nickname we care about right now, is already special case here in a custom branch right above. So the change seems to introduce extra complexity without much of a win. Plus, this whole command is a bit unfortunate.. we really need that "connections" command we discussed a few times.

So perhaps we should keep this simpler and more straightforward for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are you suggesting I should drop maybeAsNickname() here, as well as where connections and unconnected plugs are printed or just this particular location?

Copy link
Contributor

Choose a reason for hiding this comment

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

We discussed this on IRC

daemon/api.go Outdated
@@ -1852,6 +1852,13 @@ func changeInterfaces(c *Command, r *http.Request, user *auth.UserState) Respons
st.Lock()
defer st.Unlock()

for i := range a.Plugs {
a.Plugs[i].Snap = systemCoreSnapUnalias(a.Plugs[i].Snap)
Copy link
Contributor

Choose a reason for hiding this comment

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

"alias" means something else in the snap world. Perhaps;

  • useSnapNick
  • dropSnapNick

snap/info.go Outdated

// Nickname returns the nickname for given snap name. If there is none, returns
// the original name.
func Nickname(snapName string) string {
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this the same function we have above? Can we use the same without cycles?

Also, perhaps similar to the above point:

  • snap.UseNick
  • snap.DropNick

Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
@zyga
Copy link
Contributor

zyga commented May 14, 2018

# github.com/snapcore/snapd/daemon
daemon/api_test.go:4113:23: not enough arguments in call to repo.Connect
	have (interfaces.ConnRef)
	want (interfaces.ConnRef, map[string]interface {}, map[string]interface {}, interfaces.PolicyFunc)
daemon/api_test.go:4113:23: multiple-value repo.Connect() in single-value context

Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Copy link
Contributor

@chipaca chipaca left a comment

Choose a reason for hiding this comment

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

Nice one.

@bboozzoo
Copy link
Contributor Author

This is ready for re-review

@bboozzoo bboozzoo requested a review from niemeyer May 18, 2018 06:01
Copy link
Contributor

@mvo5 mvo5 left a comment

Choose a reason for hiding this comment

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

This looks nice! What I find interesting is that maybe we can use something like snap.UseNick,DropNick also for upcoming installs. The problem is somewhat similar.

@niemeyer niemeyer merged commit 58a848f into canonical:master May 22, 2018
bboozzoo added a commit to bboozzoo/snapd that referenced this pull request May 22, 2018
There was a certain time span between canonical#5080 being last built and merging it,
meanwhile some incompatible changes entered master. Update the tests to
accomodate for API changes.

Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants