[02:55] rharper: that looks better, yes. [03:05] rharper: although I note that I get KeyError: 'r' when trying to run 'make srpm'... [03:08] ...because I needed PYVER=python2, right. [03:09] Although: I would call it a bug if something declares "template: cheetah" and we continue without producing an error message... === sambetts|afk is now known as sambetts [14:46] larsks: thanks for the feedback, we're looking to drop cheetah as a template (there is some code which does fallback if you don't have cheetah but those messages go to logging, which isn't configured for the tool) [14:46] so you're right w.r.t the error; and we're looking to drop cheetah soon [17:50] hiya larsks, do you have any idea what meta package I'd need in centos/7 to setup repositories which would give me access to download python3 system package for oauthlib? I've got epel-release installed, but it doesn't yum search is coming up empty. [17:51] sorry larsks, I should introduce myself. I'm Chad Smith, a recent join to Canonical's cloud-init/curtin team. [17:52] blackboxsw: hi there! [17:53] I know that oauthlib is not available in RHEL. It may not be in CentOS either. Let me look. [17:54] blackboxsw: yeah, there is no generally available oauthlib package. [17:55] ok thanks for the confirmation larsks. [17:55] It is available in the openstack repositories (e.g., centos-release-openstack-newton), but you wouldn't normally expect those to be enabled where people are running cloud-init. [17:56] http://oauthlib.readthedocs.io/en/latest/installation.html says it has a python3 oauthlib [17:56] for redhat [17:56] but that doesn't seam right, I would expected python34 or something [18:10] rharper: we actually include a patch in our cloud-init package specfically to fail gracefully if oauthlib is missing. [18:10] ah, ok [18:10] (we catch the importerror, and then raise an exception later on if something actually tires to call the oauth_headers method) [18:10] we probably want that then [18:11] http://chunk.io/f/c756394a7c91432f8a92fdbad2682fda [18:12] cool [18:13] thanks larsks that works for me. I was just working on setting up a make ci-deps-centos target and I didn't want to rule out installing any dependencies I could get together if they are reasonably available for setting up our test environments. [18:14] so not having python3-oathlib isn't a deal breaker for our CI [18:14] fwiw, it's a good idea not to depend on anything not available in the stock centos repositories. E.g., don't rely on EPEL. [18:18] +1 [18:52] https://bugzilla.redhat.com/show_bug.cgi?id=1417025 [18:52] bugzilla.redhat.com bug 1417025 in cloud-init "cloud-init tries to run hostnamectl before dbus is up" [Unspecified,Closed: rawhide] [18:52] that's going to be "fun" [19:57] rharper: looks like that was fixed. [20:10] larsks: ok; I was looking at ubuntu and our dbus.service doesn't depend on After=sysinit.target ; was going to test with that [20:11] rharper: I finally threw up my hands and completely abandoned the systemd units in the source tree. [20:11] =/ ok, I can look at the changes; we may need to template the units as well [20:11] There were too many weird edge cases where ubuntu and redhat had different dependencies. [20:11] yeah [20:12] Well, I had another suggestion: [20:12] Using systemd drop-ins for the distribution specific stuff. [20:12] ah, yes [20:12] that is a good idea [20:12] I need to play with those some more [20:12] THe model would be: cloud-init units only have dependencies on other cloud-init units, and dependencies on anything else would be configured in drop-ins. [20:19] yes, that makes sense