[06:03] <rbasak> nacc: interesting. I guess we should fix the release then :-/
[06:19] <cpaelzer> ThiagoCMC: you can always twek things as needed via http://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot if not natively supported
[06:19] <cpaelzer> ThiagoCMC: there is way more net config to come by the means of https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039464.html
[06:35] <cpaelzer> ThiagoCMC: depending on what you are looking for you might look at http://cloudinit.readthedocs.io/en/latest/topics/datasources.html#no-cloud to inject e/n/i for now?
[06:48] <innercode> Hi, is it possible to copy a LXC1 container to a LXC2 host or is there a way to convert the LXC1 container?
[07:08] <cpaelzer> innercode: you mean lxc1 to lxc2 and not to lxd right?
[07:09] <innercode> cpaelzer: That's it
[07:10] <cpaelzer> innercode: that should be a straight upgrade on the host itself according to e.g. http://lxc-users.linuxcontainers.narkive.com/IsqEwMzt/upgrade-lxc1-to-lxc2-lxd
[07:10] <cpaelzer> innercode: but you were thinking on moving off to a newer host right?
[07:11] <cpaelzer> maybe making a clone of your current host, then do the upgrade on the clone and roll-back to the original in case things went wrong?
[07:11] <innercode> cpaelzer: Yes, but I can upgrade the current host first
[07:11] <cpaelzer> if you can clone you can also use it for various verifications before doing the real switch
[07:12] <cpaelzer> innercode: of course you "can" upgrade the current host first, just IMHO it is always wise to have a fallback strategy
[07:12] <innercode> cpaelzer: I will backup first the current host, upgrade lxc and then move it to the new host
[07:12] <innercode> cpaelzer: Thanks for your help and link
[07:13] <cpaelzer> innercode: that sounds reasonable, only one change at a time and a way to fall back if needed
[07:15] <cpaelzer> jamespage: it seems OVS gos into final apply&clenaup mode several important fixes I was already keeping a list to backport got applied the last two days
[07:15]  * cpaelzer is touching all kind of wood for a great ovs 2.6 release
[07:32] <jamespage> cpaelzer, I'll look at another snapshot in advance of final release
[07:42] <jamespage> ddellav, coreycb: doing designate rc1
[08:56] <jamespage> coreycb, hmm
[08:56] <jamespage> coreycb, ddellav: designate is done
[09:02] <jamespage> coreycb, ddellav: https://review.openstack.org/#/c/372146
[09:02] <jamespage> concerns me
[09:02] <jamespage> ceilometer-api binary is actually broken in rc1 - it worked ok in b3
[09:21] <jamespage> ddellav, coreycb: infact this is why ceilometer is stuck in proposed - its autopkgtests fail due to the broken ceilometer-api binary
[09:43] <cpaelzer> jamespage: we got the first report on dpdk no more able to handle the permission/ownership fix
[09:43] <cpaelzer> jamespage: I created bug 1625542 to track
[09:44] <cpaelzer> jamespage: but I think we wait the few days until you picked up a OVS 2.6 and then add delta as (if) needed
[09:44] <cpaelzer> there still is the small but existing chance that they pick up https://www.mail-archive.com/dev@openvswitch.org/msg69706.html
[09:44] <roberthl> Good morning
[09:46] <roberthl> Last week I was experiencing an issue with apt-get update taking an extremely long time via the AWS eu-west-1 package mirror, especially with a few instances doing it simultaneously
[09:46] <roberthl> I'm doing some tests now and can't seem to replicate the problem I was having, so I wondered if there were any known issues with the package archive last week that have now been resolved?
[12:26] <coreycb> jamespage, wth, dropped ceilometer-api?
[12:26] <coreycb> in RC1
[12:26] <jamespage> coreycb, no its been replaced with an equivalent command that runs wsgi app standalone
[12:26] <jamespage> I've picked the patch and updated the packaging
[12:27] <coreycb> jamespage, ok so nothing major after all?  I'll take a look at what you did.
[12:27] <jamespage> coreycb, no it was a bit of a false alarm
[12:27] <jamespage> the term wsgi script is overloaded - at least three people have asked the same question about the change
[12:28] <coreycb> jamespage, ok
[12:38] <cpaelzer_> rbasak: interesting ... you might be able to explain me why I can assign bug tasks for Xenial on my own, but only nominate for P&T
[12:48] <coreycb> jamespage, any idea what this means? E: Could not find python-mock-services*/python-mock-services_*.dsc  http://10.245.168.2:8080/job/backport_package/1481/console
[12:49] <jamespage> coreycb, hmm
[12:50] <jamespage> coreycb, cloud-archive-backport: Cloud Archive is already up-to-date for python-mock-services.
[12:50] <jamespage> that should stop it trying to build the package?
[12:51] <coreycb> jamespage, oh duh.  yeah I think it usually quits at that point.
[12:51] <jamespage> bom does
[12:51] <jamespage> not sure about individual backports
[12:51] <jamespage> might need a tweak
[12:51] <coreycb> jamespage, ok
[13:10] <rbasak> cpaelzer_: packagesets ACLs are release-specific. So it may be that there are things missing from the ACL for you for older releases.
[13:56] <jamespage> coreycb, we need to discuss dnsmasq in UCA
[13:56] <jamespage> coreycb, we managed not tod that last week
[13:57] <coreycb> jamespage, yeah
[13:57] <coreycb> jamespage, it seemed like a self-contained backport on my quick glance
[13:58] <jamespage> coreycb, is this for ipv6 dnsmasq support
[13:58] <jamespage> ?
[13:59] <coreycb> jamespage, I think all we need is dhcp_release6
[13:59] <coreycb> jamespage, here's the neutron commit: https://review.openstack.org/#/c/301747/
[14:00] <jamespage> coreycb, ok +1
[14:00] <jamespage> lets make sure neutron gets a versioned dep as well please
[14:02] <coreycb> jamespage, would you prefer to attempt an SRU of just the dhcp_release6 code to xenial?  not sure if that would be acceptable since it's not a bug.
[14:02] <jamespage> coreycb, hmm
[14:02] <jamespage> can mitaka use it?
[14:03] <coreycb> jamespage, looks like the neutron code is just in yakkety
[14:03] <coreycb> jamespage, I mean, newton
[14:03] <jamespage> coreycb, add it to the UCA then
[14:03] <jamespage> its a feature so is unlikely to be SRU worthy
[14:04] <coreycb> jamespage, ok
[14:08] <jamespage> coreycb, adding swauth for newton UCA as well
[14:09] <coreycb> jamespage, +1
[14:15] <coreycb> jamespage, dnsmasq backported successfully
[14:15] <coreycb> jamespage, updating neutron d/control
[14:33] <NorskElectric> is it possible to use ubuntu-vm-builder (or the just the underlying vm builder) via cli syntax to use a dedicated NIC? Like direct dev private macvtap?
[14:33] <NorskElectric> or does that have to be done in a template at best?
[14:46] <DesertedWarf> Good morning all
[14:46] <DesertedWarf> (Or evening)
[14:47] <DesertedWarf> Does anyone have a ballpark estimate of how long the Raspberry Pi's Ubuntu version with a server pre-configured take to complete it's first boot?
[14:47] <Voyage> Hi
[14:47] <DesertedWarf> Hey Voyage
[14:47] <Voyage> Can anyone help with this Its a nightmare to bypass this: https://pastebin.mozilla.org/8911617
[14:59] <smoser> Voyage, you dont like being propmted for a passphase ?
[14:59] <smoser> what is the nightmare ?
[15:04] <Voyage> smoser:  how to I login ?
[15:04] <smoser> to what ?
[15:05] <smoser> itis asking you for the pass phrase to your ssh key. i dont know if your ssh key is present in the user that you're trying to get to or not.
[15:05] <Voyage> aws
[15:05] <Voyage> smoser:  I changed computers
[15:05] <Voyage> and used same ssh key
[15:05] <smoser> if you have public keys in the instance you launched, then
[15:05] <smoser> ssh ubuntu@that-ip-address
[15:05] <RoyK> well, obviously the key is protected with a passphrase
[15:06] <smoser> and sshing in as 'root@that-ip-address' will tell you to do that.
[15:07] <Voyage> RoyK:  I never set it. I changed computers and used the same key. On this computer, I get a passphrase prompt that I cant bypass
[15:09] <RoyK> debug1: Authentications that can continue: publickey <-- hm
[15:10] <RoyK> not quite sure what you're doing here
[15:11] <jgrimm> lamont, bug 1611923.  Do you need that back into xenial (and/or trusty) too?  or just enough to fix in yakkety?
[15:13] <lamont> jgrimm: many things are relative...
[15:13] <lamont> jgrimm: we currently monkeypatch the hell out of it, so it doesn't absoltely need to be backported
[15:13] <lamont> OTOH, others might like it
[15:14] <jgrimm> lamont, certainly doable.  i'll put it back to xenial at least then
[15:14] <lamont> jgrimm: so it's really a question of what our ipv6 support story is for xenial
[15:14] <lamont> trusty is dead to me (wrt ipv6)
[15:14] <lamont> too many breakages
[15:15] <jgrimm> lamont, fair enough. and why i was thinking xenial at least would be nice
[15:15] <lamont> yep
[15:15] <jgrimm> thanks sir
[15:15] <lamont> np
[15:17] <ThiagoCMC> cpaelzer_, I was reading that very same doc! Thanks! The problem is that, if I disable the DHCP for a specific subnet, Cloud Init still configured the IP as static!!! But I do not want any setup for the secondarie networks. As a workaroung, I'm doing this on cloud init script: ifdown ens4 ; ifdown ens5 (while ens3 is fine, first).
[15:18] <cpaelzer_> ThiagoCMC: you might ask smoser in #cloud-init for an experts advise
[15:21] <ThiagoCMC> ok, thanks!
[15:21] <NorskElectric> is there a ubuntu kvm or libvirt sub group?
[15:34] <coreycb> frickler, dnsmasq 2.76 and neutron that depens on it are working their way back to the newton cloud archive
[15:34] <coreycb> depends
[15:37] <nacc> smoser: from a usability perspective, do you think it's a usability issue you hit yesterday (passing a non-xgit'd directory results in it starting from teh beginning). I can at least put that in the -h
[15:39] <smoser> nacc, i do think itunawell, i guess it just depends  on who you think is going to run the importer
[15:40] <smoser> if the usd-importer branch is always up to date, its not a big deal.
[15:40] <smoser> if it is out of date, then i would really epxect that a normal user is probably wanting to git clone <that>
[15:40] <smoser> and then 'usd-import'
[15:40] <nacc> smoser: yeah, i didn't optimize for regular users running it -- mostly myself in testing and then eventually the cronjob
[15:40] <nacc> smoser: yeah, but even that won't generally work even w/o xgit
[15:40] <nacc> as you have to have somewhere to pull sources too
[15:41] <nacc> but i'll have a think
[15:42] <smoser> nacc, i guess in my mind your time is better spent making the importer branch always up to date
[15:42] <smoser> then you wont have bothersome users saying "why doesnt it work like a bothersomeo user thinks it should"
[15:44] <smoser> nacc,  a simple 'xgitify' would probably be sufficient too
[15:44] <smoser> dear user, if you want to run the importer your self do:
[15:45] <smoser>  git clone http://.../your-package
[15:45] <smoser>  usd-importer xgitify your-package your-xgit-dir
[15:45] <smoser>  usd-import your-xgit-dir
[15:45] <smoser> where xgitify can basically just 'git clone'
[15:45] <nacc> smoser: yep, that makes sense
[15:46] <nacc> smoser: that's the thing, if you just use the importer (and don't clone), it does work :)
[15:46] <smoser> :)
[15:47] <smoser> thats a good point.
[15:47] <smoser> i was just trying to be too smart
[15:47] <smoser> and re-use what i had
[15:50] <nacc> yep
[15:50] <nacc> the other unfortunate bit i've hit is that git-clone and xgit are incompatible anyways
[15:53] <rbasak> nacc, smoser: if enhancing xgit, it might be an idea to make it work with "git worktree" instead, now that it exists
[15:54] <rbasak> Assuming that's possible
[15:54] <nacc> rbasak: yep, that's my theory
[15:54] <nacc> *thinking
[15:54] <nacc> we shouldn't "need" xgit beyond convenience
[15:54] <nacc> i also wonder if we could put the pull-*-source -d output in .git/junk or something
[15:55] <nacc> rbasak: ubuntu/devel should point to ubuntu/<current-proposed> if it exists and if not, then ubuntu/<current>, correct?
[15:56] <rbasak> As a type of cache? That could work well.
[15:56] <rbasak> nacc: correct
[15:57] <nacc> rbasak: yeah, something like that, i'd need to dig into it -- i was thinking also as a means to not really need xgit itself (as it feels like the primary reason is to keep pulled things out of the working tree
[15:57] <rbasak> nacc: agreed
[15:58] <nacc> rbasak: would then make smoser's git-clone case also 'just work', i think
[16:00] <smoser> rbasak, nacc get it importing everything on cron. and i will be uber happy.  and never bother you again :)
[16:00] <nacc> smoser: :) we're getting very close to that
[16:01] <nacc> i think we've got a method to work around bad changelogs now, which seems to work well. I need to fix isc and then i think those are the two classes of major workarounds that we've had to recode for
[16:22] <coreycb> rockstar, pylxd 2.0.5 is uploaded to xenial and I'll ask arges if he can review it.  and nova-lxd b3 is uploaded to yakkety.
[16:23] <rockstar> coreycb: ta
[16:43] <rbasak> jgrimm: would you like to take bug 1595096?
[16:44] <jgrimm> looking
[16:44] <rbasak> Looks like a cherry-pick from Debian for an SRU is all that is needed, though I haven't confirmed.
[16:45] <jgrimm> rbasak, looks like cpaelzer had done some looking at it
[17:23] <Fira> Hey! Anyone around tried using conjure-up to install openstack in single-machine mode around ?
[17:25] <Fira> It's uh, not quite working out here, conjure-up itself is failing in a failcascade, and the more i get bleeding edge versions the worse it is, culminating at conjure-up just apt-get install 'ing argv0 in a loop.
[17:26] <sarnold> argv0? o_O
[17:26] <Fira> well, i mean the conjure-up's arg
[17:27] <sarnold> ah
[17:27] <Fira> that would be 1 not 0
[17:27] <sarnold> was all for the best though, I hadn't seen ssh-argv0 yet, heh
[17:27] <Fira> my bad
[17:27] <Fira> :P
[17:28] <Fira> so yeah the documentation looks pretty outdated, since the docs still speak of openstack-install which doesn't seem to exist anymore
[17:29] <Fira> tried going through conjure-up but it failed due to invalid LXD image names, so i tried taking the official image and naming it as requested, but it failed later on so i guess that wasn't quite it :P
[17:30] <Fira> tried getting conjure-up bleeding edge, and as i said, it just runs apt-get install in a loop with whatever you give it
[17:30] <Fira> which uh, is quite, err, weird
[17:38] <Fira> oh :) got it to work by beating it sufficiently with removal and reinstalls :p
[17:38] <sarnold> the beatings will continue until morale improves
[17:38] <sarnold> (sorry, I got nothing)
[20:25] <jayjo> I'm trying to figure out why a crontab element isn't firing. I have one that is definitely working with the permissions -rwxrwxr-x and one that is not working with -rwxr-xr-x .. would that be the reason why?
[20:34] <jayjo> is there a way to run a task from the cron user? to see if it works?
[20:36] <JanC> the user is not the only difference
[20:44] <sarnold> jayjo: probably something makes an assumption about a PATH being set differently than it is. that's what it always is. :)
[20:45] <jayjo> is there a way to echo some of those variables from the shell script?
[20:45] <sarnold> /usr/bin/env > /tmp/environment_variables   :)
[20:58] <JanC> PATH or another environment variable, trying to run some tool that expects a TTY, trying to access something with the wrong permissions, expecting a login session, etc.
[21:48] <bjf> docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: flag provided but not defined: -bundle".
[21:48] <bjf> is ^ a known issue?
[21:48] <bjf> this is on a fresh Xenial install