I'm reviving this ancient thread to ask: Will there be a code summit
session about this? And/or are there plans to start developing a
standard set of guest agents for Folsom?
-Andrew
On 12/15/11 2:34 AM, Jesse Andrews wrote:
Great question.
Right now there are 3 approaches to
On Tue, 10 Apr 2012, Andrew Bogott wrote:
I'm reviving this ancient thread to ask: Will there be a code summit session
about this? And/or are there plans to start developing a standard set of
guest agents for Folsom?
http://summit.openstack.org/sessions/view/100
I maintain my stance from pre-Diablo, that the configuration drive should be
exported as a virtual cdrom device with an ISO9660 filesystem. We can generate
the filesystem without root access and the filesystem is well-supported.
Additionally, it lacks the patent-related issues associated with
: [Openstack] Metadata and File Injection (code summit session?)
On Tue, 10 Apr 2012, Andrew Bogott wrote:
I'm reviving this ancient thread to ask: Will there be a code summit
session about this? And/or are there plans to start developing a
standard set of guest agents for Folsom?
http
-
From: openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:
openstack-bounces+philip.day=hp@lists.launchpad.net] On Behalf Of
Scott Moser
Sent: 10 April 2012 16:52
To: andrewbog...@gmail.com
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Metadata and File Injection
@lists.launchpad.net] On Behalf Of Scott Moser
Sent: 10 April 2012 16:52
To: andrewbog...@gmail.com
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Metadata and File Injection (code summit session?)
On Tue, 10 Apr 2012, Andrew Bogott wrote:
I'm reviving this ancient thread to ask
Config drive can support all EC2 functionality, I believe.
Images would need to be respun for OpenStack with config-drive, unless we
populated the config drive in a way that worked with cloud-init. (Scott?)
Personally, I'd rather our effort went into producing great images for
OpenStack, than
EC2 is strategically important. I don't believe that building gold images is
the right focus for OpenStack.
Anyone wanting to use config-drive would need to support it in their images,
that is a no-brainer. It should not be required that images launching in Nova
via the EC2 API support
What I crave is a communication channel between nova and running
instances. There was discussion at some point about extending the
metadata api to have this ability.
Having a solid config drive standard seems like a good idea, but it
won't get me run-time interaction, will it?
-Andrew
On
On Tue, Apr 10, 2012 at 3:12 PM, Eric Windisch e...@cloudscaling.com wrote:
EC2 is strategically important. I don't believe that building gold images
is the right focus for OpenStack.
Indeed. Amazon drives a huge portion of the IaaS market today, and has
an enormous impact on non-Amazon IaaS
I presume you're looking for more than SSH offers. What are the missing
features you need?
On Tue, Apr 10, 2012 at 12:36 PM, Andrew Bogott abog...@wikimedia.orgwrote:
What I crave is a communication channel between nova and running
instances. There was discussion at some point about
On 04/10/2012 12:36 PM, Andrew Bogott wrote:
What I crave is a communication channel between nova and running
instances. There was discussion at some point about extending the
metadata api to have this ability.
Having a solid config drive standard seems like a good idea, but it
won't get
On 4/10/12 5:04 PM, Justin Santa Barbara wrote:
Can you please share that use case? I'm especially interested in
finding use cases that would not better be better served by e.g. SSH
or Zookeeper or Corosync..
The immediate use case I have in mind is to support this:
The immediate use case I have in mind is to support this:
http://wiki.openstack.org/**PackageConfigForNovahttp://wiki.openstack.org/PackageConfigForNova.
That design requires periodic checkins between an instance agent and a
nova driver. It certainly /could/ be implemented using ssh, but I
On Apr 10, 2012, at 3:04 PM, Justin Santa Barbara wrote:
Having the ability to read config data from a runtime changeable
metadata server (rather then a config file on an injected disk) serves a
use case I am interested in. The only problem is horizontal scalability
of the metadata server
One advantage of a network metadata channel is it allows for communication
with cloud provider services without having to put a key into the vm. In
other words, the vm can be authenticated via its ipv6 address.
Did you have a use case in mind here? It seems that Keystone could use the
IPV6
On 04/10/2012 03:04 PM, Justin Santa Barbara wrote:
Having the ability to read config data from a runtime changeable
metadata server (rather then a config file on an injected disk) serves a
use case I am interested in. The only problem is horizontal scalability
of the metadata
On 4/10/12 5:36 PM, Justin Santa Barbara wrote:
The immediate use case I have in mind is to support this:
http://wiki.openstack.org/PackageConfigForNova . That design
requires periodic checkins between an instance agent and a nova
driver. It certainly /could/ be implemented
On Apr 10, 2012, at 4:24 PM, Justin Santa Barbara wrote:
One advantage of a network metadata channel is it allows for communication
with cloud provider services without having to put a key into the vm. In
other words, the vm can be authenticated via its ipv6 address.
Did you have a use
On 10/04/12 15:36 -0700, Justin Santa Barbara wrote:
The immediate use case I have in mind is to support this:
http://wiki.openstack.org/**PackageConfigForNovahttp://wiki.openstack.org/PackageConfigForNova.
That design requires periodic checkins between an instance agent and a
nova driver.
On Apr 10, 2012, at 6:19 PM, Angus Salkeld wrote:
On 10/04/12 15:36 -0700, Justin Santa Barbara wrote:
The immediate use case I have in mind is to support this:
http://wiki.openstack.org/**PackageConfigForNovahttp://wiki.openstack.org/PackageConfigForNova.
That design requires periodic
On Tue, 10 Apr 2012, Justin Santa Barbara wrote:
Config drive can support all EC2 functionality, I believe.
Images would need to be respun for OpenStack with config-drive, unless we
populated the config drive in a way that worked with cloud-init. (Scott?)
cloud-init supports config-drive
22 matches
Mail list logo
