[00:30] <profall> Hello
[00:30] <profall> so a - (negative) nice value
[00:30] <profall> means the process has more priority?
[00:33] <sarnold> yes
=== Lcawte|Away is now known as Lcawte
[08:52] <lordievader> Good morning.
[12:25] <selinuxium> Hi all, completely new at all things Docker/Juju/Chef/Ansible/etc... I have a spare Wily Laptop 4 cores with 8gb to playground on... Any suggestions on where to start? (Apart from the obvious limitations of the laptop) :)
[12:26] <ikonia> selinuxium: start with what ?
[12:32] <selinuxium> I am interested in server/application automation. I am not sure on the differences between the differnet orchestration tools. ShoudlI use Juju with Docker for instance? Is it a better idea to learn Juju on it's own? Am i barking up the wrong tree entirely?
[12:33] <ikonia> just have a play, do some research
[12:33] <ikonia> everyone has different needs
[12:45] <lordievader> selinuxium: Start of small and work your way up.
[12:46] <selinuxium> :)
[12:48] <dasjoe> There's still https://www.reddit.com/r/linuxadmin/comments/2s924h/how_did_you_get_your_start/cnnw1ma
=== selinuxium_ is now known as selinuxium
=== Mined is now known as MinedAWAY
[13:35] <coreycb> jamespage, can you sync python-openstacksdk from experimental?  it builds ok on xenial.  it's a dep of python-senlinclient which is a dep of heat.
[13:35] <coreycb> I don't have permission to sync it
[13:39] <coreycb> jamespage, actually I think we need a new release of that so I'll work on that
[13:50] <jamespage> coreycb, ack
=== admcleod1 is now known as admcleod
[14:32] <Yossarianuk> hi - can anyone explain why I see different environment variables  -> using cat /proc/PID/enviorn  if I use 'service [daemon] start compared to /etc/init.d/[daemon] ?
[14:38] <Yossarianuk> i.e I have variables in /etc/environment  - if I use 'service  [daemon] start I cannot see the env variables using 'cat /proc/[PID]/environ
[14:38] <Yossarianuk> but can if I use /etc/init.d/[daemon]
[14:43] <MACscr> did i just disable this service from automatically starting or did it just state that an startup link doesnt exist? http://pastie.org/pastes/10636134/text?key=mvzsl8twaufflytdp8phqq
[15:07] <Yossarianuk> ive found the answer to my question -> http://unix.stackexchange.com/questions/44370/how-to-make-unix-service-see-environment-variables
[15:12] <davegarath> MACscr: tgt should be handed by its conf file in /etc/init/...
[15:12] <MACscr> davegarath: so i just remove the file if i dont want  it to auto start?
[15:12] <MACscr> i need to create some other checks first
[15:13] <MACscr> and then just start it manually
[15:13] <MACscr> dont want any iscsi targets up until my gluster volume is verified mounted
[15:16] <davegarath> MACscr: you can configure tgt with dependencies with glusterfs. It will not start ultil gluster is ready
[15:16] <MACscr> davegarath: gluster as service running is different than a particular gluster volume beeing mounted
[15:17] <MACscr> being
[15:17] <davegarath> MACscr: you can write a service ad-hoc
[15:17] <MACscr> i have no idea what im doing though, so it might still be possible
[15:19] <davegarath> MACscr: btw, instead removing the file I suggest you to disable it at your runlevel ( I suppose 2 )
[15:19] <MACscr> wasnt there
[15:20] <MACscr> seems like such a nasty way to handle a service starting up or not
[15:44] <icezimm> hello, I'd like to know if its possible to install maas on 15.10 and provision openstack on 14.04?
[15:44] <icezimm> I'm facing some problems… just would like to validate this setup
[15:51] <coreycb> jamespage, it looks like ironic's not doing b's rc's anymore, so I'll plan on packaging 4.3.0
[15:52] <coreycb> ddellav, ^
=== cpaelzer is now known as cpaelzer_afk
[16:20] <teward> rbasak: ping, but if you're busy disregard
[16:35] <rbasak> teward: o/
=== MinedAWAY is now known as Mined
[17:15] <teward> rbasak: post-ping my laptop died, apologies.  Care to review the merge debdiff for me prior to upload?
[17:15] <teward> sarnold did a once over yesterday, but another set of eyes is appreciated
[17:16] <rbasak> teward: sure. In the bug?
[17:17] <teward> should be, both the huge one (1.9.3-1ubuntu1 ->  1.9.6-2ubuntu1) and the small one (1.9.6-2 (Debian) -> 1.9.6-2ubuntu1 (merge))
[17:17] <teward> if all checks out i'll upload ASAP
[17:17] <teward> though i may have to beat my laptop to make the power work
[17:18] <rbasak> OK, looking.
[17:19] <teward> rbasak: thank you kindly!  :)
[17:19] <teward> (after beating my head on that for over 20 hours overall, every sanity-check is appreciated)
[17:19] <teward> oh, and sec team mandate was followed too (and I even confirmed it)
[17:27] <rbasak> teward: how thoroughly do you want me to review this? Superficially looking at just the diff it looks like a high quality merge. Everything looks good in principle.
[17:28] <teward> rbasak: basic sanity checks :)
[17:28] <rbasak> teward: I haven't exhaustively examined it though, like for example checking each configured module in -core etc.
[17:28] <rbasak> teward: all basic sanity checks passed. Thank you for the merge. Excellent work!
[17:28] <teward> rbasak: i don't need that thorough a check - the third party stuff has to be added with --add-module flags, which are excluded in the common build flags and excluded in the -core build flags entirely.
[17:29] <rbasak> Ah, that's good.
[17:29] <teward> the only changes were to copy-paste the full configure args up, and remove the --add-module stuff
[17:29] <teward> that and description changes due to the HTTP/2 thing from the sec team
[17:29] <rbasak> One moment
[17:30] <rbasak> teward: I wonder how much of a surprise HTTP/2 missing will be for users, and where we might be able to call it out specifically.
[17:31] <rbasak> teward: just to avoid your pain in filed bugs.
[17:31] <rbasak> teward: maybe call out specifically in the description that HTTP/2 is not built for security reasons? Or in README.Debian? I'm not sure how much that will help though, so it's entirely up to you.
[17:32] <rbasak> (rather than just removing it from the list which could appear to be a mistake even though it isn't)
[17:32] <rbasak> Admittedly you have documented it in the changelog.
[17:32] <rbasak> So it's just a case of deciding where appropriate will minimise user confusion.
[17:37] <rbasak> rharper: great work with bug 1511735, thanks.
[17:37] <ubottu> bug 1511735 in libnl3 (Ubuntu Trusty) "libnl: fail to bind() netlink sockets" [Undecided,New] https://launchpad.net/bugs/1511735
[17:38] <rbasak> rharper: are you happy on the regression risk to SRU this?
[17:39] <rbasak> rharper: a couple of really minor things. Can you explain in the changelog why we're SRU-ing (ie. what bug we're fixing) as well as the patches you've applied? Because some users are very selective about what SRUs they accept and the changelog helps them make that decision.
[17:40] <rbasak> rharper: and one even more minor thing which I wouldn't worry about fixing, but for next time. I really appreciate the detail in the dep3 headers, just note that Last-Update values technically should be hyphenated.
[17:44] <rharper> rbasak: thanks for the feedback.  I'm pretty sure in the changelog I recorded which bug we're fixing and which patches I applied
[17:44] <rharper> certainly can make sure we split up the DEP3 date header, sorry about that;
[17:45] <rharper> rbasak: the submitter mentioned that 3 of the patches are upstream but not in 3.2.26, which is what's currently targeted for xenial, wondering if we then should merge upward to 3.2.27 (which would include all of the fixes we;re applyin to trusty)
[17:46] <rharper> rbasak: I have to run to an appt; I'll sync up with you; thanks for the feedback
[17:46] <rbasak> rharper: yes, you did record the bug number and which patches you were applying. I'm asking for a short description of what you're fixing in the changelog though so others don't have to look up unless they want more info than a short summary.
[17:46] <rbasak> rharper: np. Thank you for your work!
[17:47] <rbasak> rharper: we don't want to end up in a situation that Trusty has bugs fixed that Xenial doesn't, since then users would experience regression on upgrade.
[17:47] <rbasak> rharper: so we can cherry-pick into Xenial, or bump to 3.2.27 if you like.
[17:47] <rbasak> rharper: either way we'll then need to sync in future once Debian has caught up.
[17:53] <teward> rbasak: upload will be delayed thanks to power issues on my system :/
[17:53] <teward> but it will eventually get uploaded
[17:54] <rbasak> np
[18:41] <beisner> jamespage, precise-icehouse proposed full deploy tests look good.  tempest results are == precise-icehouse updates.
[18:43] <beisner> jamespage, also:  wily-liberty-proposed + trusty-liberty-proposed looks good.  tempest results are == liberty-updates.
=== CiPi is now known as cipi
=== cipi is now known as CiPi
=== Mined is now known as MinedAWAY
[20:00] <rharper> rbasak: I'll look at a merge for libnl-3 in Xenial, if that's clean( I think it should as libnl-3 in trusty had no ubuntu patches) then that'll be the best
[20:00] <rharper> s/merge/sync
[20:00] <rbasak> rharper: I don't think Debian have the version you need yet?
[20:01] <rharper> bah
[20:01] <rharper> ok
[20:01] <rbasak> rharper: if so then just plain version upload is fine, rather than a merge, if you want to go that route.
[20:01] <rbasak> And then sync from Debian when they do upload the newer one.
[20:01] <rharper> Nicolas offered to rebase the patches versus the version in Xenial now
[20:01] <rbasak> Probably polite to file a bug with them, give them patches, etc.
[20:01] <rharper> but I'll defer to you for the best course of action
[20:02] <rharper> so, we'd get an upload of a new release in Ubuntu, file a debian bug against version in unstable , send patches with the bug ?
=== Piper-Off is now known as Monthrect
[20:25] <rbasak> rharper: right.
[20:25] <rharper> rbasak: cool, I updated the bug with the suggested direction
[20:25] <rbasak> rharper: cherry-picking upstream patches or updating to the latest upstream release in Ubuntu ahead of Debian are both fine.
=== cpaelzer_afk is now known as cpaelzer
[20:26] <rbasak> rharper: it's just down to time and effort you want to commit, both now and in future maintenance. I think that depends on the patches so you're best to judge that.
[20:27] <rbasak> Updating ahead of Debian risks less support from Debian if we don't sync before Xenial's release, which depends on Debian's schedule.
[20:27] <rharper> everything is already upstream, so I don't think we have any real patch maintenance; but I don't see much risk in just uploading the latest since the delta we carry is debians which is all packaging related
[20:27] <rharper> ah, ok
[20:27] <rbasak> But it might be so minor as not to matter.
[20:27] <rbasak> Cherry-picking is the same - we risk having to maintain something diverged from upstream if we don't end up updating before Xenial's release.
[20:27] <rharper> ok, if we get the Debian bug filed and patches applied, then we can just sync that version into Xenial
=== nacc_ is now known as nacc
=== cpaelzer is now known as cpaelzer_afk
=== Monthrect is now known as Piper-Off
=== Lcawte is now known as Lcawte|Away