| === sambetts|afk is now known as sambetts | ||
| === rangerpbzzzz is now known as rangerpb | ||
| smoser | rharper, so i dont think this behavior has changed. | 15:28 |
|---|---|---|
| smoser | but in order to make ds-identify be strict on ec2, you have to set the cloud-init setting in either /etc/cloud/cloud.cfg or /etc/cloud/cloud.cfg.d/[Ee][Cc]2*.conf | 15:29 |
| smoser | datasource: | 15:29 |
| smoser | Ec2: | 15:29 |
| smoser | strict_id: true | 15:30 |
| smoser | basically, its not a ds-identify setting, its a cloud-init setting that ds-identify respects, (and attempts to read more quickly by being specific on which files are read) | 15:31 |
| rharper | so, I know it's changed; I built the image and tested explicitly in the core image that if you don't supply a datasource, it skips starting cloud-init; | 15:36 |
| rharper | when I rebuilt the core snap on Friday, it picked up cloud-init from xenial-updates and it ran cloud-init and tried to hit ec2 | 15:36 |
| rharper | how would we have gotten to ec2 datasource anyhow if I have found=first,maybe=all,notfound=disabled ? maybe can't have network datasources, and if we didn't find ec2, then we should have disabled cloud-init | 15:38 |
| rharper | smoser: ^ | 15:39 |
| smoser | ec2 returns maybe unless strict is set | 15:40 |
| smoser | it has to. as "maybe there is an ec2 metadata service here" | 15:40 |
| rharper | on my local system ? | 15:40 |
| smoser | possibly you ran previously on non-intel ? | 15:40 |
| rharper | xenial laptop | 15:41 |
| smoser | how am i to knwo that there is not a ec2 metadata service there? | 15:41 |
| rharper | lol | 15:41 |
| rharper | I though if we don't see ec2 in UUID, then no network hit unless you have notfound=enabled ? | 15:42 |
| rharper | s/though/thought | 15:42 |
| rharper | maybe says that no network datasource can return a maybe | 15:42 |
| rharper | so, found=first would have had to have had a uuid of startswith('ec2') | 15:42 |
| smoser | that is what strict is | 15:43 |
| smoser | you're defining the behavior in strict | 15:43 |
| rharper | so, let me ask a different way; if I want to prevent cloud-init from running unless it's found a ds; I don't want maybes at all (even though they are supposedly non-network); what do I set ds-identify to ? | 15:45 |
| smoser | maybe isn't "no network", its just "there is no information available that says this is not a potential source". | 15:47 |
| smoser | "no network sources are allowed to return 'maybe'." | 15:49 |
| smoser | ^-- except ec2 | 15:49 |
| smoser | :-( | 15:49 |
| rharper | what ? | 15:50 |
| rharper | something changed | 15:50 |
| rharper | so maybe you fixed it to allow ec2 to retrun | 15:50 |
| rharper | I'm switching to maybe=none | 15:50 |
| rharper | which is also fine | 15:50 |
| rharper | however | 15:50 |
| rharper | I'm still seeing the generator run when I provide no user-data locally | 15:50 |
| rharper | so something is broken; I'm going to diff cloud-init from my image a few weeks ago vs what's in xenial-updates | 15:51 |
| rharper | to see if there are any ds-identify changes | 15:51 |
| smoser | i know what changed for you. | 15:54 |
| smoser | hm... or maybe i dont | 15:54 |
| smoser | but it is packaging that is only available in the ubuntu/xenial branch that changes the default behavior of strict_id on ec2 | 15:55 |
| smoser | of course the generator runs | 15:55 |
| blackboxsw | smoser, do we need to worry about support of unit tests in dev environment for cloud-init on a fresh xenial system? | 15:56 |
| rharper | http://paste.ubuntu.com/24448558/ | 15:56 |
| blackboxsw | or rharper | 15:56 |
| rharper | smoser: that's the change to ds-identify from 3/31 to friday | 15:56 |
| rharper | (what's in xenial-updates) | 15:57 |
| smoser | blackboxsw, unit tests as in running 'make' ? or as in running 'tox' | 15:58 |
| blackboxsw | so s/search/report from ds-identify updates. /me is lurking/learning about ds-identify behavior | 15:58 |
| smoser | they wont "just work", you need python dependencies. you have to get python dependencies in some way | 15:58 |
| smoser | either | 15:58 |
| smoser | a.) install the runtime (and build-time) dependencies listed in the ubuntu/ branches debian/control | 15:59 |
| smoser | (or the trunk packages/debian/control.in) | 15:59 |
| smoser | b.) use tox to install the dependencies with virtual-env or pip or whatever. | 15:59 |
| blackboxsw | smoser, both fall over on my xenial system missing various dependencies out of the box. tox runs on fresh yakkety no prob, but make test needs some updated system pkgs as you said | 15:59 |
| smoser | tox does not run on xenial "fresh" ? | 16:00 |
| smoser | how do you define "fresh". | 16:00 |
| blackboxsw | a new xenial lxc without additional dev packages installed. | 16:00 |
| blackboxsw | a new xenial lxc without additional dev packages installed == "fresh" | 16:00 |
| blackboxsw | :) | 16:00 |
| smoser | rharper, where did you get your package from in the 'from' portion of that | 16:01 |
| rharper | probably master before the release, let me find it | 16:01 |
| smoser | blackboxsw, good. so i'm surprised that yakkety would work. | 16:01 |
| rharper | I would have done a package build from master and pushed to ppa | 16:01 |
| smoser | right. | 16:02 |
| smoser | which meant you didnt pick up xenial packaging modifications | 16:02 |
| smoser | the daily ppa will have xenial packaging modifictions | 16:02 |
| * blackboxsw isn't blocked. I'll just poke at a couple things to firm up this assessment and make sure I didn't try tox on an lxc I had already installed ome deps on. | 16:02 | |
| smoser | as it builds from trunk + ubuntu/xenial branch | 16:02 |
| rharper | smoser: possible not | 16:02 |
| rharper | https://launchpad.net/~raharper/+archive/ubuntu/snapbuilds/+files/cloud-init_0.7.9-87-gd23543e.orig.tar.gz | 16:02 |
| smoser | rharper, i suspect that is what it is. that you built with ./tools/bddeb there, right ? | 16:03 |
| rharper | y | 16:03 |
| smoser | yeah, that is trunk's behavior. which is what you wanted. | 16:04 |
| rharper | I really hate tripping over this stuff though | 16:04 |
| smoser | xenial changes that behavior | 16:04 |
| smoser | for stable release reasons | 16:04 |
| rharper | surely I can configure it from ds-identify.cfg | 16:04 |
| smoser | no. because its not a ds-identify setting. its a cloud-init setting. that ds-identify respects. | 16:05 |
| rharper | =( | 16:05 |
| rharper | I don't want to have to hotpatch cloud-init in core but it looks like I have to | 16:05 |
| smoser | yeah, which sucks for you as you have no input into the cloud-inti settings. | 16:05 |
| smoser | rharper, https://code.launchpad.net/~cloud-init-dev/+archive/ubuntu/daily | 16:06 |
| smoser | that *does* have trunk + ubuntu packaging for each release. | 16:07 |
| rharper | sure, I know of it | 16:07 |
| smoser | so thats the recomended way of grabbing it. i knwo that doesnt really help. | 16:07 |
| rharper | I can't always rely on that since we've been testing before fixes/features have landed | 16:07 |
| rharper | for example the network-v2 stuff | 16:07 |
| rharper | I needed to stack the solution together; wait till it landed in truck and then use it | 16:07 |
| rharper | turns out the "patch when built on xenial" bit me (again) | 16:08 |
| smoser | yeah, then you need to do something else (or you could set up a recipe build from your branch). or do a recipe build itself. | 16:08 |
| rharper | I don't want to have a recipel I just want zesty cloud-init behavior in xenial | 16:08 |
| rharper | so, whatever we need to do to get it, I need to learn how ASAP | 16:08 |
| rharper | if it's hotpatching cloud-init, I'll do that in the core recipe | 16:08 |
| smoser | well, you can't do that on xenial right now without a config file change or a change to ds-identify | 16:09 |
| rharper | but ideally we control this with cfg files that core can lay down | 16:09 |
| rharper | I'm ok with the config file change | 16:09 |
| smoser | ? | 16:09 |
| rharper | we write out a ds-identify.cfg file in core recipe | 16:09 |
| smoser | not ds-identify config | 16:09 |
| smoser | clodu-init config. | 16:09 |
| rharper | sure | 16:09 |
| rharper | I'll take that too | 16:09 |
| smoser | then as i said above | 16:09 |
| rharper | the Datasource: | 16:09 |
| rharper | Ec2: | 16:09 |
| smoser | yes | 16:10 |
| rharper | hrm; so I'm still seeing the generator *start* cloud-init | 16:10 |
| rharper | that's not Datasource related (ec2) | 16:10 |
| rharper | so maybe I need that ds-identify change too (s,report,search) in addition to the ec2 datasource change too | 16:11 |
| blackboxsw | smoser, you mentioned you were working on ds-identify unit tests. Where will that unit test live? Under lp:cloud-init/tests subdir or down in ./tools? I'm asking as I'm looking to add some simple unit tests for ./tools/read-dependencies | 16:18 |
| blackboxsw | and I want to follow the same convention for other ./tools/ modules | 16:19 |
| smoser | blackboxsw, probalby tests/unittests/ let me see what i have | 16:20 |
| blackboxsw | although, maybe read-dependencies doesn't need unit test coverage as it's just a facility to setup your environment that's not used in cloud-init proper | 16:20 |
| smoser | i think i agree with you. | 16:24 |
| rharper | smoser: I think my policy is getting ignored; http://paste.ubuntu.com/24448820/ | 16:25 |
| rharper | also OVF is always returning DS_MAYBE (it's local) ; but I suspect that's new | 16:25 |
| smoser | http://paste.ubuntu.com/24448826/ | 16:25 |
| rharper | so then we always think we might be OVF if you have a cdrom in the instance at all (which seems broken) but not harmful on xenial, but broken on zesty (AFAICT) | 16:25 |
| smoser | that is not new though | 16:26 |
| smoser | # FIXME: currently just return maybe if there is a cdrom | 16:26 |
| smoser | # ovf iso9660 transport does not specify an fs label. | 16:26 |
| smoser | # better would be to check if | 16:26 |
| smoser | return ${DS_MAYBE} | 16:26 |
| rharper | we're setting cloud-init to run if we have a maybe | 16:26 |
| rharper | I have in the policy file maybe=none | 16:27 |
| smoser | blackboxsw, that was agree that i owuldnt bother writing unit tests for read-dependencies. | 16:27 |
| rharper | and we still run cloud-init | 16:27 |
| smoser | hm. | 16:27 |
| smoser | can i see ? | 16:27 |
| rharper | see the paste, right ? | 16:27 |
| blackboxsw | +1 dropping that test idea for tools/read-dependencies idea smoser | 16:28 |
| rharper | smoser: the most recent change was the ds-identify change to config drive path | 16:28 |
| rharper | git show 169a7105 | 16:29 |
| rharper | smoser: so, need policy: in the start of the file to get thing set; | 16:32 |
| rharper | smoser: I'll work up a patch to log that ds-identify looked at a ds-identify file but didn't file a policy; it would have helped poke me in the eye that I didn't format the policy config properly ; that sound OK ? | 16:38 |
| smoser | rharper, i'lm looking at this. you're right its busted. | 16:40 |
| smoser | rharper, i was wrong. | 16:44 |
| smoser | its your input that is busted. probably bcause there is no doc. | 16:44 |
| rharper | smoser: ack | 16:45 |
| rharper | hence the patch to log that it read a policy file but found none | 16:46 |
| rharper | that'd be a nice fat warning in the log file that you didn't format it properly | 16:46 |
| rharper | and I'll likely include a line like 'If you'd like strict behavior as in zesty, use the following line: XXX' | 16:47 |
| smoser | but you actually dont need that. | 16:47 |
| smoser | right ? | 16:47 |
| smoser | you dont need to set that there. | 16:47 |
| rharper | sure; but since I'm attempting to maintain "run xenial more strictly than default, use this config" | 16:48 |
| rharper | I wanted it documented (and ideally unittested) | 16:48 |
| rharper | so when I screw it up again (or change how I build the core snap, or whatever) we have a very clear doc on what it *should* look like | 16:48 |
| smoser | better doc of the config file format is fine. | 16:50 |
| smoser | unit tests are fine | 16:50 |
| rharper | logging that it found a policy file (ds-identify.cfg) but found no settings (missing ^policy: ) | 16:50 |
| rharper | fine ? | 16:50 |
| smoser | i'm not interested so much in documenting | 16:50 |
| smoser | ci.datasource.ec2.strict_id: true | 16:50 |
| smoser | if you want to warn that no policy was set, thats fine. but you can't warn in the following cases: | 16:52 |
| smoser | a.) empty ds-identify.cfg (thats perfectly fine) | 16:52 |
| smoser | b.) contains only : ci.datasource.ec2.strict_id: true | 16:52 |
| smoser | c.) contains only comments '# this is wehre i would put a setting' | 16:52 |
| rharper | I didn't want a warning | 16:52 |
| rharper | I just want to log it in ds-identify.log | 16:52 |
| rharper | ie, nothing printed outwardly | 16:53 |
| smoser | warning/logging, thats fine. but still same behavior. | 16:53 |
| rharper | but ack to a-c | 16:53 |
| rharper | I think (a) seems odd; b) is something we mention to do which is fine 3) ack to ignoring comments | 16:54 |
| rharper | what's OK about a) ? | 16:54 |
| smoser | thats pretty standard behavior. | 16:54 |
| rharper | to touch a file; yes; but what do we do differently with an empty policy file ? | 16:54 |
| rharper | the defaults? | 16:54 |
| smoser | yeah, that woudl take defaults. | 16:54 |
| rharper | seems like one would get that without the file though; | 16:54 |
| smoser | and thats perfectly fine. | 16:55 |
| smoser | and its fine to have an empty file. | 16:55 |
| rharper | well, depending on the core | 16:55 |
| rharper | code | 16:55 |
| rharper | in some cases the mere presence changes behavior | 16:55 |
| rharper | 'etc/cloud/cloud-init.disabled ' | 16:55 |
| blackboxsw | strange, so we "want" to avoid duplication of dependencies outside of the control file in cloud-init by using a makefile target or dependency install script, but we basically have that duplication already in tools/bddeb which defines a package name lookup for any deb package dependency in STD_NAMED_PACKAGES / NONSTD_NAMED_PACKAGES | 17:10 |
| smoser | well, we declare python (pypi named) pythonn dependencies once | 17:11 |
| smoser | we have to translate those to ubuntu package names . thats unavoidable. | 17:11 |
| blackboxsw | it seems it's only unavodable because our control file has parameterized test_requires | 17:12 |
| smoser | and the fact that names are not consistently mapped from pypi -> ubuntu is simply fact | 17:12 |
| blackboxsw | right | 17:12 |
| blackboxsw | if it were hardcoded in debian/control we wouldn't have to lookup/translate though | 17:12 |
| blackboxsw | just write it in debian/control instead of a pkg name lookup in tools/bdeb. | 17:13 |
| blackboxsw | I guess the lookup us something for pip names which conform to python-<packagename> | 17:13 |
| smoser | well,, i guess we could just drop the STD_NAMED_PACKAGES, adn then use the standard naming confvention if not presnt in NONSTD_NAMED_PACKAGES | 17:13 |
| smoser | but if we write it in debian/control, then new adds need 2 touchees. | 17:14 |
| blackboxsw | smoser, it kinda feels like that STD_NAMED_PACKAGES is superfluous. Do we run integration/install tests with the built deb? | 17:14 |
| smoser | yes. | 17:14 |
| smoser | and yeah, i sgree with std_named_packages being superflous. | 17:15 |
| blackboxsw | ok, yeah so we could drop STD_NAMED_PACKAGES I guess as our install test should cover that aspect | 17:15 |
| blackboxsw | +1 will work on that | 17:15 |
| blackboxsw | as part of this small PR | 17:15 |
| blackboxsw | (pull request0 | 17:15 |
| smoser | i guess the only value it has right now... | 17:16 |
| smoser | is that you get a nicer error message | 17:16 |
| smoser | in bddeb says | 17:16 |
| smoser | Do not know how to translate pypi " | 17:16 |
| smoser | "dependency %r to a known package" | 17:16 |
| smoser | where if you didnt have that , you wouldjust get a fail later . but maybe that is obvious enough | 17:17 |
| smoser | https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323059 | 18:31 |
| smoser | rharper, ^ | 18:31 |
| === sambetts is now known as sambetts|afk | ||
| blackboxsw | Just posted a near trivial up for "make deb". Some cleanups in packages/bddeb. | 21:22 |
| === rangerpb is now known as rangerpbzzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!