[03:56] <masber> hi
[03:56] <masber> what would be the alternative of "alternative" command on ubuntu?
[03:57] <masber> which command on ubuntu can use instead of "alternative"?
[03:57] <sarnold> alternatives are just symlinks
[04:01] <masber> sarnold, oh thanks!
[04:02] <sarnold> masber: for example, ls -l `which awk`  -- /usr/bin/awk -> /etc/alternatives/awk
[04:02] <sarnold> then ls -l ... /etc/alternatives/awk -> /usr/bin/gawk
[04:03] <sarnold> so if yo'uve broken your alternatives, you can get something working again by hand
[05:33] <crazyadm> how to install nfs server?
[05:35] <henkjan> crazyadm: apt-get install nfs-kernel-server
[06:16] <crazyadm> anyone setup docker on ubuntu?
[08:40] <PCdude> Hi all :)
[08:40] <PCdude> I have done some experimenting with openstack
[08:41] <PCdude> I have some 10 gbit/s cards that can be used by the nodes of openstack
[08:41] <PCdude> Is there a possible I can connect the storage node to the compute nodes with a direct connection from host-to-host?
[10:21] <cpaelzer> jamespage: dpdk 16.07-0ubuntu4 just got accepted into yakkety, testing OVS-DPDK without it won't be fun for you, so be aware in case you try just too early :-)
[10:22] <cpaelzer> jamespage: bug 1628419 and bug 1625542 would stop your tests
[10:22] <jamespage> cpaelzer, nowhere to test it :-)
[10:22] <cpaelzer> jamespage: good, just wanted to avoid double debugging
[10:24] <jamespage> cpaelzer, +1
[13:17] <coreycb> nacc, new python-taskflow synced and that builds ok.  still working on the python-eventlet ftbfs.
[13:25] <btorch> anyone here uses trusty seeds for kickstart ? I'm having issues with partman ... debconf-get-selections outputs partman sections that do not start with d-i but most examples I see have d-i in front of the line , anyone know the correct way ?
[13:35] <MelRay> Hi everyone...is there a channel where I can ask a question about a .pem certificate?
[13:50] <jamespage> coreycb, ddellav: pushed staging->proposed->updates for newton
[13:50] <jamespage> it smoked ok
[13:51] <caribou> rbasak: nacc: Here is the MR for the clamav merge w/o Universe dependancy : https://code.launchpad.net/~louis-bouchard/ubuntu/+source/clamav/+git/clamav/+merge/307321
[13:51] <coreycb> jamespage, ok thanks
[14:46] <skinux> Having trouble with MySQL (Maria), since updating, I had to create a new user and grant all privileges (used root before), but still can't connect using HeidiSQL nor PHP scripts?
[14:49] <nacc> coreycb: thank you!
[14:49] <nacc> caribou: cool, I will take a look later today (rbasak is out)
[14:50] <caribou> nacc: just thought I'd follow the process instead of just uploading it
[14:51] <nacc> caribou: sure, one of our goals for this cycle or next is to figure out the best way forward for bugs and rebasing merges
[14:51] <caribou> nacc: but I can upload it if you want, it's been blocked for quite a whie
[14:51] <nacc> caribou: ack, i think that's fine, given the timeline
[14:51] <nacc> caribou: and the importer will just pick it up this time
[14:52] <caribou> nacc: well, this can wait until monday; I usually avoid uploading on fridays
[14:52] <coreycb> nacc, also uploading an updated eventlet here in a few minutes
[14:52] <coreycb> nacc, so both ftbfs should be resolved
[14:52] <nacc> coreycb: great!
[15:12] <EmilienM> jamespage, coreycb: I think we found a regression in aodh packaging
[15:12] <EmilienM> the process doesn't start anymore in Puppet Ci
[15:12] <EmilienM> usage: aodh-api [-h] [--port PORT]
[15:12] <EmilienM>  aodh-api: error: unrecognized arguments: --config-file=/etc/aodh/aodh.conf --log-file=/var/log/aodh/aodh-api.log
[15:12] <EmilienM> aodh-api.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
[15:13] <EmilienM> it's happenning since a few minutes / hours - everything was working fine before
[15:22] <jamespage> EmilienM, ah
[15:22] <EmilienM> do you test Aodh ?
[15:22] <jamespage> EmilienM, I suspect a ceilometer-api style switch to wsgi_script
[15:22] <jamespage> EmilienM, nope
[15:23] <EmilienM> why such a change now?
[15:23] <EmilienM> everything was working so fine
[15:23] <jamespage> EmilienM, ask upstream aodh
[15:23] <jamespage> tbh this was a mess with ceilometer
[15:23] <EmilienM> jamespage: I'm not sure that's 100% related to upstream
[15:23] <EmilienM> in RDO we are on trunk and have 0 problem at this time.
[15:23] <jamespage> EmilienM, oh its 100% related to upstream
[15:24] <jamespage> EmilienM, do you deploy in wsgi for RDO?
[15:24] <EmilienM> https://github.com/openstack/aodh/commit/3990c5b7e1bb783092166bebf060e7846757c824
[15:24] <EmilienM> it works in devstack :(
[15:24] <EmilienM> jamespage: yep
[15:24] <EmilienM> jamespage: we deploy everything in wsgi
[15:24] <jamespage> even in Ubuntu?
[15:25] <EmilienM> yes
[15:25] <jamespage> EmilienM, I can fix this, but its as a result of switching certain daemons to be wsgi_script generated between b3 and rc
[15:26] <EmilienM> jamespage: a sec, I asked to jd to join
[15:26] <jd__> howdy
[15:26] <jamespage> fine but I had this same conversation with him last week about ceilometer :-)
[15:26] <jamespage> hey jd__
[15:27] <jd__> I know you jamespage indeed ;)
[15:27] <jd__> how can I help? if I can
[15:28] <jamespage> jd__, EmilienM just tripped over the switch to using wsgi_script for aodh-api
[15:28] <jamespage> same as I hit and fixed last week
[15:28] <jamespage> for ceilometer
[15:28] <jd__> I see
[15:29] <jd__> old pbr?
[15:29] <coreycb> ddellav, can I sync magnum?  I can't ask the release team to accept k8sclient until something depends on it
[15:29] <EmilienM> jd__: it works fine in RDO but not on Ubuntu
[15:29] <jamespage> jd__, no but the switch mandates a change to the service file to splice in -- for the wsgi_script startup stuff
[15:29] <jamespage> /usr/bin/aodh-api -- --config-file=/etc/aodh/aodh.conf --log-file=/var/log/aodh/aodh-api.log
[15:29] <jamespage> vs
[15:29] <jamespage> /usr/bin/aodh-api --config-file=/etc/aodh/aodh.conf --log-file=/var/log/aodh/aodh-api.log
[15:29] <EmilienM> it's weird, we run it in Apache
[15:30] <EmilienM> but I think you start the process at setup right?
[15:30] <jamespage> yes
[15:30] <EmilienM> ...
[15:30] <EmilienM> ok, I saw that before ;-)
[15:30] <jd__> jamespage: so you can fix that no? btw --config-file to that path is the default so you can remove it I think
[15:30] <jamespage> jd__, I can fix it yes
[15:30] <EmilienM> problem solved?
[15:30] <ddellav> coreycb i just uploaded k8sclient to a ppa and I'm building magnum now with it. I'll let you know how it goes.
[15:31] <coreycb> ddellav, ok
[15:33] <EmilienM> jamespage: please let me know when it's fixed, our CI is currently broken because of that.
[15:34] <EmilienM> it blocks everything to merge
[15:35] <jamespage> EmilienM, it will be some hours to work through the system
[15:36] <EmilienM> :(
[15:36] <EmilienM> some hours
[15:36] <EmilienM> ok
[15:36] <EmilienM> why does it take so much time since you don't test aodh?
[15:37] <jamespage> EmilienM, because first i have to upload to ubuntu development, then the release team have to accept it - it has to build and then it gets automatically backported to the uca, where it goes through a proposed area before getting to the -updates pocket you test against
[15:39] <jamespage> EmilienM, tbh I was a bit :( about ceilometer making a change with no prior notification of deprecation of running -api outside of a wsgi container
[15:39] <jamespage> but jd__ and I already discussed that
[15:39] <jamespage> :-)
[15:39] <jamespage> deprecation/removal
[15:40] <EmilienM> jamespage: when do you plan to have testing for all packages that you build?
[15:40] <jamespage> aodh should be included soon alongside barbican and designate
[15:40] <jamespage> other stuff that just syncs from Debian - we won't test that stuff
[15:40] <EmilienM> what if Puppet CI would not be around to provide feedback?
[15:40] <EmilienM> ok so "comes from debian == we don't care" ?
[15:41] <jamespage> EmilienM, no it means I have limited resource to deal with openstack packaging
[15:41] <jamespage> I have to focus on a core set of packages
[15:42] <jamespage> main vs universe in Ubuntu
[15:42] <EmilienM> jamespage: should we remove our Ubuntu jobs?
[15:43] <jamespage> EmilienM, depends whether you think people want some level of assurance of using puppet modules with Ubuntu
[15:43] <jamespage> EmilienM, I'm sorry but sometimes bugs happen
[15:44] <EmilienM> jamespage: it wouldn't happen if CI was in place, what resource need to be added to add a single service test?
[15:44] <EmilienM> I'm always curious how packages can be published without testing
[15:45] <EmilienM> I thought there would be some kind of packaging policy to test a package before publishing it
[15:45] <jamespage> no we have a policy to test packages before we release them
[15:45] <jamespage> and when I say 'we' I mean the ubuntu community
[15:45] <EmilienM> ah so you test aodh?
[15:46] <jamespage> anyway the fix is in the queue
[15:46] <jamespage> it will backport in the next hour or so
[15:46] <jamespage> EmilienM, do you think all 22000 packages in Ubuntu get tested before release?
[15:46] <jamespage> they will be automatically checked for installability etc...
[15:46] <EmilienM> I don't know, i'm asking
[15:46] <jamespage> but function - well the core set in Ubuntu main get focus
[15:47] <jamespage> but not all of them
[15:47] <EmilienM> in RDO, we have a set of CI jobs testing OpenStack services
[15:48] <EmilienM> so if you have a policy to test packages before a release, does this policy apply to OpenStack packages?
[15:49] <EmilienM> jamespage: second question, would you be interested to run Puppet tooling to test what you don't have time to test? Our tooling can be run on any machine
[15:49] <jamespage> EmilienM, it gets applied to openstack services for which we have charms for - aodh is a new charm, so its not entered packaging CI just yet (its already in charm CI)
[15:50] <EmilienM> ok so if it works in Juju, package is promoted
[15:50] <EmilienM> it reminds me the famous "It worked in Devstack" :-)
[15:51] <EmilienM> are they pro-active and current work to increase testing coverage in juju?
[15:51] <jamespage> EmilienM, tbh I find that comment rude
[15:51] <jamespage> EmilienM, the charms are a deployment tool
[15:51] <EmilienM> jamespage: it's not rude, it's humor :)
[15:51] <jamespage> EmilienM, I'm guessing you use tempest to functionally test whatever puppet configures right?
[15:51] <jamespage> well we do the same
[15:51] <EmilienM> again, i'm trying to understand and find a solution
[15:52] <EmilienM> yes
[15:52] <EmilienM> that is a rough matrix of our coverage: https://github.com/openstack/puppet-openstack-integration#description
[15:52] <dmsimard> jamespage: do you really use tempest? We found many packages to lack the tempest plugins required to actually test their project
[15:52] <jamespage> EmilienM, we do a full, multi-unit cloud deployment using production grade tooling and test with tempest
[15:52] <jamespage> that's why I found you 'it worked in devstack' comment a little offensive
[15:52] <jamespage> dmsimard, yeah I agree there are gaps
[15:53] <EmilienM> dmsimard: your example is Gnocchi and UCA CI doesn't test Gnocchi
[15:53] <EmilienM> jamespage: it's humor again
[15:53] <dmsimard> jamespage: should we file bugs against cloud-archive about packages that are missing their tempest plugins ?
[15:53] <jamespage> no we don't have gnocchi charms
[15:53] <EmilienM> jamespage: apologize if this sentence hurts
[15:53] <jamespage> EmilienM, thankyou
[15:54] <EmilienM> now, let's find a solution
[15:54] <jamespage> dmsimard, if there is something missing from a package, please do
[15:56] <EmilienM> from the upstream perspective, a solution would be to gate Debian/Ubuntu packages provided by OpenStack repositories (where zigo works) against Puppet CI jobs
[15:56] <EmilienM> and if they work, start using them
[15:58] <jgrimm> nacc, can you nominate 1622622 for trusty please? needs fixed there (fix already in yakkety&xenial)
[15:58] <nacc> jgrimm: are you sure on that bug #?
[15:59] <jgrimm> 1622622
[15:59] <jamespage> EmilienM, I'm not sure that accurately represents the lose coupling of development workflows between Ubuntu and Debian
[16:00] <jgrimm> nacc, ? should be samba bug?
[16:00] <EmilienM> jamespage: right, but we (puppet Ci) are strong users from UCA and our CI keeps breaking
[16:00] <jamespage> EmilienM, the risk of aligning with the Debian packages zigo is managing under /openstack is that might not actually be the final story with what ends up in each distribution
[16:00] <EmilienM> jamespage: i'm trying to find productive solutions
[16:01] <jamespage> EmilienM, I appreciate that - you've just caught me right at the end of my day after a very long one yesterday in the run up the charm feature freeze
[16:01] <jamespage> EmilienM, can we quantify 'keeps breaking'
[16:01] <EmilienM> it was a rough week I agree
[16:01] <jamespage> I think this cycle has been better (but not perfect)
[16:03] <EmilienM> jamespage: I agree it has been more stable
[16:03] <jamespage> EmilienM, we have repositories based on the WIP packaging changes + branches of OpenStack; I really want to focus and CI testing on that source, as its the start of the development process for a package to enter Ubuntu and then the UCA
[16:03] <EmilienM> jamespage: but there are 2 things I would like to give as feedback:
[16:04] <jamespage> WIP means unreleased here
[16:04] <EmilienM> 1) the velocity of packages updates is still too slow, you don't update packages often enough so when it breaks, it's usually at bad time (release)
[16:05] <EmilienM> 2) the lack of coverage by Juju is concerning, it's not the first time Telemetry services used to fail
[16:09] <jamespage> EmilienM, what's your ideal velocity for 1) ?
[16:10] <EmilienM> jamespage: maybe you could have nightly build to start
[16:10] <EmilienM> jamespage: in RDO we build at each commit in OpenStack
[16:10] <EmilienM> but having nightly builds would be a nice start
[16:10] <jamespage> EmilienM, https://launchpad.net/~openstack-ubuntu-testing/+archive/ubuntu/newton/+packages
[16:10] <jamespage> snap
[16:11] <nacc> jgrimm: ack, typo on my part
[16:11] <jamespage> EmilienM, we also have equivs for mitaka and liberty as well
[16:11] <nacc> jgrimm: so xenial should be fix released?
[16:11] <jgrimm> nacc, yep, but i was waiting till the trusty nomination so i didn't forget. i'll fix now
[16:11] <jamespage> EmilienM, per commit(ish) builds of packages - ish due to the resolution of git repo checks more than anything
[16:12] <nacc> jgrimm: thanks
[16:13] <EmilienM> jamespage: interesting
[16:13] <jamespage> EmilienM, we've done this since essex, albeit with a break for a cycle due to some resourcing shortfall
[16:14] <jamespage> but that's actively maintained now by the Ubuntu OpenStack Team
[16:14] <EmilienM> jamespage: I think 2) is what is worries me the most, since it affects Puppet OpenStack upstream CI
[16:15] <jamespage> EmilienM, yeah - we're working to plug those gaps
[16:15] <jamespage> EmilienM, it might be worth getting something together which documents the gaps in coverage between puppet and charms
[16:15] <EmilienM> cool
[16:15] <EmilienM> it's good to hear :)
[16:15] <jamespage> EmilienM, then at a minimum we have a high risk list to check off on for know gaps
[16:15] <EmilienM> our coverage is documented here: https://github.com/openstack/puppet-openstack-integration#description
[16:17] <jamespage> EmilienM, ack
[16:17] <jamespage> EmilienM, we'll pull something similar together for the Ubuntu Packaging CI
[16:17] <jamespage> I can see some obvious gaps
[16:17] <EmilienM> that's a good news :)
[16:19] <jamespage> EmilienM, I need to put work down for today; lets make sure we move things in a positive direction going forwards - happy to grab some time at the summit to discuss this specifically...
[16:19] <EmilienM> jamespage: thanks for helping here
[16:19] <EmilienM> I didn't disable jobs on ubuntu until now because i want to help
[16:20] <EmilienM> if I would not, I would just have disabled them
[16:20] <EmilienM> and it's not the case ;-)
[16:20] <EmilienM> so thanks for taking time to discuss, and i'm sure things will get improved
[16:25] <skinux> Anyone good with MariaDB?
[16:30] <jamespage> EmilienM, hey here's something that might be a quick win to give early warning of something broken
[16:30] <jamespage> EmilienM, can you add a non-voting job that runs from the -proposed pocket
[16:30] <jamespage> ?
[16:34]  * jamespage eods
[16:34] <jamespage> have a nice weekend all
[16:43] <EmilienM> jamespage: we could
[18:06] <powersj> nacc, Is this waiting for someone to package up? Bug# 1625734
[18:08] <nacc> powersj: i can, is fonts-android back in main now?
[18:09] <nacc> powersj: looks to be in universe right now but might get pulled once i do the package update
[18:09] <powersj> nacc, 1626245 is the MIR
[18:12] <ddellav> coreycb finally got magnum to build. I had a heck of a time getting sbuild to pull in os-api-ref from yakkety-proposed. I finally gave up and just uploaded it to my ppa.
[18:14] <nacc> powersj: ack, uploading
[18:14] <powersj> nacc, thanks!
[20:28] <jamespage> EmilienM, just pushed aodh fixes to -updates
[20:28] <EmilienM> jamespage: thanks a ton, it must be late for you
[20:28] <EmilienM> have a great week end
[20:28] <jamespage> you to
[20:28] <EmilienM> thanks!
[20:37] <skinux> I swear! Update of Ubuntu has rendered MySQL useless
[20:38] <skinux> I can only connect using root, only doing sudo mysql
[21:50] <torak> is setting up your server and database to the same computer logical?
[21:51] <bekks> sure, why not?
[21:51] <torak> bekks: i dont know it sounds like its going to overwhelm the computer
[21:52] <torak> bekks: i know it is more fast. but how about security?
[21:52] <nacc> skinux: what did you update from?
[21:54] <bekks> torak: Depends on your configuration.
[21:54] <torak> bekks: what can i do?
[21:54] <nacc> torak: by 'logical' did you mean 'recommended'? it really depends
[21:54] <bekks> torak: Be more precise and explain what you are actually trying to do.
[21:54] <torak> nacc: yes i mean recommended
[21:55] <nacc> torak: it really depends :)
[21:55] <nacc> torak: what's your end goal?
[21:55] <torak> bekks: i have an ubuntu server at a digital ocean machine. Its a parse-server and i am using mongodb which is hosted on mlab and free(not for production phase)
[21:57] <torak> So buying a mlab hosted mongodb database is much much expensive than installing mongodb to my existing server. But there is one question that makes me thin. Should i install mongodb to my existing parse-server machine or should i create another ubuntu server and install it on the new server.
[21:58] <sarnold> I understand mongo likes memory. a lot of it.
[21:59] <nacc> yeah, i would expect many databases to be pretty memory-intensive, albeit depending on application
[21:59] <nacc> so if your parse-server instance is not memory-heavy, it might be worth having one optimized/tailored for db usage
[22:01] <torak> nacc: I don't have any statistics about it. I don't know how much people will use this app or how much ram should i need. Thats why these kind of services are good because its too easy to scale up. But what about that. I have 20GB SSD space in my cheap parse-server machine. So i think this space is going to waste. I think using it for db could be usefull and cheaper. Plus if there is some stress i can scale up.
[22:02] <nacc> torak: seems like you have a reasonable plan in-place
[22:03] <torak> nacc: yes. sounded nice to me too. :)
[23:54] <wolflarson> I changed my hostname a few days ago and the network seems to have picked that up but ssh and sudo dont seem to know that I did it and keep telling me it is unable to resolve my old hostname.
[23:54] <wolflarson> not really a problem because the commands still seem to be working but would be nice to get rid of errors
[23:56] <sarnold> wolflarson: probably you need to fix the 127.0.1.1 entry in /etc/hosts
[23:56] <wolflarson> it just lists localhost
[23:56] <wolflarson> should it list my hostname as well?
[23:58] <sarnold> 127.0.0.1 should be localhost; the 127.0.1.1 should be your hostname