identify lxd-nova platform to enable Openstack datasource
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
Unassigned | ||
nova-lxd |
Fix Released
|
High
|
Unassigned | ||
cloud-init (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Xenial |
Confirmed
|
Medium
|
Unassigned | ||
Yakkety |
Confirmed
|
Medium
|
Unassigned | ||
Zesty |
Fix Released
|
High
|
Unassigned | ||
nova-lxd (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Xenial |
In Progress
|
High
|
Unassigned | ||
Yakkety |
In Progress
|
High
|
Unassigned | ||
Zesty |
Fix Released
|
Medium
|
Unassigned |
Bug 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_
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
Changed in cloud-init: | |
status: | New → Confirmed |
Changed in cloud-init (Ubuntu): | |
status: | New → Confirmed |
Changed in nova-lxd: | |
status: | New → Confirmed |
Changed in cloud-init: | |
importance: | Undecided → High |
Changed in cloud-init (Ubuntu): | |
importance: | Undecided → High |
description: | updated |
description: | updated |
Changed in cloud-init: | |
status: | Confirmed → Fix Committed |
Changed in nova-lxd (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in cloud-init (Ubuntu Xenial): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in nova-lxd (Ubuntu Xenial): | |
importance: | Undecided → High |
status: | New → Confirmed |
Changed in nova-lxd (Ubuntu Yakkety): | |
importance: | Undecided → High |
status: | New → Confirmed |
tags: | added: dsid |
We could also look at exporting a file/key via lxcfs that we could detect? Not sure if lxcfs can also emulate sys, but if so, then /sys/hypervisor/lxd would be a good place as well.