** Summary changed:
- OVF references Scott Moser's private HTTP server
+ OVF property description references Scott Moser's private HTTP server
** Changed in: cloud-init
Status: New => In Progress
** Changed in: cloud-init
Assignee: (unassigned) => Dan Watkins (daniel-thew
Public bug reported:
There's no reason for it to continue rendering the old version when we
support v2.
(Once [0] lands, this will also require modifications to the Oracle data
source, which merges its own network configuration into the one
generated from the initramfs.)
[0]
Public bug reported:
At the moment, there are some places where we do something along the
lines of `bool_thing = self.ds_cfg.get("cfg_option", False)`. This is
incorrect, because specifying anything other than the empty string in
configuration (such as "no" or "false") will result in a True-ish
On Fri, Aug 09, 2019 at 02:14:32PM -, Scott Moser wrote:
> I know I've talked to Chad and Ryan before about this, but I kind of
> see the plethora of values that are accepted as bad design (my bad
> design).
> Ultimately, I'd rather deprecate and remove that functionality than
> extend it to
Public bug reported:
YAML has native support for boolean values, and YAML has been around
long enough that it's reasonable to expect people to know how to write
it.
We should phase out accepting multiple string values ("yes", "1",
"true", "on" for True; "no", "0", "false", "off" for False) in
Hi,
Thanks for using cloud-init and filing this bug report! This behaviour
is designed to protect users from a common mistake: capturing an
instance as an image and therefore ending up with the same SSH host keys
across multiple instances. For the vast majority of users, this is the
sensible
** Changed in: cloud-init (Ubuntu)
Status: New => Invalid
** Changed in: cloud-init
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
** Changed in: cloud-init (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
Hi Amy et al,
I'm going to mark this Fix Released, as 19.1 has made its way in to
Ubuntu. Please let us know if you don't think this is fixed!
Dan
** Changed in: cloud-init (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Hi shine,
Thanks for the additional information. It looks to me like these keys
aren't valid; both of them are missing a leading "-" on their first
line, which causes gpg to not be able to operate on them. For example,
comparing the Rabbit key to the one provided upstream:
# diff their.gpg
Hi Orestes,
To work around this problem, you'll need to configure ds-identify[0] to
change its defaults. You should be able to do this by creating a file
named /etc/cloud/ds-identify.cfg and putting this in there:
datasource: Ec2
This will configure ds-identify to disable its usual
Public bug reported:
When working through bug 1837927, I had to go read the header (and
actual source code) of ds-identify to determine what the correct
configuration to apply was. We should include the ds-identify
configuration options in the regular cloud-init documentation.
** Affects:
The lack of events is not the issue. We see all the events from the
kernel that we would expect to see during a resize, and we see the same
number (and type) of events on both the passing and the failing
instances.
The problem is that if udev processes the sda1 event first then, at
least some of
This looks like an incorrect pylint warning to me. `schema` is in the
module namespace in test_snap.py, but `schema = schema` binds the value
of the module-level `schema` to `schema` on the test class. This is
required because self.assertSchemaValid refers to `self.schema`.
I'm going to look at
Public bug reported:
What does "across an instance" mean?
** Affects: cloud-init
Importance: Undecided
Assignee: Dan Watkins (daniel-thewatkins)
Status: New
** Changed in: cloud-init
Assignee: (unassigned) => Dan Watkins (daniel-thewatkins)
--
You rece
Go team!
** Changed in: cloud-init
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1722959
Title:
Implement Key-Value Pair Telemetry for
Hi Nicklas,
Thanks for the extra info! This sounds like an issue with blkid (and/or
your system), rather than a cloud-init bug. I've added a util-linux bug
task (which is the package that ships blkid), and I'm going to mark the
cloud-init bug task Invalid as I don't believe that there's
Hi!
I believe this is an issue with ifupdown, rather than cloud-init. As
such, I've added an ifupdown task and marked cloud-init's task as
Invalid. If it's determined that we won't fix this in ifupdown, then
please move the cloud-init task back to New and we can consider working
around this in
Hi! I don't think this is a bug with cloud-init, so I'm going to mark
this as Invalid. Please file a bug against Ubuntu generally if you
still are seeing this issue.
Thanks!
Dan
--
Google Translate / Traductor de google:
¡Hola! No creo que esto sea un error con cloud-init, así que voy a
*** This bug is a duplicate of bug 1834190 ***
https://bugs.launchpad.net/bugs/1834190
Hi Anisse,
Thanks for using cloud-init, and for taking the time to file a bug! I'm
going to mark this as a duplicate of bug 1834190, as the source of the
issue is snapd.seeded being unacceptably slow.
** Also affects: cloud-init (Ubuntu Eoan)
Importance: Critical
Assignee: Dan Watkins (daniel-thewatkins)
Status: In Progress
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Disco)
Importance: Undecided
Public bug reported:
== Release Notes ==
Cloud-init release 20.1 is now available
The 20.1 release:
* spanned about 9 weeks
* had 19 contributors from 19 domains
* fixed 13 Launchpad issues
Highlights:
- Python 2 support has been dropped
- A number of FreeBSD improvements landed
- Two
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1853160
Title:
uptime code does not work on FreeBSD with python
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Released
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Released
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Released
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: In Progress => Fix Released
--
You received this bug notification because you are a member
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of
Public bug reported:
The default configuration should work for developers, and therefore
shouldn't assume write access to a directory that is (a) outside of the
cloud-init tree, and (b) generally requires root privs to create in the
first place.
The specific error:
2020-02-18 18:11:21,652 -
Hi Vasili,
>From a cloud-init perspective, there isn't anything we can do so I'm
going to move the upstream task to Invalid too. I'm afraid I don't
really have any advice on how to proceed, as this appears to be a
hypervisor or cloud issue.
Dan
** Changed in: cloud-init
Status: New =>
Public bug reported:
It should appear on
https://cloudinit.readthedocs.io/en/latest/topics/modules.html but it
doesn't.
If I run `tox -e doc` locally, it _is_ included, which suggests this is
an issue with our ReadTheDocs generation specifically, not the docs in
general.
** Affects: cloud-init
Public bug reported:
e.g. https://launchpadlibrarian.net/468666983/buildlog_ubuntu-xenial-
amd64.cloud-
init_20.1-2345-gd5dbbd1-0ubuntu1+1465~trunk~ubuntu16.04.1_BUILDING.txt.gz
http_proxy= make PYVER=python3 check
make[2]: Entering directory '/<>'
python3 -m pytest -v tests/unittests cloudinit
** Changed in: cloud-init
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1867043
Title:
Daily builds failing due to missing pytest
Status
** Also affects: open-iscsi (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
cle.py#L194-L198,
we can see that this path is only taken if _is_iscsi_root returns False.
** Affects: cloud-init
Importance: Undecided
Assignee: Dan Watkins (daniel-thewatkins)
Status: In Progress
** Changed in: cloud-init
Assignee: (unassigned) => Dan Watkins (daniel-thewatkins
Ryan has started work on this, moving to In Progress.
** Changed in: cloud-init
Status: Invalid => Triaged
** Changed in: cloud-init
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Assignee: Dan Watkins (daniel-thewatkins)
Status: New
** Changed in: cloud-init
Assignee: (unassigned) => Dan Watkins (daniel-thewatkins)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
ht
Actually I think that may have been a red herring, I think "-
name:trent" was the actual problem: that's parsed as ["name:trent"], not
{"name": "trent"}. Which then means that the parser expects the
following line to be a list item, and it's a mapping item, hence the
blow up.
Regardless, glad
Public bug reported:
In OpenSSH 8.2[0], support for Include directives in ssh_config and
sshd_config was introduced. In Debian/Ubuntu version 1:8.2p1-1 [1],
Include directives were added to the config files shipped in the package
(and in 1:8.2p1-4, the directories themselves were added).
Where
Public bug reported:
In OpenSSH 8.2[0], support for Include directives in ssh_config and
sshd_config was introduced. In Debian/Ubuntu version 1:8.2p1-1 [1],
Include directives were added to the config files shipped in the package
(and in 1:8.2p1-4, the directories themselves were added).
cloud-init isn't the source of this configuration, so I'm marking our
task Incomplete and adding subiquity (which I believe generates this
config).
(Regardless, I've responded to a couple of things below for background.)
> I think with the right tooling (ip, ifconfig, ethtool or even the
Public bug reported:
It is currently implemented as a namedtuple, because it was written when
the codebase supported Python 2 (where using an enum would have
introduced a new dependency). As enum is in the stdlib in all our
supported Python releases, we can now use it without that constraint.
Public bug reported:
Currently we run cloud-init's unit tests twice in Travis:
* once on Python 3.6 with the latest versions of our dependencies from PyPI, and
* once on Python 3.5 with the versions of our dependencies that are in xenial
(but installed from PyPI, rather than apt)
We currently
OK, a binary wasn't relocated, but the dependency from util-linux ->
fdisk was dropped (in https://launchpad.net/ubuntu/+source/util-
linux/2.34-0.1ubuntu3):
util-linux (2.34-0.1ubuntu3) focal; urgency=medium
* Drop dependency from util-linux to fdisk. The transition to split-out
fdisk
Public bug reported:
When running `cloud-init analyze show` against a log file from an Amazon
Linux 2 instance (e.g. https://pastebin.com/uhJNysgm), no useful output
is produced:
$ cloud-init analyze show -i ~/Downloads/uhJNysgm.txt
-- Boot Record 01 --
The total time elapsed since completing an
Public bug reported:
This is a more general version of bug 1876323: `cloud-init analyze`
relies on the log format that upstream ships in order to detect log
lines. This means that if logging configuration by users or downstream
packagers diverges (as is the case on Amazon Linux 2, for example),
Public bug reported:
When run on the log output from Amazon Linux 2 (see bug 1876323),
`analyze` fails to find any log lines to process. Currently, it treats
this as a normal situation and emits:
$ cloud-init analyze show -i ~/Downloads/uhJNysgm.txt
-- Boot Record 01 --
The total time elapsed
Public bug reported:
Currently users may see failures if using upper-case MAC addresses in
network configuration, because cloud-init does not appropriately
normalise the case of MAC addresses in all situations.
https://cloudinit.readthedocs.io/en/latest/topics/network-config-
format-v2.html
Public bug reported:
When using the new snap.commands schema (introduced in
https://github.com/canonical/cloud-init/pull/364), it's possible to
trigger a bug in our assertion code. Specifically, this file will fail
validation (correctly, because `123` is an integer and not a string):
Public bug reported:
Between 3.0.3 (the lxd version in bionic) and 4.0.3 (the lxd version in
focal), lxd has addressed an internal accounting bug regarding network
interfaces and profiles.
Specifically, this means that after `lxd init --auto --storage-backend
dir` on each system, we see
Hey folks, I believe that this has been fixed in cloud-init 20.3
(specifically this commit: https://github.com/canonical/cloud-
init/commit/0755cff078d5931e1d8e151bdcb84afb92bc0f02) so I'm going to
move this to Fix Released.
If you are seeing this error on an earlier version of cloud-init, it
Public bug reported:
On a lxd container, which uses the NoCloud datasource[0], the only place
where "NoCloud" is queryable is in `datasource_list`:
# cloud-init query -a | grep -B1 -A2 NoCloud
"datasource_list": [
"NoCloud",
"None"
],
With ds-identify enabled, you probably _can_ take
Public bug reported:
cc_final_message calls util.write_file, which calls ensure_dir; if
nothing has caused the symlink to be created, then this means that
/var/lib/cloud/instance will be a directory, and future boots will fail
because they fail to remove it (because it's a directory, so can't
** No longer affects: cloud-init
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1124384
Title:
Configuration reload clears event that others jobs may be waiting on
Status in
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug report is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the named
function. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
Public bug reported:
This bug is tracking part of the refactor of cloudinit.net into
cloudinit.distros.networking, specifically the refactoring of the function
named in the title of this bug. See [0] for further details.
[0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
As this is a doc bug and the fix is available on ReadTheDocs, I'm going
to mark this Fix Released.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
This function is actually unused, so we're dropping it in
https://github.com/canonical/cloud-init/pull/453.
** Changed in: cloud-init
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
This function is actually unused, so we're dropping it in
https://github.com/canonical/cloud-init/pull/453.
** Changed in: cloud-init
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
This function is actually unused, so we're dropping it in
https://github.com/canonical/cloud-init/pull/453.
** Changed in: cloud-init
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
Public bug reported:
This makes it difficult to use with a function that needs to take more
than a single positional parameter, or any keyword arguments; you have
to partially apply the function before calling mount_cb.
I propose adding `args` and `kwargs` parameters, which will be passed to
the
Public bug reported:
The tmpdir creation happens before (and around, as a contextmanager) the
determination of whether or not a mount will be needed. This could be
improved.
** Affects: cloud-init
Importance: Wishlist
Status: New
--
You received this bug notification because you
OK, it sounds like cloud-init is behaving as we expect it to, so I'm
going to mark our task as Invalid. Do comment (and change status to
New, if you can) if you think that's incorrect.
** Changed in: cloud-init
Status: Confirmed => Invalid
--
You received this bug notification because
101 - 200 of 229 matches
Mail list logo
