zerovm / zpm

ZeroVM Package Manager
Apache License 2.0
6 stars 11 forks source link

Add `zpm list` command #78

Open larsbutler opened 10 years ago

larsbutler commented 10 years ago

It would be useful to list the ZeroVM applications that have been uploaded/deployed to ZeroCloud.

The intention is to be able to list the zapps that have been uploaded/deployed. zpm list could work similar to swift list. Here's roughly how I envision this to work:

# use the swiftclient to list containers
$ swift list
container1
container2
container3
$ swift list container1  # shows all files
foo.zapp
foo.json
index.html
style.css
zerocloud.js
$ zpm list container1  # only shows the zapp
foo.zapp
bar.zapp
$ zpm list container2
baz.zapp
$ zpm list container3
# no zapps installed in this one

A naïve implementation of this would basically do something similar to swift list [container] and list any files which end with a .zapp extension.

After listing, the zapp could be executed using zpm execute (which is already implemented: https://github.com/zerovm/zpm/pull/115):

$ zpm execute container1 foo.zapp

This is the general idea.

Potential gotchas:

mgeisler commented 10 years ago

I'm wondering if it makes sense to say that we reserve a full container for the apps? Do users normally have the possibility to create as many containers as they want, or do you get just a few containers?

The question is really about how fine-grained we should make the namespacing here. So far, we've not paid very much attention to containers -- you can deploy directly into a virtual subfolder of a container. The list command described above seems to take a more container-centric view, as I understand it. Is that what people used to Swift would expect?

larsbutler commented 10 years ago

I'm wondering if it makes sense to say that we reserve a full container for the apps?

I don't think we need to reserve an entire container for zapps. We could make a convention for this, but I don't know if we should do that. I'll have to think about it more.

Do users normally have the possibility to create as many containers as they want, or do you get just a few containers?

As far as I can tell, users can create as many containers as they want. Swift can set quotas for 1) total bytes per account and 2) bytes per container, but I don't see any limits for the number of containers. See http://docs.openstack.org/trunk/config-reference/content/object-storage-account-quotas.html and http://docs.openstack.org/trunk/config-reference/content/object-storage-container-quotas.html. I also found an interesting discussion about container and file limits: https://answers.launchpad.net/swift/+question/181977/.

So I think the short answer is, they get as many as they want.

The question is really about how fine-grained we should make the namespacing here. So far, we've not paid very much attention to containers -- you can deploy directly into a virtual subfolder of a container. The list command described above seems to take a more container-centric view, as I understand it. Is that what people used to Swift would expect?

The pseudo-directory stuff supported by Swift is useful for namespacing, but ultimately, the "hierarchy" is just a naming naming convention for files. The illusion is somewhat revealed if you upload files into pseudo-directories, and then try to list them:

# create a new container
$ swift post container1
# list containers
$ swift list
container1
# upload a file into a pseudo dir
$ swift upload container1/foo/bar test1.txt
test1.txt
# list contents of container
$ swift list container1
foo/bar
foo/bar/test1.txt

Swift has some support for browsing the pseudo-dirs using the --delimiter and --prefix options. It's a little weird, but it works. Here's what I was doing to play around with it:

$ swift list container1 --delimiter=/
foo/
$ swift list container1 --delimiter=/ --prefix=foo
foo/
$ swift list container1 --delimiter=/ --prefix=foo/
foo/bar
foo/bar/
$ swift list container1 --delimiter=/ --prefix=foo/bar
foo/bar
foo/bar/
$ swift list container1 --delimiter=/ --prefix=foo/bar/
foo/bar/test1.txt