osv-cloudinit

[tzach]

cloudinit is a mechanism to inject information to OSv init process, similar to other OS CloudInit [3] In particular, this is useful when running an instance on EC2[1] or open-stack [2] can be use to inject this information.

user-data can be use to:

• set public ssh keys
• set private hostname
• set CRaSH user/pass
• set env variables (#140)
• run OSv API commands etc

user data can be injected in run.py CLI

• one property at a -d, --user-data, -d s3-bucket:my-logs
• via a file of parameters -f, --user-data-file user.txt

User data file will ignore remark (start with #) like, and will be in pair format. For example

# ssh login:
ssh-username: admin
ssh-password: nimda

#run OSv API command *
api: file/rm/etc/lol
api: env-var/set/logger-dest?server=http://centralize-logger.com

• this API does not exists yet

[1] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html [2] https://github.com/cloudbase/cloudbase-init/ [3] http://pellaeon.github.io/bsd-cloudinit/

[tzach]

could-init can be an external, optional module of OSv. It will be included in an image for a cloud which support it, like EC2 or OpenStack, and can be omitted for other cases. Example for such cloudinit can be found: http://cloudinit.readthedocs.org/en/latest/index.html with the difference that OSv cloudinit will be base on API, not on scripting or CLI.

[tzach]

GCE meta data https://developers.google.com/compute/docs/metadata?hl=en

[amnonh]

I think that the question is if you want to do it internally to the image or externally.

If we're going for the internal approach (I assume we are) then I think we should reverse the order, ie have an API for everything (maybe not the ssh keys).

Add a (trivial) option to the api to get the command from a file and let it do the setting. The advantage is that it would strength the API and will not add additional tools to the boot process.

[tzach]

I think that the question is if you want to do it internally to the image or externally.

Yes, cloud-init is living inside the image BTW, not necessarily all images. It is there by default, but someone might choose to exclude it. Same goes for API.

If we're going for the internal approach (I assume we are) then I think we should reverse the >order, ie have an API for everything (maybe not the ssh keys).

No objections, but we may extend cloud-init beyond API. In the far future it may include scripts.

Add a (trivial) option to the api to get the command from a file and let it do the setting. The >advantage is that it would strength the API and will not add additional tools to the boot process.

Are you suggesting the HTTPServer will process the file itself? IMHO, this is not required. As describe above, one might choose to include API but not cloud-init.

[amnonh]

On Wed, Mar 5, 2014 at 6:07 PM, Tzach Livyatan notifications@github.comwrote:

I think that the question is if you want to do it internally to the image or externally.

Yes, cloud-init is living inside the image BTW, not necessarily all images. It is there by default, but someone might choose to exclude it. Same goes for API.

If we're going for the internal approach (I assume we are) then I think we should reverse the >order, ie have an API for everything (maybe not the ssh keys).

No objections, but we may extend cloud-init beyond API. In the far future it may include scripts.

This is where I think it should be reverse, if there are scripts it should be handle by the API as much as possible. It means having a stronger API but then you have those capabilities regardless if it comes from the could init or from somewhere else.

Add a (trivial) option to the api to get the command from a file and let it do the setting. The >advantage is that it would strength the API and will not add additional tools to the boot process.

Are you suggesting the HTTPServer will process the file itself?

yes, the file can even look like: POST:/system/password?value="admin"

IMHO, this is not required. As describe above, one might choose to include API but not cloud-init.

Right, but we can still say that if we are working with local files, it would be a local-cloud-init kind of thing.

It would simplified transition between cloud and local image and I think looks better with our overall proposition.

Reply to this email directly or view it on GitHubhttps://github.com/cloudius-systems/osv/issues/139#issuecomment-36758321 .

[slivne]

@tzach can we close this general one -we have implemented the general mechanism specific items have their own issue / some are already implemented (e.g. security credentials for httpserver)

[nyh]

We already added cloud-init module two years ago.