#cloud-init 2014-07-01
<harlowja> smoser alright, taking another stab @ https://code.launchpad.net/~harlowja/cloud-init/py2-3 (WIP)
<smoser> harlowja_away, whoohoo
<CatKiller> smoser: I'm nearly done integrating the resize operation. I've wasted most of the time finding a way to compute the size delta thinking that only "+size" operations were supported by qemu-img, not realizing you could simply specify the size by itself...
<smoser> :)
<CatKiller> smoser: And to do that in bash was really hard :P Since bash doesn't handle floats etc. Well anyways I'll keep this one in my archive as it's full of handy snippets
<CatKiller> smoser: The much much simpler version will come soon
<smoser> floating point is possible in bash, but can be tricky
<smoser> http://smoser.brickies.net/git/?p=snippits.git;a=blob;f=sh/fpdiv;h=7336f6c3b981082b7f8a39e73c0047f10193f303;hb=HEAD
<smoser> (if its not obvious, that is floating point division in bash)
<smoser> er... actually in posix sh
<CatKiller> smoser: Nice, good module actually to keep
<harlowja> smoser will do some tests on that, but the basic approach is to start nailing the crap that is changed in 3.x with six usage
<harlowja> just gotta hit all the cases (which is hard, ha)
<harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/py2-3/+merge/225240 ; hopefully helps get this going
<harlowja> the basics at least, doesn't fully work on py3 i think, but a step
<harlowja> at least imports all fine under 3.4 (unless i missed a few modules)
#cloud-init 2014-07-02
<CatKiller> smoser: Hi Scott, I've got a patch for cloud-image-callback to grow an image
<CatKiller> it's fairly simple: if --grow is specified, we try to grow the image first, then when the image is mounted we try to grow the filesystem
<CatKiller> (running an fsck right before)
<CatKiller> if that's all OK, we continue the script "as usual"
<CatKiller> it doesn't support growing raw images and will exit in error if attempted
<CatKiller> Do you want me to send you that patch?
<CatKiller> smoser: My bad I made a really bad error in it, it's not quite there yet ;)
<mnaser> I have added "resize_rootfs: noblock" in my cloud.cfg
<mnaser> but it looks like it's still blocking there
<mnaser> this is a vm with a 1.2tb disk.. seems like its taking ages to resize
<mgagne> mnaser: which OS and which version of cloud-init?
<mnaser> mgagne
<mnaser> oops early enter
<mnaser> el6 + 0.7.4
<mnaser> from epel
<mgagne> mnaser: ok, I used to patch cloud-init<0.7.2 to add support for the noblock option. but since you have 0.7.4... it should work
<mnaser> mgagne: strange .. because i checked the source of it and it seems there as well.. :\
<mgagne> mnaser: in fact, noblock was broken before 0.7.2: https://github.com/number5/cloud-init/commit/4401877324de10e7d15d9631f9799bfbb54cdf8d#diff-0cbbb4c8c15d47a0e5aebccda88fd9fb
<mgagne> mnaser: sorry I can't help you more on that one
<mnaser> mgagne: think i found my issue
<mnaser> Jul  2 21:45:59 localhost [CLOUDINIT] util.py[WARNING]: Failed forking and calling callback NoneType
<mnaser> Jul  2 21:45:59 localhost [CLOUDINIT] util.py[DEBUG]: Failed forking and calling callback NoneType#012Traceback (most recent call last):#012  File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 220, in fork_cb#012    child_cb(*args)#012TypeError: 'NoneType' object is not callable
<mnaser> cloud-init --debug single --name resizefs is failing too, good now i can easily debug
#cloud-init 2014-07-03
<mnaser> It looks like cloud-init backgrounded resize is blocking.. and any ideas why it can be taking a really long time? Jul  3 14:43:13 localhost [CLOUDINIT] util.py[DEBUG]: backgrounded Resizing took 275.751 seconds
<mnaser> That's from 20G to 160GB (with only ~6GB of data)
<mnaser> This is on CentOS 6, upgraded to the latest e2fsprogs
<harmw> that kernel doesn't support it, iirc
<mnaser> harmw: afaik, there is a feature that makes resizing much faster using lazy_itable_init
<harmw> centos' kernel is to old to certain resize things
<mnaser> hm.
<harmw> i haven't looked at this for say 4 months or so though :)
<mnaser> Any suggestions in that case? I rather not drop in a kernel that won't get updated, any "updated centos kernel" repos?
<harmw> no no, kernels are holy
<mnaser> yeah.. i didn't for a while but we had someone provision a 1.2tb disk centos vm and it's taking forever and a half :)
<harmw> perhaps centos-plus, though I doubt even that
<harmw> well, why on earth would one require a cloudy instance with 1.2TB of storage?
<harmw> :)
<harmw> (and ofcourse, 'because one can' is a viable answer :p)
<mnaser> harmw: our local disk grows with the amount of memry/etc
<mnaser> so this is a 32gb instance
<mnaser> ex: 1gb gets 40gb... we grow linearly so 32 ends up with 1280gb
<harmw> damn
<mnaser> yeah but this isnt too useful if i cant figure out how we can solve this
<mnaser> i tried e2fsprogs 1.42.6, 1.42.8 and 1.42.10 (latest) with the utils as well but no go
<harmw> on a personal note, since when did there become a direct relation between mem/hdd sizes? :)
<harmw> thats not a very good thing imho
<mnaser> how come?  it helps us not end up with un-used local disk space
<harmw> anyway, problem here is resizing takes quite long due to the large disk/fs
<mnaser> yeah.. i think it has to do with the old kernel/tooling
<harmw> I'm quite positive it was the old (ancient) CentOS kernel in this case
<harmw> have you tried ubuntu?
<harmw> or fedora?
<mnaser> ubuntu boots ultra quick with no problems
<harmw> and thats with kernel 3.x?
<mnaser> that's why i felt it had to be resize2fs/kernel
<mnaser> yup
<harmw> yeah, in that case I'm quite positive this boiled down to CentOS' kernel
<mnaser> i found this too
<mnaser> https://bugs.launchpad.net/bugs/1179610
<harmw> shouldnt take to look for them to set 7.0 free though :)
<mnaser> it looks like ubuntu had the same issue in 2013
<harmw> yea, we had this issue with cirros a while back as well
<mnaser> it does look like this got fixed by newer e2fsprogs but that didnt help me
<harmw> nah, it still requires a shiny 3.x kernel
 * mnaser sigh
<harmw> you might want to give centos7 a try, it's not far from gold status
<mnaser> pretty sure the stuff we run on centos 6 hasnt yet been fully prepped for centos 7
<mnaser> http://elrepo.org/tiki/kernel-lt i want to give this a shot
<harmw> ah yes
<harmw> well good luck
<mnaser> harmw: thanks, entering uncharted territory is fun (not)
<harmw> hehe
<mnaser> i'll let you know though! :)
<harmw> yea, I'd appreciate that
#cloud-init 2014-07-06
<cloudnoob> is there a good mailing list for cloud-init or is irc preferable?
#cloud-init 2015-06-29
<Odd_Bloke> smoser: How does https://bugs.launchpad.net/cloud-init/+bug/1456684 actually manifest itself?  (i.e. what should I put in the SRU Impact/Test Case?)
<Odd_Bloke> smoser: I'm out tomorrow, would appreciate it if you could answer my above question by the time I'm back. ;)
<harlowja> Odd_Bloke https://review.openstack.org/#/c/196884/
<harlowja> claudiupopa ^
<harlowja> pretty sure if we want to support rhel6.x we need that
<harlowja> which afaik we wanted to do
<claudiupopa> tooo baaad. :D
#cloud-init 2015-07-01
<Odd_Bloke> smoser: claudiupopa: harlowja: Any takers for this cloud-init 2.0 call?
<smoser> Odd_Bloke, i'm in a library. lets do it here.
<Odd_Bloke> smoser: Ack.
<smoser> and claudiupopa agrees.
<Odd_Bloke> So I was sprinting last week, and therefore didn't get any cloud-init work done.
<claudiupopa> hey folks.
<Odd_Bloke> I did some reviews Monday morning, then was off yesterday.
<Odd_Bloke> I'm hoping to spend Thursday/Friday on cloud-init 2.0 stuff but a week spent, effectively, off last week means I have some normal work stuff that might overwhelm that.
<smoser> ok, Odd_Bloke.
<smoser> I will be in tomorrow (likely) but out friday as that is US holiday.
<smoser> lets try this...
<smoser> we'll look at http://bit.ly/cloudinit-reviews and try to quickly go through what is there.
<smoser> and then we can talk about other things that shoudl be done.
<smoser> sound ok ?
<Odd_Bloke> Sounds good to me.
<claudiupopa> Sounds perfect.
<smoser> harlowja, sleeping still ?
<Odd_Bloke> harlowja: WAKE UP ITS A BEAUTIFUL MORNING
<smoser> west coast is lazy and often uses the excuse of the sun not rising on them yet.
<smoser> ok. so i guesi 'll just go top down in my view
<smoser>  https://review.openstack.org/#/c/195800/
<claudiupopa> yeah, that looks fine excepting the overuse of properties.
<claudiupopa> As both me and Daniel observed.
<smoser> we want one for the decoded_buffer, right ?
<smoser> as thats the whole intent of this
<Odd_Bloke> Yeah, just not the others.
<smoser> ok. so i'll just do that quick after this meeting
<smoser> next.
<smoser> https://review.openstack.org/#/c/170257/
<smoser> i'll look over Odd_Bloke's responses after this meeting
 * smoser didn't know about compiled regex.
<smoser> caching
<Odd_Bloke> smoser: http://ak-hdl.buzzfed.com/static/2015-02/1/20/enhanced/webdr02/anigif_enhanced-buzz-20392-1422840785-34.gif
<smoser> :)
<smoser> https://review.openstack.org/170252
<smoser> i think we want to support rhel6. so if we can get by with 2.6 without massive pain, then we shoudl do that.
<Odd_Bloke> I'm +1 on that change.
<smoser> wish that harlowja would not have tagged along the logging change :)
<Odd_Bloke> Do we think that cloud-init 2.0 is actually going to be used in RHEL6?
<smoser> in its life time i ope so.
<smoser> from epel i'd guess.
<smoser> we can discuss dropping it if it becomes painful.
<smoser> reasonable ?
<Odd_Bloke> Yeah, definitely.
<claudiupopa> yeah, sounds reasonable enough.
<smoser> then we just have Odd_Bloke's https://review.openstack.org/#/c/191144/
<smoser> i dont really want to pick up a dependency (especially one not pakcaged in ubuntu)
<smoser> (wrt mini-lib and taskflow.types.notifier.Notifier )
<Odd_Bloke> Yeah, I think harlowja or claudiupopa and I discussed not picking up a dependency until we thought we needed it.
<Odd_Bloke> s/discussed/discussed on IRC/
<smoser> Odd_Bloke, one thing i do see is that i report_event does not take a status code
<smoser> for exit
<smoser> pass/fail
<Odd_Bloke> smoser: Yeah, I'm going to flesh out different event types next.
<Odd_Bloke> Ah, claudiupopa and I agreed that it wasn't worth pulling in a library for our limited use case.
<Odd_Bloke> harlowja just ignored me. ;.;
<smoser> ok. well lets go with that then, but i know we need status / exit code
<smoser> last is https://review.openstack.org/#/c/195631/
<smoser> which i'd just pull other than Odd_Bloke wanted me to use tox -l, which makes sense in some contexts but not in others.
<smoser> unless i was going to do a 'tox --recreate --notests' or something to create it if it was there and didnt exist
<smoser> i just use that for thing slike:
<Odd_Bloke> I was wondering if there's a way to get tox to just create the virtualenv, without running the commands configured.
<smoser>  tox-venv py27 nosetests %
<smoser> there is.
<smoser> --recreate --notests
<smoser> or something to that effect
<smoser> yeah.
<smoser> the recreate is just confusing. it will create if does not exist.
<smoser> if you want to get that, we can.
<smoser> so.. we can come back to that.t
<smoser> the other 2 things ithat i have is
<smoser> a.) need of a main / runner... so we can actually run the stuff
<smoser> b.) i was looking some at trying to make sure we can easily test on trusty using packaged versions.
<smoser> because as we add pip things, its very easy to not realize that you dont work on older pip versions of things.
<Odd_Bloke> (In another meeting now, but it seems like I'll be done with it pretty soon)
<claudiupopa> +1 for the main / runner.
<smoser> ok. claudiupopa do you ahve anything else that you think needs to be on short list ?
<smoser> i'm definitely ok with prioritizing the main over the 'b' above, but i'd love to be able to do 2 things:
<smoser>  1.) run "get-dependencies --with-build" : to get dependencies installed via packages on trusty or other ubuntu (and other dists too, rather than using pip)
<smoser>  2.) use tox to provide me with pip at versions on trusty.
<smoser>   ie, so on my 15.10 laptop i could do: tox -e trusty-py34
<smoser> or :
<smoser>  tox -e rhel6
<smoser> which would then use versions of pip that you'd find there.
<smoser> what that means i hink si that we have to have data that includes
<smoser>  pip package name, distro_python26_name, distro_python26_version, distro_python34_version and such.
<smoser> which quite admittedly is a pita to maintain
<smoser> but i think worth it.
<smoser> ok, well, since i'm the only one talking, then i'll get to trying to review those things  and a main
<smoser> claudiupopa, if you have some cycles, what would you / could you work on ?
<Odd_Bloke> smoser: You're thinking that 'tox -e rhel6' would run the tests in a RHEL6-like environment?
<smoser> yes. and 'install-dependencies' would read/determine that i'm on rhel6 yum install any deps
<openstackgerrit> Scott Moser proposed stackforge/cloud-init: pip2distro: work in progress: build tox env for specific targets  https://review.openstack.org/197671
<harlowja> what u guys talking about, ha
<smoser> harlowja, welcome.
<harlowja> sup
<harlowja> my damn irc client not setting me away
<harlowja> need to figure that out
<smoser> glad you decided to roll out of bed this morning<cough>afternoon
<harlowja> lol
<harlowja> anytime man
<harlowja> got up just for u smoser
<harlowja> u guys get up to early, lol
<harlowja> sleep in, get your rest, let your brain rest and all
<harlowja> its the CA way :-P
<smoser> :)
<smoser> you had one thing that could get merged if you just dropped properties
<smoser> https://review.openstack.org/#/c/195800/
<harlowja> :-P
<smoser> can you do that quick ? just to make happy ?
<harlowja> i like making the happies
<harlowja> happy happy
<harlowja> in progress
<smoser> and i will respond to templater ones
<harlowja> happy happy
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Expose api response properties and cache buffer decoding  https://review.openstack.org/195800
<harlowja> ^^ happy
<smoser> harlowja, thanks
<harlowja> np
<smoser> harlowja, how did you make py26 fail ?
<smoser> https://review.openstack.org/#/c/195800/
<smoser> i saw you do that somewhere.
<harlowja> oh man
<harlowja> u killed 26
<harlowja> lol
<openstackgerrit> Scott Moser proposed stackforge/cloud-init: tools/tox-venv: support running other than ./tools/tox-venv  https://review.openstack.org/195631
<harlowja> ya, hmmm, don't think there is a importlib on 2.6, lol
<harlowja> we probably need https://pypi.python.org/pypi/importlib in the requirements for 26 then
<smoser> http://stackoverflow.com/questions/9418064/conditionally-installing-importlib-on-python2-6
<harlowja> ya, pbr now supports requirement markers so should probably just use those
<harlowja> ie crap like https://github.com/openstack/requirements/blob/master/global-requirements.txt#L37
<harlowja> so we probably want a importlib;python_version=='2.6'
<smoser> wow. that i ugly.
<smoser> :)
<harlowja> :-P
<harlowja> https://www.python.org/dev/peps/pep-0426/#environment-markers
<smoser> tox calls pip, how does pip get pbr ?
<harlowja> https://github.com/stackforge/cloud-init/blob/master/setup.py
<smoser> i see. its the first in that list, and the pip like re-executes itself or something
<harlowja> something like that
<smoser> oh. ok.
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Add importlib for python 2.6 *only*  https://review.openstack.org/197691
<smoser> so you want to fix taht ?
<smoser> there yagoo
<harlowja> ha
<harlowja> let's see if it works
<smoser> looks like no dice ?
<harlowja> hmm
<smoser> maybe. i thought it ran and failed. but hasnt ran
<harlowja> https://jenkins03.openstack.org/job/gate-cloud-init-python26/2/console
<harlowja> its ran
<harlowja> but didn't get installed :-/
<smoser> whered that link come from ?
<smoser> not run on https://review.openstack.org/#/c/197691/ yet
<harlowja> http://status.openstack.org/zuul/
<harlowja> search for cloud-init
<harlowja> then click the box
<harlowja> ^ gives u the jenkins links before they all finish
<harlowja> i'll ask some pbr folks when that all finishes (with real links)
<harlowja> unsure why it didn't get installed
<smoser> ok. thanks.
<harlowja> np
<smoser> Odd_Bloke, still around ?
<harlowja> so thats weird
<harlowja> http://logs.openstack.org/91/197691/1/check/gate-cloud-init-python26/eae73ee/console.html shows different errors than what jenkins had, lol
<harlowja> seems importlib did get installed
<harlowja> weird
<harlowja> ha
 * harlowja fixing these tests up
