The usual convention for certificate is:

• client.crt
• client.key
• ca.crt
• server.crt
• server.key

getting compile error

vagrant@vagrant-ubuntu-trusty-32:~/go/src/github.com/lxc/lxd$ make 
make -C lxc
make[1]: Entering directory `/home/vagrant/go/src/github.com/lxc/lxd/lxc'
go build
# github.com/lxc/lxd
../container.go:25: undefined: lxc.StateMap

Current standard seems to be to use the CPU intensive bcrypt or CPU+MEM intensive scrypt instead of faster hashing methods for password.

Currently lxd supports a temporary non-ssl http:// channel.

The proper use of certificates must be implemented so that https+lxd:// can be used, and http:// dropped.

syscalls aren't guaranteed to be stable across architectures. That's what we have a C library for, so rather than call them directly, when Go doesn't provide the right interface we should just do it through C.

There appears to be no guidance as to how certificates should be created, checked, and presented (how and when) to users.

On a system that has lxd installed, on first start of lxc, the following remotes should be added:

• local -> unix+lxd://var/lib/lxd/socket
• images -> https+registry://registry.linuxcontainers.org

In this case, the local remote should be marked as the default.

On a system with only lxc installed and no daemon, only the images remote should be added on first start.

In this case, no remotes should be set as default and the first one added by the user should then be marked as the default.

This issue is to track the implementation of the /1.0/images API as well as its command line.

This part of the API and command line tool deals with turning existing containers or snapshots into an image that other hosts can consume. Images are to be exported in a compressed format (xz) and available either publicly (guest REST) or privately (authenticated REST).

I think it's pretty important to support translations for the client tool.

As such, we should make sure that we do not hardcode strings in the API unless those are inherited from a lower layer (console output of the container, LXC debug output, ...). Instead, error codes should be used so that they can then be displayed in the relevant language on the client side.

The strings in the client should all be using gettext with C being American English, therefore allowing contributors to provide translations for their own language.

I'm marking this release critical because we need to make sure we think about this in the design and use gettext wrapped strings everywhere. We will never block a release on missing strings in any given language.

Currently LXD fails to build on all three of those architectures.

armhf:

• Fails because of uname type

ppc64el:

• Fails because of uname type
• Missing definition of the BTRFS magic number

arm64:

• Fails because of uname type
• Missing definition of the BTRFS magic number

The uname failure is typically:

 dist/src/github.com/lxc/lxd/lxd/api10.go:92: cannot use uname.Release (type [65]uint8) as type [65]int8 in argument to CharsToString

As can be seen on armhf here:
https://launchpadlibrarian.net/198024883/buildlog_ubuntu-vivid-armhf.lxd_0.1-0ubuntu1_FAILEDTOBUILD.txt.gz

Right now lxd just crashes when this file doesn't exist. What should happen when it is absent?

Rather than do it on the first network connection.

Showing a spinner or something similar would be nice.

I made an attempt, this is my log:
https://gist.github.com/alessioguglielmo/74b6ba3bc50e7ee452b7#file-lxdlog

I have a question. How does lxd work? Will it load a different kernel for each instance launched?

When spawning exec without websocket, it'd be nice to have an extra flag in the API which would have the server capture stdout and stderr and make them available through the operation entry.

Right now, as far as I know every code path writes a valid lxd response. However, since our Command API doesn't force methods to return anything, we really have no way of enforcing this. We should invent some Response type thunk that knows how to generate the right response and return that, thus forcing each code path to generate a real response (and also getting rid of a bunch of ugly blank returns everywhere).

The line 80 and 81 in ./specs/rest-api.md are the same (except intendation).

Is something missing from line 81 or can it be removed?

All get operations should return an etag which is tied to the static status of the resource (so the etag for a container should change if its config changes but not if its status does) and any change operation providing an etag will have that etag checked against the current one with the change only being applied if they do.

This is to avoid the case where the configuration changed between the time it's grabbed and the time it's pushed back (such as having two clients doing the same operation).

ETAG is an HTTP standard initially designed for web caching.

Exploring the cli, I ran lxc config trust and it dumped stack.

Reproduce:

1. get lxd, deps and build it with make, then run
   ~/go/bin/lxd --debug --tcp 127.0.0.1:8443
2. ~/go/bin/lxc config trust

Error Output:
% ~/go/bin/lxc config trust
panic: runtime error: index out of range

goroutine 16 [running]:
runtime.panic(0x736880, 0xb2db9c)
/usr/lib/go/src/pkg/runtime/panic.c:279 +0xf5
main.(*configCmd).run(0xc208000c10, 0xc20804c340, 0xc208000c80, 0x1, 0x1, 0x0, 0x0)
/home/rharper/go/src/github.com/lxc/lxd/lxc/config.go:52 +0xf88
main.run(0x0, 0x0)
/home/rharper/go/src/github.com/lxc/lxd/lxc/main.go:63 +0x74e
main.main()
/home/rharper/go/src/github.com/lxc/lxd/lxc/main.go:15 +0x26

goroutine 19 [finalizer wait]:
runtime.park(0x420990, 0xb43230, 0xb2fe49)
/usr/lib/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0xb43230, 0xb2fe49)
/usr/lib/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
/usr/lib/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
/usr/lib/go/src/pkg/runtime/proc.c:1445

goroutine 17 [syscall]:
runtime.goexit()
/usr/lib/go/src/pkg/runtime/proc.c:1445

go get -v github.com/lxc/lxd/...
github.com/lxc/lxd
# github.com/lxc/lxd
./client.go:240: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:241: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:246: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:247: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:248: resp.TLS undefined (type *http.Response has no field or method TLS)

Using 16765fa from master

I believe we agreed that freeze/unfreeze wasn't very likely to be useful to the normal user and that those were likely to be more confusing than anything else. So while they do make a lot of sense in the API, we shouldn't have them in the client tool at this point.

This includes implementing the /1.0/profiles API to create/query/modify/delete profiles as well as being able to add/remove profiles from containers.

This also includes the "lxc config profile" commands.

Implement our internal database.

It'd be nice if we had a way to turn profiles into security groups which would then setup the appropriate apparmor rules and use different uid/gid maps to properly isolate those containers.

This includes:

• Update the REST API to match the spec wrt "config" and "devices"
• Implement the "lxc config devices" commands
• Implement the "lxc config edit" command

I think instead of using "make" we should suggest using more go-like approach for "Building the tools" section. Maybe something like this;

[root@eleksi:~] mkdir go
[root@eleksi:~] export GOPATH=/root/go
[root@eleksi:~] go get github.com/lxc/lxd/lxc
[root@eleksi:~] go get github.com/lxc/lxd/lxd
[root@eleksi:~] ls go/bin/
lxc  lxd
[root@eleksi:~]

I could send a pull request if you are OK with this "go get" way.

Hi all, I think that lxc remote just need to do some simple jobs as in git remote, instead of bothering itself with some cert things, which should be put to some other place.

Here's my reason:

1. lxc remote add needs time (at least after a successful '/ping' and possibly '/trust/add') to finish its work, which can be time consuming under certain conditions. Also note that one can remove this client cert from lxd server anytime they want.

2. consider this, the container will be started on www.example.com? (line 242 of client.go)

   $ lxc remote add myhost www.example.com
   $ lxc remote set-default myhost
   $ lxc remote rename myhost unix:whatever    # weird name, but it's right, for now
   $ lxc start container
   

3. Moreover, people can change the config file $HOME/.lxd/config.yaml to anything, as long as it is legal, literally.

So we should not totally rely on Config, and also not try to do some initial stuff or check it's correctness too early! It only adds complexity.

In my opinion, lxc remote just need to check if the argument is invalid or duplicated, then add/remove/rename on the map. Other jobs like '/ping', '/trust/add' ... be done only when requested or needed.

Container creation currently only works for ubuntu trusty containers using the download template.

In order to properly support container creation, we'll need image stores.

Please see the specs document for details.

This function will take a filesystem path, a uid map and a gid map and shift the filesystem accordingly.

Try to make it look more like lxc-ls -f

We need a spec for profiles, in particular:

• what meta-keys are we going to allow? e.g. resources.memory = 25%
• we're storing these in a DB (i.e. not in the LXC config file), so what does the schema look like (this is probably pretty simple)
• what happens if someone sets a lxc.foo key instead of one of our predefined ones above? I guess we want to provide some way to set (and get?) arbitrary lxc.* keys, perhaps it is via this mechanism.

Running from stock ubuntu 14.04, with git and go installed.

The commands I followed from stock:

trusty-64:~$ sudo apt-get -y install git golang > /dev/null
trusty-64:~$ mkdir -p ~/sources/bin
trusty-64:~$ export GOPATH=~/sources
trusty-64:~$ export GOBIN=$GOPATH/bin
trusty-64:~$ go get github.com/lxc/lxd
trusty-64:~$ cd $GOPATH/src/github.com/lxc/lxd
trusty-64:~/sources/src/github.com/lxc/lxd$ go build
trusty-64:~/sources/src/github.com/lxc/lxd$ ????
trusty-64:~/sources/src/github.com/lxc/lxd$ go build -x
WORK=/tmp/go-build043807985

the last command being explicit with what go build is doing, which is defining a variable called WORK and then doing nothing.

I would expect running go get ../... at some point or installing pkg-config

and presumably LXC should be on the system as well? sudo apt-get install lxc ?

or compile from source?

Following the guide in the readme.md. After installing via the ppa on 14.04 and with the lxd daemon running the lxc create foo just lists the -h output which also doesn't include a create.

If so, then please add the feature label and assign it to me. I'll add it to the spec and implement it.

In order to make sure things don't regress, we should introduce a testsuite as soon as possible which tests the various bits of the REST API.

Where that makes sense, we should also have scripts to sanity check our code.

The testsuite would be run on Jenkins where we can actually start containers, the sanity check scripts would be run by Travis so pull requests that do not pass are marked appropriately.

Reproduce steps on trusty amd64 host:

1. export GOPATH=$HOME/go
2. go get github.com/lxc/lxd
3. cd $GOPATH/src/github.com/lxc/lxd
4. go get -v -d ./...
5. make

Error Output:

% make
go install -v ./...
github.com/lxc/lxd
github.com/lxc/lxd/fuidshift
github.com/lxc/lxd/internal/gnuflag
golang.org/x/crypto/ssh/terminal
# github.com/lxc/lxd
./client.go:223: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:224: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:229: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:230: resp.TLS undefined (type *http.Response has no field or method TLS)
./client.go:231: resp.TLS undefined (type *http.Response has no field or method TLS)
code.google.com/p/go-uuid/uuid
github.com/dustinkirkland/golang-petname
github.com/gorilla/context
github.com/gorilla/mux
github.com/kr/pty
golang.org/x/crypto/pbkdf2
golang.org/x/crypto/scrypt
gopkg.in/tomb.v2
make: *** [default] Error 2
(foudres) lxd % echo $?
2

After a container starts (even if that container is stopped), lxd can't be ^C'd. We should probably either not allow it at all, or allow it always and kill all the containers if it is ^C'd. I prefer the second option.

Right now there's no way to implement the restore command using the rest API, since it doesn't describe how to restore containers from snapshots.