[13:49] <smoser> larsks, i'm sorry to bother you.
[13:49] <smoser> https://bugs.launchpad.net/cloud-init/+bug/1692424
[13:49] <smoser> that has audit.log there now, and it does seem to say that 'passwd' is being denied. can you at least confirm that ?
[13:51] <larsks> smoser: that looks like what it is saying, yes.  I'm not sure that's a cloud-init bug, though.  I wonder if someone modified the image and neglected to re-label the filesystem?
[13:51] <larsks> I am pretty sure that cloud-init (both 0.7.5 and 0.7.9) are in use under EL7 without this problem cropping up.
[13:53] <larsks> I wonder if Anil can share the image that is resulting in this issue?
[14:04] <smoser> larsks, yeah. thanks.
[14:05] <smoser> what is "neglected to re-label the filesystem"
[14:05] <smoser> ?
[14:07] <larsks> smoser: applying correct selinux labels to filesystem objects.  E.g., if you replace a file, the new file will probably not have the correct selinux labels.  There are various of ways of addressing that...
[14:07] <larsks> E.g., the 'virt-customize' command has a --selinux-relabel option.
[14:07] <smoser>  thanks
[14:07] <larsks> I'm going to ask Anil if we can get access to the image that is having these issues.
[14:07] <smoser> good
[14:08] <smoser> i was just going to ask if you wanted me to mess up your words (unintentionally) or if you wanted to ask yourself in the bug :)
[14:08] <smoser> thanks!
[15:28] <blackboxsw> smoser: what's the difference in actual behavior between dmi_product_name_is and dmi_product_name_matches in ds-identify? It looks shallowly that they are dupes but I bet I'm missing shellisms of case handling vs direct equality comparison
[15:30] <blackboxsw> ahh n/m *_matches handles globbing or regex
[15:32] <blackboxsw> ahh n/m *_matches handles globbing or regex:q
[15:33] <blackboxsw> oops
[15:40] <smoser> right.
[15:40] <smoser> if you dont give it a shell glob, then they're equal
[15:43] <blackboxsw> feels like we could drop dmt_product_name_is as we can pass that string w/out the glob as $1  to get the same behavior as dmi_product_name_is
[15:44] <blackboxsw> feels like we could drop dmi_product_name_is as we can pass that string w/out the glob as $1 to dmi_product_name_match to  get the same behavior as dmi_product_name_is
[15:45] <blackboxsw> but maybe folks like the explicit semantic difference of the function name dmi_product_name_is versus dmi_product_name_matches
[15:55] <smoser> blackboxsw, i'im trying to launch you an instance on azure
[15:55] <smoser> having issues with login right now
[15:55] <blackboxsw> thank you sir. that'll help a lot.
[15:55] <blackboxsw> if it's too much work I can just setup an account
[15:55] <blackboxsw> then you don't have to be remote hands for me  :)
[16:00] <smoser> ok. that is sorted, launching now.
[16:04] <smoser> blackboxsw, what is your preferred user name ?
[16:04] <smoser> csmith ?
[16:05] <smoser> blackboxsw, ssh csmith@chad-testing.cloudapp.net
[16:05] <blackboxsw> csmith would be perfect thx
[16:06] <blackboxsw> I'm in thanks smoser
[16:17] <smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324625
[16:17] <smoser> could you take a review of that ?
[16:17] <blackboxsw> on it smoser
[16:19] <blackboxsw> strange LP is showing no diff.  Pulling it into my local branch to check
[16:20] <smoser> see my third comment there, blackboxsw
[16:20] <smoser> This has no merge proposal shown because of bug 1693543
[16:21] <blackboxsw> ahh interesting
[16:26] <smoser> blackboxsw, i'd just re-submit, but i dont know if it will hit it again.
[16:30] <blackboxsw> it's no prob smoser . It's just 3 commits right, your 2 plus Junjie right?
[16:30] <smoser> right.
[16:31] <smoser> i'll squash them, so you can view the individual commits just as context
[16:33] <blackboxsw> smoser: what's fastest for ds-identify, reading dmi content or metadata directory? I'd expect the former , dmi from sysfs
[16:33] <blackboxsw> I'm wondering why ds-identify in that branch doesn't check sysfs first and then metadata 2nd
[16:36] <blackboxsw> especially because the DMI product_name is already cached as a script var per collect_info
[16:38] <smoser> blackboxsw, looking
[16:40] <smoser> blackboxsw, http://paste.ubuntu.com/24716726/
[16:41] <smoser> there, you're asking aobut line 202 ?
[16:41] <smoser> you're probably right on the speed thing, since the dmi values are alreaady set
[16:41] <blackboxsw> smoser: yeah seed check should come after dmi check
[16:42] <smoser> but the seed dir is really just a completely separate path. seed is really kind of just for testing.
[16:42] <smoser> so i guess the justification for the order is that the datasource looks in the order (seed and then dmi)
[16:43] <smoser> ie, if you have seeded that datasource it wont look at the dmi data (and thus wont actually even read the metadata service)
[16:44] <smoser> random ... unrelated ..
[16:44] <smoser>  i found out about https://repl.it/languages/python3 over the weekend.
[16:44] <blackboxsw> ahhh
[16:44] <smoser> it is pretty cool
[16:46] <blackboxsw> so in the datasource itself, (per order of seed before sysfs) if that is an inefficient order would be want to eventually change it in both places?
[16:46] <blackboxsw> both places being ds-ident and the datasource itself
[16:46] <smoser> well, its not inefficient as preference
[16:46] <blackboxsw> ahh ok
[16:46] <smoser> if you put seed data in /var/lib/cloud/ for almost any datasource, then you are basically disabling searching
[16:48] <blackboxsw> ahh nice on the autocomplete IDE :)
[16:48] <smoser> yeah, it even has really nice (seeming) vi keybindings
[16:50] <blackboxsw> smoser: order matters in default datasource detection right? Because ..  AliYun Ec2... because AliYun is a more specific case of Ec2 right?
[16:52] <smoser> umm.
[16:53] <smoser> so i *think* that i made it such that DataSourceEc2 will not recognize a aliyun and AliYun will not recognize Ec2
[16:53] <smoser> ie, aliyun does not provide the dmi platform info that Ec2 does
[16:54] <smoser> (if it did, and Aliyun was after Ec2 in the list, then that would break aliyun)
[18:04] <blackboxsw> smoser: finally finished the review. I've approved pending some minor fixes and I'll watch for your comments on that branch just to clarify points and my understanding of datasource order.
[18:05] <blackboxsw> smoser: that last comment you made was my understanding about the order and precedence or the datasources in the list "if it did, and Aliyun was after Ec2 in the list, then that would break aliyun".    Thank you for confirming.
[18:41] <smoser> blackboxsw, i responded to that mp. i'll make most of the changes you suggested and ask for re-rview.
[18:42] <smoser> i think if aliyun changes their platform to look like they are amazon, then t hey'd kind of have to expect that guests would all of a sunden think they were on amazon.
[18:50] <smoser> powersj, when cjwatson said to me...
 smoser: don't have enough brain right now to work out whether it will hit it again, but you can try rescanning the repository using the API: https://launchpad.net/+apidoc/devel.html#git_repository-rescan
