[04:31] <mjolnir40k> Hello, I'm trying to do some things with ifupdown and VLANs and bridging for KVM
[04:32] <mjolnir40k> I suspect I'm running afoul of biosdevname, since the vlan scripts kind of assume interface names will be eth.*
[04:32] <mjolnir40k> What I want to do is create vlan tags on individual interfaces, and then create bridges on top of the VLANs
[04:32] <mjolnir40k> (bonding is not necessary in my case)
[09:13] <rbasak> powersj: I replied to bug 1623721.
[09:50] <powersj> rbasak: thank you
[11:45] <mozart1893> does anyone have a solution to this situation: I created a virtual network interface on a UBUNTU 16.04 AWS instance and it keeps going off after every restart of the server
[12:11] <mozart1893> does anyone have a solution to this situation: I created a virtual network interface on a UBUNTU 16.04 AWS instance and it keeps going off after every restart of the server
[12:25] <tsimonq2> !ask | mozart1893
[12:27] <lordievader> mozart1893: Is it configured?
[12:27] <lordievader> Without any details it could be anything.
[12:28] <mozart1893> lordievader
[12:28] <mozart1893> it is configured
[12:28] <mozart1893> but anytime i restart the instance, the configuration disappears
[13:16] <jcastro> achiang: I am actively arguing the point to make the vagrant boxes useful for vagrant users
[13:17] <jcastro> achiang: it's one of those "but we want all cloud images to be the same" vs. what people expect from vagrant boxes.
[13:18] <jcastro> also painfully aware that hashi is unrecommending our images
[13:20] <jcastro> achiang: iirc the cloud images team maintaines the image, so I think you're looking for gaughen if you want to submit patches/fixes
[13:40] <coreycb> zul, ddellav: i've uploaded the liberty point releases to liberty-staging
[13:40] <zul> coreycb: cool...
[13:40] <coreycb> zul, how's mod_wsgi?
[13:40] <zul> coreycb: slow...i had to fix ceilometer yesterday so i could test stuff
[13:41] <zul> coreycb: daemon wasnt running because one of the python-dependencies had litterally nothing in the deb
[13:41] <coreycb> zul, ok. if you're using the charms and then reinstalling from the new package, watch out for haproxy listening on the same port.
[13:42] <coreycb> zul, are you working on heat and cinder?
[13:42] <zul> yeah heat today
[13:43] <coreycb> zul, ok.  i pushed aodh, ceilometer and nova.  i think i'll get the charm updates up for review next and just mark them workflow-1 until we release b2.
[13:44] <zul> coreycb: awesome
[13:44] <zul> coreycb/jamespage: im just in the middle of backporting libvirt to xenial as well
[13:45] <coreycb> EmilienM, jamespag` : we should have all the api's moved to mod_wsgi + apache2 for the b2 release of ocata.
[13:48] <EmilienM> coreycb: good news. My second problem was that nova-api package was not idempotent when also deploying nova-placement-api
[13:48] <EmilienM> I haven't details but I saw that in puppet CI
[13:49] <EmilienM> have you tried to deploy both packages in same time and do it again? does it work?
[13:49] <coreycb> EmilienM, so just to be clear, to recreate the idempotent issue, would i have to install nova-api and nova-placement-api, then uninstall, and install them again?
[13:52] <EmilienM> coreycb: no. Do something like: 1) install nova-api 2) install nova-placement-api 3) run apt-get install nova-api again and see if it works fine
[13:52] <EmilienM> coreycb: maybe it's something with my setup but it was not idempotency
[13:52] <EmilienM> idempotent*
[13:52] <Ussat> just gonna post this once, if anyone is interested:  https://www.humblebundle.com/books/unix-book-bundle
[13:52] <coreycb> EmilienM, ok i'll take a look
[13:53] <EmilienM> coreycb: thanks!
[14:11] <coreycb> EmilienM, ok the package assumes they are mutually exclusive, so i'll fix that to enable nova-api and nova-placement-api to both be installed at the same time
[14:12] <EmilienM> coreycb: nice! so my bug was valid (/me dancing)
[14:12] <EmilienM> thx for fixing it!
[14:14] <coreycb> EmilienM, :)
[14:27] <zul> jamespag`/coreycb:libvirt updated in the CA
[14:39] <hitesh> hey
[14:40] <coreycb> EmilienM, ok so looking more, the mutual exclusive bit might be valid.  basically if you install nova-api then all other nova api packages are mutually exclusive (ie. metadata api, placement api) because the apis are read from enabled_apis in nova.conf.
[14:40] <coreycb> EmilienM, however if you install nova-compute-os-api (vs nova-api) then you can also install nova-metadata-api and nova-placement-api
[14:42] <EmilienM> coreycb: not placement api
[14:42] <EmilienM> placement api has nothing to do with enabled_apis
[14:42] <EmilienM> placement api is just a simple wsgi app to run in Apache and some config to do in nova.conf ([placement] section)
[14:43] <coreycb> EmilienM, ok maybe.  let me double check on that in #openstack-nova before I remove it.
[14:44] <EmilienM> coreycb: I already checked :D
[14:44] <EmilienM> coreycb: it has been one week I'm working on that
[14:44] <EmilienM> and we successfuly deployed it on centos7
[14:44] <coreycb> EmilienM, ok got a link to the discussion?
[14:44] <EmilienM> just a vhost to create and run the wsgi app :)
[14:44] <EmilienM> I have better
[14:45] <EmilienM> CI job deploys it, a sec
[14:45] <EmilienM> (we don't deploy on ubuntu yet because of the issues I showed you)
[14:45] <EmilienM> coreycb: https://review.openstack.org/#/c/406301/
[14:45] <EmilienM> coreycb: http://logs.openstack.org/01/406301/4/check/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/f1bb688/logs/
[14:45] <EmilienM> that's logs
[14:45] <EmilienM> you can look nova logs and also nova config if you like
[14:49] <coreycb> EmilienM, yeah just seems like it should be valid to specify on enabled_apis based on the upstream code:  https://github.com/openstack/nova/blob/master/nova/cmd/api.py#L59
[14:49] <EmilienM> coreycb: cdent, the author of Placement API told me no
[14:50] <EmilienM> enabled_apis is only for compute & metadata API
[15:03] <hitesh> can anyone helpme to install usb formatter found in linux mint in ubuntu
[15:44] <ddellav> coreycb are you working on any CI failures?
[15:44] <coreycb> ddellav, not at the moment
[15:45] <ddellav> coreycb ok, we have a ton of red so I'm gonna crank through some
[15:45] <coreycb> ddellav, sure. let me know if you have an merge proposals.
[15:45] <ddellav> coreycb will do
[15:53] <coreycb> EmilienM, ok I pushed that update so nova-api and nova-placement-api will be able to be installed together in b2
[15:53] <coreycb> zul, sahara is better now for liberty-staging
[15:54] <zul> coreycb: ack
[15:58] <SipriusPT> hello guys
[15:59] <SipriusPT> I have a smart host working in a MacosX 10.9.5 with Server App 3 (who uses postfix mail_version = 2.9.4), and i have notice that i am just able to redirect mail inside of my smart host (Outlook, Mail app and roundcubemail installed in this server), for example i am just able to send mails from user1@domainX.pt to user2@domainX.pt where i have a redirection to user1@domianY.pt,
[15:59] <SipriusPT>  if i try to send mail from user1@domainY.pt to user1@domainX.pt who is redirecting mail to user2@domainY.pt, i will get this message at mail.log:
[15:59] <SipriusPT> Dec  6 14:37:12 remote.domainX.pt postfix/smtp[28504]: 0B8BD259F57: to=<user2@domainY.pt>, orig_to=<user1@remote.domainX.pt>, relay=mail.domainX.pt[]:25, delay=0.1, delays=0/0.01/0.07/0.02, dsn=5.0.0, status=bounced (host mail.domainX.pt[] said: 550-Verification failed for <Xserver@remote.domainX.pt> 550-No Such User Here 550 Sender verify failed (in reply to RCPT TO command))
[15:59] <SipriusPT> From what it seems instead of using orig_to=<user1@domainX.pt> i am getting orig_to=<user1@remote.domainX.pt>, and my remote mail server will give that response. I am just using domainX.pt instead of remote.domainX.pt that i am not using at all. My mail server remote.domainX.pt is connected to my remote mail server mail.domainX.pt.
[15:59] <SipriusPT> Anyone knows how can i solve this?
[16:07] <EmilienM> coreycb: you rocks!
[16:18] <zul> coreycb: hey i just noticed that the openstack-ubuntu-testing ppa doesnt have the debhelper fix
[16:20] <coreycb> zul, i don't think it needs it, does it?
[16:20] <coreycb> zul, or wait... backport_package should have put it in there
[16:20] <zul> https://launchpadlibrarian.net/297025952/buildlog_ubuntu-xenial-amd64.python-oslo.log_3.19.0-0ubuntu1~cloud0_BUILDING.txt.gz\
[16:21] <coreycb> jamespage, beisner: hi, these are ready to promote if you can please: http://paste.ubuntu.com/23594026/
[16:21] <coreycb> zul, ok it's there: https://launchpad.net/~openstack-ubuntu-testing/+archive/ubuntu/ocata
[16:22] <zul> coreycb: ok
[16:22] <jamespage> coreycb, doing now
[16:22] <ddellav> coreycb seems like most if not all of the xenial ocata ci failures are deb helper issues
[16:23] <coreycb> ddellav, ok i'll take a look
[16:23] <coreycb> zul, hmm yeah so dh-autoreconf failed to build in openstack-ubuntu-testing...
[16:23] <ddellav> coreycb http://10.245.168.2:8080/view/Ocata/job/xenial_ocata_aodh/lastFailedBuild/console
[16:23] <zul> yarp
[16:24] <jamespage> coreycb, done
[16:24] <ddellav> http://paste.ubuntu.com/23594051/
[16:25] <coreycb> jamespage, thanks
[16:30] <jamespage> ddellav, coreycb, zul: ocata testing PPA appears to lack debhelper 10?
[16:30] <zul> jamespage: we were just discussing that ^^^
[16:30] <coreycb> jamespage, i just deleted it because dh-autoreconf needs to build successfully before debhelper can be backported
[16:31] <jamespage> coreycb, okies
[16:31]  * jamespage leaves experts todo their jobs :-)
[16:31] <coreycb> jamespage, lol
[16:31] <zul> jamespage: just call me carol
[16:32] <hitesh> help
[16:42] <alex-at> help
[17:34] <SipriusPT> hello guys
[17:35] <SipriusPT> https://ubuntuforums.org/showthread.php?t=2345648
[17:35] <SipriusPT> anyone here with postfix experience?
[17:40] <coreycb> beisner, hey could you please promote cinder 1:2015.1.4-0ubuntu1.1 and python-glanceclient 1:0.15.0-0ubuntu1~cloud1 to kilo-proposed?
[17:42] <beisner> hi coreycb - ^ done
[17:43] <coreycb> beisner, thx
[17:43] <beisner> yw coreycb
[17:45] <coreycb> zul, is bug 1642274 ready to be verfied?
[17:54] <zul> coreycb: not yet
[18:06] <zul> coreycb: there is another point release coming so im waiting for that
[18:28] <achiang> jcastro: thanks re: vagrant boxes
[18:29] <achiang> jcastro: fwiw, we are staying on 14.04 for now, because ubuntu/trusty64 *is* setup properly to be used with vagrant out of the box
[18:29] <achiang> jcastro: where does the cloud images team hang out?
[18:48] <rbasak> achiang: right here, mostly.
[18:52] <coreycb> zul, ddellav: debhelper is fixed up
[18:52] <zul> coreycb: sweet...
[19:05] <achiang> rbasak: looking for the appropriate forum to chat about the ubuntu/xenial64 vagrant image. seems like there is resistance to changing the default user name to 'vagrant' (from 'ubuntu')
[19:08] <rbasak> achiang: on IRC this is the right channel. Or https://lists.ubuntu.com/mailman/listinfo/Ubuntu-cloud for a mailing list.
[19:09] <rbasak> achiang: it's a trade-off between making the Vagrant image look the same as other Ubuntu cloud images (for transfer from testing to deployment) vs. consistency with other non-Ubuntu vagrant images.
[19:09] <rbasak> There's no single answer but we can only really do one. No sense in flip-flopping between the two, IMHO.
[19:09] <rbasak> Please do present your arguments (the mailing list is probably best) but keep in mind that they may already have been heard.
[19:10] <achiang> i can go search archives
[19:10] <rbasak> I'm not sure there's a previous thread at all on this, only IRC discussion (here or #ubuntu-devel, I don't remember which). But please do start a thread to create an archive trail.
[19:11] <rbasak> irclogs.ubuntu.com if you want to search.
[19:12] <achiang> not much on the mailman archive (i just checked)
[19:32] <ddellav> coreycb awesome
[20:19] <ddellav> coreycb zul i need an update on python-hacking for barbican ci, plz review lp:~ddellav/ubuntu/+source/python-hacking
[20:21] <zul> ddellav: done
[20:22] <ddellav> zul ty
[20:23] <coreycb> ddellav, i think barbican just needed pep8 in BD's
[20:23] <ddellav> coreycb oh when i tried to build it it complained about hacking
[20:23] <ddellav> said it needed 12
[20:24] <coreycb> zul, actually hold off on 12
[20:25] <coreycb> zul, ddellav https://github.com/openstack/requirements/blob/stable/newton/global-requirements.txt#L384
[20:25] <zul> coreycb: yeah 13 is actually needed
[20:25] <coreycb> zul, no
[20:25] <coreycb> zul, oh wait
[20:25] <zul> coreycb: 12 was broken last time i checked
[20:25]  * ddellav is confused
[20:25] <coreycb> zul, go ahead, i was looking at stable/newton.  12 is better than 13.
[20:25] <ddellav> it built ok in xenial and zesty
[20:26] <zul> coreycb:  https://review.openstack.org/#/c/407126/1
[20:26] <zul> coreycb: doh..
[20:26] <zul> coreycb: never mind
[22:44] <Pinkamena_D> Every 3 seconds os so I get a bunch of 'FAILED su for someuser by root' in auth.log
[22:45] <Pinkamena_D> any idea what is causing all this spamming?
[22:46] <Pinkamena_D> the reason is that the accounts were deleted, but I dont know why a deleted account is trying to be accessed every 3 seconds
[22:46] <sypher> Pinkamena_D: Could be trying to start a service, could be a cronjob.
[22:48] <Pinkamena_D> do you know of an efficient way to search for it?
[22:49] <sarnold> is the pid the same each time or different each time?
[22:50] <sarnold> if the pid changes each time, then look to see if it has a 'steady' parent; the execsnoop tool here is the easiest way I can think of to find that https://github.com/brendangregg/perf-tools/blob/master/examples/execsnoop_example.txt