<openstackgerrit> Scott Moser proposed stackforge/cloud-init: Bring over the 'templater' from bzr  https://review.openstack.org/170257
<smoser> harlowja, thanks.
<harlowja> np
<smoser> i just did ^
<harlowja> it will prob still break until 26 resolved
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Add importlib for python 2.6 *only*  https://review.openstack.org/197691
<harlowja> ok let's see if that passes
<harlowja> *passed local 2.6
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Add importlib for python 2.6 *only*  https://review.openstack.org/197691
#cloud-init 2015-07-02
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Add importlib for python 2.6 *only*  https://review.openstack.org/197691
<harlowja> ok seems good to go ^ smoser ^
<harlowja> all fixed up
<smoser> Odd_Bloke, do you have some time today that we could look at the reporting stuff ? i'd like to make some progress on that.
<Odd_Bloke> smoser: Potentially; looking at relatively important partner stuff at the moment.
<smoser> Odd_Bloke, how do i make jenkins re-test something ?
<Odd_Bloke> smoser: Pushing up a new patchset should do it automatically.
<smoser> yeah, but i think theres a way to say "re-run".
<smoser> ohwell.
<Odd_Bloke> harlowja will probably know, when he wakes up in 3 days or so. :p
<Odd_Bloke> smoser: Why do you need to rerun without any changes?
<smoser> i wasnt sure how the py26 stuff was fixed. thought it was actually not related.
<openstackgerrit> Scott Moser proposed stackforge/cloud-init: pip2distro: work in progress: build tox env for specific targets  https://review.openstack.org/197671
<Odd_Bloke> smoser: Ah, good point about using setup in timeit.
<Odd_Bloke> OTOH, we _aren't_ using the regex more than a handful of times, so I think my examples were more valid than they appeared.
<Odd_Bloke> But it was a minor point; I don't particularly mind which we do. :)
<smoser> harlowja, please ping when you wake up.
<smoser> really want to resolve the py26 stuff today.
<smoser> https://review.openstack.org/#/c/197691/
<smoser> Odd_Bloke, i have no objection to using unittest2
<smoser> i dont fully understand:
<smoser> This would mean we couldn't use testtools' TestCase class, but we would still be able to use their matchers in our assertions, if we so wished (http://testtools.readthedocs.org/en/latest/for-test-authors.html#assert-that-function).
<smoser> claudiupopa, do you have any objection to unittest2 ?
<claudiupopa> does it have assertRaises as a context manager? ;-)
<claudiupopa> No, no objection.
<Odd_Bloke> smoser: So we're using testtools.TestCase, which inherits directly from unittest.TestCase.
<Odd_Bloke> smoser: It is therefore incompatible with using unittest2.TestCase as our root test case.
<smoser> ah. ok.
<claudiupopa> Why are we using testtools? What benefits does it bring us?
<Odd_Bloke> ^ I'm curious about this as well.
<Odd_Bloke> (I think testtools has useful stuff, I just don't think we're using any of it ATM :p)
<smoser> i have no attachment to it
<smoser> it blames to
<smoser>  http://paste.ubuntu.com/11810295/
<smoser> is setUp and tearDown stuff it provides ?
<smoser> guess not
<claudiupopa> Nope, that's in unittest as well.
<smoser> ok, we really need to resolve this today, as all tests fail on on the py26 gate right now.
<smoser> Odd_Bloke, did you see my comment at https://review.openstack.org/#/c/170257/4/cloudinit/templater.py  ?
<Odd_Bloke> smoser: Re: timeit?
<smoser> yeah.
<smoser> am i wrong ?
<smoser> there definitely *is* a pentalty for compiling, but it does make up for itself.
<smoser> (assuming it gets used)
<Odd_Bloke> smoser: If you use the regex a lot, yeah.
<Odd_Bloke> So the truth is somewhere between our two benchmarks.
<Odd_Bloke> :p
<Odd_Bloke> Mine tests the worst case (we use it zero or one times).
<Odd_Bloke> Yours tests the best case (we use it 1000s of times).
<smoser> well, but yours has so much noise
<smoser> re.compile() seems to take about as much time as 'import re'
<Odd_Bloke> The actual truth: we've spent more time discussing/thinking about this than is likely to be saved by selecting the correct option across all instances forever. ;)
<smoser> correct
<smoser> now lets get thsi stupid py26 stuff settled.
 * smoser waits for harlowja 
<Odd_Bloke> That guy.
<Odd_Bloke> Does he ever wake up.
<Odd_Bloke> harlowja: What does testtools actually get us over unittest2?
<Odd_Bloke> (Except for ugly exception testing :p)
<harlowja_at_home> fixtures integration, having to figure out what to do about py3 (unittest2 only works on py2.x), so we'd end up making a mini testtools anyway, testtools also heavily used throughout openstack so its common ground.... the author is helpful and involved in openstack to
<harlowja_at_home> same author owns unittest2 :-P
<harlowja_at_home> a bunch of other matchers, https://github.com/testing-cabal/testtools/tree/master/testtools/matchers
<harlowja_at_home> integration with https://github.com/testing-cabal/fixtures
<harlowja_at_home> ...
<harlowja_at_home> so thats my 2 cents
<harlowja_at_home> testtols is using unittest2 anyway and its providing the py2/py3 compat
<harlowja_at_home> need me to ask the author to jump in here (he's in new zealand) so he's probably not awake yet
<Odd_Bloke> harlowja_at_home: lifeless?
<harlowja_at_home> yes
<Odd_Bloke> harlowja_at_home: So you can use the matchers outside of the TestCase.
<Odd_Bloke> (I know this because I wrote the function that supports doing it ;)
<harlowja_at_home> ok
<Odd_Bloke> I thought unittest2 worked on 2 and 3.
<harlowja_at_home> https://hg.python.org/unittest2/file/d091f0086b03/setup.py#l40
<harlowja_at_home> so seems not
<Odd_Bloke> harlowja_at_home: The description at https://pypi.python.org/pypi/unittest2 says "It is tested to run on Python 2.6, 2.7, 3.2, 3.3, 3.4 and pypy."
<Odd_Bloke> *shrugs*
<Odd_Bloke> SHURG
<harlowja_at_home> lol
<harlowja_at_home> guess the classifiers haven't been updated
<Odd_Bloke> harlowja_at_home: Maybe because it doesn't make sense to use for later versions?
<Odd_Bloke> (Or maybe just olde)
<harlowja_at_home> probably
 * harlowja_at_home shrugs
<harlowja_at_home> lol
<harlowja_at_home> anyways, will be off most of today, for some reason they gave us 2nd & 3rd off
<smoser> dagummit.
<smoser> harlowja_at_home, want to get through this  py2.6 thing
<smoser> i dont have strong feelings on fixtures/unittest2/testtools
<smoser> but do have strong feelings on jenkins gate job failing :)
<smoser> and also my feeling is that less dependencies is better.
<harlowja_at_home> smoser, ya, only feeling i have is that this is what the rest of openstack uses, it has some nice helpers, losing a context manager, meh
<smoser> also, harlowja_at_home right now onyour branch, if i 'tox -e py27' it doesn't work.
<harlowja_at_home> its a test-time-dependency
<smoser> complains of the importlib;python_ver==2.6
<smoser> or whatever that is.
<harlowja_at_home> yup, upgrade pip
<smoser> :-(
<smoser> upgrade pip is not too easy though.
<harlowja_at_home> ya, not much i can do about that one, this change for all these in pbr is forcing this throughout all of openstack
<smoser> but i just remembered system i'm running it on is 14.04 where usually i do wily
<harlowja_at_home> for better or worse
<harlowja_at_home> ya, i've also got my 14.04 vm and now have to uprade pip, sorta blows
<smoser> what version do you need ?
<smoser> https://launchpad.net/ubuntu/+source/python-pip
<harlowja_at_home> 6+ i think
<smoser> wily is 1.5.6
<harlowja_at_home> afaik only pip 6+ understands version markers
<harlowja_at_home> http://lists.openstack.org/pipermail/openstack-dev/2015-June/067823.html
<harlowja_at_home> and such from robert
<harlowja_at_home> i'm pretty sure that these changes are gonna force many distros to have a massive pip upgrade
<smoser> are these version numbers the same ? 1.5.6 is in wily, but i need 6?
<harlowja_at_home> 6.0+
<harlowja_at_home> they did a huge version number bump, from 1.5 -> 6.0
<harlowja_at_home> now its 7.0 i think, lol
<harlowja_at_home> * https://pypi.python.org/pypi/pip (7.1)
<smoser> ok.
<smoser> so i'd kind of like to avoid this.
<smoser> the only thing we're needing it for is python2.6 needing importlib
<smoser> (at least at this point)
<smoser> right ?
<harlowja_at_home> ya
<smoser> in our tox environment we can easily enough just use a different py26 requirements environment then everything else.
<harlowja_at_home> that is possible to
<smoser> i think i like that better at the moment.
<smoser> than making people (including me) install pip from outside of distro
<smoser> it'd be more acceptable if at least wily had a suitable pip
<harlowja_at_home> ya, i'm pretty sure now that openstack is using those markers, alot of people are gonna have to upgrade
<harlowja_at_home> *for better or worse*
<smoser> ok. so my take out of the above is
<smoser> a.) use testtools unless Odd_Bloke cries
<smoser> b.) remove requirement of newer pip as smoser is a luddite
<harlowja_at_home> :-P
<smoser> if you're on holiday i can try to do that.
<harlowja_at_home> i get it done, but probably heading out soonish
<smoser> i just need some sane path to running this on ubuntu, and "download pip from the intertubes" isn't really sane
<harlowja_at_home> time to get an upgrade :-P
<smoser> harlowja_at_home, you are allowed to not do this today :) its ok for you to celebrate your countries independence from the queen
<smoser> country's even.
<harlowja_at_home> lol
<smoser> (if you only have the one)
<harlowja_at_home> obama the queen
<Odd_Bloke> smoser: FWIW, using a virtualenv on Ubuntu solves the pip problem.
<harlowja_at_home> ya, its still a pita though :-P
<harlowja_at_home> create virtualenv, enter virtualenv, install newer pip
<smoser> using virutalenv to run tox which runs creates a virtualenv
<smoser> i really like the simplicity of 'tox'
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Add importlib for python 2.6 *only*  https://review.openstack.org/197691
<harlowja_at_home> ok let's see what happens
<smoser> what'd you do ?
<smoser> you took importlib out ?
<smoser> oh. isee.
<smoser> but the py26-gate thing wont figure that out, will it ?
<smoser> seems to have figured it out;
<smoser>  https://jenkins02.openstack.org/job/gate-cloud-init-python26/1/
<smoser> i have a feeling that we should have a template engine that uses python formatting.
<smoser> as probably immediately more powerful and better documented than 'builtin'
<smoser> and no dependencies
<smoser> but it might not be sufficent for how we want to expose objects to templating.
<Odd_Bloke> The new formatting syntax is pretty comprehensive.
<harlowja_at_home> cloud-init-formatter-v1000
<harlowja_at_home> lol
<Odd_Bloke> Though we should investigate if you can do anything untoward using it. :p
<smoser> Odd_Bloke, i dont think i can access object.property
<smoser> can i ?
<Odd_Bloke> smoser:
<Odd_Bloke> smoser: Sure.
<Odd_Bloke> smoser: http://paste.ubuntu.com/11811141/
<smoser> awesome.
 * harlowja_at_home pretty sure i made that possible :-P
<smoser> ok. so yeah, i like this.
<smoser> harlowja_at_home, you did. you rock.
<harlowja_at_home> oh, i think thats the built-in python formatting, nothing i did :-P
<smoser> right.
<smoser> thats what i'm saying we should offer as a templating option
<harlowja_at_home> ah
<harlowja_at_home> except afaik it only got good on 3.0 +
<harlowja_at_home> https://www.python.org/dev/peps/pep-3101/
<Odd_Bloke> Oh, Python 2.6 might be screwed.
<harlowja_at_home> and 2.7?
<Odd_Bloke> That example is on 2.7.
<harlowja_at_home> k
<harlowja_at_home> guess they must of backported some of it
<harlowja_at_home> or something
<Odd_Bloke> Just tested it, and the above works on 2.6.
<harlowja_at_home> cool, up to u guys
<smoser> i think makes sense to add it
<smoser> and will just fail on py2.6 .
<smoser> https://review.openstack.org/#/c/197691/5/cloudinit/sources/openstack/httpopenstack.py
<smoser> as seen there, you had to make that change as the .format didnt' work on py26 right?
<smoser> Odd_Bloke, could you review https://review.openstack.org/#/c/197691/
<smoser> it is sane to me.
<smoser> the one thing ihave left is that we added the py26 environment, which means 'tox' will fail now on any recent ubuntu. where as previously it would pass ( as we didn't need py26)
<harlowja_at_home> u running all the tox envs?
<harlowja_at_home> for fun
<smoser> well, i want to run 27 and 34 for sure by default
<openstackgerrit> Merged stackforge/cloud-init: Add importlib for python 2.6 *only*  https://review.openstack.org/197691
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Bring over the 'templater' from bzr  https://review.openstack.org/170257
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: pip2distro: work in progress: build tox env for specific targets  https://review.openstack.org/197671
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: tools/tox-venv: support running other than ./tools/tox-venv  https://review.openstack.org/195631
<openstackgerrit> Joshua Harlow proposed stackforge/cloud-init: Expose api response properties and cache buffer decoding  https://review.openstack.org/195800
<smoser> why does tox docs not work
<smoser> :-(
<smoser> http://paste.ubuntu.com/11811416/
<smoser> https://bugs.launchpad.net/oslotest/+bug/1379998
<harlowja_at_home> no idea, jump on #openstack-oslo ask pbr folks?
<smoser> harlowja_at_home, well. this fixes it.
<smoser> but i dont know how that bug reports fixed in oslotest
<harlowja_at_home> ya, not sure
<smoser> http://paste.ubuntu.com/11811486/
<smoser> that fixes it.
<smoser> but will break again when 1.3b4 is released unless its fixed there.
<harlowja_at_home> ya
<harlowja_at_home> ok, i'm off
<harlowja_at_home> will be on maybe at night or something, ha
<smoser> ok.
<openstackgerrit> Scott Moser proposed stackforge/cloud-init: fix 'tox -e docs' by limiting sphinx versions  https://review.openstack.org/198080
<openstackgerrit> Merged stackforge/cloud-init: Bring over the 'templater' from bzr  https://review.openstack.org/170257
<smoser> if someone else could check my work on https://review.openstack.org/#/c/198080/
<smoser> i'd appreciate it. Odd_Bloke claudiupopa ^
<openstackgerrit> Merged stackforge/cloud-init: Bring over the 'safeyaml' from bzr  https://review.openstack.org/170252
<openstackgerrit> Merged stackforge/cloud-init: tools/tox-venv: support running other than ./tools/tox-venv  https://review.openstack.org/195631
<openstackgerrit> Scott Moser proposed stackforge/cloud-init: fix 'tox -e docs' by limiting sphinx versions  https://review.openstack.org/198080
<openstackgerrit> Scott Moser proposed stackforge/cloud-init: Expose api response properties and cache buffer decoding  https://review.openstack.org/195800
<openstackgerrit> Merged stackforge/cloud-init: fix 'tox -e docs' by limiting sphinx versions  https://review.openstack.org/198080
<openstackgerrit> Merged stackforge/cloud-init: Expose api response properties and cache buffer decoding  https://review.openstack.org/195800
<smoser> why can't anything be easy.
<smoser> attempt at running http://paste.ubuntu.com/11812524/ on vivid
<smoser> results in http://paste.ubuntu.com/11812519/
<smoser> and, oh joy. py34-coverage and py27-coverage now fail.
<smoser> fail as in we dont have 90% coverage.
<smoser> Odd_Bloke, ^ claudiupopa ^ feel free to fix that. :)
#cloud-init 2015-07-03
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Don't consider Python 2.6-only code for coverage.  https://review.openstack.org/198263
<Odd_Bloke> smoser: The coverage jobs have failed forever, but ^ should fix them.
<Odd_Bloke> smoser: And you can get Jenkins to run again using "recheck" as a comment on the change. :)
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Basic implementation of a reporting framework.  https://review.openstack.org/191144
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Move our TestCase in to the cloudinit.tests package.  https://review.openstack.org/198308
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Speed up a slow test.  https://review.openstack.org/198348
#cloud-init 2016-07-05
<hendry> hi guys, looking for a way to turn off ssh password authentication
<hendry> saw mention of ssh_pwauth, but I can't find it in the docs
<hendry> do you guys seriously still use bzr? https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
<magicalChicken> hendry: just setting 'ssh_pwauth: false' in config should disable it. its handled in cc_set_passwords.py around line 100 if you want to see the details
<hendry> magicalChicken: thank you, though is it in the documentation?
<hendry> was curious to figure out what was the default too
<magicalChicken> i searched the docs and I don't think its there
<magicalChicken> I think the default is to just preserve whatever the distro default is
<magicalChicken> which I think for ubuntu is true
<hendry> magicalChicken: shouldn't that be raised as a bug perhaps? that's its not documented?
<magicalChicken> yeah, probably, there's some other documentation that needs to be updated too
 * hendry wonders what the difference is between repo_upgrade: all and package_upgrade: true