[18:50] <smoser> have you looked at doing such a thing ?
[18:51] <nacc> i've also foudn that resubmitting the MP works (re-propose?) it does supersede it, but you can keep the old comments
[18:51] <smoser> ie, if its easy and youv'e done it before, i'd like to kicki it on
[18:51] <smoser>  https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324625
[18:51] <powersj> I have not, but I would like to as that MP has generated 300+ emails to my
[18:51] <smoser> i guess i can just try re-submit
[18:51] <powersj> to me*
[18:51] <powersj> please do :)
[18:51] <nacc> it's a button int he top right, iirc
[18:51] <powersj> not having a diff has made the CI job think it needs a review
[18:52] <smoser> didnt fix it
[18:52] <smoser> :-(
[18:53] <powersj> ok I'll look at rescan while I eat lunch in a bit.
[18:53] <smoser> i am pretty sureits because i changed Junji's name in a commit message.
[18:53] <smoser> and i suspect it wont help if we kick it another way
[19:15] <powersj> smoser: https://paste.ubuntu.com/24717938/ you may need to try that as I don't have uber-user privs on cloud-init
[19:15] <powersj> actually I logged in as anon... that might be why
[19:17] <powersj> effectively you would want to try this I think: https://paste.ubuntu.com/24717974/
[19:37] <smoser> powersj, ran that with python2.
[19:37] <powersj> smoser: no 401 auth error?
[19:38] <smoser> it did run to completion
[19:38] <smoser> dont knwo what that means.
[19:49] <smoser> blackboxsw, i didnt realize your comment on the P_PRODUCT_NAME was from ds-identify test rather than from the datasource test
[19:49] <smoser> my response still kind of applies
[19:49] <smoser> i dont have really strong feelings
[19:57] <blackboxsw> same here smoser, just finished a reply on the MP. I don't really have strong feelings about it, I just like less duplication wherever possible
[19:58] <blackboxsw> we've combined spent way more time that needed for how on the fence I am.
[20:06] <smoser> agreed.
[20:09] <smoser> copying the variable into the unit tests ensures against future accidental breakage.
[20:09] <smoser> at least more so.
[20:09] <smoser> we have diff at https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324807 now
[20:13] <smoser> blackboxsw, i'm going to leave tests/unittests/test_ds_identify.py unmodified
[20:13] <smoser> in order to maintain consistency
[20:13] <smoser> i'm not opposed to a cleanup though
[20:13] <smoser> (other data there uses copied strings)
[20:14] <blackboxsw> +1 smoser
[20:15] <blackboxsw> woot visual diff
[20:15] <smoser> now i'm going to see if i break it
[20:26] <smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324807
[20:26] <smoser> i thin i've addressed all your feedback there
[20:26] <smoser> (other than *adding* a copy of that string)
[20:27] <blackboxsw> thanks checking
[20:33] <blackboxsw> smoser: you're good on that branch thanks
[20:42] <smoser> merged. thanks.
[20:44] <smoser> oh fudge
[20:44] <smoser> we missed one blackboxsw
[20:44] <smoser> the settings test
[20:45] <smoser> as in why did that still pass
[20:46] <blackboxsw> ahh right the NonDefault
[20:46] <blackboxsw> looking
[20:47] <smoser> oh.
[20:47] <smoser> the change was made to fix test_expected_default_network_sources_found
[20:47] <smoser> we just now have no need for test_expected_nondefault_network_sources_found
[20:47] <smoser> as it is essentially covered now in the former
[20:50] <blackboxsw> smoser: agreed. Yeah it was only to cover non-default cloud datasources which now no longer exist.
[22:02] <askb> smoser, ping
[22:02] <askb> smoser, wondering if you got a chance to look into the updated for 1692424