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

Import LXD changes #181

Merged
merged 19 commits into from
Oct 20, 2023
Merged

Import LXD changes #181

merged 19 commits into from
Oct 20, 2023

Conversation

stgraber
Copy link
Member

No description provided.

MusicDin and others added 19 commits October 19, 2023 23:18
…on w/o volume snapshots

Signed-off-by: Din Music <din.music@canonical.com>
Signed-off-by: Din Music <din.music@canonical.com>
…perations.

The ResponseHeaderTimeout in the http.Transport for the client was, in
most cases, set to 1 hour throughout the codebase. This change unsets
the timeout, allowing us to wait for an operation to complete
indefinitely.

Signed-off-by: Mark Laing <mark.laing@canonical.com>
…nly flag

Signed-off-by: Din Music <din.music@canonical.com>
Signed-off-by: Din Music <din.music@canonical.com>
…xc/lxc-git-master

Let's be consistent with go-incus [1] and use ppa:ubuntu-lxc/daily to fetch
and install development build of liblxc.

I have checked that builds in ppa:ubuntu-lxc/daily and ppa:ubuntu-lxc/lxc-git-master
right now are equal. Likely we need to get rid of ubuntu-lxc/lxc-git-master at some point,
but as a first step let's just start using ubuntu-lxc/daily for Incus CI builds.

[1] https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/.github/workflows/test.yml#L29

Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
…sock module not being fully initialised

Sometimes we were seeing the initial vsock context ID of 4294967295 (equivalent to VMADDR_CID_ANY)
and then a few seconds later the context ID was returning the valid context ID for the VM.

This was previously causing the vsock listener to be restarted 30s after the VM booted, which if
there were any exec sessions ongoing would cause them to be terminated.

This fixes the issue by waiting for a valid vsock ID and ignoring the value 4294967295.

Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
…k listener is restarted just after boot

This PR switches the lxd-agent vsock listener to use the VMADDR_CID_ANY (4294967295) CID,
rather than trying to ascertain the VM's local CID and listening only on that.

The reason is two-fold:

 1. We were seeing that sometimes the vsock.ContextID() call was returning 4294967295 just
    after the vsock module was loaded, but shortly afterward then started returning the
    correct CID assigned in QEMU. This would trigger the vsock CID change detector up to 30s
    later and cause the vsock listener to be restarted. Any ongoing exec operations that had
    started before that would be prematurely terminated. The vsock VID change detector was
    originally added to detect when a VM was statefully restored/migrated in such a way that
    its QEMU assigned CID was changed whilst the VM was running. This prevented Incus from
    using the lxd-agent until such time as the lxd-agent noticed its local CID had changed
    and restarted its listener on the new CID.

 2. However it was observed during investigating this issue that if we bound the lxd-agent
    listener to the VMADDR_CID_ANY (4294967295) CID then this continue to work even if the VM
    was statefully restored using a different CID. This is because the VMADDR_CID_ANY seems
    to be used as a kind of wildcard CID. The vsock manpage says:

     Consider using VMADDR_CID_ANY when binding instead of getting the local CID with
     IOCTL_VM_SOCKETS_GET_LOCAL_CID.

     There are several special addresses: VMADDR_CID_ANY (-1U) means any address for binding;

By binding to the VMADDR_CID_ANY address it also allows us to simplify the vsock listener logic
and remove the vsock CID change detector entirely, neatly sidestepping the original problem.

Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
Go's net.URL requires Path to be populated with unencoded path and
RawPath to be populated with the hint on how we want Path to be
encoded.

This avoids double path encoding when calling url.EscapedPath(),
which is used in url.String().

Fixes #12398

Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
…nces are to be deleted

Signed-off-by: Gabriel Mougard <gabriel.mougard@canonical.com>
Signed-off-by: Gabriel Mougard <gabriel.mougard@canonical.com>
… member name is set

This fixes a regression introduced in https://github.com/lxc/incus/pull/12348
which causes the `--destination-target` flag to be ignored.

When renaming a volume using `incus storage volume move`, the args were
passed to the handler behind `incus storage volume rename` which does not
support the `--destination-target` flag.

Instead if the destination flag is set when renaming a volume, use the handler for volume movements.

Signed-off-by: Julian Pelizäus <julian.pelizaeus@canonical.com>
Signed-off-by: Julian Pelizäus <julian.pelizaeus@canonical.com>
…ilure of a proxy listen address an error

Fixes #12368

Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
If dependabot creates new PRs, those are not originating from a fork.
Instead a new branch is created in the same repository which triggers
on both `push` and `pull_request`.

Limiting the push trigger to the main and release branches doesn't
anymore duplicate the jobs for dependabot PRs.

Signed-off-by: Julian Pelizäus <julian.pelizaeus@canonical.com>
…ore patches

And then reload them after patches have run in case its been modified.

Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
…atchStorageZfsUnsetInvalidBlockSettingsV2

Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
Signed-off-by: Thomas Hipp <thomas.hipp@canonical.com>
…atchStorageZfsUnsetInvalidBlockSettings

Signed-off-by: Thomas Hipp <thomas.hipp@canonical.com>
@github-actions github-actions bot added the API Changes to the REST API label Oct 20, 2023
@brauner brauner merged commit bd0ec82 into lxc:main Oct 20, 2023
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Changes to the REST API
Development

Successfully merging this pull request may close these issues.

None yet

9 participants