canonical / lxd Goto Github PK
View Code? Open in Web Editor NEWPowerful system container and virtual machine manager
Home Page: https://canonical.com/lxd
License: GNU Affero General Public License v3.0
Powerful system container and virtual machine manager
Home Page: https://canonical.com/lxd
License: GNU Affero General Public License v3.0
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.
There appears to be no guidance as to how certificates should be created, checked, and presented (how and when) to users.
Try to make it look more like lxc-ls -f
This includes:
Right now lxd just crashes when this file doesn't exist. What should happen when it is absent?
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.
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.
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?
Exploring the cli, I ran lxc config trust and it dumped stack.
Reproduce:
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
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.
We need a spec for profiles, in particular:
Current standard seems to be to use the CPU intensive bcrypt or CPU+MEM intensive scrypt instead of faster hashing methods for password.
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).
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?
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).
This function will take a filesystem path, a uid map and a gid map and shift the filesystem accordingly.
On a system that has lxd installed, on first start of lxc, the following remotes should be added:
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.
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
The usual convention for certificate is:
Rather than do it on the first network connection.
Showing a spinner or something similar would be nice.
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:
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.
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
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.
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.
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.
Implement our internal database.
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.
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.
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
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.
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.
Currently LXD fails to build on all three of those architectures.
armhf:
ppc64el:
arm64:
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
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.
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.
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.
If so, then please add the feature label and assign it to me. I'll add it to the spec and implement it.
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.
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?
Reproduce steps on trusty amd64 host:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.