| Age | Commit message (Collapse) | Author |
|---|
|
|
|
All other marker files by cloud-init live in /var/lib/cloud/sem
it makes sense for uncloud-init's file to live there too.
|
|
The new classes 'DataSourceNoCloud' and 'DataSourceNoCloudNet'
implement a way to get data from the filesystem, or (very minimal)
data from the kernel command line. This allows the user to seed data to
these sources.
There are now 2 "cloud-init" jobs, cloud-init-local that runs on
mounted MOUNTPOINT=/
and 'cloud-init' that runs on
start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0 and
stopped cloud-init-local )
The idea is that cloud-init-local can actually function without network.
The last thing in this commit is "uncloud-init".
This tool can be invoked as 'init=/usr/lib/cloud-init/uncloud-init'
It will "uncloudify" things in the image, generally making it easier
to use for a simpler environment, and then it will exec /sbin/init.
|
|
|
|
if user data is of type text/cloud-boothook, or begins with
#cloud-boothook, then assume it to be code to be executed.
Boothooks are a very simple format. Basically, its a one line header
('#cloud-config\n') and then executable payload.
The executable payload is written to a file, then that file is executed
at the time it is read. The file is left in
/var/lib/cloud/data/boothooks
There is no "first-time-only" protection. If running only once is
desired, the boothook must handle that itself.
|
|
|
|
|
|
if the BUILD_FILE file had more than 4 fields in it, 'serial' would get
all additional fields and would then look wrong in the message.
protect from that case by adding a var to 'read'.
|
|
|
|
|
|
|
|
If a part of a multipart file is 'text/part-handler' then it is
expected to be python code that implements 2 methods
- list_types()
list the types that this part-handler supports, return
a list. ie: return(['text/plain'])
- handle_parts(data,ctype,filename,payload)
this method will be called:
once, when loaded, with ctype == '__begin__'
once per part
once, at the end, with ctype == '__end__'
- ctype is the content type ('text/plain')
- filename is the filename portion of the mime data
- payload is the content of the part
- data is currently the cloud object, but this could change
|
|
|
|
|
|
|
|
write-mime-multipart text/x-shellscript path/filename.sh \
text/x-cloud-config my.yaml \
> my.userdata
|