<hendry> https://twitter.com/kaihendry/status/750178637026996224
<mgagne> smoser: so I tested cloud-init with baremetal and found that Nova does not use vlan_mac_address but ethernet_mac_address
<rharper> mgagne: do you have your network_data.json and the network config it rendered ?
<mgagne> rharper: it failed to render with a KeyError
<rharper> mgagne: ok, so there's a vlan device but no vlan_mac_address key in the json
<rharper> or that's my guess without seeing the network_data.json
<mgagne> yea, it is ethernet_mac_address
<rharper> well that's odd
<mgagne> not vlan_mac_address
<rharper> to have ethernet_mac_address under vlan device ?
<mgagne> I don't think that's the point
<mgagne> https://github.com/jayofdoom/cloud-init-fedora-pkg/blob/master/cloud-init-0.7.5-onmetal-configdrive.patch#L103-L104
<mgagne> https://github.com/openstack/nova/blob/master/nova/virt/netutils.py#L261
<mgagne> there is no special case for vlan
<mgagne> and provider implementing the spec are using ethernet_mac_address, not vlan_mac_address.
<mgagne> in fact, I found that glean supports both
<mgagne> https://github.com/openstack-infra/glean/blob/master/glean/cmd.py#L514-L515
<mgagne> or I misinterpreted it
<mgagne> what do you think?
<rharper> I'm checking some doc;  I had at least one example where the data included a vlan_mac_address
<mgagne> jroll: ^ do you know if rax provides mac address for VLAN interfaces in config drive? if so, in which field?
<rharper> mgagne: AFAICT, vlans can have a uniq mac, if they want;    if the type: vlan didn't include vlan_mac_address or ethernet_mac_address, then the vlan interface would get the mac from the vlan_link interface it runs on top of;  in your case, I think we should at least check for either vlan_mac_address or ethernet_mac_address in the type:vlan dictionary;
<mgagne> rharper: right so this could fallback gracefully to the "raw" interface mac address? I'm not sure of the impact of such change tbh
<rharper> mgagne: well, it would omit including a hwaddress under the vlan interface
<mgagne> I'm more or less concerned about what should be the name of this field as I saw implementation differing from spec
<rharper> well
<rharper> it could be called 'mac_address'
<rharper> and it's properly scoped under a type: ethernet  or type: vlan
<mgagne> it's already ethernet_mac_address in code
<rharper> in our model, in either case, if when rendering a type: x, it shows up as an interface property
<rharper> the spec didn't cover vlans IIRC, no ? just mentioned them in passing
<rharper> in the examples show, they were type: ethernet devices and then included the 'ethernet_mac_address' field
<mgagne> rharper: yea, they mentioned it in the example which happened to be a "strong" reference when writing the implementation
<rharper> right
<mgagne> but as you saw, they followed part of it
<mgagne> they renamed neutron_network_id for network_id and didn't update the spec
<mgagne> and now we also have out of tree implementation floating around (including mine)
<rharper> right, and others
<rharper> rackspace/ironic  (which is where I got the vlan_mac_address) for their type: vlan
<mgagne> which I happened to write to fit the rax's cloud-init fork implementaiton
<mgagne> rharper: there is no mention of vlan_mac_address in their implementation in cloud-init. Do you happen to have access to a config drive generated at rax?
<rharper> I'm not certain what we should do w.r.t the spec lacking specification other than be widely accepting in *mac_address
<mgagne> will check bifrost
<rharper> mgagne: I have the network_data.json , is that good enought ?
<mgagne> I'm sure it contains all that's needed
<mgagne> I'm happy to change my implementation if the consensus happens to be vlan_mac_address
<mgagne> well... https://github.com/openstack/bifrost/blob/fa5f65adeff340f8415be46754cb327a3912852d/playbooks/library/network_metadata.py#L83
<rharper> honestly, it'd be nice to drop the prefix, since the field is under a type: XXX dictionary
<mgagne> looks like I was wrong =()
<mgagne> true
<rharper> I have ethernet, bond and vlan dictionaries
<rharper> each which *could* have a mac_address value, and it's scoped per-interface anyhow;
<mgagne> but it's a public "api" and changing implementation is close to impossible to make for "don't break end user interface"
<mgagne> ok, will update my implementation I guess
<rharper> http://paste.ubuntu.com/18575659/
<rharper> that's the rax one we got with ipv6 , bonding, and vlans
<mgagne> cool, looks like it's vlan_mac_address
<mgagne> but
<mgagne> I'm sure it used to be ethernet_mac_address =)
<rharper> yeah, and I'd +1 updating spec to just be 'mac_address' under type: X
<mgagne> because otherwise this would make no sense: https://github.com/jayofdoom/cloud-init-fedora-pkg/blob/master/cloud-init-0.7.5-onmetal-configdrive.patch#L277
<rharper> mgagne: yeah, that wouldn't work with the mismatch
<mgagne> so I guess I will include both for now until I fix all my images :-/
<mgagne> oh, I know why
<mgagne> it used to be in vendor_data.json
<mgagne> and now it's in network_data.json which happens to respect the new approved spec
<rharper> interesting
<mgagne> so to conclude: cloud-init implementation is right. old implementation by rax is wrong when used against upstream Nova implementation (but not against their own vendor implementation)
<mgagne> and I'm stuck in the middle :D
<rharper> that looks about right =(
<harlowja> mgagne start contributing to the upstream cloud-init one ;)
<harlowja> shouldn't be a need for a custom version anymore
<harlowja> and with https://code.launchpad.net/~harlowja/cloud-init/cloud-init-render-tool u can test the rendering(s) before using it
<mgagne> waiting for git repo (muhaha)
<harlowja> ah, smoser ^^^^^
<harlowja> ding a ling
<harlowja> lol
<rharper> nice
<harlowja> ya, that render helper thing is useful for seeing exactly wtf is gonna be output given a network_data.json
<harlowja> and yes mgagne u should let me know if that thing has rendering issues
#cloud-init 2016-07-07
<hendry> hello? https://twitter.com/jshharlow/status/750710649169162240
<hendry> think the timezones are going to screw us
<Odd_Bloke> hendry: o/ I don't know about harlowja, but I think smoser is on vacation this week.
<hendry> ohkay
<Odd_Bloke> hendry: (And I'm pretty sure harlowja is West Coast US)
<harlowja> yup i am
#cloud-init 2016-07-09
<linuxgeek_> hi
<linuxgeek_> i want to set password of the default user in debian8.5 and centos7 cloud images
<linuxgeek_> i followed the guestfish https://ask.openstack.org/en/question/5531/defining-default-user-password-for-ubuntu-cloud-image/
<linuxgeek_> however it did not login
<linuxgeek_> i also added a new user under default
<linuxgeek_> that also did not work
<linuxgeek_> need some help in settting password to default and new users
<linuxgeek_> i booted an instance using the ubuntu 16.04 cloud image. it shows this message http://paste.openstack.org/show/529031/ and does not apply any cloud-init configuration.
<linuxgeek_> i see the same behaviour with debian 8.5. centos 7 works
<linuxgeek_> for debian 8.5, seems like https://bugs.launchpad.net/cloud-init/+bug/1454185
<linuxgeek_> need pointers how to sort this
#cloud-init 2017-07-03
<Wulf> I'm running AWS EC2 instances. I would like to pass a parametrized URL as userdata like "#include http://path/foo?a=b&c=d". foo should contain python code (same for all instances) that will be executed by cloud-init and dynamically create a cloud-config configuration and inject it into cloud-init. I kind of got it working with a part-handler and sys._getframe, but it's really ugly. Is there (or should
<Wulf> there be) any proper way to achieve the same?
<smoser> Wulf, you're wanting the instance to identify itself in the '#include' i guess ?
<smoser> somehow ?
<smoser> (headers would be an option)
<Wulf> smoser: no, the web server is static (e.g. s3), so the client (cloud-init) won't identify itself
<Wulf> smoser: but the url might contain like ?name=newhostname
<smoser> i guess you overrode the part-handler for '#include' ?
<smoser> what you're asking for does sound interesting
<Wulf> smoser: no, for a new mime type
<Wulf> So is there currently any other way to download+execute arbitrary code than a part-handler?
<smoser> well, a '#!'
<smoser> Wulf, but that has the same general issue ... i think you're wanting python access to hostname or instanceid ... is that right ?
<smoser> is that what you were using sys._getframe for ?
<Wulf> smoser: I want python access to the cloud-config part so I can set the hostname of a list off ssh keys, host specific mounts, etc. I use sys._getframe to access walker_callback.data['handlers']['text/cloud-config']
<Wulf> *or a list of ssh...*
<smoser> so i think i udnerstand, but i'm kind of confused.
<smoser> is the url static for each node ?
<smoser> ie, you want static url and static content
<smoser> that produces different cloud-config for the node based on information available on the node.
<Wulf> smoser: the content is static, the url might vary with ?parameter=value which the webserver behind it ignores
<smoser> i think
<smoser> powersj, do you know why the copr build failures ?
<powersj> smoser: I looked briefly friday and it appears that the lxd pull is failing
<powersj> lxd file pull*
<powersj> says the file does not exist; I didn't have enough time to determine if it was due to the lxd 2.15 update, but that is the only thing to have changed
<powersj> blackboxsw: \o/
<blackboxsw> powersj: and smoser you guys are around an awful lot for vacationing ;)
<smoser> blackboxsw, i'm officiall in today
<blackboxsw> ohh didn't realize that.
 * powersj isn't, but broken AC means I'm sitting at coffee shop
