start to become very expensive.
--
Michael Glasgow
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
itially the aim would just be to provide the operator
with the bare minimum info necessary for more efficient break-fix.
It could be a big investment, but it also doesn't seem like "optional"
functionality from a large operator's perspective. "Enable debug and
try ag
of users who
can read the metadata from a guest. Which I'm pretty sure is not true
in the general case.
Am I missing something?
--
Michael Glasgow
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
ral not-so-great options, but I wish I could think of a better one.
--
Michael Glasgow
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
tomers if those
efforts were coordinated or even consolidated, but so far that has not
been possible.
--
Michael Glasgow
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-de
area could speak to the longer term vision for Murano.
Granted it's an orthogonal concern, but clearly this decision will have
some effects on its future.
--
Michael Glasgow
__
OpenStack Development Mailing List (not for usage questi