[06:16] <elurkki> smoser: CentOS 7.4 & cloud-init 0.7.9 didn't set the gateway when used earlier user-data and meta-data files with NoCloud. Managed to figure out the network-config syntax and now all the network configurations are set correctly.
[10:04] <mtangaro> Dear experts, I've a problem with Cloud-init or at least I think so
[10:04] <mtangaro> can you please help me?
[14:17] <smoser> robjo, around ?
[14:20] <smoser> responded to both your mps
[14:32] <robjo> on the phone, will check after, thanks
[14:54] <smoser> k
[16:09] <robjo> smoser: https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331142 should hopefully meet the needs
[16:30] <smoser> robjo, are you ok if i change the indent on 'Copyright' ?
[16:31] <robjo> sure
[16:35] <smoser> robjo, ok. and is it ok if i just drop the copyright ?
[16:35] <smoser> i think they're 99% largely harlowja work anyway.
[16:36] <robjo> Yeah, I guess, this is going away in 2019 anyway when SLE 11 dies, I can't wait.....
[16:37] <smoser>  http://paste.ubuntu.com/25587157/
[16:39] <smoser> thats the diff from redhat/* to suse/*
[16:41] <robjo> yup, just off enough to be annoying, I know
[16:42] <smoser> i think then we shoudl just do a straight copy and then make the changes that matter
[16:42] <smoser> is that ok ?
[16:42] <smoser> we could do some integration or templating, but sysvinit in suse and redhat are both really EOL
[16:42] <smoser> so that doesn't make much sense.
[16:43] <kszarlej> hey guys, I have a Libvirt VMs that are using cloud-init provided by the 'config drive'. Is this possible using cloud init to setup the eth0 interface when booting the instance? I use in my network only static addressing and I dont want to add DHCP server
[16:43] <robjo> Yes copy and then changing the bits where it matters also works for me
[16:44] <kszarlej> So instance starts with no configured interfaces -> cloud init configures statically the eth0
[16:48] <smoser> robjo, http://paste.ubuntu.com/25587206/
[16:48] <smoser> thats what i would do on top of your branch
[16:49] <smoser> which leaves me with
[16:49] <smoser>  http://paste.ubuntu.com/25587211/
[16:49] <smoser> as (redhat -> suse differences)
[16:49] <smoser> robjo, i'm sorry that i didnt realize at the start that you had copied the redhat/ scripts
[16:49] <smoser> i assumed they'd come from your packaging or something
[16:49] <smoser> sorry
[16:49] <smoser> kszarlej, not statically
[16:50] <smoser> oh. sorry. wait.
[16:50] <smoser> kszarlej, "config drive"
[16:50] <kszarlej> ye
[16:50] <smoser> is that meaning "OpenStack config drive" ?
[16:50] <smoser> or meaning "configuration disk" more generically
[16:50] <kszarlej> I am creating .iso with 'user-data' and 'meta-data'
[16:50] <smoser> right.  NoCloud then.
[16:50] <kszarlej> and I mount it to VM as 'cdrom' device
[16:51] <kszarlej> and the VM recognizes it just fine
[16:51] <smoser> 'config drive' is a term that means something specifically to openstack.
[16:51] <smoser> sorry. i was just trying to clarify what you were asking
[16:51] <robjo> smoser: http://paste.ubuntu.com/25587206/ looks fine, do not recall the origins os the sysvinit stuff it's been too long, been carrying those patches in cloud-init package forever
[16:51] <kszarlej> I have problem setting up the dnsmasq in my network infrastructure that would be leasing DHCPs to VMs.. and I am thinking if it would be possible to
[16:51] <smoser> ok. then robjo i'll pull those in with my changes.
[16:51] <kszarlej> configure the interfaces using cloud-init instead of DHCP
[16:52] <robjo> thanks
[16:52] <smoser> kszarlej, so on your disk with 'user-data' and 'meta-data'.
[16:52] <smoser> you need to
[16:52] <robjo> also replied on the other proposal
[16:52] <smoser> a.) set the label to be 'cidata'
[16:52] <smoser> b.) provide 'network-config' file in addition to user-data and meta-data
[16:53] <smoser> the network-config is described http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1.html#network-config-v1
[16:53] <kszarlej> so like that https://gist.github.com/Informatic/0b6b24374b54d09c77b9d25595cdbd47
[16:53] <kszarlej> ??
[16:53] <smoser> or http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#network-config-v2
[16:53] <kszarlej> ok smoser
[16:53] <kszarlej> thanks!!
[16:53] <kszarlej> I was looking for "cloud init config drive network configuration"
[16:54] <smoser> you do not need dsmode: local now
[16:54] <smoser> i'm 99% sure
[16:54] <kszarlej> and tried the network-interfaces: in meta-data
[16:54] <kszarlej> but I am failed :)
[16:54] <kszarlej> will try the network-config :)
[16:54] <smoser> network-interfaces is legacy
[16:54] <smoser> (as described in that do up there)
[16:54] <kszarlej> thanks!
[16:54] <paulmey> I have a case of vanishing tempdir... Any idea what might cause this? http://paste.ubuntu.com/25587235/
[16:55] <smoser> kszarlej, if you're able, its best to provide the mac address of the nic
[16:55] <smoser> that way cluod-init can
[16:55] <smoser> a.) rename the nic to whatever you want
[16:55] <paulmey> Is systemd mounting tmpfs on /tmp while cloud-init is in the middle of something?
[16:55] <smoser> b.) actually identify it, rather than you guessing the name that the kernel will give it.
[16:55] <smoser> paulmey, yes
[16:56] <smoser> sort of
[16:56] <smoser> paulmey, https://bugs.launchpad.net/cloud-init/+bug/1707222
[16:56] <smoser> not "mounting", but deleting
[16:57] <smoser> robjo, i'm going to pull the sysvinit changes for you
[16:58] <paulmey> hmmm... nasty
[17:02] <paulmey> smoser: thanks. That will be in the upcoming release, I assume?
[17:02] <smoser> yeah, i just marked it fix-committed.
[17:02] <paulmey> awesome thanks
[17:02] <smoser> note, it had fallout though
[17:02] <smoser> we changed to using /run/cloud-init/tmp
[17:02] <smoser> so that systemd wouldnt think it should just delete things for us
[17:03] <smoser> and that broke because /run is (typcially) mounted with 'noexec'
[17:03] <smoser> and at times we need exec
[17:03] <smoser> fun
[17:03] <paulmey> sigh... sorry for your pain...
[17:03] <smoser> i find the idea of deleting files under almost any criteria by a central daemon questionable.
[17:04] <paulmey> but getting into earlier boot races is a good condition to be in... ;-)
[17:04] <smoser> ie, there is stuff that will delete your files in /tmp if they're 30 days old
[17:04] <robjo> smoser: thanks
[17:04] <smoser> well... sometimes i put stuff there :)
[17:04] <smoser> i dont plan ahead of time how long i'll want to keep something for
[17:04] <paulmey> yeah... systemd is getting power hungry...
[17:09] <harlowja> smoser wut
[17:09] <harlowja> lol
[17:09] <smoser> harlowja, cloud-init misses you
[17:09] <harlowja> ya
[17:09] <harlowja> i miss her to
[17:09] <harlowja> lol
[17:11]  * dpb1 hands smoser /home
[17:12] <smoser> dpb1, i have ~/t/ for tmp files in /home that i think i might need later.
[17:12] <smoser> but sometimes i just dont know.
[17:13] <dpb1> smoser: I have a ~/tmp/
[17:13] <dpb1> for same
[17:13]  * smoser is 66% more effective than dpb1, but has to think about typing 'affective' or 'effective'
[17:14] <dpb1> hahaha @ affective
[17:14] <smoser> (googled that for kids last week. RAVEN: Remember Affect Verb Effect Noun)
[17:17] <smoser> rharper, what do you think...
[17:17] <smoser> https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331140
[17:17] <smoser> robjo's merge above
[17:17] <smoser> we can drop the duplicated 'Default user' section (line 31-44) with this change instead
[17:18] <smoser> http://paste.ubuntu.com/25587352/
[17:18] <smoser> ie, the only change that robjo put in there was different default groups
[17:30] <smoser> blackboxsw, what do you think ?
[17:30] <blackboxsw> was looking it over
[17:33] <smoser> basically i'm asking about whether to "nested loop" or "copy block"
[17:33] <smoser> er...
[17:33] <smoser> "nested if/else"
[17:34] <blackboxsw> smoser: it looks like it's the same content as centos/rhel/fedora too
[17:34] <smoser> ?
[17:34] <smoser> my diff should make it clear what is different
[17:34] <smoser>  http://paste.ubuntu.com/25587416/
[17:34] <blackboxsw> ahh didn't know your were talking about a pastebin. I was on robjo's branch
[17:34] <blackboxsw> yeah looking now
[17:35] <smoser> my pastebin there is on top of robjo's branch. (and *this* pastebin doesn't use undefined variables)
[17:35] <smoser> which is a nice feature i think (the last one spelled variant wrong)
[17:35] <blackboxsw> +1 on that pastebin as I was thinking kinda the same, we didn't want to copy a separate block for suse as it's nearly the same as rhel etc
[17:36] <blackboxsw> yeah I like that fix
[17:36] <blackboxsw> s/fix/patch
[17:36] <blackboxsw> gotta go for kid pickup
[17:36] <smoser> ok. then i am going to pull that also.
[17:36] <smoser> with my change there.
[17:40] <smoser> robjo, are you there ?
[17:40] <smoser> i do have some questions though on that mp.
[17:40] <robjo> smoser:  on the phone again
[17:42] <smoser> welll, please when you get done take a look at my comments.
[17:47] <smatzek> Does multiple interface configuration work for anyone using the OpenStack datasource on Xenial using 0.7.9?
[17:47] <smoser> i'd expect it to work.
[17:47] <smoser> ah.
[17:47] <smoser> with config drive
[17:47] <smatzek> it works with config drive but not the OpenStack datasource.
[17:48] <smoser> yeah
[17:48] <smoser> er.. yes. that is what i would expect.
[17:48] <smatzek> why is that?  A bug? I've dug through the code and have some ideas.
[17:48] <smatzek> cloud-init successfully reads the network json: 2017-09-21 13:07:58,001 - url_helper.py[DEBUG]: Read from http://169.254.169.254/openstack/latest/network_data.json (200, 626b) after 1 attempts
[17:48] <robjo> smoser: I did respond on the inline comments, hmm not sure what I screwed up that they didn't arrive on your end
[17:49] <robjo> basic.target vs. sysinit.target
[17:49] <smatzek> but then says this: stages.py[INFO]: Applying network configuration from fallback bringup=True
[17:49] <smatzek> likely because the OpenStack datasource doesn't have the network_config() property in 0.7.9 and doesn't override it from the base class at master in github either
[17:49] <smatzek> https://git.launchpad.net/cloud-init/tree/cloudinit/stages.py#n623
[17:49] <smoser> robjo, maybe you didn't hit 'submit
[17:50] <smoser> r... 'Save comment'
[17:50] <smoser> i dont see them. i'm sorry
[17:50] <robjo> probably :(
[17:50] <robjo> I bet I cannot get back there now, darn.....
[17:51] <smoser> smatzek, right now, only "local" datasources can provide network data.
[17:51] <smoser> this is because the point at which cloud-init.service (non-local) runs is too late in boot to declaritively set up networking.
[17:52] <smatzek> ah, I suppose because you don't want to depend on the networking to come up to allow metadata service gets to then configure networking....
[17:52] <smoser> and we don't currently have any configuration of hotplugged networking
[17:52] <smatzek> thanks!
[17:52] <robjo> smoser: do you see the comments now?
[17:52] <robjo> They were not lost that's nice
[17:53] <smoser> the real problem woudl be that at cloud-init.service point in boot osmehting could already be using the network (and rightfully so, as network.target is reached)
[17:53] <smoser> so taking it down to fix it would be difficult and possibly break things
[17:53] <smoser> so it is as it is right now, smatzek but we do have intent on fixing feature to address it
[17:53] <robjo> Well, that's not intuitive, I comment in-line but hen have to click "Save-Comment" for an empty text field....
[17:53] <robjo> something learned
[17:53] <smoser> robjo, yeah, launchpad has saved me there before :)
[17:54] <rharper> smoser: +1 on the smaller delta to the config template for suse
[18:06] <smoser> robjo, ok. if you're ok with my suggested changes, then i'll make some small comments in the template based on your responses and pull it
[18:06] <smoser> my only concern is that you're never going to figure out why basic.target v sysinit.target so i'm accepting this technical debt when what i should tell you to do is properly justify it
[18:06] <robjo> smoser: sounds good thanks
[18:08] <robjo> I will put a card on my trello board to re-visit this topic before the end of the year
[18:10] <blackboxsw> back
[18:12] <smoser> robjo, http://paste.ubuntu.com/25587623/
[18:12] <smoser> that is my total diff against your current branch (73acbf4a00741f8)
[18:12] <smoser> seem sane ?
[18:14] <robjo> smoser: yes, thanks
[18:14] <blackboxsw> my heart goes pitter-patter when I hear others use trello. /me ♥'s agile w/ trello.
[18:14] <blackboxsw> ... yeah I don't get out much
[18:16] <rharper> lol
[18:18] <smoser> but look at the mastery of unicode usage. 💕
[18:19] <blackboxsw> heh
[18:19] <robjo> the world was much simpler without .decode() ;)
[18:23] <rharper> f = '💕''
[18:23] <rharper>   File "<stdin>", line 1
[18:23] <rharper>     f = '💕''
[18:23] <rharper> SyntaxError: EOL while scanning string literal
[18:23] <rharper> so masterful
[18:34] <smoser> blackboxsw, rharper robjo i'm looking at
[18:34] <smoser>  https://cloud.google.com/compute/docs/storing-retrieving-metadata#querying
[18:34] <smoser> and then planning on making sure that goes thorugh an integration run and then change versions and tag
[18:35] <rharper> smoser: did you mean a code link not gce metadata ?
[18:35] <robjo> yes, puzzled...
[18:36] <rharper> smoser is having cut-n-paste fun after switching main browsers
[18:36] <robjo> but did I tell you about gcemetadata ;)  https://github.com/SUSE/Enceladus/tree/master/gcemetadata
[18:37] <blackboxsw> I recall from the summit, thanks for the link!
[18:38] <smoser> i meant
[18:38] <smoser> https://code.launchpad.net/~arnd-arndnet/cloud-init/+git/cloud-init/+merge/331148
[18:38] <blackboxsw> btw /run/cloud-init/instance-data.json is queued for review an will land post this release
[18:39]  * blackboxsw wants to get a branch up for DataSource.crawl_metadata ++ cloud-init devel crawl-metadata 
[18:43] <smoser> powersj,
[18:43] <powersj> yo
[18:43] <rharper> smoser: sounds like a plan
[18:43] <smoser> once i push above, i'd like to push a branch candidate/17.1
[18:44] <smoser> then i'd like to run through integration tests on that
[18:44] <smoser> and also as much other stuff as possible
[18:44] <smoser> then just pull that.
[18:44] <powersj> ok
[18:44] <smoser> what all do you recommend we run and how can we do that ?
[18:44] <powersj> honestly we should be doing all the tests we say we will run for an SRU exception: https://wiki.ubuntu.com/CloudinitUpdates
[18:45] <powersj> so touching each of the data sources
[18:45] <powersj> for integration tests, run through all tests on LTS + devel via lxd
[18:45] <blackboxsw> I could spin up a couple instances on azure, gce and aws to test too
[18:45] <smoser> hm..
[18:45] <powersj> `python3 -m tests.cloud_tests run --verbose --platform --os-name xenial --os-name artful`  should do the lxd side
[18:46] <powersj> woops forogt the lxd part
[18:46] <powersj> python3 -m tests.cloud_tests run --verbose --platform lxd --os-name xenial --os-name artful`
[18:46] <smoser> powersj, well, i'd like for jenkins to run that for me
[18:46] <smoser> then there are some thing sthat ideally we'd test that dont (currently) take a branch
[18:47] <powersj> you are looking for a release testing job that runs that based on a given branch?
[18:47] <smoser> ie, testing xenial is actually much more valid to test the daily ppa
[18:47] <smoser> which builds from trunk
[18:47] <smoser> powersj, so yes, sort of :)
[18:47] <smoser> what you said
[18:47] <smoser> this doesnt have to be perfect now
[18:48] <powersj> You know our current daily integration tests build for each distro and then run using the built deb right?
[18:48] <smoser> well, do they ?
[18:48] <powersj> yes
[18:48] <powersj> https://github.com/canonical-server/jenkins-jobs/blob/master/cloud-init/integration.yaml
[18:48] <smoser> do they use the packaging branch ?
[18:48] <powersj> no they use trunk
[18:49] <powersj> I sbuild each
[18:49] <powersj> I do not have direct testing on your release branches, only master
[18:49] <powersj> sounds like a test gap
[18:49] <smoser> right.
[18:49]  * powersj adds a card for release branch testing
[18:50] <smoser> it'd be best for us to test those daily ppas or some other way build trunk + ubuntu packaging
[18:50] <smoser> and test the result.
[18:50] <powersj> I think I am testing the latter option, right?
[18:50] <robjo> Our image build system has been terribly slow the last couple of days. I had hoped to have some rudimentary test results on SLES in EC2 by now but well, no images, no testing.....
[18:51] <robjo> however rather than pulling master and pushing more on the long queue I'll just wait until this round goes through that should be a reasonably close approximation
[18:56] <smoser> powersj, i suspect you're not testing ubuntu packaging
[18:56] <smoser> i think its just using packages/bddeb
[18:56] <smoser> which builds trunk's packaging
[18:56] <powersj> can you define what you mean by that... to mean ubuntu packaging == debian directory
[18:56] <smoser> which is missing some patches
[18:57] <smoser> yeah, the debian/ directory in the ubuntu/xenial branch
[18:57] <powersj> so I'm not testing the specific release patch sets
[18:57] <smoser> right.
[18:57] <powersj> ok table that for next week?
[18:57] <smoser> from a "we are upstream" perspective, its arguable that that is fine.
[18:57] <smoser> yeah
[18:58] <powersj> more immediately you want a jenkins job to run lxd backed integration tests that i proposed above?
[18:58] <smoser> powersj, yes
[18:58] <powersj> ok
[18:58] <smoser> but it will just do that
[18:58] <smoser> right ?
[18:58] <smoser> if i push a branch for review
[18:59] <powersj> The review ill run 2-3 integration test cases on xenial only
[19:02] <smoser> powersj, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/331161
[19:02]  * smoser wonders if that will pass check_version in c-i
[19:02] <blackboxsw> smoser is that using log2dch?
[19:03] <powersj> heh we will find out shortly :)
[19:03] <smoser> blackboxsw, it did, yeah
[19:03] <blackboxsw> I just pushed that into our cloud-init/qa-scripts repo
[19:03] <blackboxsw> so we have a copy of it in non-gist format :)
[19:03] <smoser> i un-indented
[19:04] <blackboxsw> figured we'd collect any tools we are using for our varios dev practice in powers
[19:04] <blackboxsw> figured we'd collect any tools we are using for our varios dev practice in powers' shared repo
[19:04] <blackboxsw> various even
[19:04] <blackboxsw> bak 2 typoe skool
[19:05] <powersj> :D
[19:06] <powersj> ok created two jenkins jobs for release based testing, given a repo + branch it will run all LXD tests, one for xenial, one for artful.
[19:15] <powersj> smoser: build passed
[19:15] <powersj> install deb: "cloud-init_17.1-0-gbf6456f-1~bddeb_all.deb" into target
[19:15]  * blackboxsw runs that branch on aws 
[19:15] <powersj> smoser: are we really still including the git tag?
[19:16] <smoser> powersj, ?
[19:16] <powersj> when you release will the version string have "-gbf6456f" or some revision string in it and not just "17.1"?
[19:18] <smoser> the version string in the debian package will have that.
[19:20] <smoser> hm..
[19:22] <powersj> CI passed
[19:22] <powersj> running integration tests
[19:26] <blackboxsw> smoser: python-jsonschema needs to not be required by the package on that branch
[19:26] <blackboxsw> dpkg: dependency problems prevent configuration of cloud-init:
[19:26] <blackboxsw>  cloud-init depends on python3-jsonschema; however:
[19:26] <blackboxsw>   Package python3-jsonschema is not installed.
[19:27] <kszarlej> Hey. I am having an exception when trying to use `network-config` with NoCloud cloudinit that is suppose to provision my libvirt instances. I tried both version1 and version2 of the network-config. Details can be found in http://paste.ubuntu.com/25588011/ (both configurations and an error)
[19:27] <smoser> blackboxsw, so the debian packages built from trunk will get -0-gXXXX the ones that go into ubuntu will have
[19:27] <smoser>  17.1-0ubuntu1
[19:27] <smoser> but then the first time we grab a snapshot again we'll get
[19:28] <smoser>  17.1-0-gXXXXX-0ubuntu1
[19:28] <smoser> blackboxsw, "package on that branch" ?
[19:28] <smoser> blackboxsw, trunk requires python3-jsonschema
[19:29] <smoser> xenial patches that dependency out
[19:29] <blackboxsw> sorry, just a reminder that we carry a patch for no python3-jsonschema
[19:29] <blackboxsw> yeah
[19:29] <blackboxsw> ok good good
[19:31] <smoser> this is one of the things that testing the daily builds from the ubuntu/xenial + trunk build would cover
[19:31] <smoser> https://git.launchpad.net/cloud-init/tree/debian/patches/stable-release-no-jsonschema-dep.patch?h=ubuntu/xenial
[19:31] <smoser> ist hte patch
[19:32] <powersj> xenial lxd tests passed https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-integration-release-lxd-xenial/2/console
[19:33] <blackboxsw> 2017-09-21 19:31:43,001 - util.py[DEBUG]: Cloud-init v. 17.1 running 'init-local' at Thu, 21 Sep 2017 19:31:42 +0000. Up 5.54 seconds.
[19:33] <blackboxsw> 2017-09-21 19:31:43,523 - handlers.py[DEBUG]: finish: init-local/search-Ec2Local: SUCCESS: found local data from DataSourceEc2Local
[19:33] <blackboxsw> ok looking good aws
[19:37] <rharper> kszarlej: I've seen that error before; I can't find the bug but it should be fixed in trunk;  if possible you can test/try the daily cloud-init rpm https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
[19:41] <smoser> kszarlej, please do try trunk. i can't reproduce the error there.
[19:41] <smoser> i suspect you're on centos/rhel based on python2.7
[19:43] <kszarlej> yep
[19:43] <kszarlej> 2 bad
[19:43] <kszarlej> I have to modify the
[19:43] <kszarlej> original centos cloud image
[19:45] <smoser> http://paste.ubuntu.com/25588132/
[19:45] <smoser> kszarlej, ^ shows how you can use a tool in trunk to more quickly iterate
[19:45] <smoser> which probably would have been useful to you earlier
[19:45] <smoser> :)
[19:48] <blackboxsw> 2017-09-21 19:45:36,396 - util.py[DEBUG]: Cloud-init v. 17.1 running 'init-local' at Thu, 21 Sep 2017 19:45:36 +000
[19:48] <blackboxsw> 0. Up 9.36 seconds.2017-09-21 19:45:39,401 - handlers.py[DEBUG]: finish: init-network/search-GCE: SUCCESS: found network data from Dat
[19:48] <blackboxsw> aSourceGCE
[19:48] <blackboxsw> https://www.irccloud.com/pastebin/7XrX4aVw/
[19:48] <blackboxsw> gce looking good
[19:48] <blackboxsw> and now to remember my azure creds
[19:49] <rharper> 7a3nf07sf
[19:49] <rharper> something like that =)
[19:49] <powersj> blackboxsw: created card and added to you
[19:49] <powersj> blackboxsw: can you add links to your pastebin results there?
[19:50] <blackboxsw> I'm pretty good w/ ctrl-v. let's see :)
[19:50] <blackboxsw> thx powersj
[19:50] <powersj> https://trello.com/c/sd5qvgJx/428-171-release
[19:50] <rharper> blackboxsw: maybe you can help smoser; there was some ctrl-v/ctrl-p trouble earlier
[19:50] <blackboxsw> hahaa
[19:54] <smoser> in firefox with pentadactyl i could just hit 'y' rather than ctrl-v.
[19:54] <smoser> but cvim doesn't seem to work as well. thats supposed to work i think, but doenst sometimes. in chrome.
[19:54] <rharper> vimium!
[19:54] <dpb1> vimperator
[19:54] <rharper> did that get ported to chrome ?
[19:55] <rharper> it used to be ff only (*years* ago )
[19:55] <dpb1> idk, actually
[19:55] <dpb1> ya
[19:55] <dpb1> my cube neighbor at hp was hardcore vimperator user
[19:55] <rharper> sadly, it's not as complete as vimperator was (input boxes) so I've added also wasavi (which is inputbox only vim support)
[19:56] <rharper> but the link/tab highlighting is super cool in vimium
[19:56] <smoser> pentadactyl was well better follow-on to vimperator
[19:56] <smoser> but is kind of dead.
[19:56] <smoser> https://github.com/5digits/dactyl/issues/99
[19:57] <smoser> google seemed to think that cvim was better than other options for chrome
[19:58] <smoser> and wasavi is pretty nice. but can't read or write to files.
[19:59] <rharper> yeah
[20:00] <powersj> artful lxd tests passed https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-integration-release-lxd-artful/2/console
[20:04] <powersj> running nocloud kvm
[20:06] <blackboxsw> azure clean boot test completed
[20:07] <blackboxsw> ok, looks like that'll cover it w/ powersj' test
[20:07]  * blackboxsw remebers to teardown my azure resource group
[20:08] <powersj> smoser: ok got coverage on ec2, azure, aws, nocloud, lxd
[20:08] <powersj> +build +ci
[20:09] <powersj> +MAAS Compatability Testing
[20:09] <blackboxsw> I use wasavi too. ... though I keep accidentally triggering it
[20:16] <dpb1> same
[20:16] <dpb1> it's also not the same
[20:16] <smoser> https://public.etherpad-mozilla.org/p/cloud-init-17.1
[20:24] <kszarlej> smoser: I upgraded to newest from daily rpm builds
[20:25] <kszarlej> (v0.7.9)
[20:25] <kszarlej> and still same error
[20:27] <kszarlej> the exact version is cloud-init-0.7.9+286.gd3a8777-1.el7.centos.noarch
[20:29] <smoser> kszarlej, hm..
[20:29] <smoser> ah
[20:29] <smoser> wait
[20:30] <smoser> kszarlej, so...
[20:30] <smoser> first thing
[20:31] <smoser> is that 'network:' should not be present in the network-config file
[20:31] <smoser> as its already namespaced to 'network'
[20:31] <smoser> clearly better error would be ncie.
[20:31] <smoser> but try out-denting that and dropping network:
[20:31] <smoser> the 'version: 2.... i'm not sure
[20:31] <rharper> https://bugs.launchpad.net/cloud-init/+bug/1708255
[20:32] <kszarlej> ok trying to out-dent
[20:32] <kszarlej> trying with version 1 synta
[20:33] <kszarlej> x
[20:33] <smoser> oh. and kszarlej you didn't have a mac_address in your v1
[20:34] <kszarlej> smoser: I have
[20:34] <kszarlej> network:
[20:34] <kszarlej>   version: 1
[20:35] <kszarlej>   config:
[20:35] <kszarlej>   - type: physical
[20:35] <kszarlej>     name: eth0
[20:35] <kszarlej>     mac_address: 0e:a5:95:fd:a3:b2
[20:35] <kszarlej>     subnets:
[20:35] <kszarlej>       - control: auto
[20:35] <kszarlej>         type: static
[20:35] <kszarlej>         address: 10.10.1.120/24
[20:35] <kszarlej>         gateway: 10.10.1.3
[20:35] <kszarlej>         dns_nameservers:
[20:35] <kszarlej>           - 8.8.8.8
[20:35] <smoser> yeah, in your paste you didn't have {{ mac address }}
[20:35] <kszarlej>           - 8.8.4.4y
[20:35] <kszarlej> here is the exact config. (the y on the end is by accident)
[20:35] <kszarlej> sry I should have used paste
[20:35] <kszarlej> thats the exaact config I used now and it failed
[20:36] <smoser> well you should not have 'network'
[20:36] <smoser> remove l ine 1
[20:36] <smoser> out-dent 2 spaces
[20:36] <kszarlej> yep
[20:36] <kszarlej> I will try that now
[20:36] <kszarlej> is it possible to
[20:36] <kszarlej> run cloud-init on host once again
[20:36] <kszarlej> or I have to reproviosion it?
[20:37] <kszarlej> (I will have to dd the original image to the VM disk and it takes time)
[20:38] <rharper> if you have console, you should be able to restart the service (cloud-init-local)   you may need to remove /var/lib/cloud/instance/obj.pkl;  and of course update the the on-disk network-config file;
[20:39] <blackboxsw> wouldn't sudo rm -rf  /var/log/cloud*log /var/lib/cloud; sudo reboot work too?
[20:41] <smoser> blackboxsw, bah
[20:41] <dpb1> blackboxsw: we have 'cloud-init clean' or something on our ideas, right?
[20:41] <smoser> look at your /tmp
[20:41] <smoser> see if you have ci-FakeExtendedTempFile*
[20:53] <powersj> ci-FakeExtendedTempFile.b5pmLb
[20:53] <powersj> ci-FakeExtendedTempFile.oqisp_15
[20:53] <powersj> ci-FakeExtendedTempFile.pkggbqro
[20:53] <powersj> ci-FakeExtendedTempFile.q9aq1dpv
[20:53] <powersj> ci-FakeExtendedTempFile.uIPh1b
[20:53] <powersj> ci-FakeExtendedTempFile.vq9_ldsb
[20:58] <kszarlej> smoser: rharper finally
[20:58] <kszarlej> it works
[20:58] <kszarlej>  :)
[21:01] <smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/fix/fake-extended-tempfile-cleanup
[21:03] <blackboxsw> bah /tmp
[21:03] <blackboxsw> oops bah blackboxsw
[21:03] <blackboxsw> not cleaning up my own tmpfiles
[21:04] <smoser> blackboxsw, i might have regressed that for you
[21:04] <smoser> i took that duplicated class out
[21:04] <smoser> and put it at the top
[21:04] <smoser> you probably had it reerencing  self.tmp_dir
[21:04] <smoser> as i remember
[21:06] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/331168
[21:07] <rharper> kszarlej: \o/
[21:08] <smoser> kszarlej, so version 1 worked.
[21:08] <smoser> version 2 should work also
[21:08] <smoser> but if it works, it works.
[21:08] <kszarlej> yup the out-dent helped
[21:09] <kszarlej> :)
[21:09] <kszarlej> thanks
[21:09] <blackboxsw> smoser: still seeing the /tmp leaks
[21:09] <blackboxsw> with the patch
[21:10] <blackboxsw> smoser: nevermind. PEBKAC
[21:10] <blackboxsw> approved
[21:15] <blackboxsw> dpb1: I didn't know if we committed on that 'cloud-init clean'. We can have a branch up today if we want it. I think it sounds like a good idea, and it's simple to implement a basic approach. (We might end up tweaking it a bit with the re-rentrant cloud-init features). Certainly if all it is is wiping the cloud-init logs/lib dirs
[21:16] <dpb1> blackboxsw: no, just curious
[21:16] <dpb1> blackboxsw: it's a common testing pattern
[21:16] <dpb1> would be nice to codify it
[21:16] <blackboxsw> agreed
[21:26] <robjo> blackboxsw: Could you take a look at https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149, need some help filling in the rest of the schema data, thanks
[21:27] <blackboxsw> robjo: you made my week
[21:27] <blackboxsw> I was just looking over schema stuff last night and thought that this is going to be a lot of work for the 50 remaining cloud-config modules
[21:27] <blackboxsw> :)
[21:28] <robjo> Well this is net new, so I am not really helping you get that work done, sorry. But at least I am not creating more ;)
[21:30] <blackboxsw> +1 to that.
[21:43] <kszarlej> ok there is one more problem. Cloud-init in NoCloud doesnt manage the resolv.conf. Both when setting in network-config for subnet as dns_nameservers: ['8.8.8.8'] and in meta-data
[21:43] <kszarlej> manage_resolv_conf: true
[21:43] <kszarlej> resolv_conf:
[21:43] <kszarlej>   nameservers:
[21:44] <kszarlej>     - '8.8.8.8'
[21:44] <kszarlej>     - '8.8.4.4'
[21:44] <kszarlej> in first case it should set the DNS1=8.8.8.8 in eth0 script but it doesnt actually.
[21:49] <kszarlej> seems like the module is not activated on centos
[21:54] <robjo> 17.1 is building in Cloud:Tools:Next smoser thanks for including all the new patches and for the help, hopefully I'll get to do some testing tomorrow.
[21:56] <robjo> the https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149 will change the config format for SUSE repos, thus I am negotiating with the internal user of this feature whethere we will add the patch I am working on to the 17.1 build or keep the old patch and switch the next time
[21:57] <robjo> Things are looking up I am 17 patches down from the previous package :D
[21:58] <rharper> kszarlej: it looks like the sysconfig renderer doesn't handle the dns_nameserver entry under the subnets (eni does);  you can specify it as a top-level type: nameserver
[21:58] <rharper>         - type: nameserver
[21:58] <rharper>           address:
[21:58] <rharper>           - 8.8.8.8
[21:58] <rharper> kszarlej: if you have time, please file a bug; sysconfig render should handle both
[22:07] <kszarlej> rharper: as top level in networking section
[22:07] <kszarlej> or in cloud-config 'meta-data' ?
[22:07] <rharper> at the same level as the type: physical
[22:07] <rharper> under config: array
[22:08] <kszarlej> btw. in centos7 /etc/cloud/cloud.cfg 'resolvconf' module is not listed under any of the 'stages'
[22:08] <rharper> that's likely a but too w.r.t the which modules are run by default;
[22:08] <kszarlej> w.r.t ?
[22:09] <rharper> sorry, with respect to
[22:09] <rharper> s/but/bug
[22:29] <kszarlej> pl thx
[22:29] <kszarlej> ok* ;p
[22:29] <kszarlej> I will create bug reports tomorrow. Time to sleep. Gn8
[23:42] <powersj> smoser: I usually run the integration tests by doing `python3 -m ...` versus tox... well since I added simplestreams as a dependency that broke tox. I don't see simplestreams in pypi.
[23:44] <powersj> Becuase tox will only work with the lxd backend, my thought was to remove references to tox in the docs and remove the tox support. However, since you were pretty happy with that ability to run I wanted your thoughts.