Re: [Cloud-init-dev] [Merge] lp:~harm-o/cloud-init/freebsd into lp:cloud-init
Agreed on uptime, I guess we can keep the current impl, although I do wonder what happens if ctypes fails to load the library, perhaps some exception handled is useful around that? -- https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130 Your team cloud init development team is requested to review the proposed merge of lp:~harm-o/cloud-init/freebsd into lp:cloud-init. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] lp:~harm-o/cloud-init/freebsd into lp:cloud-init
Great start! Thanks :) I've taken your comments plus some notes from #cloud-init and did some additions and changes. - wow, didn't know uptime had to be done with ctypes, is there no other way? is the `uptime` command pretty standard? for the logexc(LOG, Unable to read uptime) can we also add in the method (similar to the above mount method); so that if it fails we can easily know which method was tried, maybe we could consider using https://pypi.python.org/pypi/uptime which seems to be more platform agnoistic (and simpler to use) - http://pythonhosted.org/uptime /#supported-platforms While a pure python module sure would look (a lot) better, it would impose yet another dependency to merely cover just a tiny thing - one thats already in the codebase aswell. I'm definately not against this, just wondering on what the project's thought are about imports in general? Your ideas about putting more in parsers/ seems nice, I'll see if I can make that work (though, all in good time). Regarding Cloudbase, I strongly agree with leaving that to do Windows and pulling BSD on board the cloud-init train. It just makes more sense. -- https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130 Your team cloud init development team is requested to review the proposed merge of lp:~harm-o/cloud-init/freebsd into lp:cloud-init. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] lp:~harm-o/cloud-init/freebsd into lp:cloud-init
https://github.com/pellaeon/bsd-cloudinit This may have more features from which to merge as well. It doesn't do config-drive AFAIK, but it might be useful? That's a different version of cloudinit that isn't this version, but a derivative that the windows folks created instead of getting cloudinit (this project) to work on windows. For bsd/linux variations I'd think it makes sense to keep just 1 version of cloudinit and 1 project (the changes that this introduces are not imho big enough to be a new project, or be imported into the windows cloudbaseinit, https://github.com/pellaeon/bsd-cloudinit). That being said I think stuff from https://github.com/pellaeon/bsd-cloudinit might be a useful reference, but having 2 projects (one for windows + bsd) and one for linux (or linux like, fedora, ubuntu, rhel...) doesn't seem to make sense. -- https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130 Your team cloud init development team is requested to review the proposed merge of lp:~harm-o/cloud-init/freebsd into lp:cloud-init. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] lp:~harm-o/cloud-init/freebsd into lp:cloud-init
- for disk selections, probably easier to parse sysctl kern.disks instead of trolling around in /dev and assuming that disk names (even though this is probably fine) will allways be virt-io device names. e.g. for disk in `sysctl kern.disks`; do diskinfo $disk; done -- https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130 Your team cloud init development team is requested to review the proposed merge of lp:~harm-o/cloud-init/freebsd into lp:cloud-init. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] lp:~harm-o/cloud-init/freebsd into lp:cloud-init
https://github.com/pellaeon/bsd-cloudinit This may have more features from which to merge as well. It doesn't do config-drive AFAIK, but it might be useful? -- https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130 Your team cloud init development team is requested to review the proposed merge of lp:~harm-o/cloud-init/freebsd into lp:cloud-init. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] lp:~harm-o/cloud-init/freebsd into lp:cloud-init
Great start! Some initial comments :-) givecmdline() - can this function be in the distro object itself?? - can we use signal.SIG_DFL instead of just 0 (using the constant makes it so people can lookup that on websites, and understand it a little easier) - sys.platform - util.system_info(), this little util function should be helpful here, its using something that can be mocked out (and uses the platform module instead of sys module) freebsd.py - for rc.conf have u tried the parsers/sys_conf.py, it might be more robust than the one u created (from initial looking at, it seems like it should work, might be worth a try) utils.py - an idea, maybe for a future change, is to have a parser for the mount data, similar to the ones we have in https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/cloudinit/distros/parsers/, that way its pretty easy to decouple the getting of the mount data from the parsing of it (allowing the parsing to be tested in a way that is not connected to the executing) - logexc(LOG, Failed fetching mount points), can we also include the method that was used here, this will help in case of debugging why this method may have failed, -- logexc(LOG, Failed fetching mount points using method %s, method) - wow, didn't know uptime had to be done with ctypes, is there no other way? is the `uptime` command pretty standard? for the logexc(LOG, Unable to read uptime) can we also add in the method (similar to the above mount method); so that if it fails we can easily know which method was tried, maybe we could consider using https://pypi.python.org/pypi/uptime which seems to be more platform agnoistic (and simpler to use) - http://pythonhosted.org/uptime/#supported-platforms - /etc/mtab parsing, seems like another good candiate for beign a parser in https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/cloudinit/distros/parsers/ thoughts? -- https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130 Your team cloud init development team is requested to review the proposed merge of lp:~harm-o/cloud-init/freebsd into lp:cloud-init. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
[Cloud-init-dev] [Merge] lp:~harm-o/cloud-init/freebsd into lp:cloud-init
Scott Moser has proposed merging lp:~harm-o/cloud-init/freebsd into
lp:cloud-init.
Requested reviews:
cloud init development team (cloud-init-dev)
For more details, see:
https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130
initial freebsd support.
--
https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130
Your team cloud init development team is requested to review the proposed merge
of lp:~harm-o/cloud-init/freebsd into lp:cloud-init.
=== modified file 'cloudinit/config/cc_growpart.py'
--- cloudinit/config/cc_growpart.py 2013-10-02 18:35:14 +
+++ cloudinit/config/cc_growpart.py 2013-12-06 21:40:35 +
@@ -22,6 +22,7 @@
import os.path
import re
import stat
+import sys
from cloudinit import log as logging
from cloudinit.settings import PER_ALWAYS
@@ -137,6 +138,35 @@
return (before, get_size(partdev))
+class ResizeGpart(object):
+def available(self):
+if not os.path.exists('/usr/local/sbin/gpart'):
+return False
+return True
+
+def resize(self, diskdev, partnum, partdev):
+
+GPT disks store metadata at the beginning (primary) and at the
+end (secondary) of the disk. When launching an image with a
+larger disk compared to the original image, the secondary copy
+is lost. Thus, the metadata will be marked CORRUPT, and need to
+be recovered.
+
+try:
+util.subp([gpart, recover, diskdev])
+except util.ProcessExecutionError as e:
+if e.exit_code != 0:
+util.logexc(LOG, Failed: gpart recover %s, diskdev)
+raise ResizeFailedException(e)
+
+before = get_size(partdev)
+try:
+util.subp([gpart, resize, -i, partnum, diskdev])
+except util.ProcessExecutionError as e:
+ util.logexc(LOG, Failed: gpart resize -i %s %s, partnum, diskdev)
+raise ResizeFailedException(e)
+
+return (before, get_size(partdev))
def get_size(filename):
fd = os.open(filename, os.O_RDONLY)
@@ -156,6 +186,12 @@
bname = os.path.basename(rpath)
syspath = /sys/class/block/%s % bname
+# FreeBSD doesn't know of sysfs so just get everything we need from
+# the device, like /dev/vtbd0p2.
+if sys.platform.startswith('freebsd'):
+m = re.search('^(/dev/.+)p([0-9])$', devpath)
+return (m.group(1), m.group(2))
+
if not os.path.exists(syspath):
raise ValueError(%s had no syspath (%s) % (devpath, syspath))
@@ -206,7 +242,7 @@
stat of '%s' failed: %s % (blockdev, e),))
continue
-if not stat.S_ISBLK(statret.st_mode):
+if not stat.S_ISBLK(statret.st_mode) and not stat.S_ISCHR(statret.st_mode):
info.append((devent, RESIZE.SKIPPED,
device '%s' not a block device % blockdev,))
continue
@@ -281,4 +317,4 @@
# LP: 1212444 FIXME re-order and favor ResizeParted
#RESIZERS = (('growpart', ResizeGrowPart),)
-RESIZERS = (('growpart', ResizeGrowPart), ('parted', ResizeParted))
+RESIZERS = (('growpart', ResizeGrowPart), ('parted', ResizeParted), ('gpart', ResizeGpart))
=== modified file 'cloudinit/config/cc_power_state_change.py'
--- cloudinit/config/cc_power_state_change.py 2013-10-09 14:03:03 +
+++ cloudinit/config/cc_power_state_change.py 2013-12-06 21:40:35 +
@@ -23,12 +23,34 @@
import os
import re
import subprocess
+import sys
import time
frequency = PER_INSTANCE
EXIT_FAIL = 254
+#
+# Returns the cmdline for the given process id.
+#
+
+def givecmdline(pid):
+# Check if this pid still exists by sending it the harmless 0 signal.
+try:
+ os.kill(pid, 0)
+except OSError:
+return None
+else:
+# Example output from procstat -c 16357
+# PID COMM ARGS
+# 1 init /bin/init --
+if sys.platform.startswith('freebsd'):
+(output, _err) = util.subp(['procstat', '-c', str(pid)])
+line = output.splitlines()[1]
+m = re.search('\d+ (\w|\.|-)+\s+(/\w.+)', line)
+return m.group(2)
+else:
+return util.load_file(/proc/%s/cmdline % pid)
def handle(_name, cfg, _cloud, log, _args):
@@ -42,8 +64,8 @@
return
mypid = os.getpid()
-cmdline = util.load_file(/proc/%s/cmdline % mypid)
+cmdline = givecmdline(mypid)
if not cmdline:
log.warn(power_state: failed to get cmdline of current process)
return
@@ -119,8 +141,6 @@
msg = None
end_time = time.time() + timeout
-cmdline_f = /proc/%s/cmdline % pid
-
def fatal(msg):
if log:
log.warn(msg)
@@ -134,16 +154,14 @@
break
try:
-cmdline =
-with open(cmdline_f) as fp:
-cmdline = fp.read()
+cmdline = givecmdline(pid)
if cmdline != pidcmdline:
