[00:51] <dpb1> ah interesting.  DO is doing an object storage product
=== frickler_ is now known as frickler
[08:37] <niluje> powersj: https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Syntax-Reference
[08:37] <niluje> just found that
[08:37] <niluje> the pipeline reference for the declarative syntax
=== sambetts|afk is now known as sambetts
=== rangerpbzzzz is now known as rangerpb
[14:22] <bob_cheesey> could anyone comment on a workaround for this? https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1686338
[14:22] <bob_cheesey> we're using cloud-init on our VPS platform and we don't want cloud-init to configure networkign (we have our own tool for that which cloud-init provides the data to) so network_data.json contains "{}" - would this be sufficient to run into the above bug?
[14:22] <ubot5`> Ubuntu bug 1686338 in cloud-init (Ubuntu) "cloud-init fails if no network config is set" [Undecided,New]
[14:23] <dpb1> bob_cheesey: I'll respond on the bug
[14:23] <bob_cheesey> dpb1: thanks!
[14:23] <dpb1> bob_cheesey: a patch is certainly welcom
[14:23] <dpb1> e
[14:28] <bob_cheesey> dpb1: I can attempt that, however I'm not sure my Python skill are sufficient to achieve this. I'll await your response first!
[14:29] <dpb1> bob_cheesey: my first comment was just a general how to submit the issue, now to look at the issue
[14:31] <bob_cheesey> ok, understood. thanks again
[14:37] <dpb1> bob_cheesey: what cloud is this, btw?
[14:39] <bob_cheesey> dpb1: it's not, it's custom images which run on our own Xen platform
[14:42] <rharper> bob_cheesey: if you want to disable networking in the image, you can write out /etc/cloud/cloud.cfg.d/05-disable-network.cfg with "network: {config: disabled}"  http://cloudinit.readthedocs.io/en/latest/topics/network-config.html
[14:44] <rharper> that said, if it's custom, still interested in what files in the datasource you're using are indicating that network configuration is available (I suspect this is either ConfigDrive or NoCloud);  likely some files are being included but empty;  I'd like to confirm which ones; the DataSource should handle this so cloud-init can generate a fallback network config if it's not really present
[14:45] <bob_cheesey> rharper: thanks, I wasn't aware of that (I'm picking up where someone left off after developing this so I'm learning as I go). Would I need to ensure that network_data.json is completely empty or will the solution you mentioned ensure that the network_data file is ignored?
[14:46] <rharper> if you disable networking entirely, then nothing will attempt to consume the network_data.json file
[14:46] <bob_cheesey> rharper: we're using ConfigDrive
[14:46] <rharper> on the other hand, it seems odd to include the network_data.json file if it's empty
[14:46] <bob_cheesey> rharper: agreed; I'm not sure why that decision was arrived at
[14:46] <rharper> further though, we should check if it's returning an empty config and propagate that back
[14:47] <rharper> if you could just mention in the bz that it's COnfigDrive, and show the contents of the network_data.json file included,; we can reproduce with that and get a fix;  I do think in your case you'll likely want to just disable networking (but we'll fix the bug as well)
[14:48] <bob_cheesey> rharper: certainly, i'll do that now
[14:48] <bob_cheesey> thanks!
[14:49] <rharper> sure; thanks for the bug
=== sambetts is now known as sambetts|afk
[18:36] <smoser> powersj, did we have some c-i failures for cloud-init ?
[18:36] <powersj> smoser: there was a LXD xenial hash mismatch that recked havoc on testing last night.
[18:37] <powersj> that was resolved, so things will clean up tonight
[18:37] <powersj> There have not been any commits I believe, so I didn't expect any changes in test restults.
[18:42] <smoser> right. ok. i saw chad say something above in my logs about a change to 'bash' invocation
[19:46] <blackboxsw_away> yeah that was bbsw barking up the wrong tree :/
[19:47] <blackboxsw_away> I just saw bash in the traceback and assumed incorrectly
[20:24] <smoser> blackboxsw_away, go back to away. :)
[20:24] <smoser> later.
=== rangerpb is now known as rangerpbzzzz
[22:50] <dpb1> hi blackboxsw_away
[22:50] <dpb1> :)
[22:57] <powersj> dpb1: rharper: I know both of you are buried.. but FYI take a look at last comment on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1686514
[22:57] <ubot5`> Ubuntu bug 1686514 in cloud-init (Ubuntu Zesty) "Azure: cloud-init does not handle reformatting GPT partition ephemeral disks" [Medium,Fix committed]
[23:14] <rharper> powersj: ok
[23:21] <rharper> powersj: it appears that sdb1 is getting claimed by the system; possible due to /etc/fstab having an entry from the previous boot
[23:21] <rharper> that prevents the mkfs command from running
[23:22] <powersj> seems odd that the other two distros didn't see this
[23:36] <rharper> newer systemd
[23:36] <rharper> I suspect
[23:36] <rharper> powersj: ^
[23:36] <rharper> we found systemd fstab/mount unit to be 'racier'
[23:37] <powersj> ah
[23:38] <rharper> so , not your fault but possibly indicating that we need to try harder to get that out of the way (or root cause it)
[23:38] <rharper> and it's beer thirty for sure