| 2017-02-04 03:03:53 |
Scott Moser |
bug |
|
|
added bug |
| 2017-02-04 03:04:04 |
Scott Moser |
bug |
|
|
added subscriber Paul Hummer |
| 2017-02-04 03:04:09 |
Scott Moser |
bug |
|
|
added subscriber Chuck Short |
| 2017-02-04 03:04:15 |
Scott Moser |
bug |
|
|
added subscriber page james |
| 2017-02-04 03:04:19 |
Scott Moser |
removed subscriber page james |
|
|
|
| 2017-02-04 03:04:32 |
Scott Moser |
bug |
|
|
added subscriber James Page |
| 2017-02-08 14:58:13 |
Scott Moser |
bug task added |
|
nova-lxd |
|
| 2017-02-08 14:58:25 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2017-02-08 14:58:33 |
Scott Moser |
cloud-init: status |
New |
Confirmed |
|
| 2017-02-08 14:58:36 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
| 2017-02-08 14:58:39 |
Scott Moser |
nova-lxd: status |
New |
Confirmed |
|
| 2017-02-08 14:58:43 |
Scott Moser |
cloud-init: importance |
Undecided |
High |
|
| 2017-02-08 14:58:45 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
High |
|
| 2017-02-08 15:00:05 |
Scott Moser |
description |
nova-lxd uses the Openstack Network metadata service.
In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.
We need to be able to positively identify that the container we are running
inside should have access to an openstack metadata service so we can
safely assume it will be there.
How can we positively identify that a container is running in nova-lxd?
Is there anything in the environment (possibly pid 1 environ?) that we
can look at?
One way I could see doing t his would be for lxd-nova to put
CLOUD_PLATFORM='openstack-nova'
inside the pid 1 environment. then cloud-init can look at /proc/1/environ
and pick that out.
Open to other ideas, and would love it if there was something we could do.
Related bugs
bug 1660385: Alert user of Ec2 Datasource on lookalike cloud |
nova-lxd uses the Openstack Network metadata service.
In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.
We need to be able to positively identify that the container we are running
inside should have access to an openstack metadata service so we can
safely assume it will be there.
How can we positively identify that a container is running in nova-lxd?
Is there anything in the environment (possibly pid 1 environ?) that we
can look at?
One way I could see doing t his would be for lxd-nova to put
CLOUD_PLATFORM='openstack-nova'
inside the pid 1 environment. then cloud-init can look at /proc/1/environ
and pick that out.
Open to other ideas, and would love it if there was something we could do.
Related bugs
bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
bug 1661797: identify lxd-nova platform to enable Openstack datasource
bug 1661693: identify brightbox platform to enable Ec2 datasource |
|
| 2017-02-08 16:01:55 |
Jon Grimm |
bug |
|
|
added subscriber Jon Grimm |
| 2017-02-09 16:36:05 |
Scott Moser |
description |
nova-lxd uses the Openstack Network metadata service.
In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.
We need to be able to positively identify that the container we are running
inside should have access to an openstack metadata service so we can
safely assume it will be there.
How can we positively identify that a container is running in nova-lxd?
Is there anything in the environment (possibly pid 1 environ?) that we
can look at?
One way I could see doing t his would be for lxd-nova to put
CLOUD_PLATFORM='openstack-nova'
inside the pid 1 environment. then cloud-init can look at /proc/1/environ
and pick that out.
Open to other ideas, and would love it if there was something we could do.
Related bugs
bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
bug 1661797: identify lxd-nova platform to enable Openstack datasource
bug 1661693: identify brightbox platform to enable Ec2 datasource |
nova-lxd uses the Openstack Network metadata service.
In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.
We need to be able to positively identify that the container we are running
inside should have access to an openstack metadata service so we can
safely assume it will be there.
How can we positively identify that a container is running in nova-lxd?
Is there anything in the environment (possibly pid 1 environ?) that we
can look at?
One way I could see doing t his would be for lxd-nova to put
CLOUD_PLATFORM='openstack-nova'
inside the pid 1 environment. then cloud-init can look at /proc/1/environ
and pick that out.
Open to other ideas, and would love it if there was something we could do.
Related bugs
bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
bug 1661797: identify lxd-nova platform to enable Openstack datasource
bug 1661693: identify brightbox platform to enable Ec2 datasource
bug 1663304: identify openstack kvm platform on arm64 |
|
| 2017-02-09 20:31:24 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2017-02-09 20:37:34 |
Scott Moser |
cloud-init: status |
Confirmed |
Fix Committed |
|
| 2017-02-09 20:37:49 |
Scott Moser |
bug task added |
|
nova-lxd (Ubuntu) |
|
| 2017-02-09 20:38:00 |
Scott Moser |
nova-lxd (Ubuntu): status |
New |
Confirmed |
|
| 2017-02-09 20:38:03 |
Scott Moser |
nova-lxd (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-02-15 20:41:29 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-02-15 20:41:29 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2017-02-15 20:41:29 |
Scott Moser |
bug task added |
|
nova-lxd (Ubuntu Xenial) |
|
| 2017-02-15 20:41:29 |
Scott Moser |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-02-15 20:41:29 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Zesty) |
|
| 2017-02-15 20:41:29 |
Scott Moser |
bug task added |
|
nova-lxd (Ubuntu Zesty) |
|
| 2017-02-15 20:41:29 |
Scott Moser |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-02-15 20:41:29 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Yakkety) |
|
| 2017-02-15 20:41:29 |
Scott Moser |
bug task added |
|
nova-lxd (Ubuntu Yakkety) |
|
| 2017-02-15 20:42:37 |
Scott Moser |
cloud-init (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
| 2017-02-15 20:42:37 |
Scott Moser |
cloud-init (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-02-15 20:42:55 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-02-15 20:42:55 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-02-15 20:43:17 |
Scott Moser |
nova-lxd (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2017-02-15 20:43:17 |
Scott Moser |
nova-lxd (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-02-15 20:44:08 |
Scott Moser |
nova-lxd (Ubuntu Yakkety): importance |
Undecided |
High |
|
| 2017-02-15 20:44:08 |
Scott Moser |
nova-lxd (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-03-03 02:28:55 |
Scott Moser |
tags |
|
dsid |
|
| 2017-03-03 14:41:05 |
Scott Moser |
description |
nova-lxd uses the Openstack Network metadata service.
In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.
We need to be able to positively identify that the container we are running
inside should have access to an openstack metadata service so we can
safely assume it will be there.
How can we positively identify that a container is running in nova-lxd?
Is there anything in the environment (possibly pid 1 environ?) that we
can look at?
One way I could see doing t his would be for lxd-nova to put
CLOUD_PLATFORM='openstack-nova'
inside the pid 1 environment. then cloud-init can look at /proc/1/environ
and pick that out.
Open to other ideas, and would love it if there was something we could do.
Related bugs
bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
bug 1661797: identify lxd-nova platform to enable Openstack datasource
bug 1661693: identify brightbox platform to enable Ec2 datasource
bug 1663304: identify openstack kvm platform on arm64 |
nova-lxd uses the Openstack Network metadata service.
In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.
We need to be able to positively identify that the container we are running
inside should have access to an openstack metadata service so we can
safely assume it will be there.
How can we positively identify that a container is running in nova-lxd?
Is there anything in the environment (possibly pid 1 environ?) that we
can look at?
One way I could see doing t his would be for lxd-nova to put
CLOUD_PLATFORM='openstack-nova'
inside the pid 1 environment. then cloud-init can look at /proc/1/environ
and pick that out.
Open to other ideas, and would love it if there was something we could do.
Related bugs
bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
bug 1661797: identify lxd-nova platform to enable Openstack datasource
bug 1661693: identify brightbox platform to enable Ec2 datasource
bug 1663304: identify openstack kvm platform on arm64
bug 1668313: [SRU] mitaka point release |
|
| 2017-03-03 14:41:48 |
Scott Moser |
nova-lxd (Ubuntu Zesty): status |
Confirmed |
Fix Released |
|
| 2017-03-03 14:42:21 |
Scott Moser |
nova-lxd (Ubuntu Yakkety): status |
Confirmed |
In Progress |
|
| 2017-03-03 14:42:50 |
Scott Moser |
nova-lxd (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2017-03-16 10:27:27 |
James Page |
nova-lxd: importance |
Undecided |
High |
|
| 2017-03-16 10:28:16 |
James Page |
nova-lxd: status |
Confirmed |
Fix Released |
|
| 2017-03-30 11:03:33 |
Christoph |
bug |
|
|
added subscriber Christoph |
| 2017-09-23 02:15:06 |
Scott Moser |
cloud-init: status |
Fix Committed |
Fix Released |
|
| 2018-03-06 01:37:13 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto Murata |
| 2023-05-10 20:08:26 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/2799 |
|
