[12:04] hi all ... i am facing some issue with cloud init on suse.... is anyone available now to help me? thanks in advance ! [12:04] i have installed cloud-init version 0.7.6 ... and i am seeing cloud-init-local or config status as unused [12:04] could someone please help/correct me if i missed something..thanks [12:31] kalyan: cloud-init-local does need to run. [12:37] smoser: Thanks, but when i tried starting it ..i am seeing the message "failed" [12:42] smoser: just curious.. so it will be in "unused" state? [12:49] what is the init system ? [12:50] cloud init 0.7.6 on suse [12:50] suse 11 [12:52] kalyan: the init system.. sorry i'm not familiar enough to know [12:52] upstart ? systemd? sysvinit ? [12:52] you'll have a file on your system: [12:52] /etc/cloud/cloud.cfg.d/05_logging.cfg [12:52] you proably have a line like [12:53] - [ *log_base, *log_syslog ] [12:53] in it. [12:53] comment that line out [12:53] then re-run and pastebin /var/log/cloud-init.log [12:53] ok sure [13:08] hey smoser. do you have some time to look at some code in https://code.launchpad.net/~d-info-e/cloud-init/+git/cloud-init/+merge/340220 ? [13:09] i am struggeling to find a nice way to easy parse a file that can have 2 different layouts. [13:10] while writing tests for this branch i realized that the output of "mount" command can be different - so we have to take care of both layouts [13:19] do3meli: sure [13:21] do3meli: well i guess the one thing is to have some intermediate object there. [13:21] def parse_mounts(): [13:21] """Return a representation of mounts on the system." [13:21] if util.isFreeBSD(): [13:21] return one thing [13:21] else [13:21] another [13:22] then use that thing [13:22] but maybe that doesnt help you [13:23] unrelated: dont bother passing the LOG thing around . i just didn't really understand python logging when i put that stuff in (handle taking a 'log=' param) [13:23] just use LOG.debug or LOG.warning [13:24] oh. i see so we do have 'parse_mount' . and that returns a dev path, fstype and mount point. [13:25] ahh did not know that. my pycharm always told me its not so nice to use a variable that has not been passed. [13:27] i may can get rid of get_mount_parse_regex() i am just about to put together a better regex that makes it obsolete [13:29] i have this regex now that matchs both formats: [13:30] https://regex101.com/r/2F6c1k/1 and the other format https://regex101.com/r/T2en7a/1 [13:32] the problem now is that the group id's are differnet. for the first one the fs_type is group id 4 and for the second one its group id 3. [14:29] do3meli: you can do names in your regex [14:30] and reference them by name [14:30] do3meli: (?P...) [14:30] https://docs.python.org/3.4/library/re.html [14:31] groupdict() FTW [14:45] let me try that. this would make things much easier ;) [14:50] not sure that works in combination with a positive lookahead [14:51] or the other way around: having the if and else clause the same group name does not work. it says "name must be uniqe" [14:55] see this here: https://regex101.com/r/2F6c1k/2 [16:19] do3meli: thats neat. i'd nto seen that. [16:19] i think i found a solution in the meanwhile smoser [16:19] refactoring that whole stuff now ;-) [16:20] great. thanks. [16:20] do3meli we really apprecate your contributions [16:20] thanks :-) [16:21] saw the monday protocol btw. was not able to attend unfortunately. and most likely can't attend the next one too [16:43] blackboxsw: https://code.launchpad.net/~kgarloff/cloud-init/+git/cloud-init/+merge/341844 [16:43] smoser: just saw you merged it [16:43] merged that with [16:43] was bringing that up. will respond on dojordan's branch [16:43] review-mps -v --project-name=cloud-init --git-user=smoser --merge [16:43] but the related bugs did not get marked fix-committed [16:44] ahh, something to tackle today. I'll re-run it and make sure the bugs get marked by review-mpos [16:44] ahh, something to tackle today. I'll re-run it and make sure the bugs get marked by review-mps [16:51] got it. [16:52] running now and pushing the regex improvemnt. needed to match \s* at end of line not \s+ [16:59] dojordan: welcome, sorry for the delay, I'm posting a minor round of review comment to your azuretimeout branch and testing it today. something landed in trunk today that affects the exception_cb passed to readurl. [16:59] .. and sorry for IRC pouncing [16:59] no worries, its why im here! [17:00] I'll have a patch suggestion for you shortly to see what you think. unless you beat me to it after you git fetch; git rebase master [17:02] basically exception_cb to readurl needs to return True to retry [17:03] if it returns False the current exception gets raised [17:03] yup just found that [17:04] basically this I'm thinking //paste.ubuntu.com/p/qPd7fTp7rz/ [17:04] but wanted to test it [17:04] yup, my thoughts exactly [17:04] ok good deal. [17:05] I'm running through a deployment of that + tip + your branch now should clear out on your branch then in the next hour [17:06] want me to push that patch? [17:06] +1 dojordan it'd save me time [17:06] after a git rebase [17:06] sure, just running unit tests first [17:06] just to include Kurt's changes. thanks [17:12] hmm, getting a slow test: tests.unittests.test_ec2_util.TestEc2Util.test_userdata_fetch_fail_server_not_found 5.0287s . Not a chance my change of AzureDataSource affects this but just FYI [17:13] hm... yeah, i was just seeing that oto. will investigate, dojordan [17:13] ahh good find, that tends to mean a missed requests mock [17:13] thanks [17:13] or a readurl/wait_for_url mis-mocked [17:16] @blackboxsw pushed [17:16] +1 I'm testing live now on a xenial instance w/ your patch ++ the minor pastbin [17:17] sounds good [17:18] BTW we are going to change the logic of exception_cb passed to readurl in a subsequent branch (post 18.2 release). Now exception_cb will be expected to raise an exception if warranted and ignore if retries are expected. It's more intuitive than this return True|False stuff (as you have to go re-read readurl implementation to see what expected behavior is) [17:19] that change will then align more with wait_for_url behavior too [17:19] and we'll fix this callsite for readurl + openstack and scaleway datasources [17:19] which also use exception-cb [17:20] great, i'll keep my eye out for that change [17:20] thanks for the warning [17:59] dojordan: landing it, both failure modes (404 versus service not present work great) thanks for the bump [18:02] great, thanks for the help! [18:12] blackboxsw: 2 reviews please. quick-ish. [18:12] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341995 [18:12] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341997 [18:12] second is (i think) not objectionable in any way [18:26] blackboxsw: ping [18:26] smoser: +1 on the second and will get through the first. didn't want to report back til finished :/ [18:27] blackboxsw: smoser: thoughts on https://bugs.launchpad.net/cloud-init/+bug/1758409 when you have a sec [18:27] Ubuntu bug 1758409 in cloud-init "integration tests: restructure ssh timeout " [Undecided,New] [18:27] * blackboxsw removes python-jsonschema deb from my env as it should have failed for me locally [18:29] blackboxsw: i was pinging becauase of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341998 [18:30] which dojordan pointed out. [18:30] if we wanted to touch that like this... or just go for the bigger fix [18:31] * blackboxsw looks over read_file_or_url implemetation [18:31] dang, ok missed the third caller [18:33] hrm. I think we should just go for the bigger fix since we have context at the moment. it shouldn't be that big. OpenStack. Scaleway, Ec2 and Azure. Then we don't have to revist risk in 18.3 SRU validation too [18:34] smoser: well, actually, I have to get through your IBMcloud run too and I'd like us to make a bionic cut today including it if we can [18:34] blackboxsw: sure. [18:34] i can work on b igger fix [18:34] so, I wouldn't be able to write up that branch. :/ so don't want to force you to do it [18:34] but we can just as well take the small one now. [18:34] yeah +1 [18:34] will approve [18:35] note that https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341995 [18:35] made jenkins catch the failure [18:37] blackboxsw: just becausae youre bored... [18:37] https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/340546 [18:38] that has a comment on it with a bad hash [18:38] (ie, click the link) [18:39] @blackboxsw, random question. Any reason why the upstream commit https://git.launchpad.net/cloud-init/commit/?id=2d618e27 isn't showing up? [18:39] haha [18:39] :) [18:39] i had that typed out but assumed it was a stale cache or something [18:40] interesting.... hmm, checking how the lander got that hash [18:41] hrm hold up. [18:46] dojordan: smoser ok fixed. I had the lander sitting at pdb [18:46] it did all the launchpad work, just didn't git push [18:46] hahaha [18:46] nice === r-daneel_ is now known as r-daneel [18:58] smoser: minor tweak and then approved https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341997 [19:19] blackboxsw: maybe it wasnt clear to you why you had jsonschema in your tox env. [19:19] its in requirements.txt [19:19] so it gets put in there by setup.py [19:20] so we could either deal with "optional" things in a generic way, which woudl be fine or like this. [19:20] smoser: yeah, I just generally had performed a pip remove of it when testing new schema additions, I forgot about that when I put up test_snap and test_ubuntu_advantage [19:20] but for the moment thats the only optional [19:20] this way C-I will catch it for you. [19:20] hence the tests which passed locally, (because or requirements.txt) [19:20] yeah [19:20] I like that [19:21] smoser: and oauthlib right? [19:22] as for optional requirements [19:22] and pyserial :) [19:22] ohh right yep [19:22] so we could do something more generic [19:22] but the schema is the most invasive [19:22] the others are very optional paths [19:24] yeah I think your approach in tox -e xenial. it at least asserts we are exercising optional paths without the dependency [19:25] we could come up with something a bit more generic if we have more cases I guess. [19:26] can you rebase and push https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341995 so we get the pretty ci green [19:26] now that you've landed the prior branch [19:27] done [19:28] blackboxsw: wow. MAAS comopatibiltiy testing takes 11 minutes now [19:28] i swear it wasnt that long before [19:28] powersj: ^ [19:28] https://jenkins.ubuntu.com/server/job/cloud-init-ci/ [19:28] something got slower... but of course i have to data to that. [19:29] that's about right [19:29] that was half the ci time [19:29] well, it looks like its more 2/3 now [19:30] but ohw ell [19:30] the other times, for reasons unknown to me, seem to have gone down [19:30] I know blackboxsw and I found a number of test escapes last fall and fixed them [19:31] The build and the integration tests specifically [19:31] right, yeah invalid mocks w/ httpretty, but yeah I don't know what else would have been improved [19:32] I would like to consider moving the maas compat back out and run it only nightly on trunk [19:47] blackboxsw: c-i happy now [19:47] then bbsw is happy [19:47] and i updated the commit message [19:51] landed [19:51] IBMcloud next [19:51] then chrony/ntp [21:24] minor comments on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/341774ConfigDriveReader [21:24] sans the ConfigDriveReader [21:26] blackboxsw: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/342007 [21:26] thats not all the way done.. but [21:27] blackboxsw: i had thought the .json thing too... [21:28] i dont know. [21:28] smoser: yeah I just have a hard time looking over 3 item tuples instead of two. take it or leave it not critical by any means [21:29] blackboxsw: i really have to go now. [21:29] i'd like to have that in too, bjut just out oftime [21:29] if you want you can take it and just finish it. [21:30] i'm really 30 minutes over :-( [21:30] +1 see ya. [21:30] have a good weekend [21:30] i will pop backc in if you have aMP for upload [21:30] +1 will have one [21:30] just because that is "easy" [21:30] later [21:35] hrm, all of the reword of the url reading makes me a little nervous, post 18.2, right ? [21:38] rharper: your comment on the ibmcloud branch.... blocker for release or tech-debt we can pickup as a separate branch? [21:38] Shouldn't we update util.find_devs_with() to make use of this? or some other refactoring [21:38] since we now have to callers to blkid? [21:38] not a blocker [21:38] I understand the two modes [21:38] but it is tech debt IMO [21:38] I see your point, lots of commonality with find_devs_with. it seems like a good candidate for consolidation though [21:39] find_devs should be implemented with util.blkid() however, util.blkid needs to change to accept the parameters that are in-use by find_devs_with() [21:39] so, that'll be a bit of refactoring [21:39] agreed [21:40] your comment about the reword of url reading is related to this one right? https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/342007 [21:41] well, there are like at least two no? the raise exception, and then the follow up ? [21:41] yeah we've landed the prior already which was to invest the readurl(exception_cb) logic to continue retries when exception_cb returns True. False == raise [21:42] blackboxsw: the invert and then consistent [21:42] rharper: right those have both landed, invert and consistent across 4 datasources [21:42] =/ [21:42] ok [21:43] yeah, it was inconsistent for OpenstackDatasource for months. resulting in long retries on 404s [21:43] I should have spoke sooner; those sort of changes seemed post 18.2 release, but I guess we'll just need to poke on them [21:43] Openstack 404ed in what scenario ? [21:44] https://bugs.launchpad.net/cloud-init/+bug/1702160 [21:44] Ubuntu bug 1702160 in cloud-init "OpenStack datasource should not retry user-data on 404" [Medium,Fix committed] [21:44] when no user-data is provided, it'd retry to exhaustion [21:44] instead of bailing and continuing [21:46] lol [21:46] why wouldn't the file be empty ? [21:46] and finally smoser's last attempt is to change behavior of exception_cb to actually raise if needed, instead of expecting that readurl will do the raise. only reason I thought about getting that 'in' is because we are already exposed on the exception_cb changed behavior front [21:47] so might as well only cross that changed-behavior on 4 clouds once. [21:47] y [21:47] it all makes sense, just wish it was post 18.2; we have one more release before 18.04 anyhow; but I guess for bionic, at least, sooner is better [21:47] it does worry me re: SRU though [21:49] +1, yeah we'll have to manually exercise upgrade path and fresh install on Openstack too (we already handle Azure/ec2). Not sure what to do about Scaleway though [21:50] I'll give ec2 a run right now with tip before we cut an MP for publish to bionic (just to make sure the system hasn't been killed) [21:50] y [23:08] just tested on EC2 with tip of smoser's branch. [23:08] I'm awaiting a jenkins integration test then I'm merging and proposing a bionic release [23:08] https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-ci/922/ [23:09] tested on azure earlier today with basically the same content (regarding the exception_cb behavior changes as do-jordan's branch had to account for that) [23:29] smoser: it's up for review [23:29] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/342011 [23:29] if you wanted to enable IBMCloud in debian cloud.cfg.tmpl go4it [23:29] :)