| 2017-05-18 14:23:03 |
Scott Moser |
bug |
|
|
added bug |
| 2017-05-18 14:23:10 |
Scott Moser |
cloud-init: status |
New |
Confirmed |
|
| 2017-05-18 14:23:13 |
Scott Moser |
cloud-init: importance |
Undecided |
Medium |
|
| 2017-07-31 20:23:16 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2017-07-31 20:23:24 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Fix Released |
|
| 2017-07-31 20:23:27 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-07-31 20:23:45 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-07-31 20:23:45 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2017-07-31 20:23:45 |
Scott Moser |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-07-31 20:23:45 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Zesty) |
|
| 2017-07-31 20:24:51 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-07-31 20:24:54 |
Scott Moser |
cloud-init (Ubuntu Zesty): status |
New |
Confirmed |
|
| 2017-07-31 20:24:57 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-07-31 20:24:59 |
Scott Moser |
cloud-init (Ubuntu Zesty): importance |
Undecided |
Medium |
|
| 2017-08-02 02:28:18 |
Scott Moser |
description |
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12 |
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No Cloud" fashion an easier way to regain that functionality.
The solution was to read the 'system-serial-number' field in DMI data and
consider it as as input to the nocloud datasource in a similar way to
what we had done in the past with the kernel command line.
[Test Case]
FIXME
[Regression Potential]
The code attempts to parse the 'system-serial-number' entry in dmi data as string with data in it. If that field had the string 'ds=nocloud' that was not intended as consumable for cloud-init, a false positive could occur and an exception cause the NoCloud datasource to not read data from another location.
This seems somewhat unlikely and other paths should result in simply no
new action being taken.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
=== End SRU Template ===
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12 |
|
| 2017-08-02 15:00:21 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No Cloud" fashion an easier way to regain that functionality.
The solution was to read the 'system-serial-number' field in DMI data and
consider it as as input to the nocloud datasource in a similar way to
what we had done in the past with the kernel command line.
[Test Case]
FIXME
[Regression Potential]
The code attempts to parse the 'system-serial-number' entry in dmi data as string with data in it. If that field had the string 'ds=nocloud' that was not intended as consumable for cloud-init, a false positive could occur and an exception cause the NoCloud datasource to not read data from another location.
This seems somewhat unlikely and other paths should result in simply no
new action being taken.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
=== End SRU Template ===
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12 |
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No Cloud" fashion an easier way to regain that functionality.
The solution was to read the 'system-serial-number' field in DMI data and
consider it as as input to the nocloud datasource in a similar way to
what we had done in the past with the kernel command line.
[Test Case]
a.) download a cloud image, update its cloud-init
# see below for 'get-proposed-cloudimg'
$ release=xenial
$ get-proposed-cloudimg $release
b.) boot that image with command line pointing at a 'seed'
$ img=${release}-server-cloudimg-amd64-proposed.img
# url has to provide '<url>/user-data' and '<url>/meta-data'
$ url=https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/
$ qemu-system-x86_64 -snapshot -enable-kvm -m 512 \
-device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 \
-drive "file=$img,if=virtio" \
-smbios "type=1,serial=ds=nocloud-net;seedfrom=$url" \
-nographic
# note, you can hit 'ctrl-a c' to toggle between the qemu monitor
# and the serial console in '-nographic' mode.
c.) Log in with 'ubuntu:passw0rd' and check hostname.
If the above url was correctly used, then:
* you can log in with 'ubuntu:passw0rd'
* the hostname will be set to 'nocloud-guest'
* /run/cloud-init/result.json will show that the url has been used.
ubuntu@nocloud-guest:~$ hostname
nocloud-guest
ubuntu@nocloud-guest$ cat /run/cloud-init/result.json
{
"v1": {
"datasource": "DataSourceNoCloudNet [seed=dmi,https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/][dsmode=net]",
"errors": []
}
}
[Regression Potential]
The code attempts to parse the 'system-serial-number' entry in dmi data as a
string with data in it. If that field had the string 'ds=nocloud' that was
not intended as consumable for cloud-init, a false positive could occur and
an exception cause the NoCloud datasource to not read data from another
location.
This seems somewhat unlikely and other paths should result in simply no
new action being taken.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
get-proposed-cloudimg is available at [1], it basically downloads an
ubuntu cloud image, enables -proposed and upgrade/installs cloud-init.
--
[1] https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/get-proposed-cloudimg
=== End SRU Template ===
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12 |
|
| 2017-08-04 01:01:51 |
Brian Murray |
cloud-init: status |
Confirmed |
Fix Released |
|
| 2017-08-04 13:47:31 |
Scott Moser |
cloud-init: status |
Fix Released |
Fix Committed |
|
| 2017-08-23 12:28:02 |
Chris J Arges |
cloud-init (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2017-08-23 12:28:04 |
Chris J Arges |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-08-23 12:28:05 |
Chris J Arges |
bug |
|
|
added subscriber SRU Verification |
| 2017-08-23 12:28:09 |
Chris J Arges |
tags |
|
verification-needed verification-needed-xenial |
|
| 2017-08-23 12:31:26 |
Chris J Arges |
cloud-init (Ubuntu Zesty): status |
Confirmed |
Fix Committed |
|
| 2017-08-23 12:31:30 |
Chris J Arges |
tags |
verification-needed verification-needed-xenial |
verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-08-28 20:44:45 |
Chad Smith |
tags |
verification-needed verification-needed-xenial verification-needed-zesty |
verification-done-xenial verification-done-zesty |
|
| 2017-09-13 01:26:05 |
Launchpad Janitor |
cloud-init (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-09-13 01:26:40 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-09-13 01:27:27 |
Launchpad Janitor |
cloud-init (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-09-23 02:32:54 |
Scott Moser |
cloud-init: status |
Fix Committed |
Fix Released |
|
| 2020-05-20 17:10:51 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No Cloud" fashion an easier way to regain that functionality.
The solution was to read the 'system-serial-number' field in DMI data and
consider it as as input to the nocloud datasource in a similar way to
what we had done in the past with the kernel command line.
[Test Case]
a.) download a cloud image, update its cloud-init
# see below for 'get-proposed-cloudimg'
$ release=xenial
$ get-proposed-cloudimg $release
b.) boot that image with command line pointing at a 'seed'
$ img=${release}-server-cloudimg-amd64-proposed.img
# url has to provide '<url>/user-data' and '<url>/meta-data'
$ url=https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/
$ qemu-system-x86_64 -snapshot -enable-kvm -m 512 \
-device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 \
-drive "file=$img,if=virtio" \
-smbios "type=1,serial=ds=nocloud-net;seedfrom=$url" \
-nographic
# note, you can hit 'ctrl-a c' to toggle between the qemu monitor
# and the serial console in '-nographic' mode.
c.) Log in with 'ubuntu:passw0rd' and check hostname.
If the above url was correctly used, then:
* you can log in with 'ubuntu:passw0rd'
* the hostname will be set to 'nocloud-guest'
* /run/cloud-init/result.json will show that the url has been used.
ubuntu@nocloud-guest:~$ hostname
nocloud-guest
ubuntu@nocloud-guest$ cat /run/cloud-init/result.json
{
"v1": {
"datasource": "DataSourceNoCloudNet [seed=dmi,https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/][dsmode=net]",
"errors": []
}
}
[Regression Potential]
The code attempts to parse the 'system-serial-number' entry in dmi data as a
string with data in it. If that field had the string 'ds=nocloud' that was
not intended as consumable for cloud-init, a false positive could occur and
an exception cause the NoCloud datasource to not read data from another
location.
This seems somewhat unlikely and other paths should result in simply no
new action being taken.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
get-proposed-cloudimg is available at [1], it basically downloads an
ubuntu cloud image, enables -proposed and upgrade/installs cloud-init.
--
[1] https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/get-proposed-cloudimg
=== End SRU Template ===
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12 |
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No Cloud" fashion an easier way to regain that functionality.
The solution was to read the 'system-serial-number' field in DMI data and
consider it as as input to the nocloud datasource in a similar way to
what we had done in the past with the kernel command line.
[Test Case]
a.) download a cloud image, update its cloud-init
# see below for 'get-proposed-cloudimg'
$ release=xenial
$ get-proposed-cloudimg $release
b.) boot that image with command line pointing at a 'seed'
$ img=${release}-server-cloudimg-amd64-proposed.img
# url has to provide '<url>/user-data' and '<url>/meta-data'
$ url=https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/
$ qemu-system-x86_64 -snapshot -enable-kvm -m 512 \
-device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 \
-drive "file=$img,if=virtio" \
-smbios "type=1,serial=ds=nocloud-net;seedfrom=$url" \
-nographic
# note, you can hit 'ctrl-a c' to toggle between the qemu monitor
# and the serial console in '-nographic' mode.
c.) Log in with 'ubuntu:passw0rd' and check hostname.
If the above url was correctly used, then:
* you can log in with 'ubuntu:passw0rd'
* the hostname will be set to 'nocloud-guest'
* /run/cloud-init/result.json will show that the url has been used.
ubuntu@nocloud-guest:~$ hostname
nocloud-guest
ubuntu@nocloud-guest$ cat /run/cloud-init/result.json
{
"v1": {
"datasource": "DataSourceNoCloudNet [seed=dmi,https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/][dsmode=net]",
"errors": []
}
}
[Regression Potential]
The code attempts to parse the 'system-serial-number' entry in dmi data as a
string with data in it. If that field had the string 'ds=nocloud' that was
not intended as consumable for cloud-init, a false positive could occur and
an exception cause the NoCloud datasource to not read data from another
location.
This seems somewhat unlikely and other paths should result in simply no
new action being taken.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
get-proposed-cloudimg is available at [1], it basically downloads an
ubuntu cloud image, enables -proposed and upgrade/installs cloud-init.
--
[1] https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/get-proposed-cloudimg
=== End SRU Template ===
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12
Related bugs:
* bug 1879294: Support fw_cfg data source
* bug 1753558: NoCloud should use "OEM Strings" instead of
system-serial-number
* bug 1691772: provide a way to seed NoCloud from network without image modification. |
|
| 2023-05-11 01:53:49 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/2895 |
|