<smoser> powersj, has no excuse.
<smoser> blackboxsw, i'm out the rest of the week thoguh
<smoser> blackboxsw, if you were just bored...
<smoser> 2 things
<smoser> a.) when i run: tox-venv py3 python3 -m nose tests/unittests/
<smoser>   tests.unittests.test_datasource.test_openstack.TestOpenStackDataSource is the slowest.
<smoser> b.) i believe if you launch an openstack instance without user-data then it will re-try to get it (if its not been given it will 404)
<smoser> and we should accept that as "no user data", rather than trying again
<smoser> (i think these 2 things might be related)
<blackboxsw> roger smoser
<blackboxsw> ok so we want the code to avoid retries on 404?
<smoser> for user-data specifically
<blackboxsw> hmm I already see MetadataReader.should_retry_cb in cloudinit/sources/helpers/openstack.py which should return False if error code >= 400
<smoser> blackboxsw, ssh ubuntu@10.245.162.120
<smoser> i think you should be able to get there (with vpn)
<smoser>   /var/log/cloud-init.log -> http://paste.ubuntu.com/25012904/
<blackboxsw> I'm there
<smoser> 2017-07-03 18:26:51,445 - url_helper.py[DEBUG]: [0/6] open 'http://169.254.169.254/openstack/latest/user_data' with {'timeout': 10.0, 'method': 'GET', 'allow_redirects': True, 'headers': {'User-Agent': 'Cloud-Init/0.7.9'}, 'url': 'http://169.254.169.254/openstack/latest/user_data'} configuration
<smoser> 2017-07-03 18:26:52,514 - url_helper.py[DEBUG]: Please wait 1 seconds while we wait to try again
<blackboxsw> heh, well that looks like it's not using that retry logic I saw for the base metadata crawler. ok thx.
<blackboxsw> looks like it hit that retry about 5 times/
<blackboxsw> ok
<smoser> right
<blackboxsw> ok I exited your instance
<blackboxsw> ok it's the wait _for_url  call
<blackboxsw> got it.
<blackboxsw> sure I'll pull together a fix
<smoser> blackboxsw, file a bug please too
<smoser> and thank you
<blackboxsw> no prob
<blackboxsw> smoser: vendordata and networkdata (both are optional metadata, shall we also avoid retries in those cases?)
<smoser> i think those work as expected.
<smoser> i think.
<smoser> i think they're both guaranteed
<blackboxsw> ok I was just trying to queue off of the commonolity of networkdata and vendordata also being listed as optional in cloudinit/sources/helpers/openstack.py 227-241
<blackboxsw> commonality rather
<blackboxsw> as in, if optional: don't retry 404
<blackboxsw> but we can make it specific to just user_data if we want
<smoser> blackboxsw, they may be optional. i was just going from memory
<smoser> you can look in https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L449
<smoser> thats the backend
<blackboxsw> If I'm reading things right, looks like network_data is avail on Liberty, but not on other versions. Vendor data is available on Havana, but Vendor-data2 is avail on Newton2. So they too look optional.
<blackboxsw> depending on the version of openstack
<blackboxsw> https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L627
<blackboxsw> ahh that _check_os_version call is that the version is >= <version_name> so    vendor_data exists >= Havana, network_data exists >= Liberty
<blackboxsw> does cloud-init need to support < Havana?
<smoser> i didnt know there is a vendor-data2.
<smoser> blackboxsw, https://releases.openstack.org/
<smoser> i'd say we can get away with breaking support for a platform that has been EOL for 2.5 years.
<smoser> i guess the realistic scenario would be someone running 12.04 but wanted to run 16.04 guests... we'd break them.
<blackboxsw> heh, didn't know if cloud-init had compelling customer base running on pre-Havana (I'd think any vendor running on that version of openstack would have moved to something a bit more recent anyway)
<blackboxsw> gotta head out for the day
#cloud-init 2017-07-05
<voja> Hi, I'm using KVM and I'd like to boot a Ubuntu Xenial cloud image and pass a static IPv4 / IPv6 dual stack configuration via NoCloud datastore. I'm using the network configuration v1 format, because I'd like to be able to boot CentOS later, too. I added a second subnet with type: static6, but it seems that the resulting generated entry is somehow invalid. The IPv6 network is not configured correct. Is there any example for
<voja> dual stack configuration?
<Wulf> voja: if not correct, what is it?
<Wulf> voja: post your configuration and the result
<voja> https://www.irccloud.com/pastebin/KfepW47y/
<voja> I hope you can open that link
<voja> My IRC client made this because it seem to be too long
<voja> OMG
<voja> Perhaps I should try to discard the second interface and make a second subnet entry
<voja> I'm currently not sure why I used the interface alias
<Wulf> voja: your irc client automatically turns large pastes into a link? nice feature :-)
<Wulf> voja: do *not* use the interface:0 syntax
<Wulf> voja: that would be a good /etc/network/interfaces: https://pastebin.com/9cfdg9Z2
<voja> https://www.irccloud.com/pastebin/hpzOFUQ2/
<voja> This result in
<voja> https://www.irccloud.com/pastebin/UAI0e7IR/
<Wulf> voja: looks better. does it work?
<voja> No :-(
<voja> The 2a01::XX is not up
<Wulf> voja: if you use ifup/ifdown manually, does it work?
<voja> sudo ifup ens3
<voja> sudo: unable to resolve host cloudimg: Connection refused
<Wulf> that's a sudo problem
<voja> And: /etc/network/interfaces.d/50-cloud-init.cfg:17: unknown or no method and no inherits keyword specified
<Wulf> voja: and what's in there?
<voja> When I change the line 17 "iface ens3 inet6 static6" in /etc/network/interfaces.d/50-cloud-init.cfg to "iface ens3 inet6 static"
<voja> sudo ifup ens3
<voja> sudo: unable to resolve host cloudimg: Connection refused
<voja> Waiting for DAD... Done
<voja> The IPv6 is up then
<Wulf> oh, "static6" is of course rubbish
<voja> I assume the static6 should be replaced by static in /etc/network/interfaces.d/50-cloud-init.cfg
<voja> Should I try static instead? AFAIR I got this from the docs
<Wulf> voja: https://pastebin.com/9cfdg9Z2
<Wulf> voja: I don't know how to teach that to cloud-init though
<voja> Yes, that's what it should look like
<voja> I'm trying again with static instead of static6
<voja> A this leads to an unusable VM
<voja> [   13.669155] cloud-init[FAILED] Failed to start Initial cloud-init job (pre-networking).
<voja> See 'systemctl status cloud-init-local.service' for details.[396]: Cloud-init v. 0.7.9 running 'init-local' at Wed, 05 Jul 2017 09:29:30 +0000. Up 12.91 seconds.
<voja> This breaks even the generation of the login user, so it's hard to get to the systemctl to view a log...
<voja> Could this be a bug in cloud-init that it renders static6 instead of static to /etc/network/interfaces ?
<Wulf> voja: possible
<voja> Would you recommend opening a ticket, or do you have any other idea what I could try?
<Wulf> voja: read the source, find the bug?
<voja> Yes... So Python it is
<Wulf> yep :)
<Wulf> python 3 even
<voja> I wanted to learn Python since a few weeks, but I got stuck with the question Python 2 or 3
<Wulf> 3.
<voja> 50-cloud-init.cfg is referenced in cloudinit/distros/debian.py:
<voja> NETWORK_CONF_FN = "/etc/network/interfaces.d/50-cloud-init.cfg"
<voja> When I grep for NETWORK_CONF_FN there is no other result
<voja> That is confusing, because this filename needs to used somewhere
<voja> The only caveat with 3 was probably that Ansible sometimes requires v2
<voja> Okay, I did not see the second ocurence of /etc/network/interfaces.d/50-cloud-init.cfg
<voja> Okay, I think I found the bug
<voja> cloudinit/net/eni.py line 127
<voja> "iface {fullname} {inet} {mode}"
<voja> Need to figure out how mode is set
<voja> okay, the bug may then be located in another line ;-)
<voja> okay, the _render_iface doesn't fix the mode
<voja> This method does the inet/inet6 mapping, but does not write static instead of static6
<voja> That causes the syntax erro
<voja> r
<voja> I need to find a proper way to inject the fix to the cloud image, then I can test my solution
<voja> My patch is working :-)
<voja> I'll create a launchpad.net account later and submit a bug report + patch suggestion
<powersj> rharper: blackboxsw: this is why the copr build is failing: https://github.com/lxc/lxd/issues/3499
<rharper> urg
<rharper> we can workaround by taring
<rharper> tar -cpf package.tar *.src.rpm ; and lxc file pull
<rharper> or lxc exec container -- cat cloud-init-*.src.rpm > cloud-init.src.rpm
<rharper> etc
<rharper> naughty bug though
<rharper> powersj: building an updated cloud-init for my curtin work, the i386 cent6 build failed, something under cloud_tests;  https://copr-be.cloud.fedoraproject.org/results/%40cloud-init/cloud-init-curtin/epel-6-i386/00576191-cloud-init/build.log.gz
<powersj> rharper: this is tot?
<rharper> no
<rharper> a branch of mine
<powersj> ah
<rharper> but I've not touched any thing under cloud_tests
<powersj> ok got me scared for a min, as nightly tests are reporting passed
<rharper> but I've merged from trunk today
<rharper> nightly tests building srpms under cent6 ?
<powersj> yes
 * rharper goes looking for trunk el6 i386 builds
