[02:08] <ubuntu_> Hello, ubuntu-server won't ad a network adaptor.
[02:09] <ubuntu_> test
[03:28] <linuxmint> Hello?
[05:36] <cpaelzer> good morning
[09:56] <halvors> Hi. How can i disable dhclient for some given interfaces?
[10:08] <Walex> halvors: that's not a good question
[11:21] <halvors> Walex: Is there any way to just run the dhclient on a spcifed interface? Where is the config file for this?
[11:22] <Odd_Bloke> halvors: /etc/network/interfaces and /etc/network/interfaces.d/* should be what controls it.
[12:16] <coreycb> jklare, it looks like bug 1586443 was fixed so I'll take a look at backporting gnocchi again.  it's going to be a bit though if at all since the fix will need to land in yakkety first before an SRU to xenial can be approved.
[12:16] <coreycb> jklare, your best bet would be to test on xenial
[12:17] <jklare> coreycb thanks, would be great to see it in trusty too. We are already using it on xenial and it seems to work :)
[12:18] <coreycb> jklare, that's good to hear.  I'll keep you posted.
[12:20] <halvors> Odd_Bloke: Well, it isn't as both are completly empty.
[12:20] <halvors> But dhclient still requesting DHCP on all interfaces.
[12:25] <cpaelzer> halvors: for static and manual configs it shouldn't - would you mind providing a pastebin of your /etc/network/interfaces[/.d] and name an interface in it that you expect to not do dhcp, but does it?
[12:28] <halvors> cpaelzer: As i said both /etc/network/interfaces and /etc/network/interfaces.d is empty.
[12:28] <halvors> cpaelzer: My interfaces is configured with iproute2
[12:30] <Odd_Bloke> halvors: Could you pastebin your /var/log/syslog somewhere?
[12:30] <cpaelzer> halvors: ah I read that as "not empty" sorry
[12:31] <cpaelzer> like "it is not like both would be completely empty" - anyway clarified now
[12:38] <cpaelzer> somebody might know the inner workings if that file is completely empty (I don't out of my head) - I'd try to just replace dhclient with a wrapper that reports PPID and current ps axlf output to a tmp file - so you'd see where it is coming from
[12:46] <Impaloo> Hey not sure what's going on with a mounted USB stick. `df` says it has 29G used, whereas `du` says the mount point has 3.6G usage
[12:47] <Odd_Bloke> Impaloo: Could you pastebin the two outputs?
[12:48] <Impaloo> Odd_Bloke: http://pastebin.com/C8V710Bp
[12:48] <Impaloo> worth noting it's an exFAT fs
[12:49] <Odd_Bloke> Impaloo: Hmm, I'd expect du to report permissions errors, but there might be files on there that your user can't access?
[12:50] <Impaloo> Odd_Bloke: nope, no extraneous files
[12:51] <Odd_Bloke> Do you have access to any other distros/OSes?  What do they report/
[12:51] <Odd_Bloke> *?
[12:51] <Impaloo> Odd_Bloke: unfortunately no, on Raspbian atm
[12:52] <Odd_Bloke> Hmm, afraid I'm out of ideas then. :)
[12:52] <Impaloo> i'll try reformatting to ext4
[12:53] <cpaelzer> Impaloo: http://serverfault.com/questions/57098/du-vs-df-difference http://linuxshellaccount.blogspot.de/2008/12/why-du-and-df-display-different-values.html
[12:53] <cpaelzer> Impaloo: the difference of "trusting superblock" vs "counting" could be amplified by behavior of xfat in your case
[12:54] <cpaelzer> As Odd_Bloke thought the omst common issues are permissions or mounting over directories then invisible to du
[12:56] <jayjo> Is there a way to program a cron job to skip certain calendar days - as in skip July 4th, August 2nd, etc
[13:02] <cpaelzer> jayjo: I don't know of a "skip" parm, people usually do like this http://unix.stackexchange.com/questions/88770/cron-to-not-run-on-specific-day-but-all-other-days
[13:02] <Walex> jayjo: not really, but you can write a shell script script to do that with 'date'
[13:04] <Walex> halvors: I think that you are asking the right question...
[13:04] <Walex> halvors: I think that you are NOT asking the right question...
[13:05] <Walex> halvors: it usually helps if you say first what you want to achieve, not about the way you think is theb way to do it.
[13:06] <Walex> halvors: for example "I have 2 interface and I want to configure statically one and dynamically the other and I am using 'ifup'/NM/... to configure them.
[13:07] <smoser> flarunt, invalid manifest (sorry, long weekend). is that still an issue ? you're saying the manifest file in the ova has invalid sum for the .ovf file i think, right?
[13:07] <Walex> halvors: you could also ask why your original question was wrong...
[13:07] <Walex> or at least looked wrong.
[13:07] <smoser> please file a bug against cloud-images https://bugs.launchpad.net/cloud-images/+filebug
[13:14] <jayjo> Walex: so use a cronjob to execute a shell script, and that script will only continue if it meets the date param criteria?
[13:18] <devster31> can I apt upgrade python* making apt only update packages already installed?
[13:19] <patdk-wk> why do you want to update python? but nothing else?
[13:20] <devster31> it was an example, first thing
[13:25] <shewless> Hi guys. Does anyone know a good place to read up on keystone configuration? I'm using this guide but it does not give enough detail on LDAP configuration: http://docs.openstack.org/developer/keystone/configuration.html
[13:25] <shewless> Do I need to download the source code and read it or is there some proper documentation that I just can't find?
[13:26] <devster31> shewless: #openstack and #openstack-keystone might be better fits?
[13:28] <shewless> devster31: thanks I'll look there. To be honest you guys at ubuntu-server are far more responsive :)
[13:29] <devster31> maybe, but I know absolutely nothing about openstack, you could also try http://docs.openstack.org/developer/devstack/ if you aren't already
[13:48] <caribou> rbasak: I'm done with the kexec-tools's merge; should I wait for usd-import to be run so I get the repository created ?
[13:59] <jamespage> coreycb, poked a load of things in packaging CI today
[13:59] <jamespage> most things working/in the pipe for build testing again
[13:59] <jamespage> ironic broken due to my mistake in the versioning field for the build - fixed now
[14:00] <coreycb> jamespage, awesome, thanks.  b1 should be released any day now.
[14:01] <jamespage> coreycb, yah - I see global-requirements sync's going past
[14:01] <jamespage> coreycb, we should probably do a oslo.* run through
[14:01] <jamespage> (says the man not here for the rest of the week)
[14:01] <jamespage> coreycb, we're nearly deployable from branch PPA's now
[14:01] <coreycb> jamespage, ok.  on that note I'm catching up on all the upstream g-r review policies etc to help out with that.
[14:02] <jamespage> \o/
[14:02] <jamespage> coreycb is awesome
[14:02] <coreycb> jamespage, lol I've not done much yet.  ack on the oslo bumps.
[14:04] <coreycb> jamespage, re: almost deployable from PPAs, are you referring to the charms?
[14:04] <jamespage> coreycb, yes
[14:06] <coreycb> jamespage, that's good, so we should be in pretty good shape to get b1 out the door.
[14:06] <jamespage> hope so
[14:22] <cpaelzer> caribou: you might want to highlight nacc for that question as well - @nacc importer timing question above
[15:28] <rbasak> caribou: I was about to reply to you when nacc appeared!
[15:28] <rbasak> nacc: seen caribou's request for import of kexec-tools? I wanted to ask you if I'm fine to run the importer for people on request now.
[15:28] <rbasak> (I haven't actually tried to run it at all yet :-/
[15:28] <nacc> rbasak: it would work, but i've not pushed our rework yet
[15:29] <nacc> rbasak: so it would result in a different tree, not sure if kexec-tools would be affected or not :)
[15:29] <nacc> rbasak: i can do the import later today, i think, i was pretty close to being done with the rewrite on friday
[15:30] <nacc> rbasak: i'll respond to caribou on-list regardless :)
[15:30] <nacc> rbasak: if that's ok with you?
[15:31] <rbasak> nacc: sure!
[15:31] <nacc> rbasak: also, did you see my last e-mail from last week? re: merge and double-commits?
[15:32] <rbasak> nacc: sorry, I forgot about that.
[15:32] <nacc> rbasak: np! long weekend and i sort of asked you not to respond at the time :)
[15:32] <rbasak> nacc: I think one commit is fine, but we'll have to end up with two commits when a user pushes to upload/<version>
[15:33] <rbasak> This is assuming that there isn't a case I'm missing here.
[15:33] <nacc> rbasak: right, i'll need to consider that case still (right now, i'm not handling upload/ being added properly, i expect, even in the current code)
[15:33] <rbasak> It would be nice if the importer could somehow detect and add the second commit so a merger would only have to upload a straightforward rebase, but I'm not sure that's possible.
[15:34] <nacc> rbasak: yeah, i'll think through it, and worst-case put some comments in
[15:37] <caribou> nacc: rbasak: on-list is fine for me btw
[15:37] <nacc> caribou: thanks, sorry for the delay, holidays and just waking up now :)
[15:38] <caribou> nacc: no worry, I was fighting with my merge anyway
[15:38] <caribou> nacc: I need to spend some time cleaning the Wiki's notes & merge mine
[15:39] <nacc> caribou: ack, i also was considering making a second page that's more tied to this tool and with a working example
[15:40] <caribou> nacc: well, I will most probably have to redo my own merge with the new tree so I'll write down a set of side notes that I can add somewher
[15:40] <nacc> caribou: sounds good -- it'll be some sort of combination and distillation of what's in the serverreleasehandling page (which has gotten quite long :)
[15:41] <caribou> nacc: some pkg specifics makes things weird sometimes; like kexec-tools that provides patches that it doesn't apply and that are removed as delta
[15:42] <caribou> nacc: couldn't figure out why there were patches in d/p but the result was still ok wrt the merge :)
[15:42]  * caribou makes a note to submittodebian this one
[15:43] <rbasak> There's a thought
[15:44] <rbasak> submittodebian could do with expanding to work on individual git commits.
[16:15] <nacc> rbasak: yeah, all of these tools and stuff, are part of what i want to document, too :)
[16:16] <nacc> rbasak: i will say the new algorithm makes some nice gitk graphs :)
[16:18] <caribou> nacc: FYI, I have pushed a kdump-tools update which should take care of the ppc64el crashkernel issue
[16:18] <caribou> nacc: It'll hit Yakkety once I get kexec-tools merged in
[16:19] <nacc> caribou: awesome, that's what i was looking forward to seeing :) i'm sure ibm will appreciate it ... eventually :)
[16:19] <caribou> nacc: well, I'll need someone to formally test it as I don't have the hardware available
[16:19] <nacc> caribou: yep, should be easy to find someone if you need me too
[16:27] <rbasak> rharper: for bug 1518440, I'll mark as cleared in my tracking. There seem to be enough people affected that one would think someone could complete SRU verification. If not, then the SRU team will warn and remove, and I think that's fine to avoid regression risk (if nobody cares).
[16:27] <rbasak> rharper: thank you for driving.
[16:27] <rharper> rbasak: sure
[16:40] <rbasak> nacc: for the bacula bugs, I think I'm missing a big picture of how the different issues interact. For the MySQL-specific ones, upstream and I are quite happy to help - I'm just not sure how everything needs to fit together to make the whole thing usable.
[16:41] <nacc> rbasak: yeah, i think we discussed this during the sprint and was why we demoted bacula to universe?
[16:41] <nacc> in 16.04
[16:42] <rbasak> nacc: I think that given we demoted it it's up to us to unbreak it. Once unbroken and in sync, we (Canonical) have done our duty and don't need to worry about it any more.
[16:43] <nacc> rbasak: ack, not disagreeing
[16:48] <rbasak> magicalChicken: around? I've got some old bug assignments I'm tracking - bug 869017, bug 1394403, and a new one, bug 1511222.
[16:48] <rbasak> magicalChicken: I know you've been out, but jgrimm informs me that you should be able to work on these again soon, so I'm just checking in.
[16:49] <magicalChicken> rbasak: Hey, I'm back in this week
[16:50] <magicalChicken> Sure, I'll pick these back up, I think I had partial fixes for all of them, just never got through the final stages for getting them approved
[16:52] <magicalChicken> I'll take a look at the new apache bug first
[16:54] <rbasak> magicalChicken: thanks!
[16:54] <magicalChicken> rbasak: Of course, sorry it took so long to get the two old bugs handled
[17:39] <spaceturtle> Does anyone know how I can use an .ssh/config entry that will re-write my username based on the hostname? The %h varaible doesnt work for User
[18:16] <EmilienM> coreycb, jamespage: did you already try trove? trove-taskmanager recently fails to start on Mitaka (works on RDO): http://logs.openstack.org/20/323320/1/check/gate-puppet-openstack-integration-3-scenario003-tempest-ubuntu-xenial/cb423b0/logs/etc/trove/trove-taskmanager.conf.txt.gz
[18:16] <EmilienM> err, wrong link
[18:17] <EmilienM> http://logs.openstack.org/20/323320/1/check/gate-puppet-openstack-integration-3-scenario003-tempest-ubuntu-xenial/cb423b0/logs/trove/trove-taskmanager.txt.gz#_2016-05-31_12_25_39_482
[18:21] <EmilienM> coreycb, jamespage: found it, it's a bug in packaging I'm reporting it
[18:22] <jamespage> this rings a bell - something todo with the wrong config files EmilienM?
[18:22] <EmilienM> yes
[18:22] <EmilienM> trove packaging loads trove.conf only
[18:22] <EmilienM> while trove use multiple files
[18:22] <jamespage> EmilienM, https://bugs.launchpad.net/bugs/1516471
[18:23] <jamespage> I have a fix committed in the repo
[18:23] <EmilienM> omg
[18:23] <EmilienM> so it's not fixed in xenial?
[18:24] <jamespage> unsurprisinly a comment on a bug is not always the best way to get peoples attention
[18:24] <jamespage> I picked that out of the backlog last week
[18:24] <EmilienM> we disable trove testing on ubuntu in the meantime.
[18:27] <jamespage> EmilienM, sure - I'll get the bits lined up next week (about to disappear for a few days).
[18:34] <jamespage> EmilienM, is it relatively easy for you to test from our stable branch PPA's?
[18:35] <jamespage> ppa:openstack-ubuntu-testing/mitaka will have pre-upload fixes in a while
[18:35] <EmilienM> jamespage: we already released mitaka, which means now we rely on what you provide in stable repo
[18:35] <EmilienM> jamespage: we don't want to use ppa on purpose because we want stable things
[18:35] <EmilienM> and fwiw, trove was working on trusty/mitaka
[18:36] <EmilienM> jamespage: we can enable ppa but only for our master branch (and only if you give us newton packages)
[18:36] <EmilienM> otherwise, we're not interested by ppas
[18:37] <jamespage> EmilienM, I was not suggesting you release an update with a PPA; I was asking whether you could help test the fix
[19:13] <ddellav> coreycb almost forgot, lp:~ddellav/ubuntu/+source/keystone and lp:~ddellav/ubuntu/+source/ceilometer re: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1587589
[19:28] <coreycb> ddellav, keystone looks good. can you rebase ceilometer?
[19:29] <ddellav> coreycb i thought i did but i'll look again
[19:30] <coreycb> ddellav, there were probably some ci fixes that snuck in since
[22:49] <aslaen> hello, I am trying to use openstack autopilot. I have MaaS installed and working (nodes ready), juju installed and connected to MaaS, but when I run autopilot it fails because the environments.yaml is ignored and it uses ~/.cloud-install/juju/environments/maas.jenv instead.
[22:49] <aslaen> For some reason that yml file tries to connect to MaaS on port 5420 but my MaaS runs on port 80 so it fails
[22:51] <aslaen> sorry meant 5240