[00:12] <rharper> smoser: shall I land https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/343122  ?
[00:51] <blackboxsw> I'm for  it as mentioned, I think we can do a followup with something dynamic if needed.
[00:51] <blackboxsw> I'd like us to continue spending time on the CLI, so there will be ample opportunity if needed to touch this again and make it dynamic at that point.
[00:51] <blackboxsw> as it is for now it's fast and correct and 'done' so I'm all for that
[00:52] <smoser> rharper: yeah.
[00:53] <blackboxsw> we can borrow  some simple regex cli --help parsing that landscape-api CLI did for the next iteration, it won't be too bad to pull in.
[00:53] <smoser> i consider myself more competant than one should be with shell scripting
[00:53] <smoser> and compgen stuff just makes me cringe
[00:55] <blackboxsw> seen here is another option. but yeah uses compgen too https://bazaar.launchpad.net/~landscape/landscape/trunk/view/head:/canonical/landscape/api/client/etc/bash_completion.d/landscape-api
[00:55] <blackboxsw> and yeah, I'm all for something simple if we could get away with it
[00:57] <blackboxsw> smoser: sorry I'm late on the review comments of ifconfig->iproute2 stuff, still massaging unit tests for the switch to look before you leap (i.e. which('ip') elif which('ifconfig') )
[00:58] <blackboxsw> FTR, I agree with the approach to testing for the cmd before running it. instead of all the CalledProcessError handling
[00:58] <smoser> blackboxsw: yeah, i knew that that was going to be a pain for your tests
[00:58] <smoser> one way or another we shoudl decide "we are using 'ip'" and then use it
[01:00] <blackboxsw> yeah right, instead of separate tests in each separate function (ip vs netstat    or  ip vs ifconfig)
[01:00] <blackboxsw> yeah just a has_iproute2 would be easy, only one thing to mock then.
[01:01] <blackboxsw> I might just make that change now, as it's too late to get this fixed and back to you for review tonight anyway
[01:04] <blackboxsw> meh, n/m I retract that statement, as we also check which(netstat) and which(ifconfig) and have different error messages/failure paths to handle, so the consolidation doesn't buy much as we'd have to still handle ProcessExecutionErrors and log warnings if the 2nd command we run isn't present anyway
[01:04] <blackboxsw> ahh well
[01:05] <smoser> freebsd uses ifconfig i believe ?
[01:05] <smoser> other than that i would be fine to assume that if you have netstat then you have ifconfig
[01:05] <smoser> they';re' both from net-tools
[01:06] <rharper> smoser: ok, pushing bash completion
[01:10] <rharper> blackboxsw: Yeah, regex parsing is one way though I think the parsers are relegated to other files, so we can't just grep through cmd/main.py;  the recursive --help invokation may be more robust and we can do that at build-time so we have a static bash file.
[01:31] <blackboxsw> +1 rharper we can create a ./tool to gen that static file from recursive --help invocations
[01:31] <blackboxsw> good pt
[01:32] <blackboxsw> could do it at build time. or just run it on a branch in progress prior to commit
[16:13] <smoser> blackboxsw: have a minute ?
[16:22] <blackboxsw> yes definitely
[16:22] <blackboxsw> smoser: heading to hangout
[17:11] <blackboxsw> rharper: smoser dropped Metric column from route info output to retain original behavior. Only differences in behavior to what currently exists in bionic when relying on ip instead of ifconfig/netstat are that we do the following:
[17:11] <blackboxsw> 1. properly print full scope name for addrs as presented by ip
[17:11] <blackboxsw> 2. drop trailing ':' in the device column
[17:12] <blackboxsw> 3. print ipv6 addrs instead of '.'
[17:12] <blackboxsw> 4. print an ipv6 routes table
[17:12] <blackboxsw> smoser: rharper the diff on an ec2 instance: https://pastebin.ubuntu.com/p/KZWYPbCRvC/
[17:14] <smoser> are we consistent with o urselves now ?
[17:14] <smoser> between ifconfig and ip
[17:18] <smoser> blackboxsw: my freebsd seems not working on server stack :-(
[17:18]  * blackboxsw is trying freebsd on ec2
[17:41] <rharper> blackboxsw: can you run ec2 with ipv6 addr so we can see the diff?  I didn;t think we displayed link-local ip6 addrs; and we don't split out v4 and v6 for netdev, but we do for route ?
[17:43] <blackboxsw> rharper spinning one up now
[17:43] <rharper> blackboxsw: w.r.t the interface to the various parse output methods;  as smoser has told me, if you don't want someone using the modules as an api, then you need to use _ prefix
[17:44] <rharper> otherwise, those methods in netinfo *are* an api, and that means callers could pass non-strings to you
[17:44] <blackboxsw> +1, I should change that
[17:44] <rharper> if smoser doesn't mind, then I'm OK with not adding checks on the inputs, but it seems reasonable to me to set those as input=None, and then add if not input: input = ""
[17:45] <rharper> or something safer;
[17:48] <smoser> why set a default ?
[17:48] <smoser> they require input
[17:52] <rharper> one way of ensuring you don't blow up doing .split() on a non string for typical usage, None is more comment than passing in a dict;  or raise valueerror on the wrong type
[17:52] <smoser> rharper: well, we really aren't providing an api. we're just not really doing that.
[17:52] <rharper> smoser: then it I think blackboxsw will end up marking the methods with _
[17:52] <smoser> we should, and ideally would. but just really are not.
[17:54] <smoser> rharper: there is no reason to provide a default variable
[17:54] <smoser> changing
[17:54] <smoser>  def netdev_info_iproute(ipaddr_out):
[17:54] <smoser> to
[17:54] <smoser>  def netdev_info_iproute(ipaddr_out=None)
[17:54] <smoser> is contrary to useful
[17:54] <rharper> sure
[17:54] <smoser> raising a TypeError if ipaddr_out is not a string is fine.
[17:55] <blackboxsw> yeah +1 not defaulting as we don't want users calling netdev_info_iproute(). it needs something to parse
[17:55] <blackboxsw> TypeError I balked at because our code is the only caller and it stuffs in util.subp output which is a known quantity of a string type
[17:56] <smoser> right.
[17:56] <smoser> so that is why i didnt' feel we need it.
[17:56] <blackboxsw> so it's a case where I didn't feel users could likely induce a failure path by presenting an invalid type
[17:57] <smoser> at this point we're not *really* providing an api.  no one that is using cloud-init as a python library (at thsi point) is surprised by that :)
[17:57] <smoser> that isnt that we shouldnt. just that we're imature.
[17:57] <blackboxsw> if we were, say, processing user-provided cloud-config information which we've loaded into a dict, then I'd be more concerned about checking types of data etc.
[17:57] <smoser> yeah, i largely agree with that.
[17:57] <smoser> but i'm also OK to just shove a _ on it too.
[17:58] <blackboxsw> yeah I'll do that _ as I feel like for our own sanity it's nice to designate what we think should really have internal (to the module) callers
[17:58] <blackboxsw> it's a good function/method documentation policy
[18:07] <mgerdts> smoser: thanks for landing those
[18:20] <blackboxsw> rharper: ec2 w/ ipv6 address
[18:20] <blackboxsw> https://pastebin.ubuntu.com/p/96qtpRpdxV/
[18:21] <rharper> thx
[18:21] <rharper> so, the link-local is new, as is the lo in the routing v6 table
[18:22] <rharper> should we clean those up?  unreachable seems unhelpful, on the fence on link-local ipv6 values, we're not showing link-local v4 stuff
[18:22] <smoser> link local is new ?
[18:22] <rharper> printing link-local values in the net dev info table
[18:22] <rharper> yeah, look at the 17.2 vs 18.2
[18:23] <blackboxsw> yeah it was previously just .
[18:23] <blackboxsw> just absent I mean
[18:43] <smoser> blackboxsw: so what are you doing with all that ?
[18:43] <smoser> are we looking to make output identical to previous ?
[18:45] <blackboxsw> smoser: rharper I just wanted to see if you guys had concerns about that behavior and if you think we should avoid printing link local info like line 29 of https://pastebin.ubuntu.com/p/96qtpRpdxV/
[18:46] <blackboxsw> and if line 27 and 30 should really be like 8 and 10
[18:46] <blackboxsw> do we want to continue to not process/report certain data, even though I fixed what I felt was a bug in the ommission
[18:46] <rharper> I dunno; my use of that table is mostly restricted to seeing what networking as applied, typically the ipv4/v6 addresses, I don't think for clouds many users will ahve a second instance in the same network where they could reach it via link local
[18:47] <smoser> i dont think line 29 is bad.
[18:48] <blackboxsw> also the whole table line 40+ (ipv6 routes) is 'new'
[18:48] <smoser> and i'm fine with 27 and 30 too
[18:49] <smoser> i think they're generally improvements.
[18:50] <smoser> blackboxsw: for the ipv6 output
[18:50] <smoser> i think there is no reasno to show routes on interface lo
[18:50] <smoser> (they're not seen on ipv4)
[18:52] <blackboxsw> +1 will drop them
[18:52] <blackboxsw> for SRU fodder, would we want to drop the ipv6 route table altogether
[18:52] <blackboxsw> ?
[18:53] <blackboxsw> or it's just more output that users could take advantage of (not really change in existing functionality presented by other tables)
[18:53] <smoser> i think its fine. idont really believe any tools are likely scraping that.
[18:53] <blackboxsw> cool sound good rharper ?
[18:56] <rharper> blackboxsw: yeah, I agree with smoser
[19:11] <smoser> blackboxsw: can i help you with anything ?
[19:13] <blackboxsw> all good. just pushed all changes
[19:14] <blackboxsw> was going to make deb one more time and test lxc and ec2 while waiting for ci
[19:14] <blackboxsw> smoser: rharper all done
[19:14] <rharper> nice
[19:14] <blackboxsw> will pastebin one more pass
[19:14] <smoser> rharper: i have updates to https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343246 and responses to your comments
[19:18] <blackboxsw> done smoser rharper https://pastebin.ubuntu.com/p/dK8JBmdpNk/
[19:18] <blackboxsw> looks good
[19:19] <blackboxsw> I think we can land it and I'll put up a merge proposal for bionic if that sounds good?
[19:21] <blackboxsw> https://jenkins.ubuntu.com/server/job/cloud-init-ci/1025/ in progress
[19:33]  * blackboxsw will be back in 30 mins
[19:41] <smoser> https://www.diffchecker.com/9sLtnCgT
[20:04] <smoser> blackboxsw: i put a patch on there. https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/342428
[20:35] <blackboxsw> waiting on ci
[20:56] <smoser> blackboxsw: marked approved
[21:21] <blackboxsw> smoser: sorry power loss. I'm back up, landing and publishing
[21:22] <blackboxsw> and cutting a bionic upload MP
[21:29] <blackboxsw> smoser: it'
[21:29] <blackboxsw> s up https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/343562


[18:04] <jfalk> Hi, I get an exception when trying to login to https://bugs.launchpad.net with my ubuntu one account. The exception message tells me to either tell you at this channel, file a bug report (I can't login to the bug tracker), or write an Email to<EMAIL_ADDRESS>Exception as follows: Oops!
[18:04] <jfalk> Sorry, something just went wrong in Launchpad.
[18:04] <jfalk> We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.
[18:04] <jfalk> If you can't login, join us on #launchpad IRC channel at irc.libera.chat, e-mail us or visit our feedback page.
[18:04] <jfalk> If you report this as a bug, please include the error ID below, preferably by copying and pasting it rather than by taking a screenshot.
[18:04] <jfalk> (Error ID: OOPS-839f904cf1050b90f18ea837b4c559f3)
[18:06] <jfalk> FYI. This is nothing urgent, the problem just persisted for a few days, and I thought it might notify you.


[03:47] <Trioxin> to get the latest amd graphics driver on 15.10 should I add: ppa:xorg-edgers/ppa ? I saw a warning when adding the repo that it's compatible with wily 15.04
[03:48] <Trioxin> I'm having some trouble with the open source driver kubuntu installed and I'd like to try the proprietary driver
[05:30] <maysara> How can I log the terminal output without having to use "script file.log" each time?
[05:46] <garvitdelhi> maysara: if you running a command through terminal you can easily do like this : "comand > output.log"
[06:00] <maysara> garvitdelhi: OK thanks
[09:09] <Guest3393> #gcompris
[09:55] <lordievader> Good morning.
[12:39] <ddn> Hi all
[12:40] <ddn> I have deleted /etc/ld.so.conf.d/. Is there way to restote it?
[12:49] <Smurphy> Nope. One does not delete a directory in /etc
[13:07] <BluesKaj> Hi folks
[13:41] <Smurphy> Morning :)
[13:44] <_shaun_> hi guys is it possible when a record is deleted for postgres to verbosely state which referenced foreign keys gets deleted as well?
[13:44] <_shaun_> sorry i posted this question on the wrong forum
[13:52] <zhn_> hey
[14:16] <Pici> :/
[14:21] <BluesKaj> Pici, ?
[14:21] <Pici> BluesKaj: just remarking on the aurelie___ clones.
[14:23] <BluesKaj> oh well , I see that practically everyday in here
[14:25] <dakoslug1> Hi, I'm looking to install my audio drivers are kubuntu...
[14:26] <dakoslug1> I tried Driver manager, nothing showed  up
[14:26] <BluesKaj> dakoslug1, aplay -l in the terminal
[14:27] <dakoslug1> BluesKaj: alright
[14:27] <BluesKaj> that will give us your audio chip
[14:27] <dakoslug1> BluesKaj: HDA INTEL PCH?
[14:27] <dakoslug1> http://termbin.com/epnr
[14:28] <BluesKaj> dakoslug1, yes
[14:28] <BluesKaj> which output are you going to use or using, analog or HDMI ?
[14:29] <dakoslug1> BluesKaj: I'm not entirely sure the difference? But I have speakers at the back and headphones at the front...but I'd prefer headphones
[14:31] <BluesKaj> dakoslug1, well that would be analog for both, so open alsamixer in the terminal and for starters turn up the master , pcm and front vol ctls, then make sure the automute is disabled using the down arrow key when you navigate to it
[14:33] <dakoslug1> BluesKaj: alright so i noticed headphones was muted and so was automute and front
[14:34] <dakoslug1> BluesKaj: Anything else
[14:34] <BluesKaj> dakoslug1, after you do that, use the escspe key to get back to the prompt , and run sudo alsactl store
[14:34] <dakoslug1> BluesKaj: alright
[14:34] <BluesKaj> so you unmuted the headphones as well with M key ?
[14:35] <dakoslug1> BluesKaj: not with the M key but arrow key up?
[14:35] <dakoslug1> BluesKaj: ah i see the difference
[14:36] <dakoslug1> BluesKaj: Okay so I press M on it
[14:36] <BluesKaj> yes
[14:36] <dakoslug1> Sorry I mean that I did
[14:37] <BluesKaj> you should see 00 in the box where M was
[14:37] <dakoslug1> BluesKaj: I ran the alsactl store command again
[14:37] <dakoslug1> BluesKaj: It's working now :)
[14:37] <BluesKaj> right
[14:37] <dakoslug1> BluesKaj: Thanks!
[14:38] <BluesKaj> dakoslug1, np, glad you have audio :-)
[14:38] <dakoslug1> BluesKaj: Is there a GUI program for alsactl ?
[14:38] <dakoslug1> i mean
[14:38] <dakoslug1> alsamixer
[14:40] <dakoslug1> nvm found one
[14:40] <dakoslug1> thanks again :)
[14:40] <BluesKaj> there is another app that runs as a gui called pulseaudio that also lets you control inputs and outputs, it's in system setting>multimedia , beside device prefernces
[14:41] <dakoslug1> ooh i see
[14:44] <BluesKaj> dakoslug1, one has to use the combination of alsamixer and pulseaudio settings to setup audio on 'buntu, unfortunately. It's a bit of a mixed bag , but it can be setup to work properly
[14:44] <dakoslug1> BluesKaj: Yeah I guess the terminal one is fine tbh, I don't see why I'd need to use it again either
[14:45] <BluesKaj> dakoslug1, the multimedia setting once stup won't change unless you change audio devices
[14:46] <dakoslug1> BluesKaj: what if I unplug and replug?
[14:46] <BluesKaj> that shouldn't matter
[14:46] <dakoslug1> ah okay good
[14:50] <BluesKaj> dakoslug1, one more thing , if after an update/upgrade your sound doesn't work , run , sudo modprobe snd-hda-intel , sometimes the audio driver fails to load upon reboot , it hasb't been a problem in 15.10 tho
[14:50] <dakoslug1> BluesKaj: Noted! Thanks
[14:50] <BluesKaj> hasn't
[14:51] <BluesKaj> righto
[16:21] <cycoe> hey
[16:23] <cycoe> hey
[16:23] <BluesKaj> hi cycoe
[16:24] <cycoe> M from China
[16:25] <BluesKaj> cycoe, ok do you have a kubuntu support question?
[16:26] <cycoe> I have tried many ways before connecting in
[16:26] <cycoe> not yet
[18:37] <SnowSky> Test
[18:37] <SnowSky> Hello
[18:42] <lordievader> o/
 test
