[00:05] hello there [00:38] o/ [01:55] paulmey: so os.path.exists('/sys/module/ntfs') is one; and typically there should be a mount.$fstype binary in $PATH; so we have /sbin/mount.ntfs ; mount -t $sf is going to invoke a mount.$fs binary to handle it; [01:56] rharper: i just uploaded .. slight change to your MP. [01:56] we had not added chagnelog entries for the commits on the ubuntu/devel branch [01:56] so i added them. [01:59] its https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text= now [14:16] smoser: ok; is that change that should be in qa-scripts new-upstream-snapshot ? [14:25] rharper: i'm not sure. that might be possible. [14:25] but what I had always been doing is when i commit to the ubuntu/devel branch (or any ubuntu/* branch) [14:26] to "queue" the commits for next [14:26] i would 'dch -i' [14:26] and make a commit with 'git commit -m "update changelog"' debian/changelog [14:27] i guess we could traverse the ubuntu branch since merge also and grab those commits to write the entry. [14:28] kind of weird to have new-upstream-snapshot do it though as those commits/entries-in-changelog are not from the new-upstream-snapshot. they were from commits to the ubuntu/ branch [14:28] woudl be nice though to have something doing that / envforcing it. [14:29] I didnt mean for it to do it, but just printing of the steps [14:30] I just need a reminder [14:30] oh. well, they're kind of supposed to be done *befor* you run new-upstream-snapshot [14:30] ie, when we commit to that branch [14:30] heh [14:30] we should do it [14:30] hrm [14:30] nothing new is committed ot ubuntu devel until we do the snapshot, right ? [14:30] I'm confused (as you already knew) [14:44] rharper: see 85ff391b29ec8ea2168371498ffe083c51258ef3 [14:45] we have packaging only on the ubuntu branches [14:45] so those commits have to go to that branch [14:46] i prefer commits like that to be in one commit that makes the change, and one commit that updates the changelog ("git commit -m 'update changelog'") [14:46] that way they can be easily cherry-picked to other ubuntu/ branches [14:46] as debian/changelog changes are going to always conflict [14:46] oh, I see [14:47] that hit master, but should ahve been ubuntu/devel only [14:54] rharper: well we fixed in on master too [14:54] in master its just for the bddeb work flow [14:54] ok [14:54] right [14:55] i really only noticed that because I knew wer were explicitly looking for those 2 fixes [14:55] (isc-dhcp-client and iproute2) [15:15] smoser: you setting up the Bionic update ? [15:21] blackboxsw: yeah, i'll file a bug now [15:21] ok then I'll poke at IBM xenial a bit [15:32] blackboxsw: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1767412 [15:32] Launchpad bug 1767412 in cloud-init (Ubuntu Bionic) "SRU cloud-init 18.2-27-g6ef92c98-0ubuntu1" [Medium,Confirmed] [15:33] smoser: blackboxsw and I were discussing if there was a way to keep the ConfigDrive -> softlayer detection in the xenial/artful only branches so bionic didn;t have to have that logic; but there is that gnarly hard-coded datasource list in /etc/cloud/cloud.cfg.d/ that's present which restricts what ds-identify looks for; [15:34] um... what detection is that ? [15:34] I don't think we have a way to tell ds_check on a particular datasource that it's really a different one; [15:34] there's a datasource_list: [NoCloud, ConfigDrive, None] list in those images, that's what blackboxsw found on the xenial instance [15:34] right [15:34] which means that after upgrade, ds-identify still won't "See" softlayer [15:35] hoping to somehow transition to the softlayer datasource but that sort of means either nuke or re-writing , or somehow overriding it [15:35] which I'm not sure how we can do that reasonably [15:37] it should nto "see" softlayer [15:37] thats the plan [15:38] it shoudl go on using the datasource on disk. [15:39] separately we can/should discuss with CPC for them to start making new images on IBM in the same way they make bionic images. [15:39] so as to not have the slop that is there. [15:41] @rharper thanks for taking a look at the ntfs bug (1767002), i saw your comments from yesterday, you asked if there are further checks that can be done, but I’m not sure what further checks can be done? Many of the distro’s on the platform do not support ntfs in the images. [15:42] danMS: generally, is there a kernel module loaded (ntfs); and are there tools (mount.ntfs, fsck.ntfs, mkfs.ntfs); would be two other indicators (specically mount.ntfs) [15:42] that would allow modified centos/rhel images which have those tools to work rather than banning the distro entirely [15:42] if that makes sense [15:45] danMS: maybe another way out of this would be to just allow this configurable [15:45] and have RH and SuSE build images with "support_ntfs: false" [15:45] or what not. [15:46] hten dont worry at all about blowing away data on an ntfs partition. [15:46] rharper: http://paste.ubuntu.com/p/GYsxMyTR2F/ [15:46] blackboxsw: ^ that is what i was thinking is the fix [15:47] smoser: but how would the softlayer ds get added to the datasource_list ? [15:48] it wont [15:48] and thats fine. [15:48] smoser: I was hoping to transition into the softlayer datasource [15:48] oh [15:49] so, once launched on a ConfigDrive, it would stay that way through upgrade and dist-upgrade to bionic ? [15:50] yeah. [15:50] that has some asymmetry w.r.t things checking what ds was used; not sure if that's a big issue or not [15:50] if the user removed the entry from the 99networklayer.cfg and dpkg-reconfigure, then they'd transition just as a new instance had been created. [15:50] right [15:51] sure on pastebin smoser though maybe we can fold in the is_ds_enabled check inside is_ibm_cloud in ds-identify [15:51] because we also have that check in dscheck_NoCloud [15:53] I also just noted that our DataSourceNoCloud doesn't have a comparable filter for ibm too [15:53] like ds-identify does [15:53] blackboxsw: yeah, you could potentially do that. but the fact that something is or is_not ibm cloud is not specifically related to whether or not hte datasource is in that list [15:53] so.. i just wrapped. but yeah, i dont have a real good reason to not do what you did. [15:54] uyeah..that was kidn of why i dropped the check in NoCloud [15:54] (in my diff) [15:54] if you have a Nocloud, then thats your issue. (and ours since we have aofficial images with it... ) [15:57] thanks guys, will chat with paulmey [15:58] rharper: i'm going to force push the ubuntu/devel branch back to before we merged you. [15:58] smoser: ok [15:58] and then i'm going to make a bionic branch [15:59] sure [16:26] rharper: you want to do this or wnat me to ? [16:27] which ? [16:27] or what [16:27] ubuntu/bionic is now in a state that you can run new-upstream-snapshot [16:27] and it will all "just work" [16:27] one change to new-upstream-snapshot that i just pushed [16:27] I can run it again, but likely faster for you to do it [16:27] and your bug nuber is dch --release --distribution=bionic [16:27] oops [16:27] bug number is 1767412 [16:27] ok. i can just do it. [16:28] * rharper looks at git log to see what's different === r-daneel_ is now known as r-daneel [16:32] smoser: nice change to new-upstream-snapshot [16:32] rharper: it should differ only in the changelog [16:32] * smoser verifies that is true :) [16:33] from what to what ? [16:34] 7609065fd30c3a02122bded6ab213ebc3912584b [16:34] is raharper/ubuntu/devel/newupstream-20180426 [16:34] what you had proposed [16:34] and diff current ubuntu/bionic -> that [16:34] you get [16:34] smoser: upload good now? [16:35] http://paste.ubuntu.com/p/ScfhfhXvBP/ [16:35] yeah, i just uploaded [16:35] yes [16:35] i shoudl have reversed the order there [16:35] but good. [16:35] smoser: that looks right (minus the order) [16:36] http://paste.ubuntu.com/p/DbqJ945jMh/ [16:36] I put that here: raharper/ubuntu/devel/newupstream-20180427 [16:36] just uploaded [16:37] \o/ [16:37] https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text= shows it. [16:42] blackboxsw: Hey, just following up on merge request: https://code.launchpad.net/~jocha/cloud-init/+git/cloud-init/+merge/344192 :) [16:42] jocha: thanks sorry for the delay, if I can't get to it today, it will be tomorrow. (was on vacation yesterday) [16:43] no worries! I understand that you must have a lot on your plate [16:44] blackboxsw: did you get sorted on launch ? [16:44] smoser: I'm currently trying to use the UI for it. I'll try again cli and really look at the traceback to see what gives [16:46] smoser: this is what I hit https://pastebin.ubuntu.com/p/Vq7fw5S2tf/ [16:50] ahh got it smoser [16:50] it's because of how I set up my account [16:50] to automatically inject my ssh key. [16:50] adding a check in launch-softlayer now [16:57] ok have a fix. pushing now [17:10] pushed, testing a potential SL fix now [17:35] blackboxsw: i just pushed another on top there. [17:35] make sure it still works for you [17:35] i just verified emptying my keys and having it add one for me and then matching too. [18:13] blackboxsw: you make progress ? [18:13] i booted xenial on IBMCloud, upgraded, put this chagne in place [18:13] http://paste.ubuntu.com/p/cRPzBt3Qg7/ [18:14] (by hand) [18:14] and then rebooted and came up ok. [18:16] smoser: I used the original changeset and tried a ds-identify run and saw an error on line 616 [18:16] DS_LIST param not set [18:16] yeah. i fixed taht [18:16] DI_DSLIST [18:16] is the name [18:16] yeah [18:18] smoser: the issue I think I'm seeing with that fixed is that xenial was originally ds-id'd as ConfigDrive but now returns NoCloiud [18:18] hrm, wait a sec [18:18] need to recheck that [18:18] :q [18:20] n/m strike that, it was originally detected NoCloud, not ConfigDrive. ok so logic remains intact [18:20] well,. remember 4 scenarios [18:20] with user-data and without, template and os_code [18:22] * blackboxsw is waiting on reboot and reboot clean [18:23] even though the clean reboot isn't really an intended upgrade path. [18:29] their apt mirror is nice [18:29] Fetched 83.1 MB in 2s (28.2 MB/s) [18:30] suggests IO is decent as well [18:30] well, eatmydata helps with the io [18:31] and i dont run apt-get any other way :) [18:31] lol === r-daneel_ is now known as r-daneel [18:57] rharper: re "is there an ntfs kernel module", I propose to run 'modinfo ntfs" (rc=0) to check that is true and I'll run a util.which on 'mount.ntfs' to see if that exists in $PATH [18:58] does that sound like the right path? [18:59] paulmey: yes; === r-daneel_ is now known as r-daneel === r-daneel_ is now known as r-daneel [21:31] alright, I'll make it so... [21:45] blackboxsw: I did get the datasource list rioght in ConfigDrive [21:45] 2018-04-27 20:52:41,219 - DataSourceConfigDrive.py[DEBUG]: devices=['/dev/xvdh'] dslist=['ConfigDrive', 'NoCloud'] [21:46] yeah, and then as i think.... [21:46] your case enabling IBMcloud on a template image without user-data on xenial [21:46] hm.. maybe not [21:46] i htought i had a thoguht on it. [21:47] buti have to go now. [21:47] later. [21:47] later [21:47] yeah and going through the motions here