<powersj> although we don't do i386 builds...
<rharper> all mine failed
<powersj> to be more specific I am referring to these results: https://jenkins.ubuntu.com/server/job/cloud-init-ci-nightly/
<rharper> so not just i386
<rharper> maybe I have dirtry tree when src rpm building
<powersj> that is tot, and the last test is it runs the tests and builds the srpm under centos 6 and 7
<rharper> oh, it has the same error but something else must of failed
<rharper> /usr/bin/python -O /tmp/tmpVVbF54.py
<rharper> SyntaxError: ('invalid syntax', ('/usr/lib/python2.6/site-packages/tests/cloud_tests/config.py', 60, 19, '                for k, v in override.items() if isinstance(v, dict)})\n'))
<powersj> rharper: aren't the "File not found" errors fatal?
<rharper> yes
<rharper> if you say it should be packaged, and it's not; that's an error
<rharper> powersj: found it,   in my branch I've got a patch that touches the specfile and the switch to jinja template got broken so, still had \$RPM_BUILD_ROOT instead of $RPM_BUILD_ROOT
<powersj> rharper: ah! :) good to know
#cloud-init 2017-07-06
<korean101> Hi guys.
<korean101> i use openstack Kilo releases. and i wanna change my user-data
<korean101> but cached files in '/var/lib/clou
<korean101> '/var/lib/cloud'
<korean101> re read original user-data
<korean101> how can i change already created user-data
<korean101> ??
<Putti> korean101, if you use nova, then try passing to nova boot the --user-data option, but I think if you ask openstack people they might give you a better answer
<korean101> Putti: already created VM (with --user-data) -> can't change user-data
<korean101> Putti: https://blueprints.launchpad.net/nova/+spec/userdata-modification (not yet)
<korean101> Putti: thanks!!
<Putti> ok, glad that something worked
<Putti> :)
<nixstar> hello
<nixstar> wanted to know if there is any way to get the fqdn - eth0 IP addr entry in /etc/hosts?
<nixstar> wanted to get an entry like below
<nixstar> 10.87.3.83 comet.test.com comet
<nixstar> not able to see any variables that have IP addr in cloud-init
<Putti> nixstar, at least something like a shell script given as user data should do it.
<Putti> nixstar, or http://cloudinit.readthedocs.io/en/latest/topics/examples.html#writing-out-arbitrary-files
<nixstar> thanks Putti
<nixstar> I was hoping there must be some variable or inbuilt function that gets the IP
<Putti> nixstar, you should use this: http://cloudinit.readthedocs.io/en/latest/topics/modules.html#update-etc-hosts
<nixstar> i used that
<Putti> ah yes, you want the ip too
<nixstar> yes
<Putti> nixstar, I looked the code cloudinit/distros/__init__.py and it seems not. Currently the value comes from the function _get_localhost_ip() so you could change that if you want, or could make a patch to be applied in upstream... I could even do that.
<Putti> hmm or if you just change the ip with some script in /etc/cloud/templates/hosts.tmpl it looks like it preserves the ip addr
<Putti> nixstar, you can of course use other tools like ansible to add the ip address there
<nixstar> Putti, let me check the code
<Putti> I started making the patch but I'm currently looking code for getting the eth0 ip address.
<Putti> can the interface have multiple ip addresses?
<nixstar> In my case no
<nixstar> Putti are contributing member of cloud-init?
<nixstar> * are you
<Putti> I have submitted some patches to the launchpad but none yet in
<nixstar> ok :)
<nixstar> I haven't worked much with cloud-init, so thought there might be some to get the IP and ...came here
<blackboxsw> nixstar Putti are you folks looking at  http://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname  maybe?
<blackboxsw> bummer, missed nixstar.
#cloud-init 2017-07-07
<mob1> Hello, is there a way to install latest cloud-init to ubuntu 14.04?
<mob1> I could compile it but I couldn't find compilation guide from tar ball
<mob1> I got this far on ubuntu LTS 14.04 https://pastebin.com/TJJ1a1jK
<mob1> argparse was missing, fixed.
<blackboxsw> mob1 we recently added a new make target which should pull in any system dependencies you may need to build and run cloud-init. Try 'make ci-deps-ubuntu'
<blackboxsw> for next time :).  It'll get you everything you need.
<blackboxsw> powersj: rharper so configuring a link-local 169.254.X.Y address on eth0 in aws ephemeral boot (init-local stage) can't wget http://169.254.169.254, but after a dhclient eth0 in that environment (getting me a 172.31.X.Y address I do get to access the metadata service.  I've tried dumping ethtool/ifconfig info in both cases and can't really determine yet why manually configured link local addresses don't get through to
<blackboxsw> 169.254.169.254. pastebins coming
<blackboxsw> any logging I added is prefaced w/ Chad :/
<blackboxsw> successful init-local ephemeral instance gets metadata service after  a dhclient eth0 request http://paste.ubuntu.com/25040315/
<blackboxsw> unsuccessful init-local ephemeral instance setting static random link local 169.254.X.Y address on eth0 http://paste.ubuntu.com/25036317/
<blackboxsw> I'm about to try a tcpdump -i on eth0 to see if the interface can actually see any traffic in link-local mode vs. dhclient
<blackboxsw> if anyone has other tool suggestion besides ethtool, mii-tool, tcpdump, route  I should be looking at to triage network connectivity issues I'm all ears
<blackboxsw> I also might try statically configuring the expected dhcp ip address & routes given to this instance to see generally if the instance can touch 169.254.169.254 when statically config'd (non link-local addr)
<rharper> blackboxsw: it's certainly possible there needs some interaction with the cloud via DHCP to authorize/enable it
<rharper> blackboxsw: in general, you can check for carrier which should be enough; but it's possible that there needs to be some forwarding or otherwise backend things that have to happen to allow off-instance networking
<blackboxsw> powersj: rharper: ok so looks like in ephemeral environment on AWS I can also manually setup a static IP with the ip address and route I was given to the non-ephemeral instance when it booted and that ip gets ahold of the metadata service ip 169.254.196.254 without issue. so it doesn't necessarily look like I have to dhclient in the ephemeral environment in order to talk to the metadata service. But I do wonder if the
<blackboxsw> initial dhclient from the non-ephemeral instance set something up, sec-group or firewall wise, for the metadata service to allow traffic from the the allocated dhcp ip.
<blackboxsw> http://paste.ubuntu.com/25040989/ shows static IP set to the 172..... IP addr and default gateway setup
<blackboxsw> meh, I'm not liking how this sounds http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses
<blackboxsw> It seems  I cannot manally configure a different private net address on the 172... network as I get the same timeouts. I also cannot seem to allocate a link-local address to the instance. I'm thinking the instance is tightly bound to the dhcp allocated ip address for aws but I can't confirm that in docs.
<blackboxsw> The link above does say the folllowing about private ip addresses for EC2-Classic instances "We select a single private IP address for your instance; multiple IP addresses are not supported."
<blackboxsw> rharper: why is it that we don't want to dhclient eth0 in init-local of cloud-init (speed?)
<rharper> yeah, DHCP takes longer than ip up
<rharper> also cleanup of lease files and other things
<blackboxsw> hmm. If dhclient ends up being the only answer to obtain a "local" ipv6 configuration setup from the AWS metadata service,  I'm not quite sure at what stage we'd want to perform the dhclient on eth0
<blackboxsw> hmm got a few mins for a hangout?
<rharper> yeah, on one with dpb at the moment
<blackboxsw> sounds good, saw a trello card moved over to me
<blackboxsw> figured as much
<rharper> blackboxsw: https://hangouts.google.com/hangouts/_/canonical.com/link-local?authuser=1
#cloud-init 2017-07-09
<jamesr__> Hi All, I'm trying to use cloud-init on Ubunut 17.04 via OVF deploy on vSphere. I suspect it's not finding a valid datasource via ds-identify (though I am a bit new to all of this). Anyone any luck with this deployment method?
<jamesr__> http://bazaar.launchpad.net/~baoli/cloud-init/cloud-init/revision/1173 - might be this?
#cloud-init 2018-07-02
<do3meli> hey folks
<do3meli> just came around a freebsd issue with newest 18.3 release. may @smoser or chad can look at https://bugs.launchpad.net/cloud-init/+bug/1779672 quickly? i see you guys recently changed something in netinfo -> commit id: 14cb4924a6cf191107f9c04698ace2753eb44d2b
<ubot5> Ubuntu bug 1779672 in cloud-init "netdev_pformat key error on FreeBSD with 18.3" [Undecided,New]
<ybaumy> smoser: today ive seen that my centos box sees itself as ubuntu distro and tries package_upgrade for example with apt.. is this a known bug?
<ybaumy> im on 18.2
<ybaumy> i looked at the code from stages.py and util.py.. the get_linux_distro function makes a lookup at /etc/os-release which is there
<ybaumy> i havent debugged the function yet
<ybaumy> https://github.com/cloud-init/cloud-init/commit/bbcc5e82e6c8e87ca483150205127cb0436c4cd9#diff-c4ca7388c7bb98a487f86f4d62d7fab3
<ybaumy> can it be that i have to use 18.3?
<danMS> @smoser - just wondered if you can take a look at https://bugs.launchpad.net/cloud-init/+bug/1779207 and let me know your thoughts on it?
<ubot5> Ubuntu bug 1779207 in cloud-init "Failed mount of '/dev/sdb1' with Swap File cloud-init config" [Undecided,New]
<blackboxsw> danMS: smoser is out for a few days, one of us will look at it this week.
<blackboxsw> perharps today even :).
<danMS> Thank you, appreciated!
<blackboxsw> looks like it's time for our cloud-init bi-weekly status meeting
<blackboxsw> ... the topic lies :)
* blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 7/2 16:00 UTC | cloud-init 18.2 released (03/28/2018)
<blackboxsw> not anymore it doesn't :)
<blackboxsw> danMS: I'll potentiall have an item of interest for you(Azure-related) in this meeting
<danMS> :)
<blackboxsw> if you have a chance to glance at it today, it's nothing pressing, but might be interesting.
<blackboxsw> #startmeeting Cloud-init bi-weekly status meeting
<meetingology> Meeting started Mon Jul  2 16:05:44 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> hi folks, just kicking off another cloud-init status meeting to communicate the recent events in cloud-init land.
<blackboxsw> welcome to all, feel free to interrupt as we go through the agenda. As always cloud-init status minutes will live at the following url
<blackboxsw> #link https://cloud-init.github.io/
<blackboxsw> The meeting agenda is as follows:
<blackboxsw> agenda: Previous Actions, Recent Changes, In-progress develepment and office hours (~30 minutes)
<blackboxsw> #topic Previous Actions
<blackboxsw> Last meeting we have a couple of actions to look over:
<blackboxsw>  #ACTION blackboxsw carryover network hotplug vs network maintenance on reboot-only
<blackboxsw>  #ACTION blackboxsw carryover network hotplug vs network maintenance on reboot-only [DONE]
<blackboxsw> we held multiple meetings, including discussion with mgerdts on a SmartOS solution for handling regenerating network configuration per-boot when a user selects this behavior
<blackboxsw> We have just landed a supporting branch in cloud-init tip to enable datasources to define what events (BOOT vs BOOT_NEW_INSTANCE) they will react to when generating network config.
<blackboxsw> #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348000
<blackboxsw> that should give a foundation for other datasources to write/change network config across boots, instead of allowing network config to remain static based on cloud-init's initial network configuration
<blackboxsw> the 2nd action ..
<blackboxsw> #ACTION haper/blackboxsw review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904 [CARRYOVER]
<meetingology> ACTION: haper/blackboxsw review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904 [CARRYOVER]
<blackboxsw> I'd like to carry this one over. We got a bit bogged down in SRU, CentOs stuff last week and we shold be able to get some eyes on this branch
<blackboxsw> I think that's it for actions.
<blackboxsw> #topic Recent Changes
<blackboxsw> Below is a list of changes landed in cloud-init tip or package publishing that has occured for the project:
<blackboxsw> * our 18.3 release was cut from tip if you caught the email on that mailing list
<blackboxsw> Congrats all for a great effort at improving quality and adding more datasource/cloud support
<blackboxsw> #link https://lists.launchpad.net/cloud-init/msg00164.html
<blackboxsw> ^ in case you didn't get the message
<blackboxsw> * we also publish 18.3 release into Ubuntu Cosmic and started a stable release update (SRU) to publish 18.3 in to xenial, artful, bionic
<blackboxsw> published*
<blackboxsw> expectations are that xenial, artful and bionic will have 18.3 after this week of testing
<blackboxsw> the remaining changes landed in tip are:
<blackboxsw>     - update_metadata: a datasource can support network re-config every boot
<blackboxsw>       [Chad Smith]
<blackboxsw>     - tests: drop salt-minion integration test (LP: #1778737)
<blackboxsw>     - Retry on failed import of gpg receive keys.
<blackboxsw>     - tools: Fix run-container when neither source or binary package requested.
<blackboxsw>     - docs: Fix a small spelling error. [Oz N Tiram]
<blackboxsw>     - tox: use simplestreams from git repository rather than bzr.
<ubot5> Launchpad bug 1778737 in cloud-init "salt-minion test needs fixing" [Undecided,Fix committed] https://launchpad.net/bugs/1778737
<blackboxsw>     - release 18.3 [Chad Smith] (LP: #1777743)
<blackboxsw>     - docs: represent sudo:false in docs for user_groups config module
<blackboxsw>       [Chad Smith]
<ubot5> Launchpad bug 1777743 in cloud-init "Release 18.3" [Undecided,Fix released] https://launchpad.net/bugs/1777743
<blackboxsw>     - Explicitly prevent `sudo` access for user module
<blackboxsw>       [Jacob Bednarz] (LP: #1771468)
<ubot5> Launchpad bug 1771468 in cloud-init "Allow a way to explicitly disable sudo for a user" [Undecided,Fix released] https://launchpad.net/bugs/1771468
<blackboxsw> next topic
<blackboxsw> #topic In-progress Development
<blackboxsw> Our ongoing development is always listed publicly at the following trello board
<blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
<blackboxsw> We are going to be focused on SRU validation for Ubuntu this week which should take up the majority of the week.
<blackboxsw> At the end of this SRU process we will also rebuild centos binaries in our copr repo
<blackboxsw> #link https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/
<blackboxsw> so that folks in other envs will have access to latest bits if their distro/cloud doesn't have that update
<blackboxsw> Also, specfic to mgerdts  and danMS_ there is a branch in progress for Azure support to regenerate network-config for all interfaces on each boot.
<blackboxsw> #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348704
<blackboxsw> mgerdts: might like it only as another example of a datasource managing network config across boots
<mgerdts> Thanks.  Will look at that soon.
<blackboxsw> no prob, sorry for all the pings :)
<danMS_> will take a look too and spk to paulmey
<blackboxsw> also smoser is working on implementing an OCIC datasource (Oracle Cloud Infrastructure Classic)
<blackboxsw> think that wraps it up for this week.
<blackboxsw> #topic Office Hours (next ~30 mins)
<blackboxsw> there should be a couple of eyes on this channel for discusssions, questions, bug requests etc that might need a bit more attention.
<blackboxsw> again, thanks for tuning in and helping make cloud-init better!
<blackboxsw> meeting minutes will ultimately show at
<blackboxsw> #link https://cloud-init.github.io/
<blackboxsw> #endmeeting
<meetingology> Meeting ended Mon Jul  2 17:02:56 2018 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-07-02-16.05.moin.txt
#cloud-init 2018-07-03
<danMS> @blackboxsw - did you or the team got a chance to check out https://bugs.launchpad.net/cloud-init/+bug/1779207 ?
<ubot5> Ubuntu bug 1779207 in cloud-init "Failed mount of '/dev/sdb1' with Swap File cloud-init config" [Undecided,New]
<blackboxsw> danMS: didn't quite yet. but it's on my radar for today. (was working on the azure-write-network-each-boot branch yesterday
<danMS> ah great - thanks!
<blackboxsw> thanks for the ping. danMS can you attach full cloud-init logs to the bug (you can grab them running "sudo cloud-init collect-logs" on the commandline if cloud-init is >= 17.2
<danMS> will do
<blackboxsw> thank you
<blackboxsw> +1 on bug response https://bugs.launchpad.net/cloud-init/+bug/1779847 rharper . yeah I had just finished that validation too :/
<ubot5> Ubuntu bug 1779847 in cloud-init "cloud-init 18.2/18.3 centos thinks its ubuntu" [Medium,Incomplete]
<blackboxsw> was going to grab tip to be certain.
<rharper> blackboxsw: well, nightly build failed
<rharper> but what's currently in the repo seems fine
<rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/build/773236/
<rharper> haven't looked at it yet
<blackboxsw> yeah I had run against 18.2.4 in el-testing
<blackboxsw> 18.2.5 rather
<rharper> ould not retrieve mirrorlist http://mirrors.fedoraproject.org/mirrorlist?repo=epel-7&arch=x86_64 error was
<rharper> 14: HTTP Error 503 - Service Unavailable
<rharper> not a cloud-init problem, infra problem
<rharper> blackboxsw: yeah; they mentioned daily
<blackboxsw> yeah just also validated the recent get_linux_distro() logic in cloud-init and added a comment there
<blackboxsw> python -c 'from cloudinit.util import get_linux_distro; print(get_linux_distro())'
<blackboxsw> ('centos', '7', 'x86_64')
<blackboxsw> something smells funky with that bug
<blackboxsw> anyway. on to other things
#cloud-init 2018-07-05
<rharper> blackboxsw: we'll need to see what we might need to do in cloud-init when this hits proposed: https://bugs.launchpad.net/netplan/+bug/1770082
<ubot5> Ubuntu bug 1770082 in systemd (Ubuntu) "systemd-networkd not renaming devices on boot" [Undecided,Confirmed]
<blackboxsw> robjo: is this bug related to the EphemeralDHCP problem you mentioned do you think? https://bugs.launchpad.net/cloud-init/+bug/1779139
<ubot5> Ubuntu bug 1779139 in cloud-init "metadata api detection runs before network-online" [Undecided,New]
<blackboxsw> Given that the bug comes up with DataSourceNone, it makes me think that there was a traceback on missing dhclient (instead of using wicked) so it skips the openstack datasource falls back to datasourceNone
<blackboxsw> I'm asking the filer for more info
<robjo> blackboxsw: Sorry was on the phone.
<robjo> I have not looked at that bug in detail. In any event I think the issue can probably be avoided with modified config file.
<robjo> There are a couple of issues that have cropped up after my update to 18.2, the sethostname problem appears to be rearing it's ugly head again as well
<blackboxsw> ok all done here w/ Azure ds changes https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348704. Moving onto SRU validation
#cloud-init 2018-07-06
<danMS> blackboxsw: i uploaded the collect-logs output for 1779207, lmk if you need anything else?
<blackboxsw> thanks danMS !
<blackboxsw> oops rharper: $ lxc exec test-xenial -- python3 -c 'from platform import dist; from cloudinit.util import get_linux_distro; print(dist()); print(get_linux_distro())'
<blackboxsw> ('Ubuntu', '16.04', 'xenial')
<blackboxsw> ('ubuntu', '16.04', 'x86_64')
<blackboxsw> so cloud-init's new get_linux_distro is actually returning arch instead of series
<rharper> eww
<rharper> how do we not have unittest for that ?
<blackboxsw> I think it's all mocked, but checking now
<rharper> there's no reason for a mock
<rharper> at least not under the util path
<rharper> certainly for distro objects
 * blackboxsw wonders what the impact would have been here. (and why it didn't show up as a problem)
<rharper> but unittesting get_linux_distro shouldn't ; we could mock the read() results from parsing what os-release looks like
<rharper> we only use release in one place
<rharper> under ntp for ubuntu
<rharper> generally, getting 'ubuntu' vs. 'redhat' is the variant that we key on
<rharper> possible the opensusu/sles stuff for ntp could fail as well though I suspect the code works fine with the os-release in opensuse
<blackboxsw> hrm all unit tests were using platform.machine() as the third entry in the tuple
<rharper> which gives me x86_64
<rharper> on my xenial machine
<blackboxsw> which made an incorrect assumption about the orig output of platform.dist()
<blackboxsw> yeah, that's a valid return, but platform.dist() on your system reports series as 3rd element
<rharper> yes
<rharper> platform.dist()
<rharper> ('centos', '7.4.1708', 'Core')
<rharper> that's even stranger
<rharper> ah, that's its code name
 * blackboxsw checks sles
<rharper> hrm, machine just looks wrong; not sure why we didn't catch that
<blackboxsw> hrm ('SuSE', '42.3', 'x86_64')
<blackboxsw> on suse that is what it returns
<rharper> right, that path looks like it's not expected to be taken
<rharper> how do you get that path anyhow ?
<rharper> oh I see, parsing os-release path
<blackboxsw> sorry not following. right, we process /etc/os-release
<rharper> I see it now; it's like we're missing the last tuple being read out of os-release
<rharper> in Xenial, it should be VERSION_CODENAME
<rharper> and there is no such field in redhat/centos
<rharper> yuck, so in centos/redhat PRETTY_NAME includes the codename, but ubuntu's PRETTY_NAME has Ubuntu 16.04 LTS
<rharper> so no single entry works to pick out element 3 of the platform.dist() tuple
<blackboxsw> from sles https://pastebin.ubuntu.com/p/q89fsmwBVD/
<rharper> I wonder if they have a codename
<blackboxsw> yeah I'm filing a bug, SRU-blocker :/
<blackboxsw> rharper: system_info()['dist'] series is used by cloudinit/distros/ubuntu.py for ntp client choices
<blackboxsw> so it'll break on xenial
<blackboxsw> coding up a fix :/
<blackboxsw> weird behavior on sles.
<blackboxsw> platform.machine instead of codename or series
<blackboxsw> it was my original review on that branch. I should've noted it :/
<rharper> blackboxsw: yeah =(
<rharper> I think bringing in the major distro os-release files into the unittest to verify we pull out the bits we want is going to be needed
<blackboxsw> yeah can add that in this pass
<blackboxsw> thank lxc for ease of testing these envs
<rharper> the ci tests with different distros could (should) verify we get what we want out of /etc/os-release ?
<rharper> yeah
<blackboxsw> ok filed https://bugs.launchpad.net/cloud-init/+bug/1780481
<ubot5> Ubuntu bug 1780481 in cloud-init "ubuntu/centos/debian: get_linux_distro has different behavior than platform.dist" [Undecided,New]
<blackboxsw> hrm rharper robjo this also won't work exactly as it currently does on opensuse 42.3,
<blackboxsw> sles42:~ # python3 -c 'from platform import dist; print(dist());'
<blackboxsw> ('SuSE', '42.3', 'x86_64')
<blackboxsw> but per /etc/os/release: ID=opensuse
<rharper> =(
<blackboxsw> so cloudinit.util.get_linux_distro would return ('opensuse',...) instead of SuSE
<rharper> shoudl we back this out?
<rharper> we've not crossed the EOL for platform.dist() yet
<rharper> blackboxsw: we're both out next week, but smoser is back
<blackboxsw> I think it's worth backing it out as it doesn't seem to work on all release of any given distribution
<robjo> in opensuse 42.3 cloud-init runs with python 2 and because .dist works the os-release is not read, or should not be read
<robjo> backing it out will break SLES 15 which will be released on monday and is way more important to us than openSUSE
<robjo> I am pretty certain I tested on openSUSE and things worked as expected
<blackboxsw>  robjo I thought the get_linux_distro code sources /etc/os-release as primary option if file exists
<robjo> let me double check
<rharper> robjo: do you have a sles15 os-release handy while you're looking ?
<rharper> while we're triaging the bug blackboxsw filed, best to collect as much details so we can see how best to sort it out;
<rharper> robjo: we certainly don't want to break any distro
<blackboxsw> robjo: trying to validate now
<blackboxsw> sles42:~ # python -c 'from cloudinit.util import get_linux_distro; from platform import dist; print(dist()); print(get_linux_distro())'
<blackboxsw> ('SuSE', '42.3', 'x86_64')
<blackboxsw> ('opensuse', '42.3', 'x86_64')
<blackboxsw> so here's the diff on opensuse 42.3
<blackboxsw> it's like we need a mapping from ID -> python_dist_value
<robjo> but this is used for variant definition and I handled all cases and added opensuse as needed
<robjo> why is this popping up?
<rharper> processing os-release on xenial results i getting x86_64 and no variant
<rharper> centos is the same
<rharper> platform.dist() tuple returns the 'codename'  of the release
<blackboxsw> yeah, surfacing just platform.machine() in all distros doesn't match platform.dist() output :/
<robjo> so os-release on xenial does not confirm to the freedesktop.org format of os-release?
<robjo> s/confirm/conform/
 * blackboxsw tries to find a spec on that.   I don't think it's /etc/os-release related that's the problem, it's platform.dist() reporting different content on different distros
<rharper> reading os-release means that the third tuple is platform.machine()
<rharper> that doesn't match on centos nor on ubuntu
<rharper>  platform.dist()
<rharper> ('centos', '7.4.1708', 'Core')
<rharper> platform.dist()
<rharper> ('Ubuntu', '16.04', 'xenial')
<blackboxsw> on sles-based it seems platform.machine() as the 3rd element is reasonable. but centos/rhel/ubuntu/debian it breaks conformance as 3rd element is series
<blackboxsw> series/flavor/codename
<rharper> we don't use the variant much, but at least in the ntp path on Xenial, we are using it there
<blackboxsw> yeah that's the only place in cloudinit that it is being used
<rharper> I wonder why python on sles returns the machine ?
<rharper> or why ubuntu and redhat/centos return the codename ?
<blackboxsw> and why on opensuse it return 'SuSE' instead (which also isn't represented in /etc/os-release)
<robjo> touche sample size of one :(, so platform.machine() needs to be replaced by whatever returns the flavor, I think that would be codename in os-release
<rharper> yes
<rharper> but
<rharper> CODENAME is not present in all os-releases =(
<rharper> what a PITA
<rharper> the 'Core' in os-release in centos/redhat is part of the VERSION_ID but the value CODENAME is not set
<blackboxsw> and Core for centos' os-release would work for debian
<blackboxsw> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
<blackboxsw> match the (<codename>) re
<rharper> yeah, but we should try to get as many of these
<blackboxsw> but codename doesn't matter for debian.... root@debStretch:~# python -c 'from platform import dist; print(dist());'
<blackboxsw> ('debian', '9.4', '')
<rharper> rolling our own sorta hurts here
<rharper> lol
<blackboxsw> yeah I think I can draw up a fairly simple fixup if we need to keep this changeset in. At least it should get us through on debian/ubuntu/centos....
<rharper> we should get an os-release of SLES 15 from robjo if we can
<blackboxsw> since robjo doesn't get affected by ('opensuse',...) instead of 'SuSE' we probably don't need a distro-release-lookup map to sort those differences
<rharper> and the python2/python3 platform.dist() output as well
<rharper> just for completeness sake
<blackboxsw> +1 robjo if possible. I know you included snippets in unit tests
<blackboxsw> in cloudinit/tests/test_util.py
<blackboxsw> I can add an opensuse42.3  one too as I have that on hand
<blackboxsw> then at least we document existing behavior and only resolve the mapping opensuse -> SuSE if need be
<robjo> # cat /etc/os-release
<robjo> NAME="SLES"
<robjo> VERSION="15"
<robjo> VERSION_ID="15"
<robjo> PRETTY_NAME="SUSE Linux Enterprise Server 15"
<robjo> ID="sles"
<robjo> ID_LIKE="suse"
<robjo> ANSI_COLOR="0;32"
<robjo> CPE_NAME="cpe:/o:suse:sles:15"
<robjo> SO we could do "if codename in os-release -> use it, else platform.machine()" that is is xenial sets codename ;)
<rharper> robjo: yes, that sounds right
<robjo> blackboxsw: rharper one of you handling this or you want me to?
<blackboxsw> robjo: on it no worries I'll assign you as a reviewer on the brnach
<robjo> I will not get to it until Monday, in the middle of pushing out EC2 images
<blackboxsw> +1 robjo
<robjo> OK, cool thanks
<blackboxsw> no worries
<blackboxsw> robjo: rharper branch pushed a branch for review whenever https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/349081
<blackboxsw> I'll block cloud-init's SRU on this
#cloud-init 2020-06-29
<bilsch> hey looking for some help on cloud-init and growfs / resizefs.
<bilsch> ```  growpart:    ignore_growroot_disabled: false    mode: auto    devices:      - "/"      - "/home"      - "/var"      - "/var/log"      - "/var/log/audit"      - "/var/tmp"    resizefs: true    resize_rootfs: true```
<bilsch> err, no markdown raw or I suck at webchat ;)
<bilsch> so, maybe another way to ask - does resizefs need anything special to get other filesystems than /? I can see growpart has resized the partitions but the fs was not grown. Not sure if this is os / cloud-init version specific but this is on rhel7 and cloud-init version 18.5.6 ( yea, rhel7 :shame: but ... )
<Odd_Bloke> bilsch: I'm not 100% sure I understand the question.  Could you perhaps use https://paste.ubuntu.com/ to paste your configuration, and describe what it is you want/expect it to do?
<blackboxsw> https://github.com/canonical/cloud-init/pull/375 landed. thanks lucasmoura
 * blackboxsw is reviewing the vmware PR now
<blackboxsw> Odd_Bloke: sorry looks like you just rebased https://github.com/canonical/cloud-init/pull/464
<blackboxsw> I think it's stale again because of my merge
<bilsch> Odd_Bloke https://paste.ubuntu.com/p/rhhrBnVKY7/
<blackboxsw> hi smoser/rharper: I added the following response to the vmware review https://github.com/canonical/cloud-init/pull/441/files#r447132910 suggesting maybe a datasource config option to override vmware's default image customization behavior. If either of you disagree with approach, just let me or the PR know.
<blackboxsw> smoser: had reviewed the earlier invocation of that PR, but I think very little has changed from the first attempt
<blackboxsw> at least as far as overrides from cloud-init user-data image customization side
<Odd_Bloke> bilsch: Thanks!  Can you paste the output of `mount`?
<rharper> blackboxsw: ok
<powersj> blackboxsw, eta on the SRU?
<bilsch> Odd_Bloke https://paste.ubuntu.com/p/VJRfjt7sJV/
<bilsch> looking at the properties for cc_resizefs.py I don't think it even takes an array / list or looks up devices / mounts. I also don't see where growpart calls a resizefs etc. I kinda wonder if this works at all or is just cryptic. I'm hoping its as easy as "yea dummy set this config / yaml key" ;)
<Odd_Bloke> bilsch: This line suggest to me that your configuration isn't being consumed by cloud-init: cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  Using default: {'ignore_growroot_disabled': False, 'mode': 'auto', 'devices': ['/']}
<Odd_Bloke> So that would probably be the next thing to debug. :)
<bilsch> its set as user data for the vm in ec2 ...
<blackboxsw> powersj: only waiting on cdoqa. test run. it's queued, but I don't think it's run yet
<blackboxsw> powers, /me needs to attach all our verification logs. cloud-init side of testing is complete
<powersj> blackboxsw, awesome, thanks!
<Odd_Bloke> bilsch: What does `sudo cloud-init query userdata` give you?
<blackboxsw> good one Odd_Bloke. bilsch if the following was your full user-data. it's missing a leading header line containing  "#cloud-config"
<blackboxsw> https://paste.ubuntu.com/p/rhhrBnVKY7/
<blackboxsw> but that query cmd mentioned would tell you for certain
<bilsch> ah, I did not paste the full file. That "#cloud-config" header is there
<bilsch> `sudo cloud-init query userdata  #cloud-config  runcmd:    - yum -y remove ansible  growpart:    ignore_growroot_disabled: false    mode: auto    devices:      - "/"      - "/home"      - "/var"      - "/var/log"      - "/var/log/audit"      - "/var/tmp"    resizefs: true    resize_rootfs: true`
<bilsch> bah newlines and such
<bilsch> https://paste.ubuntu.com/p/SZwVc9mMRj/
<bilsch> would the spacing in there cause issues? Its technically valid yaml but not sure how strict the parser is
<blackboxsw> bilsch: the newlines/whitespace is probably what is breaking cloud-init's interpretation of the growpart key maybe? Try:   grep "Failed at merging" /var/log/cloud-init.log.       I presume if it was invalid cloud-config or yaml you'd get that message.
<bilsch> the grep returned nothing
<bilsch> though, I think I jus t re-created without the leading spaces
<blackboxsw> also something I sometimes do:    sudo cloud-init query userdata > my.yaml; cloud-init devel schema --config-file my.yaml
<bilsch> oh thats handy thanks
<bilsch> yea those leading spaces are a problem
<blackboxsw> yeah we are building that schema validation cmdline utility up, so it's still considered a 'devel' subcommand.  It'll at least validate proper yaml (and all keys and config values for about 10 of the cloud-config modules)
<bilsch> Cloud config schema errors: format-l1.c1: File my.yaml needs to begin with "#cloud-config"
<blackboxsw> ok there it is. silly white space
<blackboxsw> and about 90% of the problems in cloud-init deploys that people have.... darn you YAML
<bilsch> yea we need another file markup language. someone should fix that!
<blackboxsw> and strict yaml cloud-init processing :)
<bilsch> yea assume you guys know of yamllint? saves so much time ( and yea I know... I should have done that )
<blackboxsw> bilsch: I am curious about your deploy still (while we have something 'broken') I'm wondering why cloud-init didn't match the failure log
<blackboxsw> do you have a match from grep Trace /var/log/cloud-init.log ?
<bilsch> yea sure whats up
<bilsch> yea 2 tracebacks
<blackboxsw> ok those should point to the specific type of trace in trying to process invalid user-data
<blackboxsw> unfortunately, cloud-init tries hard to succeed, even if vendor data or user-data is "broken" so the VMs still come up. We are generally trying to move it from "bring the system up as best you can" approach to "complain loudly because nobody looks in logs for warnings :)"
<bilsch> so, both look like permission denied. These boxes have selinux on them
<blackboxsw> ok. I'll get a test system with leading whitespace and reproduce locally then. Thanks for peeking
<bilsch> yea I second that motion make it fail so I learn and fix my broken crap
<bilsch> yea for sure thanks for the help!
<blackboxsw> yeah same for me too. I don't want to dig into a log to find out why I'm not 100% in line with my config
<blackboxsw> surely thx Odd_Bloke
<bilsch> yea I prefer determinism - if something is not configured right say so, break, seg fault the kernel whatever
<blackboxsw> agreed
<bilsch> oh ha terraform was happily waitng for me to say yes to test the fixed yaml ( heredoc with spacing proper to the tf file )
<bilsch> are the resizefs and resize_rootfs top-level or nested within growpart?
<bilsch> also rathher than constantly re-creating a vm is there a way to just apply the modified yaml locally?
<bilsch> eg, save the yaml like before, tweak / whatever and use cloud-init to do all the things?
<blackboxsw> bilsch: can you run cloud-id ( I think terraform == NoCloud datasource type right?)
<blackboxsw> or "cloud-init status --long"
<bilsch>  cloud-init status --longstatus: donetime: Mon, 29 Jun 2020 20:03:25 +0000detail:DataSourceEc2
<bilsch> bunch of new lines in there, want it in pastebin?
<blackboxsw> that 2nd command will tell you (if on NoCloud, where your seed directory is coming from)
<blackboxsw> nah it's good
<bilsch> so is growpart intended to also automagically expand the filesystems?
<bilsch> I see the devices expanded but not the filesystems
<bilsch> post init of a fresh vm
<bilsch> data blocks changed from 523776 to 5242619
<bilsch> that is only after I ran xfs_growfs.  cloud-init had expanded the partition just fine
<blackboxsw> bilsch: the hammer that let's you re-run everything in cloud-init is `cloud-init clean --logs --reboot` that'll wipe the system and re-run. The problem with ec2 datasource is that you have already set the user-data on the metadata service in ec2 I think. So, even though you cleaned cloud-init, it'll still grab the original user-data.
<bilsch> ahh
<bilsch> ok
<blackboxsw> nocloud datasource is different in that it has a seed directory that you can re-write after the fact and re-run with new user-data content
<bilsch> no biggie just looking to debug in place / reduce cycle time to get it right is all
<bilsch> almost as much time to go mess with ec2 console and muck with it vs just letting tf rebuild it so
<blackboxsw> yeah we reduce cycles by using 'lxc launch ubuntu-daily:focal mylocalvm'    which also has images:centos/7 sles/* etc
<bilsch> ah ok that makes sense
<bilsch> https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_resizefs.py#L242-L247 so I'm back to questioning if resizefs works for anything other than the root filesystem....
<blackboxsw> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart so what you want is  https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_growpart.py#L276 I think?
<bilsch> well, growpart and resizefs appear to be separate modules / tools
<bilsch> growpart is just the partition table change
<bilsch> resizefs looks for / runs the proper command to grow the filesystem for an already-expanded partition / volume etc
<Odd_Bloke> blackboxsw: bilsch: I'm catching up, but the complication with completely aborting a boot is that makes it harder for people to get log files off of it to diagnose the issue; obviously kernel panics have a similar effect, but you generally can't cause a kernel panic by passing misformatted YAML to your cloud provider. ;)
<bilsch> heh - yea even kill -9 1 does not work anymore ;(
<bilsch> and yea it does make sense that you won't want to make the pain too bad, gotta give people a chance to find the information
<bilsch> I've tried a few incantations on the growpart devices - I get the partition expanded via growpart but only / via resizefs
<AnhVoMSFT> @blackboxsw @rharper at which point during cloud-init-local.service that systemd will trigger other units that are marked "after" cloud-init-local.service
<rharper> AnhVoMSFT: since it's in oneshot more, after the first Exec= line is complete,
<rharper> AnhVoMSFT: so cloud-init init --mode=local must exit before units depending on it can start
<AnhVoMSFT> I see - thanks @rharper. We're seeing this strange issue in RHEL with cloud-init (18.5) where if an NFS mount exists in /etc/fstab, cloud-init will hang in "mount -a" during deallocate/restart of a VM
<rharper> https://www.freedesktop.org/software/systemd/man/systemd.service.html  ; "Behavior of oneshot is similar to simple; however, the service manager will consider the unit up after the main process exits. It will then start follow-up units. RemainAfterExit= is particularly useful for this type of service. Type=oneshot is the implied default if neither Type= nor ExecStart= are specified. Note that if this option is used without
<rharper> RemainAfterExit= the service will never enter "active" unit state, but directly transition from "activating" to "deactivating" or "dead" since no process is configured that shall run continously. In particular this means that after a service of this type ran (and which has RemainAfterExit= not set) it will not show up as started afterwards, but as dead.
<rharper> AnhVoMSFT: is the mount entry marked with _net ... what's the bit
<rharper> _netdev
<AnhVoMSFT> the mount is added manually by the customer to /etc/fstab , not through cloud-init mounts config
<rharper> cloud-init local does not call  mount -a, that happens in cloud-init init (network mode);
<rharper> ok, it must have _netdev in the options field if it depends on networking
<rharper> this informs systemd-fstab-generator which creates .mount files to set them to run After=network-online.target
<AnhVoMSFT> it does not have _netdev in the options field
<rharper> that said, mount -a only runs in cloud-init init (stage 2) and networking should be up
<rharper> so I'm not sure why it would hang; so I suspect that maybe networking isn't coming all the way up (or no route to the mount)
<AnhVoMSFT> the mount unit indicates type=nfs, which will have after=network-online.target added automatically by systemd I believe
<rharper> yep
<AnhVoMSFT> yeah, but you're right it's in cloud-init's init phase, not init-local
<rharper> but a mount -a will force mounting of all entries when it's run; meant to bring up any new entries added since fstab-generator ran
<rharper> the fstab generator runs before cloud-init local does;  so if we add a new mount, then we trigger a mount -a ;  the ephemeral disk in azure's case
<rharper> but ... it should come up; so that means networking issues (or possibly missing nfs client)
<AnhVoMSFT> if I move "mounts" to the config phase it works fine
<rharper> the ubuntu image, I don't think has nfs-common package included by default
<rharper> sounds like networking isn't fully yp
<rharper> up
<AnhVoMSFT> this issue does not happen in Ubuntu, but in RHEL only, which is strange
<rharper> I suspect it's network-manager related
<AnhVoMSFT> it does look like some sort of issue with networking
<rharper> I know otubo was chasing NM "being all the way up" issues
<rharper> this was maybe 6 months ago, but I thought the workaround there was to ensure the Network-Manager-wait-online.service was also waited upon by cloud-init.service
<AnhVoMSFT> the init's phase also runs before network-online ?
<AnhVoMSFT> https://paste.ubuntu.com/p/h4yftHdYbC/
<AnhVoMSFT> that's what the cloud-init.service looks like in RHEL
<rharper> that doesn't look right to me
<rharper> upstream we run After=networking.serivce NetworkManager.service;  and I thought otubo added a drop-in to include NetworkManager-wait-online.service;
<rharper> basically cloud-init.service runs after OS networking is up; but before network-online.target;  which means that cloud-init knows that networking is up; and can fetch networking based #include cloud-configs, which need to be present before we run cloud-config.service
<AnhVoMSFT> let us try that quickly, then we can open a support ticket on Redhat and get that fixed
<rharper> https://bugs.launchpad.net/cloud-init/+bug/1869181/comments/12  ;  I poked around with getting NM to fully come up in Ubuntu and it needed more work;   especially tricky  w.r.t the ordering NM needs dbus and strange things happen (boot dep cycle)
<ubot5> Ubuntu bug 1869181 in cloud-init "[Focal] cloud-init service never get nework actived during MaaS deploy." [Undecided,Incomplete]
<rharper> AnhVoMSFT: the DefaultDependencies=no to both NM and NM-wait-online.service I think  and then adding the After=NetworkManager-wait-online.service helped ;  that may be enough on Centos/RHEL; Ubuntu the netplan bits convering to NM config weren't quite there;  on Cent/RH they use the sysconfig rh plugin, so I don't think you'll see the rest of the issues I saw in that bug
<AnhVoMSFT> we tried adding the After=NetworkManager-wait-online.service to cloud-init.service but that did not help
<AnhVoMSFT> i did not add DefaultDependencies=no
<rharper> AnhVoMSFT: journalctl -b -o short-monotonic -u NetworkManager.service -u NetworkManager-wait-online.service -u cloud-init.service -u network-online.target ;
<rharper> that should print in timestamp order ... if you see cloud-init.service dumping the netinfo table and not everything is then, something isn't ordered correctly (or NM is failng to bring everything online)
<rharper> s/then/there
<AnhVoMSFT> adding the DefaultDependencies=no also did not help
<AnhVoMSFT> let me check the journalctl output to see what is missing
#cloud-init 2020-06-30
<crandon> Hi, I'm trying to boot up a centos 7.8 clou image on a libvirt host passing a cloud-init image. Network config and user config works fine, however ntp config doesn't seem to be set for chrony. I simply added an ntp fragment to the meta-data file with enabled: true, ntp_client: chrony and a servers list.
<crandon> Here's the resulting instance-data.json: https://pastebin.com/10C2rJDf
<Odd_Bloke> crandon: Can you expand a little on "added an ntp fragment to the meta-data file"?  Which file, specifically#?
<crandon> To the /meta-data file
<crandon> I wonder if the ntp module needs to be explicitly enabled...
<Odd_Bloke> Aha, right, in the image/ISO you're creating: meta-data is information from "the cloud" about its view of the instance (e.g. hostname, cloud region), where as user-data is information about what the user wants the instance to do; NTP configuration belongs in user-data.
<Odd_Bloke> If that's a problem, you could also consider using vendor data.
<crandon> Ah sh... I thought all network related info should go there (like network-interfaces).
<Odd_Bloke> Right, "the cloud" (i.e. you, in this case ;) defines network interfaces, so they are meta-data.
<crandon> Yes, but the same way the cloud defines/provides the ntp service as well (ideally). Anyway, I moved it to user-data and it's still not working.
<crandon> Odd_Bloke: Here's the user-data as it is seen now from the guest: https://pastebin.com/bRPmyRM5
<crandon> I tried to follow the ntp module docs from: https://cloudinit.readthedocs.io/en/latest/topics/modules.html
<Odd_Bloke> crandon: You need the first line of user-data to be "#cloud-config" for cloud-init to process it.
<Odd_Bloke> Clouds define and provide all sorts of services, NTP doesn't need special treatment.  (If a cloud did want to pass in default NTP configuration, then it could use vendor-data for that; that's cloud-provided default user-data, precisely for this sort of usecase.)
<crandon> Makes sense.
<crandon> With regard to the #cloud-init. That's my bad I only copied the relevant parts and below. It's actually there.
<Odd_Bloke> smoser: rharper: Can either of you give me some background on the specific-to-RHEL hostname setting behaviour?  (The context being https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1883649; feel free to comment there! :)
<ubot5> Ubuntu bug 1883649 in cloud-init (Ubuntu) "cloud-init on Ubuntu 18.04 does not set FQDN" [Undecided,New]
<Odd_Bloke> crandon: Just to double-check: it's "#cloud-config" there, right?
<crandon> I just checkd (on the VM itself) and the first line is: #cloud-config
<Odd_Bloke> OK, cool.
<Odd_Bloke> (You wouldn't believe how many times that's the issue, I always like to be absolutely sure. ;)
<crandon> I don't see any ntp related log entries in /vat/log/cloud-init, but the user data gets copied into /var/lib/cloud/instances/<host>/user-data.txt
<Odd_Bloke> crandon: Are there any WARN or "Traceback" lines in your log?
<crandon> Odd_Bloke: Honestly I got the template from some ansible playbook, so I woudn't have notice it for sure...
<crandon> Nope all DEBUG except for 3 lines of INFO
<Odd_Bloke> OK, in that case I think you'll need to pastebin the whole thing for me to take a more detailed look at. :)
<rharper> Odd_Bloke: lemme refresh;
<Odd_Bloke> Thanks!
<rharper> Odd_Bloke: I think your suggestion in the bug is the right answer; as to the history of this; it's related to OS documentation;  RHEL has insisted on using FQDN, where has Debian has it separate;  many software stacks query their hostname (and fqdn) differently;  smoser usually reminds me of some strangeness in java's hostname lookup  vs other stacks;
<crandon> Odd_Bloke: This is the complete stuff with sensitive info masked: https://pastebin.com/3iHadMse
<crandon> Would it help if I'd move it to vendor data?
<Odd_Bloke> crandon: Apologies, I meant the full cloud-init.log.
<crandon> Uh, that's going to be tricky as the customer classifies hostnames and even private IPs as confidential...
<crandon> And I can copy out anything only via clipboard...
<crandon> Let me see, what I can do and come back to you (I can't promise it's gona happen today).
<Odd_Bloke> crandon: Fair enough, that's understandable. :)  (You could try reproducing this elsewhere; not necessarily an easy task, but would free you from that restriction.)
<smoser> Odd_Bloke: java stacks (what is that java web framework?) often do stupid things
<smoser> but other things do the same.
<smoser> they think for some reason that they can reverse lookup their hostname
<smoser> to an IP address (a single IP address)
<smoser> and then tell other things "Hey! you can talk to me at x.y.a.b"
<smoser> well, that is flawed for so many reasons.
<smoser> and often ends in the hilarity of "you can talk to me at 127.0.0.1"
<AnhVoMSFT> @rharper continuing from the mounting issue yesterday, it seems like the nfs mount is declared implicitly (because type is nfs) to be After network-online.target, it means that whatever cloud-init.service does, it won't be able to successfully call mount -a if there is an nfs mount in /etc/fstab, is that correct?
<AnhVoMSFT> because cloud-init.service is Before network-online.target, this means network-online.target won't be reached until we finish with cloud-init.service, and as such the nfs mount cannot be successfully brought up, or does mount -a not rely on the nfsvolume.mount unit and actually try to mount it individually?
<blackboxsw> #startmeeting cloud-init status meeting
<meetingology> Meeting started Tue Jun 30 16:22:42 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> community notice: time for another bi-weekly (or semi-monthly if you prefer) cloud-init community status meeting
<blackboxsw> #chair smoser rharper Odd_Bloke
<meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
<blackboxsw> welcome to another round of cloud-init upstream updates and discussion. We use this meeting as a time to gather to discuss current development of cloud-init, ask and answer questions, and generally expedite development be unblocking devs.  All questions. side-conversations and interruptions are welcome
<blackboxsw> last meeting minutes are at the link below
<blackboxsw> #link https://cloud-init.github.io/status-2020-06-16.html#status-2020-06-16
<blackboxsw> turns out I didn't update the topic for the next meeting time last session. Let's do that now
<blackboxsw> +2 weeks from now, same time
* blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting July 14 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug
<blackboxsw> July 14th, same UTC time
<blackboxsw> now that that's out of the way, we typically cover the following topics.
<blackboxsw> Previous Actions, Recent Changes, In-progress Development, Community Charter, Office Hours (~30 mins).
<blackboxsw> additionally today, I'll discuss the current cloud-init SRU
<blackboxsw> #topic Previous Actions
<blackboxsw> topic #1. our previous meeting minutes logged two actions:
<blackboxsw> ACTION: file feature bug about refactoring startup services
<blackboxsw> I think in further discussion during last meeting, we talked with Odd_Bloke and meena and determined that we can't actually refactor startup services to live in the distro specifically, because these startup service templates actually get determined at cloud-init generator time (before distribution is determined in cloud-init's python code) so trying to specialize startup script content generation in the distro
<blackboxsw> python classes in cloud-init is too late
<blackboxsw> so this action is tabled as /wont-fix
<blackboxsw> that follows as well with the other ACTION: mailing list email requesting comment/concerns about a refactor of startup services
 * blackboxsw isn't sure how to close out actions in meetingology syntax/cmds
<blackboxsw> #topic In-progress Development
<blackboxsw> The following is the set of  commits landed in 'master' of cloud-init upstream repo: found with git log --since 06-20-2020
<blackboxsw> #link ACTION: mailing list email requesting comment/concerns about a refactor of startup services
<blackboxsw> #link https://paste.ubuntu.com/p/fSvwRks86z/
<blackboxsw> heh paste error
<blackboxsw> #topic Recent Changes
 * blackboxsw sets appropriate topic for this section
<blackboxsw> so recently Odd_Bloke and a number of BSD folks (meena igalic etc) have gone through a number of discussions and design regarding a refactor of cloudinit.net functions to a cloudinit.distro.networking module as most network-related functionality is highly distro-dependent
<blackboxsw> Odd_Bloke: created an overview of this current refactor work and published it to readthedocs
<blackboxsw> #link https://cloudinit.readthedocs.io/en/latest/topics/hacking.html#ongoing-refactors
<blackboxsw> This has been a big effort to get organized and started so many thanks for all those paricipating in this discussion, development and reviews.
<blackboxsw> there are many, functions that need to be refactored  from cloudinit.net into the distribution-specialized cloudinit.distro.networking classes.
<blackboxsw> It is work that can be easily done in parallel and there is a tag used to classify each refactor as a "net-refactor" bug in launchpad
<blackboxsw> #link https://bugs.launchpad.net/cloud-init/+bugs?field.tag=net-refactor
<blackboxsw> community notice: we encourage anyone interested in refactoring cloud-init networking functionality to grab and work any of those net-refactor bugs
<blackboxsw> there are a couple of example PRs up that give a good idea of how to get started
<blackboxsw> #link https://github.com/canonical/cloud-init/pull/457
<blackboxsw> and I can't seem to find the other at the moment.
<blackboxsw> besides net-refactor content landing, there have been fixes to Hetzner and RbxCloud datasources,  redhat's systemd generator templates, Centos copr build fixes to help RPM build runs and Azure datasource logging. Thanks smoser, paride Moustafa and otubo Adam Dobrawy for contributions this round
<blackboxsw> #topic In-progress Development
<blackboxsw> Generally the last two weeks have been sunk into upstream testing and validation of cloud-init for SRU (Stable release Update) into Ubuntu Xenial Bionic, Eoan and Focal.
<blackboxsw> 3 to 5 of us have been on verification tasks on various clouds for all Ubuntu releases targeted and all features which affect ubuntu.
<blackboxsw> A thousand thanks rharper Odd_Bloke factor lucasmoura and xiaofeng for working through and validating some of these SRU tasks.
<blackboxsw> Our job is done, and we are awaiting feedback from an automation CI from Canonical solutions QA at the moment which runs through a ton of Openstack networking customer-configurations.  It has been in the test queue for a week, and I just saw a successful run from that test harness this morning. That team has told us it looks for 3 successful runs to "pass" so I expect that pass to come shortly as the test runs
<blackboxsw> are currently inprogress.
<blackboxsw> as soon as this test passes we will mark the SRU bug verified and the SRU team will publish bits of cloud-init.
<blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,In progress]
<blackboxsw> This SRU has taken about 1+ week longer than normal verification because we hadn't SRU'd cloud-init in around 6 months, so there was a lot more content to verify.
<blackboxsw> Hopefully additional SRUs will be more frequent and less heavy-weight. We are looking into reducing the overhead on this process and will pitch ideas to the cloud-init mailinglist for input
<blackboxsw> Beyond SRU work, the following other work is in progress:
<blackboxsw> * net-refactor formerly mentioned
<blackboxsw> * falcojr into Oracle integration test harness
<blackboxsw> * extending  json schema validation for remaining cloud-config modules for better error reporting around invalid user-data
<blackboxsw> Long term work: cloud-init standalone daemon to improve startup time by avoiding reloading python across each cloud-int boot  stage, initial networking hot-plug support to which datasources could "opt-in"
<rharper> blackboxsw: =)
<blackboxsw> I think that about wraps this topic.
<blackboxsw> yeah rharper, we've got it on our roadmap. We'd love to see that get in this round.
<blackboxsw> #topic community charter
<blackboxsw> We have a couple of general themes of features we are working toward as a community this year:
<blackboxsw> * json schema additions for cloudinit.config.cc_* modules to improve user-facing errors on invalid user-data
<blackboxsw> * datasource documentation improvements, updates and corrections
<blackboxsw> * cloudinit.net-refactor work
<blackboxsw> We encourage any interested developers to grab any of these work items related to these features.
<blackboxsw> We have two bug tags which enumerate each component of these work streams:
<blackboxsw> #link https://bugs.launchpad.net/cloud-init/?field.tag=bitesize
<blackboxsw> #link https://bugs.launchpad.net/cloud-init/+bugs?field.tag=net-refactor
<blackboxsw> #topic Office Hours (~20 mins)
<blackboxsw> This 'section' of the meeting is a time where a couple of upstream devs will be available in channel for any discussions, questions, bug work or PR reviews.
<blackboxsw> I think I spent most of the time typing, but will hit the review queue in the absence of any other discussion
<blackboxsw> merged https://github.com/canonical/cloud-init/pull/461
<blackboxsw> lucasmoura: one minor change request and description update on the PR requested https://github.com/canonical/cloud-init/pull/390#pullrequestreview-440241947
<blackboxsw> then we can land this one
<blackboxsw> ok folks, thanks for checking into the cloud-init status meeting. See you in 2 weeks.
<blackboxsw> #endmeeting
<meetingology> Meeting ended Tue Jun 30 17:51:54 2020 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-30-16.22.moin.txt
<lucasmoura> blackboxsw, ack
<Odd_Bloke> blackboxsw: I've added the tests I think your comment called for, please re-review and LMK: https://github.com/canonical/cloud-init/pull/457#discussion_r447879423
<blackboxsw> Odd_Bloke: approved , will let you land when CI passes
<blackboxsw> Odd_Bloke: merged xenial https://github.com/canonical/cloud-init/pull/462
<blackboxsw> keeping that daily build building
<Odd_Bloke> Thanks!
<AnhVoMSFT> @rharper, in RHEL 7.8 rpc-statd and rpc-statd-notify.service which are required for nfs mounting are marked "After" network-online. mount -a with nfs mount presence can't proceed with it. In Ubuntu those services are marked After network.target, and not network-online. I changed rpc-statd and rpc-statd-notify to be After network.target and that seemed to work. I think we'll advise the
<AnhVoMSFT> customer to work with Redhat support on this. I think rpc-statd and rpc-statd-notify can be safely started after networkmanager-wait-online and don't have to wait till network-online.target?
<rharper> AnhVoMSFT: nice;  yes; I suspect they could use the same After= network.target that ubuntu does;   but your suggestion will also work as well, just slightly later than network.target;
<Odd_Bloke> Trivial oneline review needed: https://github.com/canonical/cloud-init/pull/465
<blackboxsw> done
<Odd_Bloke> Thanks!
<smoser> AnhVoMSFT: fwiw, the issue with 'network-online.target' is network-online.target itself.
<smoser> "network-online.target is a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. Usually it indicates a configured, routable IP address of some kind"
<smoser> cloud-init (and probably rpc-statd-notify and loads of other services) do not require any network services.
<smoser> its perfectly fine to have no networking and do work
<smoser> if you said 'after' of network-online.target, and had no network configured, would you expect 'after' to have been accomplished?
<smoser> and as the doc says "for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up), its primary purpose is network client software that cannot operate without network."
<AnhVoMSFT> @smoser Agreed. I don't think it's a problem with cloud-init, but rather with the nfs-utils package in Redhat and how they declare dependencies. The ones in Fedora and Ubuntu don't have this issue
#cloud-init 2020-07-01
<crandon> Odd_Bloke: Hi Again! So I rather recreated the issue locally. Here's the cloud-init.log: https://pastebin.com/33iVf0pb As a reminder: the ntp config from user-data not getting populated to chrony.conf
<blackboxsw> crandon Odd_Bloke is off today. I see you are on cloud-init 18.5 I'm wondering two things, would you be able to run and paste `sudo cloud-init query userdata` be wary if you have secrets/passwords defined in your user data
<blackboxsw> also, it may make a difference as a lot has changes since 18.5, we have a copr repo up with some rpms built from tip of upstream cloud-init master here that may assist in confirming if this a bug that has already been resolved https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
<blackboxsw> crandon: ^
<blackboxsw> as well
<AnhVoMSFT> @rharper what are the potential ramifications of moving mounts to config stage?
<AnhVoMSFT> One thing that comes to mind would be modules such as write_files won't be able to use mounts indicated in mounts unless write_files is moved to config stage as well
<rharper> AnhVoMSFT: yeah, also, folks can mount up things like /home or whereever write_files might want to send things;
<crandon> blackboxsw: Hi! Thanks for taking this over. I checked and the command you've sent prints out the user-data file content.
<crandon> blackboxsw: I'm updating now cloud-init to see if the newer version behaves differently.
<rharper> crandon: can you confirm if you have /etc/cloud/templates/chrony.conf.*.tmpl ?
<AnhVoMSFT> actually in Ubuntu cloud images today (at least the azure ones) mounts module comes after write_files, so that point is moot anyway
<rharper> ah, in this centos7 cloud image, I don't see 'ntp' in /etc/cloud/cloud.cfg
<crandon> rharper: I do, but: there's no chrony.conf.centos.tmpl (only fedora and rhel, plus some other non relevant ones)
<rharper> ah, centos should use the rhel tmpl
<rharper> in your paste earlier I don't see cc_ntp   ...   and your user-data has ntp: {}  at min in there?
<crandon> Nope, there's no ntp in /etc/cloud/cloud.cfg
<crandon> So you're saying the ntp module is not enabled, hence the problem?
<rharper> crandon: right, so they've left the ntp config module off by default
<rharper> crandon: yes
<rharper> you can manually force to run it like:  cloud-init single --name cc_ntp
<rharper> assuming you've already supplied ntp:  {} config in your user-data;  if not, you can do it in a separate file,  cloud-init --file my_conf.cfg single --name cc_ntp;  that should run it
<crandon> Grrr... why would one do that I wonder... I'm using a cloud image not to have to maintain an image myself. Configuring NTP is something very basic, unless of course the reason is, that they assume, that the VM will sync it's clock with the host, which then can be synced via NTP
<crandon> This didn't alter the chrony.conf either: cloud-init single --name cc_ntp
<rharper> AnhVoMSFT: right; wont help write files, but it does help with user homedir
<rharper> crandon: I think I need to get you more config;  each distro may have a default policy; I though centos preferred chrony; lemme dig up the config
<crandon> Ah wait, I updated cloud-init, but didn't reboot yet.
<crandon> Hmm "cloud-init single --name cc_ntp" failed.
<rharper> looks like there's a bug, chronyd.service not chrony.service
<crandon> Yep, that seems to be the issue
<rharper> and, if you run in a container, it may not allow you to run;
<crandon> But now at least I can see the entries from user-data being populated to the config
<rharper> crandon: can you file a bug on the chrony/chronyd  ?
<crandon> Sure, but the version is still cloud-init single --name cc_ntp
<crandon> Is it still relevant?
<rharper> lemme check upstream; one sec
<rharper> crandon: yeah, it's still listed as chrony for the service name
<rharper> so, bug is relevant;
<crandon> Ok, I'll submit a bug. I guess NTP being off by default is something I should check with the RH/CentOS guys, right?
<rharper> well, I suspect you're getting systemd-timesyncd by default ; it's a "good enough" one-shot ntp service;
<rharper> in this centos7 cloud image, it has systemd-timedatad.service ...   not sure if that's the same;
<crandon> Chrony is there by default, I haven't installed it myself also it is enabled by default, while systemd-timedated is not. Regardless, either will require modifying the cloud.cfg to include ntp... Is it possible to modify cloud.cfg via cloud-init :) ?
<crandon> The filed bugreport: https://bugs.launchpad.net/cloud-init/+bug/1885952
<ubot5> Ubuntu bug 1885952 in cloud-init "Wrong service name used for chrony when restarting service" [Undecided,New]
<rharper> crandon: thanks!
<crandon> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/chap-kvm_guest_timing_management: "To avoid the problems described above, the Network Time Protocol (NTP) should be configured on the host and the guest virtual machines. "
<crandon> So it seems RedHat suggests using NTP in guest eventhough: "KVM avoids these issues by providing guest virtual machines with a paravirtualized clock (kvm-clock)"
<crandon> rharper: Well, I guess there isn't much we can do for now. I'll try to submit a bug/feature request to RH to include the NTP module by default. I wonder if they left it out because of this bug...(which would not be nice without raising the bug themselves...)
<rharper> right, typically modern hosts and guests use kvmclock and a paravirtual interface to keep the guest clock up-to-date;  however;  ntp in the guest can help with higher resolution data and drift, https://opensource.com/article/17/6/timekeeping-linux-vms
<rharper> crandon: I played around with getting ptp bits enabled, but never finished up that work;
<crandon> Well, I guess for new, I'll either create a custom image with ntp enabled in cloud.cfg and the service name fixed (or systemd-timesyncd being used), or just configure chrony via ansible after deployment. I guess I'll do the later, otherwise I'll have to maintain the image for the customer, which I'd like to avoid....
<crandon> rharper: Thanks for your and also blackboxsw' and Odd_Bloke's help!
<rharper> crandon: yw
<crandon> A small compliment if you allow, is that there aren't that many IRC communities around, with this level of activeness/support. Thx again.
<rharper> crandon: =) Thank you
<rharper> paride: cloud_tests lxd bits don't seem to work with lxd 4.0 ... I'm fighting the image export;  is this known ?
#cloud-init 2020-07-02
<MICROburst> I created a user X with homedir but 'lock_passwd: true' during install I get annoyed with "ci-info no authorized ssh keys fingerprints found for user X" - how do I get rid of this message?
<Odd_Bloke> MICROburst: I'm not sure I follow, why do you want to get rid of that message?
<MICROburst> Looks like a config problem. I want to be able to sudo to this user. As opposed to a system account it should have a homedir
<MICROburst> is someone here using mounts: to add entries to /etc/fstab?
<Odd_Bloke> MICROburst: The only way someone can know if they can answer your question is if you ask it. :)
<Odd_Bloke> (Given that cloud-init devs including myself are active in here, someone should be able to!)
<MICROburst> Odd_Bloke: Entries added via cloud-init simply do not work. For some reason cloud-init uses TABs in /etc/fstab *facepalm*
<blackboxsw> hrm. man page for fstab "Fields on  each  line are separated by tabs or spaces."
<blackboxsw> and true cloud-init does separate by tabs it seems https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_mounts.py#L498
<blackboxsw> MICROburst: I'd be curious about what distro you are running on
<blackboxsw> if some distros don't support tabs in /etc/fstab we probably should adjust cloud-init to make the right white-space choice for those elements
<MICROburst> It's ubuntu 18.04 Line added was "10.0.10.10:/volume1/backup    /net/backup nfs x-systemd.automount,noauto,comment=cloudconfig  0   0"
<MICROburst> ubuntu cloud image.
<Odd_Bloke> Yeah, tabs are supported in /etc/fstab AFAIK, so I don't know that that's the issue.
<Odd_Bloke> MICROburst: So what does `mount /net/backup` in a shell do?
<blackboxsw> uuuuum, so your user-data was this?    https://paste.ubuntu.com/p/YcbRJQzs34/
<blackboxsw> MICROburst: I'm curious what the pasted mounts: specific output is when you run 'sudo cloud-init query user-data'
<MICROburst> looks like, but I'm not Chad smith
<blackboxsw> hehe :) that's me
<MICROburst> :)
<blackboxsw> soo stock cloud-image and nfs rings a bell. MICROburst is this the symptom you are seeing https://bugs.launchpad.net/cloud-init/+bug/1870370
<ubot5> Ubuntu bug 1870370 in cloud-init "cloud-init doesn't support NFS in mounts" [Undecided,Fix released]
<blackboxsw> and Odd_Bloke's question about what does `mount /net/backup` in your shell do
<MICROburst> works.
<MICROburst> the odd thing is the other VMs with that config are working too. Very odd...
<Odd_Bloke> https://github.com/canonical/cloud-init/pull/473 is the test refactoring PR I mentioned in stand-up this morning.
<MICROburst> regarding the pointer to the launchpad: I don't use AWS yet.
<blackboxsw> :/,   I think probably need to see a paste of your /var/log/cloud-init.log if possible . I'd expect we'd see a "mount -a" which should have mounted that nfs entry. I'm wondering if we hit something with nfs not responding during initial system boot?
<blackboxsw> grabbing the PR Odd_Bloke
<rharper> paride: my irc proxy got reset, not sure if you responded and I wasn't here on cloud_tests and lxd 4.0  ...
<Odd_Bloke> rharper: I didn't see a response, but paride mentioned in stand-up that he was looking into issues we were seeing in Jenkins that he was anticipating might be the same as yours.
<rharper> Odd_Bloke: ok, yeah, it seems to me that lxd image export seems to have changed ... it now expects a filename (not a dir) and it writes a tar.xz file and I think the metadata tarball .. so all of the image import/export bits need updating for 4.0
<Odd_Bloke> Fun!
<rharper> Odd_Bloke: what a PITA, I was writing a cloud_test for the chrony bug we worked through yesterday;  hoping to contribute an integration test while fixing the bug.    I might see if nocloud kvm is easier ... but need to figure out how to update releases.yaml to point to Centos images
<Odd_Bloke> rharper: So I think a short-term resolution would be switching to the 3.x lxd channel while we work on updating the integration?
<rharper> Odd_Bloke: ok;  I suspect I'll need to do that in a VM or something; I really loath messing with my existing install (it's a PITA already to get things "happy" )
<Odd_Bloke> Or, actually, I'm on 4.2 so maybe even just going back to 4.1 would work?
<Odd_Bloke> Or maybe we're on edge on Jenkins ATM, so even with 4.2 we might not be broken?
<rharper> Odd_Bloke: well, let me just file a bug with details;
<rharper> I'm on latest/stable ; 4.2
<blackboxsw> Odd_Bloke: minor Change requested and we can land https://docs.pytest.org/en/2.9.2/example/markers.html#custom-marker-and-command-line-option-to-control-test-runs
<blackboxsw> oops paste fail
<blackboxsw> https://github.com/canonical/cloud-init/pull/473#pullrequestreview-441880118
<rharper> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1886080
<ubot5> Ubuntu bug 1886080 in cloud-init (Ubuntu) "lxd cloud_tests fail to export images on latest/stable " [Undecided,New]
<Odd_Bloke> blackboxsw: Good catch on that nit, thanks!  Fix pushed up.
<blackboxsw> Odd_Bloke: rharper lucasmoura and falcojr I'm off tomorrow and CDOqa just came in with cloud-init test results as success for SRU into ubuntu X, B , E, F. Upstream doesn't release on Fridays, but I'd like to ping the SRU vanguards in #ubuntu-release  as soon as CDO logs are attached to see if we can't get this approved for today. I'd need folks to be aware of the update/publish in case of bug reports tomorrow.
<blackboxsw> does that sound good/
<blackboxsw> or shall we wait for Monday
<blackboxsw> I'm imagining a lot of US-based folks aren't going to be around tomorrow
<Odd_Bloke> blackboxsw: We have and will only have CDO QA results for bionic, right?  Do we need to resolve that inconsistency with our SRU exception before asking for release?
<Odd_Bloke> Yeah, I'd hold off regardless, given that tomorrow's a US holiday.
<Odd_Bloke> (Speaking as someone who lives in Canada. ;)
<blackboxsw> heh. ok will hold. and yes, I'll ping about xenial results, typically CDO qa doesn't do non-LTS (and I'm not certain where they are as far as focal)
<blackboxsw> merged https://github.com/canonical/cloud-init/pull/473
<rharper> blackboxsw: good luck with the release today;  Monday isn't terrible either
#cloud-init 2020-07-03
<paride> Odd_Bloke, hi! We've been seeing this error: https://paste.ubuntu.com/p/4kjf5rfQf7/ in the cloud-init-ci-nightly testing since https://github.com/canonical/cloud-init/commit/66e114a660c53400e389f119781f378311b65108 landed
<paride> same error lucasmoura mentioned yesterday in his triage
<paride> fixing it could be as easy as adding a missing dep, but I can't find the right one
<paride> maybe it is something you know already?
<Odd_Bloke> paride: Yep, I can dig into it!
<Odd_Bloke> paride: Oh, I think we dropped that job from config when we migrated to GH.
<Odd_Bloke> paride: So I think it just needs deleting from Jenkins?
<Odd_Bloke> paride: Specifically in https://github.com/canonical/server-jenkins-jobs/commit/3036d11d8955c48fc7e8025704d2a1d98c5632b5
<paride> Odd_Bloke, I was coming to the same conclusion :) I deleted them from the jjb config but not from jenkins
 * paride proceeds to the deletion
<paride> Odd_Bloke, thanks!
<paride> there, one less red job
<Odd_Bloke> (As an aside, the fix would have been to add `--release xenial` to the `bddeb` call, so that the xenial-specific dependency is added to Build-Depends as in https://github.com/canonical/cloud-init/commit/66e114a660c53400e389f119781f378311b65108#diff-354f30a63fb0907d4ad57269548329e3)
<Odd_Bloke> rharper: Not sure if you're around given the 4th, but do you have any thoughts on next steps for https://bugs.launchpad.net/cloud-init/+bug/1874544?
<ubot5> Ubuntu bug 1874544 in cloud-init "issue with double mac addresses on azure/ib0 devices" [High,Triaged]
<rharper> Odd_Bloke: if we must fix the ib double mac issue on our side; then it's just a matter of ignoring duplicate macs when the interface type is infiniband;  Azure really should fix the platform which is duplicating the hv_net mac into the ib device; but I don't expect that to change any time soon;
<Odd_Bloke> rharper: Thanks!
<compufreak> How should /meta-data work for nocloud-net? I tried to model it after AWS but it looks like it requests /meta-data and expects it to return yaml whereas AWS returns text/plain list of keys
<compufreak> ahh, nocloud-net expects yaml--finally found it in the docs
<Odd_Bloke> compufreak: :) Let us know if you have any follow-up Qs!
<meena> Odd_Bloke, rharper, : on a "standard Bionic image" â my first thought was, blame the imageâ¦
<Odd_Bloke> meena: I'm missing some context here. :)
<meena> Odd_Bloke: re https://bugs.launchpad.net/cloud-init/+bug/1874544
<ubot5> Ubuntu bug 1874544 in cloud-init "issue with double mac addresses on azure/ib0 devices" [High,Triaged]
<MICROburst> How to enable disk encryption/LUKS and have cloud-init asking for the passphrase?
<Odd_Bloke> MICROburst: cloud-init doesn't really "ask" users for anything, could you explain what you're looking to do a little more?
<Odd_Bloke> meena: Aha, right; nope, just giving us something concrete that we can confirm a reproducer/fix with. :)
<MICROburst> Odd_Bloke: I would like to use one system for all. On Fedora I was using kickstart, but now I'm about to migrate to Ubuntu. so cloud-init should do the job on bare metal too.
 * meena mumbles something about preseed
<Odd_Bloke> MICROburst: cloud-init isn't designed for installing systems, it customises pre-built images (such as those used for cloud instances).  You might be looking for something like subiquity autoinstalls: https://ubuntu.com/server/docs/install/autoinstall-reference ?
<Odd_Bloke> (You'll notice that you can pass cloud-init configuration to subiquity, if there is cloud-init functionality you would like to use that isn't covered by subiquity's own configuration.)
<MICROburst> Looks like a hen and egg problem: https://discourse.ubuntu.com/t/cloud-init-and-the-live-server-installer/14597 https://discourse.ubuntu.com/t/please-test-autoinstalls-for-20-04/15250 -- ubuntu is referring to cloud-init - there is little or not description for subiquity
#cloud-init 2020-07-04
<Davidian1024> hello
<Davidian1024> i'm running into some diffifulties in debugging my cloud-init network-config
<Davidian1024> i'm getting generic python errors like: "AttributeError: 'str' object has no attribute 'get'"
<Davidian1024> i'm wondering if there's a way to get it to tell me more clearly what's wrong with my config
<Davidian1024> ok well, i got past it.  not sure i understand why i was getting the error.
<Davidian1024> under ethernets: i had put renderer: NetworkManager, when i commented that line the error went away and it's now taking my other settings within the ethernets section
<Davidian1024> so this still leaves me in the same boat so to speak.  i've been going through a number of different configurations.  and fairly often i hit these python errors that do very little to clue me into what's wrong.
<Davidian1024> i'm hoping someone here can point me to a way to troubleshoot things better when i hit these types of errors
<compufreak> From a python perspective, you usually call .get on a dictionary so I'm guessing it's something like `renderer: \n   NetworkManager:` vs `renderer: NetworkManager`
<MICROburst> let's say I installed a machine with Ubuntu using their installer. Can I install cloud-init afterwards to gain cloud-init config files?
<compufreak> yeah it should run on next reboot automatically depending on service settings afaik'
#cloud-init 2020-07-05
<MICROburst> compufreak: How can I convert the .json files to .cfg?