[20:16] <melodie> hi
 Hi there
[20:17] <melodie> I would like to know how to configure properly the gtk look of Synaptic, in Kubuntu? I can't seem to get a proper result, whatever I try?
 what have you tried?
[20:18] <bprompt> melodie:    gtk look of synaptic?   wass ist dat?   why not just use Muon Package Manager?  is pretty much the same thing as Synaptic, just using kde UI, is all
[20:21] <melodie> bprompt I'm not seeking for advice, but for how to do what I need to
[20:21] <melodie> thanks ^^
[20:23] <melodie> bprompt Synaptic is a powerful tool, where you can easily update, select, unselect packages without distraction.
[20:23] <bprompt> thought it was the same thing =)
 no they are different
[20:23] <melodie> Muon is more a sort of software center with suggestions of packages
[20:23] <melodie> bprompt it's really not
[20:24] <melodie> I tried to get a gtk look in synaptic, but then I can't setup the fonts properly, something is wrong about that
 all the fonts are the same in the system settings?
[20:24] <melodie> and when I remove the gtk look, then the fonts can be configured from within synaptic : I've never seen that in my current Openbox environment, for example
[20:25] <bprompt> melodie:   anyhow... gtk apps, like synaptic, use gtk theme, and you can add your themes at ~/.themes, now... it depends on your gtk version or what gtk the apps uses, some use gtk2.x and theming there is different than gtk3, gtk3 uses CSS pretty much, but whatever theme you choose for your GTK, that's what all gtk apps will use
[20:25] <melodie> bprompt this is Kubuntu Trusty.
[20:25] <melodie> I'll try putting the theme in .themes ok
[20:26] <bprompt> melodie:      there's an app, or used to be, depends on what kubuntu version you may be I assume, the app is "gtk-chtheme"  which is a gtk theme changer
[20:26] <melodie> I think Synaptic uses gtk3 but I'm not perfectly sure about that (and putting the theme into .themes might be in /root/.themes for it to work perhaps?)
[20:26] <melodie> bprompt this is very old and would not work
[20:28] <bprompt> melodie:    all gtk-chtheme does, is, write out a ~/.gtkrc
[20:29] <melodie> bprompt it's not a matter of configuring a gtk theme, it's a matter of doing it with the specific KDE4 setup : because when I add a settings.ini in the root directory, it works! But then the fonts are microscopic, and I don't have the hand on it !
[20:29] <melodie> then I don't need it, I know how to copy and modify a .gtkrc-2.0 and a settings.ini for the .gtk-3.0
[20:29] <melodie> makes me think...
[20:29] <melodie> there should be one in /etc ?
[20:30] <melodie> I'll have a look!
[20:30] <bprompt> melodie:     well... hmm if the app using a gtk3 theme.... then what I'd do is, edit the theme at ~/.themes, as aforementioned, gtk3 uses CSS for its colors and font sizes
[20:31] <bprompt> melodie:    you could also, just get another theme :), many out there at kde.look.org
[20:31] <bprompt> melodie:    kde-look.org rather
[20:33] <melodie> bprompt YESS!!!
[20:33] <melodie> that was it!
[20:34] <melodie> I looked into the content of /etc/gtk-3.0/settings.ini and the theme written there is Ambiance.
[20:34] <melodie> I installed light-themes which contains "ambiance" and that did the trick!
[20:34] <bprompt> hmmm I think I've seen that theme... I think it was too dark for my taste =)
[20:35] <melodie> Synaptic is a program started with the root permissions, so the config has to be somewhere in the system, but not in the user's sector
[20:35] <melodie> it would not work
[20:36] <melodie> I guess now I can try to apply another theme in that /etc/gtk-3.0/settings.ini (doing a backup of the file first with a copy to itself-backup)
[20:36] <bprompt> melodie:    I run it with and without root :), runs fine, when nonrooted it simply gives me a dialog box saying that it's not rooted is all
[20:36] <melodie> also installing light-themes pulled in some gtk3-engines which were not installed
[20:37] <bprompt> I run it not as root, just to peruse for packages only
[20:37] <melodie> if you run Synaptic as simple user, you can't install or administrate packages (and normally you can't start it as simple user)
[20:37] <melodie> sorry, what does "peruse" mean?
[20:38] <bprompt> melodie:    runs as regular user for me, and yes, that's the reason why I run it like so, just when I need to peruse around,  hmm peruse, browse for packages only :)
[20:45] <melodie> bprompt how are you not prompted for a root password?
[20:47] <bprompt> melodie:    I simply run "synaptic"  from a .desktop shortcut :),   now when I want to run the rooted version, I simply use my "kdesudo synaptic" shortcut :)
[22:44] <melodie> no one noticed bleachbit root does not work in Kubuntu Trusty?
[22:44] <melodie> I don't have time to report the bug today, maybe in a few days
[22:45] <melodie> good night


