=== not_a_robot is now known as rando
=== rando is now known as craftsmanship
[09:35] <craftsmanship> What are the criteria to have a project listed on cloud-init.io? it seems like bsd-cloud-init isn't getting much love these days (or it's moved from github and the link is old).
=== otubo__ is now known as otubo
[13:11] <smoser> craftsmanship: cloud-init.io is really just cloud-init.
[13:11] <smoser> we do have some bsd support (freebsd) in cloud-init, and are very open to help making that better.
[13:51] <craftsmanship> smoser: is there some kind of list of the kind of help needed?
[14:00] <robjo> smoser: anything else you need from me on lp#1772961
[14:01] <smoser> craftsmanship: well, we dont have any automated tests for it, and I'm not even sure of how to go about installing it. so that would be two things..
[14:02] <smoser> unfortunately neither of which are "easy entry"
[14:02] <smoser> robjo: just go ahead and grab the patches I have
[14:02] <robjo> OK
[14:03] <smoser> and put them in your granch... no reason to deal with others. i just fixed things until i hit the end of my knowledge
[14:03] <smoser> which was pretty quick :)
[14:03] <smoser> then i called in the experts
[14:10] <robjo> smoser: all set ~rjschwei/suseSpec branch should be good to go, thanks for working on this and getting tests and builds working on openSUSE :)
[14:45] <smoser> robjo: http://paste.ubuntu.com/p/G8sHX95JGW/
[14:46] <smoser> trying again with the trivial leading / added.
[14:46] <smoser> fudge.. well.. paste fail
[14:46] <smoser> http://paste.ubuntu.com/p/b9wzqvCVy5/ is how it ended
[14:51] <robjo> looks to be a macro issue, could be that this macro is only defined in the build service. Since we are only dealing with newer distributions I can expand it
[14:52] <smoser> robjo: oh. ok.
[14:52] <smoser> yeah, just adding a / didnt help
[14:52] <smoser> so your explaination makes more sense
[14:58] <robjo> smoser: pushed, but we might still be in trouble because in my package I carry this patch: https://paste.ubuntu.com/p/v2D6sG484t/
[15:03] <smoser> robjo: ok.. i'm fine to take fixes to upstream to figure those both out the right way.
[15:07] <robjo> what's the "right" way, do we want to import util and use get_linux_distro?
[15:07] <smoser> robjo: http://paste.ubuntu.com/p/5PM6GkFKNH/
[15:07] <smoser> \o/
[15:08] <robjo> yay :D
[15:08] <smoser> is get_linux_distro the right way to figure that out ? is it a linux distro thing ?
=== gin is now known as ginsul_
[15:08] <smoser> that means it builds and tests pass... that doenst mean the rpm is useful in any way :)
[15:08] <smoser> but... steps at a time.
[15:09] <robjo> well upstream systemd moved to /usr/lib, but in Ubuntu I know things are in /lib
[15:09] <robjo> in openSUSE we had one version where things were in /lib then things moved to /usr/lib
[15:10] <robjo> thus from that I'd say yes it is distro dependent
[15:21] <hatifnatt> Hello! Is it possible to run set_hostname and / or update_hostname at cloud-init local stage? I'm running it on Debian but I have exactly same issue as described here https://serverfault.com/questions/867473/cloud-init-local-stage-on-freebsd
[16:22] <rharper> hatifnatt: what cloud-init version are you running ?  18.2 release has this include  https://git.launchpad.net/cloud-init/commit/?id=133ad2cb327ad17b7b81319fac8f9f14577c04df which covers setting hostname before inital dhcp;
[16:33] <hatifnatt> rharper: I suppose I'm running something old cloud-init  0.7.9-2
[16:34] <rharper> hatifnatt:  yes; not sure who handles pulling upstream cloud-init into freebsd
[16:36] <hatifnatt> rharper: No I'm not running FreeBSD, I'm running Debian Stretch. This link with FreeBSD is only example with issue description.
[16:36] <rharper> ah, right, sorry
[16:36] <rharper> but my response is the same, not sure when debian will pick up the new releases
[16:37] <rharper> but the upstream deb should work
[16:39] <hatifnatt> Yes possibly I can install deb from bionic. Looks like even sid is too old, it's still at 0.7.9-5
[20:51] <jocha> Hi all I have a question regarding ubuntu 16.04 deployment on Azure, https://pastebin.ubuntu.com/p/fCKNpWPhc4/ :)
[22:22] <rharper> jocha: the change upstream to the AzureDS would break existing behavior in ubuntu xenial, so in the ubuntu/xenial branch you found, there is a debian/patches/azure-use-walinux-agent.patch which adjust this value back to what xenial cloud-init has always had
[22:22] <rharper> Description: Use walinux-agent rather than builtin fabric support
[22:22] <rharper>  Upstream now uses the built-in support for instance initialization on Azure.
[22:22] <rharper>  On a stable release, we want to continue to use the walinux-agent integration.
[22:22] <rharper>  Upstream made this change under bug 1538522.
[22:22] <ubot5> bug 1538522 in cloud-init (Ubuntu) "Calls "service walinuxagent start" in Azure data source" [Medium,Fix released] https://launchpad.net/bugs/1538522
[22:37] <jocha> thanks! let me take a look and read up about this, will come back if I have any further questions!