** Description changed:

  [impact]
  
  "lxd launch" behavior recently changed to parse any queued input on
  stdin and process it as a yaml file.
  
  Since the "autopkgtest-build-lxd" script calls "lxd launch", and input
  queued to stdin when calling "autopkgtest-build-lxd" will cause the
  internal call to lxd to fail, such as calling "autopkgtest-build-lxd"
  from inside a here document (see test case below).
  
  the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest 
package itself, e.g.:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
  
  [test case]
  
+ root@autopkgtest:~# cat <<EOF | su - ubuntu
+ > autopkgtest-build-lxd ubuntu:bionic
+ > echo ok done
+ > EOF
+ Error: yaml: unmarshal errors:
+   line 1: cannot unmarshal !!str `echo ok...` into api.ContainerPut
+ 
+ 
  run the autopkgtests for the package 'autopkgtest', or check 
autopkgtest.ubuntu.com, e.g.:
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
  
- note that this is failing only for disco and eoan, and note that the 'lxd' 
test is skipped for non-intel archs.  this does not appear to be failing on 
bionic:
+ note that this is failing only for disco and eoan, and note that the
+ 'lxd' test is skipped for non-intel archs.
+ 
+ the autopkgtest does not fail on bionic or xenial, because the tests there 
run with the lxd deb, which is still at the older version.
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
+ 
+ However, the lxd snap can be installed in xenial or bionic, and the
+ failure is reproducable when the lxd snap is installed.
  
  [regression potential]
  
  this only redirects stdin from /dev/null, for the call to 'lxc launch'
  inside autopkgtest-build-lxd; so the regression potential should be low.
  Any regressions would almost certainly involve a failure during the call
  to autopkgtest-build-lxd, during the creation of the lxd container.
  
  [other info]
  
  this is reproducable with the current packages from disco-updates using
  a local qemu vm for testing.
  
  note that the autopkgtest fails only for disco and eoan, becuase on
  xenial and bionic the lxd deb is used, which still has the older
  behavior, however the lxd snap is available to install on both xenial
  and bionic, so this problem still exists for both those releases, as
  well as disco and eoan.
  
  also, this is not just a testcase failure - this is actual new behavior
  that can break existing users of the "autopkgtest-build-lxd" script in
  the manner described in the test case.
  
  I put the 'importance' of this as low because this bug will only be
  reproduced when calling autopkgtest-build-lxd from inside a here
  document passed to a shell, or otherwise called with input queued on
  stdin, which seems like an unusual way to call autopkgest-build-lxd.

** Description changed:

  [impact]
  
  "lxd launch" behavior recently changed to parse any queued input on
  stdin and process it as a yaml file.
  
  Since the "autopkgtest-build-lxd" script calls "lxd launch", and input
  queued to stdin when calling "autopkgtest-build-lxd" will cause the
  internal call to lxd to fail, such as calling "autopkgtest-build-lxd"
  from inside a here document (see test case below).
  
  the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest 
package itself, e.g.:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
  
  [test case]
  
  root@autopkgtest:~# cat <<EOF | su - ubuntu
  > autopkgtest-build-lxd ubuntu:bionic
  > echo ok done
  > EOF
  Error: yaml: unmarshal errors:
-   line 1: cannot unmarshal !!str `echo ok...` into api.ContainerPut
- 
+   line 1: cannot unmarshal !!str `echo ok...` into api.ContainerPut
  
  run the autopkgtests for the package 'autopkgtest', or check 
autopkgtest.ubuntu.com, e.g.:
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
  
- note that this is failing only for disco and eoan, and note that the
- 'lxd' test is skipped for non-intel archs.
+ the autopkgtest test case is failing only for disco and eoan, and only
+ for amd64/i386 as the 'lxd' test is skipped for non-intel archs.
  
- the autopkgtest does not fail on bionic or xenial, because the tests there 
run with the lxd deb, which is still at the older version.
+ the autopkgtest test case does not fail on bionic or xenial, because the 
tests there run with the lxd deb, which is still at the older version.
  http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
  
  However, the lxd snap can be installed in xenial or bionic, and the
- failure is reproducable when the lxd snap is installed.
+ failure is reproducable when the lxd snap is installed, i.e.:
+ 
+ $ sudo apt remove lxd
+ $ sudo snap install lxd
+ ...perform test case
  
  [regression potential]
  
  this only redirects stdin from /dev/null, for the call to 'lxc launch'
  inside autopkgtest-build-lxd; so the regression potential should be low.
  Any regressions would almost certainly involve a failure during the call
  to autopkgtest-build-lxd, during the creation of the lxd container.
  
  [other info]
  
  this is reproducable with the current packages from disco-updates using
  a local qemu vm for testing.
  
  note that the autopkgtest fails only for disco and eoan, becuase on
  xenial and bionic the lxd deb is used, which still has the older
  behavior, however the lxd snap is available to install on both xenial
  and bionic, so this problem still exists for both those releases, as
  well as disco and eoan.
  
  also, this is not just a testcase failure - this is actual new behavior
  that can break existing users of the "autopkgtest-build-lxd" script in
  the manner described in the test case.
  
  I put the 'importance' of this as low because this bug will only be
  reproduced when calling autopkgtest-build-lxd from inside a here
  document passed to a shell, or otherwise called with input queued on
- stdin, which seems like an unusual way to call autopkgest-build-lxd.
+ stdin, which seems like an unusual way to call autopkgest-build-lxd,
+ although still a perfectly valid way to use it.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1845037

Title:
  autopkgtest package "lxd" test has started failing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1845037/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to