[00:21] <miken> Hrm... I'm seeing "error trying to stop watcher: connection is shut down" consistently when trying to upgrade a charm (rabbitmq). That is, it happened 2 out of 2 times on the initial upgrade-charm, and resolved itself 2 out of 2 on a resolved --retry. Does anyone see anything in this paste that could indicate an issue with the charm? http://paste.ubuntu.com/11380563/ (or a way I could avoid it)
[01:25] <lazyPower> miken: thats odd, and doesn't indicate something is awry with the charm that I can see. it looks like something in the env tanked briefly and resolved itself on the next go
[01:26] <miken> lazyPower: yeah, that's what I thought too initially, which is why I was surprised when I re-bootstrapped to test again and had exactly the same behaviour the second time (ie. upgrade-charm failed initially with that error, then resolved --retry resolved without issue)
[01:26] <lazyPower> hmm...
[01:26] <lazyPower> config-get is what failed though
[01:26] <lazyPower> or rather, returned > 1
[01:27] <lazyPower> can you attach to the unit after a deploy, then run the upgrade-charm sequence, and call config-get and examine the output?
[01:27] <lazyPower> debug-hooks in a consistent failure case like that should get us enough of a reproduceable env to see whats happening
[01:28] <miken> Sure - let me redeploy. My guess is that I'll see a similar api connection error.
[01:28]  * miken does that.
[01:28] <lazyPower> ta miken
[01:47] <thumper> miken: anything you see with something like "error trying to stop watcher" is a juju bug, not a charm bug AFAICT
[01:47] <thumper> miken: which version of juju?
[01:51] <miken> 1.23.2-trusty-amd64
[01:52] <miken> Yes, as above, I did assume it was a juju bug, but given that it reproduced itself twice only for that charm, I didn't know if there was something specific to the charm triggering it. I'm trying for a third time now, with debug-hooks.
[01:53] <miken> Right, I should have said s/issue with the charm/something in the charm that might trigger/
[02:04] <miken> thumper, lazyPower: Didn't trigger the error on the third redeploy with debug-hooks. Oh well :/ (if it was important, I'd redeploy again and try for a 4th time without debug-hooks, but otherwise I'll just move on)
[02:04] <lazyPower> miken: without being able to capture the env and debug whats happening - i think you're fine to move on for now. but if it crops up, by all means please capture logs and file a bug
[02:05] <thumper> agreed
[02:05] <lazyPower> miken: appreciate the time spent attempting to reproduce for us. *hattip*
[02:24] <redelmann> hi there, someone online for a quick help?
[02:25] <lazyPower> redelmann: we can try, whats the trouble?
[02:25] <redelmann> lazyPower, hi!
[02:25] <redelmann> lazyPower, i recently install docker inside a juju unit
[02:26] <redelmann> lazyPower, docker create a docker0 bridge network
[02:26] <redelmann> lazyPower, now all relation to that unit get provate-address of bridge0
[02:26] <redelmann> lazyPower, this happend in MAAS but not in AWS
[02:27] <redelmann> lazyPower, it's a know bug? or something im doing wrong?
[02:27] <lazyPower> thumper: hey have you seen this before? MAAS unit-agent is picking up on a bridge interface and not the host device
[02:27] <lazyPower> redelmann: this is most definately a networking bug in the juju unit agent if its picking up the wrong interface to be providing as a private address
[02:27] <thumper> lazyPower: oh... yeah...
[02:27] <thumper> rings a bell
[02:27] <lazyPower> ok, so if you've heard of it chances are we have a bug somewhere
[02:27] <lazyPower> let me fish this up and see if there's anything listed as a work around until it gets patched redelmann
[02:28] <thumper> the network selection logic is a bit fubared on maas right now
[02:28] <lazyPower> 1 moment
[02:28] <thumper> I know it is being worked on
[02:28] <thumper> but I don't know the status
[02:28] <thumper> one horrible thing you could do...
[02:28] <redelmann> lazyPower, i search a lot, but i couldn't find anything
[02:28] <thumper> is to name it alphabetically after 'eth0'
[02:28] <thumper> that *might* work
[02:29] <lazyPower> thumper: seriously?
[02:29]  * thumper shrugs
[02:29] <redelmann> thumper, i try to disable Docker0 bridge, but now i don't get any private-address in relation :P
[02:29] <thumper> I didn't write any of that
[02:29] <lazyPower> i'm not blaming you, i swear
[02:29] <lazyPower> not this time anyway
[02:29] <thumper> IIRC it choses the first network adapter
[02:29] <thumper> chooses
[02:30] <thumper> i may be wrong
[02:30] <lazyPower> redelmann: so you disabled the docker bridge, and it doesn't show up in ifconfig -a, but its no longer sending an address on the wire for private-address?
[02:30] <thumper> wallyworld: do you know the status of the maas networking stuff?
[02:30] <redelmann> thumper, lazyPower: netroks are in alphabetic order (eth0: noip, juju-br0: private ip, etc"
[02:30] <thumper> ah...
[02:30] <thumper> phoey
[02:30] <wallyworld> thumper: not in any detail
[02:30] <redelmann> lazyPower, exactly.
[02:30] <lazyPower> redelmann: ok, i'm not finding a bug searching launchpad either. Can you file a bug detailing this issue?
[02:31] <lazyPower> we need to get it triaged and on the docket for someone to look at it
[02:31] <thumper> if in doubt, file a bug
[02:31] <redelmann> lazyPower, is like it try to get address of first interface
[02:31] <lazyPower> i know there's a whole herd of networking stuff inc. and this may be on that ticket, but without a bug we wont know.
[02:31] <thumper> the juju team can always either mark as a dupe or invalid
[02:31] <thumper> but better to have the bug than not
[02:31] <lazyPower> https://bugs.launchpad.net/juju-core/+filebug
[02:31] <thumper> lazyPower: cheers
[02:32] <thumper> someone should make a bot that files bugs for us :)
[02:32] <thumper> an irc bot
[02:32]  * lazyPower kicks mup
[02:32] <thumper> probably need a valid person list
[02:32] <thumper> with some auth
[02:32]  * thumper thinks:
[02:32] <redelmann> lazyPower, ok. i'am in home right now. but tomorrow in work i will create an issue.
[02:32] <redelmann> lazyPower, thumper: thank yoy very much
[02:33] <lazyPower> redelmann: awesome. if you need me to take a look at it feel free to ping me here and i'll look it over and route some eyes at it.
[02:33] <lazyPower> redelmann: sorry you ran into that :( Not a very stellar experience ot have a unit just drop a private-address once a new bridge pops up
[02:33] <redelmann> lazyPower, for the record, it happen in KVM enciroment.
[02:33] <redelmann> lazyPower, environment. Sorry my english :P
[02:33] <lazyPower> that'll be good info to have in the bug, so if it happens in KVM but not on a BM host we can isolate it :)
[02:34] <lazyPower> make sure you include juju-version, maas version, and steps to reproduce
[02:34] <redelmann> lazyPower, OK, thanks
[02:34] <lazyPower> cheers redelmann
[02:37] <lazyPower> thumper: are you going to make this bot your new friday freetime project?
[02:38] <thumper> lazyPower: ha, nah
[02:40] <lazyPower> :) just teasin anyway. Its 11, i'm outy5000. See you in the am o/
[09:40] <jamespage> Tribaal, morning - we have an issue with http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/revision/373?start_revid=373
[09:40] <jamespage> its breaking anything todo with the hacluster charm due to the way that the data is passed for that relation
[09:55] <jamespage> Tribaal, I've reverted it for now - under bug 1459175
[09:55] <mup> Bug #1459175: relation_set is broken <Charm Helpers:Fix Committed> <https://launchpad.net/bugs/1459175>
[10:39] <stub> jamespage, Tribaal : That will affect Bug #1458546 and the corresponding MP (different issue probably - py3 vs. settings being lost)
[10:39] <mup> Bug #1458546: relation_set broken under Python3 <Charm Helpers:In Progress by stub> <https://launchpad.net/bugs/1458546>
[10:43] <stub> I didn't see any dataloss with 1.23, so not sure what went wrong with the hacluster charm
[10:44] <stub> (unless it is py3 and you were swallowing the AttributeError?)
[12:51] <jamespage> coreycb, hey - minor feedback on that charm-helpers merge
[12:51] <jamespage> stub, the hacluster charm uses some fairly horrid serialization techniques for the data that gets passed
[12:52] <jamespage> I suspect this is what breaks
[12:54] <coreycb> jamespage, good catch! fixing
[12:56] <Tribaal> jamespage: we'll need this to be in at some point however, without this the size of arguments passed to a relation is limited to the system's command-line size limit
[12:57] <jamespage> Tribaal, don't doubt that
[12:57] <jamespage> Tribaal, we have a horrid workaround in nova-cc due to that issue
[12:57] <Tribaal> jamespage: ok, so we're not the only ones to need the --file thing to work at least :)
[12:57] <jamespage> Tribaal, maybe it could be opt-in rather than on by default?
[12:58] <Tribaal> we need it because we set relatively complex errorpage stazans on the haproxy charm
[12:58] <Tribaal> jamespage: whatever works. We could make it another charmhelpers method (set_rlation_with_file) or something
[12:58] <Tribaal> but that feels dirty
[12:59] <Tribaal> ideally, there should be only one obvious way to do this :)
[12:59] <Tribaal> what breaks for the hacluster charm?
[13:14] <coreycb> jamespage, fixed c-h and the rest of the charms and resent you an email with mp links as I'd changed the names of the branches which changed the mp names
[13:51] <mbruzek> good morning jcastro
[13:55] <jcastro> hi!
[13:55] <jcastro> how was your break?
[13:56] <mbruzek> jcastro: Good I went camping and got rained on
[13:56] <mbruzek> jcastro: how was canada
[13:59] <jcastro> mbruzek: lovely
[14:48] <lazyPower> jcastro: Nice! re: shirts
[16:07] <redelmann> lazyPower, hi there. i report this https://bugs.launchpad.net/juju-core/+bug/1459327
[16:07] <mup> Bug #1459327: Juju MAAS netwoking with custom bridge inside service <juju-core:New> <https://launchpad.net/bugs/1459327>
[16:07] <redelmann> lazyPower, from the last chating with you
[16:07] <lazyPower> redelmann: perfect, thanks for following up. i'm in ameeting give me a moment to take a look
[16:08] <redelmann> lazyPower, ok. tellme if more info is needed
[16:15] <jcastro> kwmonroe: heya, so the texaslinuxfest guys just pinged me reminding us the deadline for talks is tomorrow, and we haven't submitted anything.
[16:17] <kwmonroe> wat jcastro?!?  http://2015.texaslinuxfest.org/content/call-papers says June 28, 2015 11:59 p.m.: Deadline for proposals
[16:17] <jcastro> oh shit
[16:17] <jcastro> that's 30 days away.
[16:17] <jcastro> my bad
[16:18] <kwmonroe> did they tell you the 28th and you just assumed may, or did they say may?
[16:18] <jcastro> well they sent me the mail today with a reminder, I saw 28th and basically panicked.
[16:19] <jcastro> kwmonroe: but hey, if you do it by tomorrow it's a full 30 days out of the way!
[16:19] <kwmonroe> i see what you're doing there
[18:36] <arosales> upper--, hello
[18:36] <upper--> arosales: :)
[19:07] <nevermam> Hi Antonio..I am an IBM charmer.Can you please share with me the charm review checklist, which we can use as guidelines/best practise, while creating charm..
[19:08] <tvansteenburgh> arosales: ^
[19:12] <tvansteenburgh> neverman: i'd start here https://jujucharms.com/docs/stable/authors-charm-store
[19:12] <tvansteenburgh> nevermam: also read "Charm store policy" and "Best practices"
[19:16] <arosales> nevermam, hello and welcome :-0
[19:21] <arosales> nevermam, in addition to the links tvansteenburgh gave you I am working on creating a checklist I would like to propose to the juju list and get feedback on.
[19:21] <arosales> nevermam, that may be the list you are after, and once I get a +1 from folks I propose adding it to the review docs.
[20:09] <jcastro> also if anyone has any things to add to those doc pages I'd be happy to integrate them if it helps the next person
[21:10] <lazyPower> hey marcoceppi, i think i know why clearwater-bono didn't make it into the revq. There was no branch attached - its a pointer to their GH repository
[21:11] <lazyPower> iirc, attaching a branch was part of the requirements
[21:12] <lazyPower> redelmann: i apologize for taking so long to get back to you, but this is exactly what we were looking for. Thanks for the bug report
[21:12] <redelmann> lazyPower, great. i get a ¿workaround?
[21:13] <lazyPower> Nothing as of yet, but its now in the queue for review by the core team. If someone on the core team knows how to work aroudn this bug, they should be chiming in on the bug soon, otehrwise we'll get an official patch landed to address it soon
[21:13] <redelmann> lazyPower, just setting docker0 to some strange network like: "<IP_ADDRESS>" and juju start working again
[21:13] <lazyPower> redelmann: really? thats interesting...
[21:13] <redelmann> lazyPower, a little reserch from here: https://github.com/juju/juju/blob/master/network/network.go
[21:13] <lazyPower> redelmann: have you tried using something like the docker core bundle to deploy your docker + networking solution?
[21:14] <lazyPower> not the most ideal situation, but adding flannel networking will reconfigure the docker0 bridge w/ an ip from etd and that may resolve the issue in a juju-centric manner
[21:14] <lazyPower> https://jujucharms.com/u/lazypower/docker-core/4
[21:15] <redelmann> lazyPower, we already have our docker scripts for the projects, it was easier to use docker from the same project
[21:16] <lazyPower> ack, just curious
[21:16] <redelmann> lazyPower, but that's is too much infrastucture for us roght now.
[21:16] <redelmann> right
[21:17] <redelmann> lazyPower, we are using docker for isolating proccess from network
[21:17]  * lazyPower nods