Utopic is already EOL, so I'm marking it as Invalid
** Changed in: cloud-init (Ubuntu Utopic)
Status: New = Invalid
** Tags added: sts
** Tags added: openstack
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in
Utopic is already EOL, so I'm marking it as Invalid
** Changed in: cloud-init (Ubuntu Utopic)
Status: New = Invalid
** Tags added: sts
** Tags added: openstack
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
cloud-init misbehaves when a vendor data json comes with information
that won't be consumed by it, a fix was added in rev 1013[0]. I
backported this patch to Trusty and prepared a patched image, having a
custom vendor data doesn't break cloud-init functionality.
I'll submit a SRU to fix this in
cloud-init misbehaves when a vendor data json comes with information
that won't be consumed by it, a fix was added in rev 1013[0]. I
backported this patch to Trusty and prepared a patched image, having a
custom vendor data doesn't break cloud-init functionality.
I'll submit a SRU to fix this in
** Description changed:
+ [Impact]
+
+ When a vendor data json provides a dictionary without a 'cloud-init'
+ key, cloud-init renders a non functional user-data, so any configuration
+ (i.e. ssh public keys to use) is missed.
+
+ This prevents cloud providers from publishing a vendor data that
** Description changed:
+ [Impact]
+
+ When a vendor data json provides a dictionary without a 'cloud-init'
+ key, cloud-init renders a non functional user-data, so any configuration
+ (i.e. ssh public keys to use) is missed.
+
+ This prevents cloud providers from publishing a vendor data that
A vendor data file should be a dict with a cloud-init key and the value
for that key is expected to be a string or a list[0], the docs provide a
simple example[1]
Here is another example that will add a user called cloudy, upgrade the
system and install htop:
{cloud-init: #cloud-config\nusers:\n
Screwed up the above script, it should be
from nova.api.metadata import base
class CustomVendordata(base.VendorDataDriver):
def __init__(self, *args, **kwargs):
super(CustomVendordata, self).__init__(*args, **kwargs)
def get(self):
return {msg: , uuid:
Screwed up the above script, it should be
from nova.api.metadata import base
class CustomVendordata(base.VendorDataDriver):
def __init__(self, *args, **kwargs):
super(CustomVendordata, self).__init__(*args, **kwargs)
def get(self):
return {msg: , uuid:
Changing the class to return a string rather than a dictionary avoids
the cloud-init explosion. That runs counter to all the documentation
that says use JSON, but it's the workaround we'll use for now
(serializing to YAML).
--
You received this bug notification because you are a member of Ubuntu
Changing the class to return a string rather than a dictionary avoids
the cloud-init explosion. That runs counter to all the documentation
that says use JSON, but it's the workaround we'll use for now
(serializing to YAML).
--
You received this bug notification because you are a member of Ubuntu
A vendor data file should be a dict with a cloud-init key and the value
for that key is expected to be a string or a list[0], the docs provide a
simple example[1]
Here is another example that will add a user called cloudy, upgrade the
system and install htop:
{cloud-init: #cloud-config\nusers:\n
Just doing something simple like
data = str(util.decomp_gzip(raw_data))
causes it to work, because data's now a string and hashable and so the
range data[0:4096] works (whether the content is actually what it's
supposed to be is another question).
--
You received this bug notification because
Just doing something simple like
data = str(util.decomp_gzip(raw_data))
causes it to work, because data's now a string and hashable and so the
range data[0:4096] works (whether the content is actually what it's
supposed to be is another question).
--
You received this bug notification because
I can reliably reproduce this issue via the following steps:
1) Create blah.py under nova/api/metadata/ with these contents:
from nova.api.metadata import base
class CustomVendordata(base.VendorDataDriver):
def __init__(self, *args, **kwargs):
super(BcpcMetadata,
I can reliably reproduce this issue via the following steps:
1) Create blah.py under nova/api/metadata/ with these contents:
from nova.api.metadata import base
class CustomVendordata(base.VendorDataDriver):
def __init__(self, *args, **kwargs):
super(BcpcMetadata,
marking trunk fix-released and ubuntu fixed-released per bug openers
suggestion that it was fixed in 0.7.7 . I have not reproduced though.
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu)
Status: New = Fix Released
**
marking trunk fix-released and ubuntu fixed-released per bug openers
suggestion that it was fixed in 0.7.7 . I have not reproduced though.
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu)
Status: New = Fix Released
**
** Changed in: cloud-init (Ubuntu Trusty)
Assignee: (unassigned) = Felipe Reyes (freyes)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1469260
Title:
Custom vendor data causes cloud-init
** Changed in: cloud-init (Ubuntu Trusty)
Assignee: (unassigned) = Felipe Reyes (freyes)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1469260
Title:
Custom vendor data
20 matches
Mail list logo
