[00:05] <Guest20118> @tavansteenburgh, thanks
[06:11] <kklimonda> when is 2.1.2 being released? launchpad suggests last friday, but there are no packages I can find
[06:42] <kklimonda> zeestrat:  looks like I can't reference variables in other variables? I guess that would be cheating ;)
[07:27] <kjackal> Good morning Juju world!
[08:22] <zeestrat> kklimonda: Yeah, I tried that too ;)
[09:56] <cnf> can you register multiple users on one machine with juju?
[09:57] <cnf> and switch between them?
[09:59] <kjackal> cnf you can register multiple users on the same controller
[10:01] <cnf> kjackal: yes, but can I log in to different users on the same local machine
[10:01] <cnf> using the juju command
[10:01] <cnf> i don't want to be admin all the time
[10:02] <kjackal> cnf: I have never seen that
[10:02] <cnf> hmm
[10:02] <cnf> and no ACL's either, it seems
[10:03] <kjackal> you mean do a "juju ssh myapplication/0" and you get a shell that is not a sudoer user
[10:03] <kjackal> That is an interesting feature. What is the use case you want to serve with this?
[10:05] <cnf> no, i mean juju register
[10:05] <cnf> multiple users
[10:06] <cnf> right now, everything i do with the juju command is as admin
[10:07] <cnf> have to pick up some guests at reception, brb
[10:13] <cnf> back
[10:14] <cnf> kjackal: i basically want to restrict myself when i don't need to be admin
[10:14] <kjackal> cnf: your juju client can be a non-priviliged user
[10:15] <kklimonda> I just had juju fail to bring a couple of containers on two machines, with error cannot start instance for machine "0/lxd/15": unable to setup network: no obvious space for container "0/lxd/15", host machine has spaces: "management", "two-ceph-private", "two-ceph-public"
[10:15] <kklimonda> but that actually worked fine for other units of the same application, and for other containers on the same machine
[10:15] <kklimonda> (I'm testing 2.1.2 from git right now)
[10:16] <cnf> kjackal: right, but do i need to delete the admin credentials?
[10:16] <cnf> or can i swap between them?
[10:17] <kjackal> cnf: what kind of credentials?
[10:26] <cnf> kjackal: the admin user you are authenticated with
[10:27] <cnf> kjackal: now, my juju command is registered as full admin, right?
[10:27] <cnf> i can destroy models, delete users, etc etc
[10:28] <kjackal> you can create a juju user (juju add-user) and then grant permissions (eg juju grant myuser add-model)
[10:28] <cnf> right, i did that
[10:28] <cnf> but when i want to register it, it says i can't because i am already registered
[10:29] <cnf> so is the only way to unregister the admin user, and register the new user
[10:29] <cnf> and when i need admin the other way around?
[10:31] <kjackal> I ahven't tried to register a juju user with a local user that is already registered
[10:31] <kjackal> I guess it is expected for juju to complain
[10:32] <kjackal> can you have a second local user to register with the controller with limited permissions?
[10:32] <cnf> you mean add a new local user?
[10:33] <cnf> that's a lot of extra work for this :P
[10:35] <cnf> maybe i'll set up a docker container or something
[11:32] <hoenir> can anyone recommand me a charm that supports adding storage?
[11:34] <kklimonda> ceph and ceph-osd
[11:44] <tvansteenburgh> hoenir: the postgres charm does
[12:33] <kklimonda> when juju is deploying containers on MAAS, what is responsible for assigning IPs? I have a reservation for IP range, but Juju still deployed LXD containers with IPs from this range
[13:10] <cnf> kklimonda: did you have free ip's?
[13:34] <kklimonda> cnf: I should have 100+ free IPs in that netwokr
[13:34] <kklimonda> (based on quick math and what MAAS tells me)
[13:37] <cnf> k
[13:37] <cnf> i had all ip's in either dynamic or static pool
[14:04] <skayskay> resources question. I have a snap charm and made a bad assumption about resources as optional things. I thought I could remove a resource. The charm is for a public snap, so I want to grab it from the store.
[14:04] <skayskay> but when I want to test a change in a fully deployed environment, I'd like to attach a snap resource
[14:05] <skayskay> that is a bad assumption since I can't remove a resource.
[14:05] <skayskay> so, how do people normally test things in that situation? I'd rather not push a candidate snap if I'm doing something like adding debugging code to get more info, etc etc etc
[14:14] <stub> skayskay: If you are using the snap layer, attaching a 0 byte resource is effectively the same as removing the resource.
[14:15] <stub> skayskay: You should be able to have your edge charms with a snap attached as a resource, and your stable channel charms with no snap or 0 byte resource.
[14:15] <skayskay> stub: thanks, I didn't think of attaching a new zero byte resource. I feel sheepish now.
[14:16] <skayskay> :)
[14:16] <skayskay> (I am using the snap layer)
[14:16] <stub> skayskay: Its a hack, but works until we can drop this resources-are-required nonsense.
[15:24] <Zic> lazyPwr: hey, long time since we didn't talk, I have a question for you (or for marcoceppi too), can I update the nginx-ingress-controller deployed by CDK manually?
[15:24] <Zic> I need this functionality recently merged: https://github.com/kubernetes/ingress/pull/246/commits/5cc5669938108ab7429bc7eee40c18a6ba18150a
[15:25] <lazyPwr> Zic: hey, 1 sec let me see whats in teh link
[15:26] <lazyPwr> Zic: so this looks like k8s golang bin code... do you know if this is landing in the addon container?
[15:26] <lazyPwr> Zic: if so, you should be able to just update the image reference in /etcd/kubernetes/addons/ingress-*.yml
[15:26] <lazyPwr> Zic: however, you might need to set it in the Template dir of the charm, so it doesn't get autogenerated right back out of the template before its re-scheduled
[15:27] <lazyPwr> stub: hey little bit of an update on that btw, i spoke to rick about optional resources @ the last sprint. It's now acknowledged that its a potential issue, but no resolution has been offered as of yet.
[15:28] <Zic> lazyPwr: the last message is what I feared :( can I do this simply without breaking future updates of the charm ?
[15:28] <lazyPwr> skayskay: also, one workflow tip that mbruzek and I have done is resource-revision 0 is always a zero byte resource (by convention, we touch and push) so you can always re-publish with a zero byte resource simply.
[15:29] <Zic> lazyPwr: or do you know if this PR is already in the image used by the kubernetes charm in 1.5.3? I'm always on 1.5.2 currently
[15:29] <lazyPwr> Zic: certainly if you patch the template and toggle ingress=true it will get your update. on teh next charm-upgrade it will ovewrite the changes to that template and you should be back in alignment with our upstream releases
[15:29] <lazyPwr> Zic: i'm not positive on if its in the 1.5.3 release, it depends on when it was cut and added.
[15:30] <Zic> yeah, I saw this PR have 26 days, but I don't know if it was merged for the 1.5.3 release
[15:30] <lazyPwr> i'm going to err and say it wasn't
[15:30] <Zic> https://github.com/kubernetes/ingress/pull/246 <= thr PR associated
[15:31] <lazyPwr> Zic: the trouble here is the issue wasn't attached to a release https://github.com/kubernetes/ingress/issues/180
[15:31] <lazyPwr> so its hard to discern when it was actually pulled into a release or if its just sitting in trunk
[15:31] <lazyPwr> Zic: i would probably ping one of the authors of this pr and ask when it was/will-be released.
[15:35] <Zic> lazyPwr: thanks, also, just seeing the tag "Coverage 46%" in the Issue, seems that it's sure that it's not released so :(
[15:36] <Zic> I will try to ping the author anyway
[15:39] <mbruzek> Zic: I can get you a resource if you can examine the binary files to see if the fix is in there.
[15:40] <mbruzek> Zic: Alternately if you check out the tag branch "v1.5.3"  You could check for the code in there
[15:42] <Zic> mbruzek: good idea, it seems to be this one: https://github.com/kubernetes/ingress/releases/tag/nginx-0.9.0-beta.2
[15:42] <Zic> I will check
[15:44] <Zic> ok so
[15:44] <Zic> 1.5.2 and 1.5.3 of Kubernetes in CDK's charm both use 0.8.3 of this nginx-controller
[15:45] <Zic> the proxy-set-headers I need appeared in 0.9.0-beta2
[15:45] <Zic> (but it's beta as you can see...)
[15:45] <Zic> but a later stable version is 0.9.2
[15:46] <Zic> are you planning to switch to 0.9.2 in next release so? :D
[15:49] <Zic> https://github.com/kubernetes/ingress/releases <= oh, I do a mistake, it's not Nginx which is in 0.9.2, it's GCE ingress...
[15:49] <Zic> the latest version of nginx-ingress-controller is still 0.9.0-beta.2, which contains the feature I wanted
[15:55] <Zic> lazyPwr / marcoceppi : for waiting, as I really need to customize nginx header for the launch of this customer, can I simply "kubectl edit rc nginx-ingress-controller", swap the image to "gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.2" instead of "gcr.io/google_containers/nginx-ingress-controller:0.8.3" (which CDK deployed) ?
[15:55] <Zic> as I understand, nex-upgrade will overwrite this change
[15:56] <Zic> but I just need to recall myself to re-put it, no?
[15:56] <Zic> I don't feel confident in hacking the CDK template and deploy it for a production cluster :/
[16:07] <marcoceppi> Zic: good question, Cynerva ryebot ^ ?
[16:08] <Cynerva> catching up, gimme a minute :)
[16:09] <Zic> :)
[16:11] <Zic> haha, I just realize that I confused marcoceppi & mbruzek for my earlier highlight-ing of CDK's maintainers :)
[16:11] <Zic> sorry :]
[16:13] <Cynerva> Zic: it looks like kubernetes-worker won't override the ingress RC until the charm is upgraded
[16:15] <Zic> and do I need to rollback to the original version of CDK kubernetes-worker charm before the next upgrade ?
[16:15] <Cynerva> Zic: so I think as a temporary workaround that should work. but i'm not 100% sure
[16:17] <Cynerva> Zic: hmm good question. all the charm does is `kubectl apply -f ingress-replication-controller.yaml` so i would think you won't have to roll it back before charm upgrade
[16:22] <Zic> ok thanks
[16:22] <Zic> I think I will upgrade from 1.5.2 to 1.5.3 before testing this
[16:22] <Zic> planned for tomorrow, I will let you know if it works :)
[16:23] <Zic> (the ingress upgrade part, I'm confident for 1.5.3 upgrade part)
[16:24] <Cynerva> cool :D
[16:24]  * Zic fix lazyPwr's eyes for the second part of his message
[16:24] <Zic> :}
[16:25] <lazyPwr> O_o
[16:25] <lazyPwr> o_O
[16:26]  * Zic begins to search "juju rollback command"
[16:26] <Zic> xD
[16:26] <lazyPwr> wait for snaps my friend, it'll make your roll forward/backwords life a bit easier.
[16:26] <lazyPwr> Zic: have you seen the etcd 3.x migration bits using snaps?
[16:27] <Zic> nop, the last time we talked about this, it was not publicly released
[16:27] <Zic> s/publicly/officially/
[16:27] <Zic> does it now?
[16:28] <stormmore> I still have the the thought about using snaps on switches / routers to load the maas and juju controllers onto them instead of servers
[16:33] <lazyPwr> stormmore: you're not alone in that thought :)
[16:34] <lazyPwr> stormmore: however storage on a switch is going to be hairy at best... you'll likely want to run your rack controller on a unit with some storage
[16:34] <lazyPwr> Zic: its pending a merge against layer-etcd, i have it published in my namespace though
[16:34] <Zic> oh, I can test it in the lab so :)
[16:34] <lazyPwr> Zic: it supports moving between channels, and if you dont attach external storage (read: ebs/gce volumes) it'll version your data
[16:35] <lazyPwr> so say you upgrade to 3.0/stable channel and things get funky, NO PROBLEM!
[16:35] <Zic> currently, we have deployed our 2nd CDK cluster, full-AWS this time
[16:35] <lazyPwr> revert back to 2.3/stable
[16:35] <lazyPwr> and it'll reload your data from the version of the snap that was installed using 2.3, you may incur some minor data loss, but this is expected with a rollback no?
[16:35] <Zic> and I convert the LXD labs into a real lab
[16:35] <lazyPwr> yeah?
[16:35] <stormmore> lazyPwr, yeah I realize that but storage is only a problem when you are a boot strapping the data center. once the servers are up, the db, etc. can be moved into the cluster
[16:35] <lazyPwr> nice man :) You're getting your hands all kinds of dirty with cdk
[16:36] <Zic> lazyPwr: yeah, I'm just using NFS & ISCSI volume
[16:37] <stormmore> lazyPwr, that just leaves the core services running on the switches / routers, i.e. pxe, etc. from maas and the juju controller agent
[16:37] <Zic> (for the first CDK cluster actually)
[16:37] <lazyPwr> Zic: i was talking to cholcombe and it appears that gluster+heketi is going to be problematic moving forward
[16:37] <lazyPwr> some mailing list drama popped up about this :/
[16:37] <Zic> for the second one, we're using AWS-EBS
[16:37] <lazyPwr> i read into it a bit, and they are wanting to not support existing glusterfs deployments, which baffles me
[16:38] <cholcombe> i find it odd also
[16:38] <Zic> (the first-one is the one I gave you the Architecture Plan, hybrid between baremetal servers / on-premise VMs & EC2@AWS)
[16:38] <Zic> (the second-one is full-AWS)
[16:38] <lazyPwr> cholcombe: <3 can we send them a gentle reminder to not stab their users in the face with a hot branding iron?
[16:38] <cholcombe> i tried on the irc channel and they shot me down
[16:38] <lazyPwr> because $reasons again?
[16:39] <cholcombe> yeah because deploying onto an existing server that they didn't setup is hard
[16:39] <cholcombe> i get it but at least try
[16:39] <lazyPwr> so what if we dont support existing clusters and instead make it a charm deployed glusterfs endpoint the only one we support in cdk?
[16:39] <lazyPwr> or am i missing something
[16:40] <lazyPwr> i dont think its out of the question to have a storage admin provision some bricks and enlist them in a gluster charm deployment, then xmodel relate them to cdk workers
[16:40] <magicaltrout> lazyPwr: http://pastebin.com/E4ZrqzNN
[16:40] <magicaltrout> http://pastebin.com/ewUELFwT
[16:40] <magicaltrout> got any suggestions?
[16:40] <cholcombe> lazyPwr: suggesting we just take over for heketi?
[16:41] <lazyPwr> magicaltrout: how did you deploy this?
[16:41] <magicaltrout> maual
[16:41] <magicaltrout> manual
[16:41] <Zic> lazyPwr: basic question, does the "juju upgradecharm <app>" have a special order recommended? because between the insights.ubuntu.com news and https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/, it's not the same
[16:41] <lazyPwr> Zic: follow the kubernetes.io docs
[16:41] <Zic> upgrade-charm*
[16:41] <magicaltrout> just walked through the bundle
[16:41] <Zic> ok :)
[16:41] <lazyPwr> we've kept that up to date
[16:41] <lazyPwr> magicaltrout: are these local copies of the charms?
[16:41] <magicaltrout> nope
[16:41] <magicaltrout> i've got 2 running workers and 2 stalled
[16:42] <lazyPwr> magicaltrout: well at the end of teh day it appears the resources didn't make it out of the charm store. You'll want to fetch the resources from jujucharms.com/u/containers/kubernetes-worker and juju attach them
[16:42] <Zic> At this time rolling back etcd is unsupported. / At this time rolling back Kubernetes is unsupported. <= you already prepare this section about snap :D
[16:42] <lazyPwr> Zic: not until it lands as GA
[16:42] <lazyPwr> but yeah, i'll be adding subsections there about rollbacks using the snaps and what to expect
[16:43] <Zic> the only snap-in-production that I used today is Rocketchat
[16:43] <lazyPwr> Zic: i'm expected to have this fully landed and r2g by the time we cut the 1.6.x release
[16:43] <lazyPwr> i've got some really good early tests in, i'm hacking on fixing the whole "i killed the master and my cluster just pooped the bed" bug
[16:43] <Zic> :}
[16:43] <lazyPwr> which is really obnoxious if you're not paying attention to what you're doing... juju remove-unit etcd-master, and suddenly things brick
[16:43] <lazyPwr> *sadtrombone.wav*
[16:43] <Zic> I need to switch to multimaster again some day also
[16:43] <Zic> I'm also on monomaster in production for now
[16:44] <Zic> the lab is in multimaster with your patch for token
[16:44] <lazyPwr> Zic: we have incoming work rn to hack in place an haproxy load balancer instead of that nginx based one
[16:44] <lazyPwr> my colleague is hacking on that rn
[16:44] <lazyPwr> magicaltrout: lmk if that doesn't resolve it, and i'm going to point a finger at a juju bug that i hvaen't found yet, but it seems like it just bailed during grabbing the resource, which is unfortunate :( i've seen this once before but it was back in the 2.0 beta days
[16:45] <lazyPwr> magicaltrout: actually, are you still using a beta or did you finally upgrade to GA?
[16:47] <magicaltrout> thanks lazyPwr testing
[16:48] <magicaltrout> this is a new deploy for the  JPL folks so nothing beta here :)
[16:48]  * lazyPwr snaps
[16:48] <magicaltrout> 2.0.2
[16:48] <lazyPwr> i was kind of hoping you would say beta-18 again, so i could easily point to why it happened
[16:49] <magicaltrout> it might have been connectivity betwen the openstack units and the charm store, but it would be nice for juju to recover if that were actually =the case
[16:59] <ybaumy> huhu juju
[17:00] <ybaumy> can somebody tell me how to filter hosts to use for a cloud by zones in maas
[17:00] <ybaumy> i tried adding zone = foobar to the yaml file for the cloud
[17:00] <ybaumy> but that didnt work
[17:17] <andrew-ii> If a MAAS node is released while it is a Juju controller... can I get that controller removed? It seems hung on `juju destroy-controller someController`
[17:19] <ybaumy> have you tried unregister
[17:19] <andrew-ii> Not yet... one moment
[17:19] <andrew-ii> oh
[17:20] <andrew-ii> Well, that was fast.
[17:20] <ybaumy> did it work
[17:20] <andrew-ii> Thanks! I think I can rebootstrap it now
[17:20] <ybaumy> yes you can
[17:20] <ybaumy> had a similar problem and that helped me too
[17:21] <ybaumy> do you happen to know how to filter maas nodes for a cloud by zones?
[17:22] <ybaumy> i need to know if that is possible
[17:22] <andrew-ii> oh man, I am barely getting this thing to download images from ubuntu's cloud repo
[17:22] <andrew-ii> I vaguely remember that... one sec
[17:23] <andrew-ii> Nuts, that's next on my list of things to try
[17:23] <andrew-ii> That's what works with the HA zones, right?
[17:24] <ybaumy> well i want to create nodes for customers and add them to zones. then create a cloud for that particular zone
[17:24] <Zic> lazyPwr: I have a lot of apt updates also on the 1.5.2 cluster I'm planning to upgrade tomorrow, do you advice me to firstly run juju upgrade-charp <app> *before* apt update/upgrade ?
[17:24] <Zic> (to bypass some problem like the time apt upgrade etcd without the charms :/)
[17:25] <andrew-ii> ybaumy: I was going about that upsidedown and was going to use Openstack to partition customers. But you make an interesting point; if I had my old pile of blade servers that sounds pretty good
[17:25] <magicaltrout> okay i think we can safely say Juju doesn't like deploying stuff to low power vms
[17:26] <ybaumy> andrew-ii: a customer should be able to create his own cloud by a webinterface with vmware and maas. that the target.
[17:27] <andrew-ii> I don't have vmware, but my customers really only need containerization, so I probably have a different use case
[17:28] <ybaumy> andrew-ii: true. thats different. i have thought about that too. and will look into it once i am able to do that ..
[17:28] <ybaumy> im creating POC's for my company
[17:29] <ybaumy> so its just try and play at the moment
[17:29] <andrew-ii> ybaumy: I get the feeling it's jumping right into the deep end to go straight-up containerization. But I only have a few machines for maas, so I can't afford to dedicate to each customer. But man, that sounds like a nice idea.
[17:30] <andrew-ii> ybaumy: same here; if I can get the cloud bootstrapped and somehow lock it down _and_ get it to be usable, then it'll be a nice playground.
[17:31] <ybaumy> andrew-ii: we have vsphere vrealize scripted to create the vm templates and distribute them across the esx farms. then i use maas to commission them and juju to create the cloud
[17:31] <ybaumy> but now i need something to filter those vm's
[17:32] <andrew-ii> ybaumy: slick. It does sound like zones are exactly what you'd want (if I understand why they were added).
[17:33] <ybaumy> andrew-ii: yes its really working now. its one last piece to put it together and close the POC
[17:33] <andrew-ii> Best I can figure is the `juju deploy someCharm --to zone=maasZone1`, but I bet you're not really looking to use the --to command
[17:33] <ybaumy> andrew-ii: does that work?
[17:33] <ybaumy> i have to try
[17:34] <andrew-ii> (For my setup I'm using maas tags to filter machines, sadly, so I may be a terrible example)
[17:35] <andrew-ii> ybaumy: note that I just sorta stole that command and assumed it worked! It may be aws specific (or maybe maas emulates that too) - sorry if it fails utterly
[17:36] <ybaumy> andrew-ii: great this seems to work. at least it used now for bootstraping the foobar zone i specified
[17:37] <andrew-ii> ybaumy: holy mackeral, whelp, I'm more optimistic now (I actually thought it'd fail...).
[17:37] <ybaumy> maybe its luck but i will try that a few times
[17:38] <andrew-ii> That's the spirit!
[17:56] <lazyPwr> magicaltrout: yeah it tends to yield a pretty crummy experience when you starve the unit resources
[17:57] <lazyPwr> Zic: probably do the upgrade charm then run the apt update/upgrades
[17:57] <lazyPwr> Zic: keep your change set to the least viable change in order to validate things are functional after making the change
[18:01] <ybaumy> andrew-ii: sadly this --to zone= seems to be ignored. i bootstrapt it then i wanted to enable-ha --to zone=foobar and one node was created in default one in foobar
[18:01] <magicaltrout> indeed lazyPwr i was hoping the units would at least start though :)
[18:01] <ybaumy> so i need something else
[18:01] <andrew-ii> ybaumy: sorry - I was afraid it wouldn't work with maas yet
[18:02] <ybaumy> andrew-ii: thanks anyway .. better die trying then havent tried at all
[18:02] <andrew-ii> Might be worth checking if a newer version manages to use it (though I think I got that command from 2.1.1)
[18:03] <ybaumy> im using devel
[18:03] <andrew-ii> ouch, nevermind then
[18:03] <andrew-ii> Did you try `--constraints zone=foobar` ?
[18:03] <ybaumy> hmm no :D
[18:03] <ybaumy> will do
[18:03] <ybaumy> hehe
[18:05] <andrew-ii> I have some real goofy machines to play with, and some are only good at certain things (like one's basically a bank of hard drives), so I use `--constraits "tags=storage"` for that one
[18:05] <ybaumy> what is your goal what are you trying to accomplish?
[18:06] <andrew-ii> Though just in case, make sure when boostrapping a controller you use `--boostrap-constraints` instead (otherwise the controller sets ALL nodes to use that constraint)
[18:06] <ybaumy> k
[18:06] <andrew-ii> I have a hodgepodge of random servers to play with, and I need a test rig that can simulate a network; plus host some in-house tools that will get replaced often
[18:07] <andrew-ii> Literally random machines collected off craigslist for a few months
[18:07] <ybaumy> is that you homelab?
[18:07] <ybaumy> your
[18:08] <andrew-ii> It's my equipment, but it's hosted in the office for it's fancy 220V line, space, and dedicated network connection
[18:10] <ybaumy> i started also with some few blades but now the project has management attention
[18:11] <ybaumy> so i got everything i requested
[18:11] <ybaumy> that neat
[18:12] <andrew-ii> haha always the best when people with checkbooks take notice
[18:14] <ybaumy> true
[18:28] <ybaumy>  juju deploy --to zone=test cs:bundle/openstack-base-49
[18:28] <ybaumy> ERROR Flags provided but not supported when deploying a bundle: --to.
[18:28] <ybaumy> also something that should work
[18:29] <andrew-ii> hmmm, yeah, that's what I thought to try
[18:30] <ybaumy> i will try single charms to see how that goes
[18:36] <ybaumy> nope ignored as well
[18:37] <ybaumy> juju deploy --to zone=test -n4 cs:ubuntu-10
[18:37] <ybaumy> creates random machines in all zones
[18:48] <ybaumy> i will try tags
[18:49] <andrew-ii> That should work, though it's a pain to tag all the machines
[18:49] <ybaumy> yep
[18:50] <ybaumy> seems like that you cannot assign tags to all machines in a zone
[18:50] <andrew-ii> Nuts. Need to do something complicated like a script to assign them all? (Overkill maybe?)
[18:52] <ybaumy> you are right. i will have to script it but thats not the problem. it would be nice if something like that would be supported out of the box
[18:59] <andrew-ii> I think there is a goal for it, it's just not added in yet?
[19:00] <ybaumy> we have to ask the devs
[19:00] <ybaumy> i signed up on the mailing list maybe i get an answer there
[19:02] <andrew-ii> ybaumy: I don't know too much about navigating launchpad, but check https://launchpad.net/juju to see if that feature is slated for addition
[19:08] <ybaumy> juju deploy --constraints tags=test  cs:bundle/openstack-base-49
[19:08] <ybaumy> ERROR Flags provided but not supported when deploying a bundle: --constraints.
[19:08] <ybaumy> ;)
[19:09] <zeestrat> ybaumy: 99% sure --constraints/--to don't work with bundles
[19:10] <zeestrat> ybaumy: same with --config
[19:10] <ybaumy> zeestrat: thats too bad. shouldnt they?
[19:10] <zeestrat> --config is on the roadmap
[19:11] <ybaumy> single charms work now with contraints with tags thats nice so i have to script the whole bundle setup as single charms
[19:11] <zeestrat> constraints and to are (or at least can be) defined in the bundle so the idea is that you set them there
[19:12] <ybaumy> ok so i can generate a yaml file with --contraints?
[19:13] <ybaumy> the format with all the : at the end is really hard to script
[19:13] <ybaumy> hmm
[19:13] <ybaumy> i will try and see
[19:13] <zeestrat> have you checked out https://jujucharms.com/docs/stable/charms-bundles ?
[19:16] <ybaumy> before not. but i can just generate it one time and then use perl or sed to change the tags=test to tags=somethingelse
[19:17] <ybaumy> nice
[19:17] <ybaumy> :)
[19:17] <ybaumy> thanks zeestrat
[19:17] <ybaumy> that will do
[19:18] <zeestrat> ybaumy: glad to help :) There are no examples of using variables in the docs at the moment, but here's a openstack HA bundle you can look at: https://launchpadlibrarian.net/298175262/bundle.yaml
[19:20] <ybaumy> no need for variables. i just sed -i 's/tags=test/tags=somethingsomethign/g' in the file for each process before i start juju deploy bundle.yaml
[19:21] <ybaumy> and thanks for the HA link
[19:38] <ybaumy> will try tomorow. now football
[19:48] <stormmore> lazyPwr, trying to put together my budget ask, is there any conference, etc. that would be good for me to try and attend? any suggestions?
[19:50] <magicaltrout> all of them \o
[19:53] <ybaumy> zeestrat andrew-ii adding constraints to the bundle works. thanks for helping me.
[19:55] <stormmore> magicaltrout, yeah I wish I could get the budget for that :-/ I have to be more realistic than that and target kubernetes, juju, maas related ones as well as the automotive ones since that is the industry we are actually in
[19:56] <magicaltrout> hmm wtaf, my deployment is green but the ingress proxy just gives me a 504 on  absolutely everything =/
[19:56] <magicaltrout> what country you in stormmore ?
[19:57] <hatch> can a 'requires' relation be related to two 'provides' at the same time?
[19:57] <lazyPwr> stormmore: well, the charmer summit is great if you want facetime with us to hack on projects :)
[19:57] <hatch> ex) kibana1 to elasticsearch1 and kibana1 to elasticsearch2
[19:58] <lazyPwr> stormmore: however if you want k8s focus, you're more than likely going ot have success attending kubecon's but our presence there isn't very big. Mostly what I would call guerilla community ops, where we roam hallway tracks and find people to engage with
[19:58] <lazyPwr> hatch: depends on how the charm is coded to use those relationships, but yeah.
[19:58] <hatch> lazyPwr ok so there is no Juju restriction to that effect?
[19:59] <lazyPwr> interfaces as the abstraction, you should be able to interface with both es clusters, but its up to the app to implement that, and up to the author to correctly implement the data coming from the interfaces.
[19:59] <lazyPwr> afaik, nope
[19:59] <hatch> the GUI explicitly prohibits that interaction
[19:59] <lazyPwr> why?
[19:59] <lazyPwr> seems....arbitrary
[19:59] <hatch> my guess, a limitation in Juju 1?
[19:59] <lazyPwr> kidna like not letting me unrelate a subordinate :P
[19:59] <lazyPwr> yeah, you're probably right
[19:59] <hatch> or from PyJuju even?
[19:59] <lazyPwr> juju1 had fun quirks like that
[19:59] <hatch> yeah
[19:59] <hatch> ok thanks
[20:00]  * hatch creates a model on jujucharms.com to test for sure
[20:00] <stormmore> lazyPwr, yeah I would love to go to a "charmer summit" but I don't see another one setup yet
[20:01] <lazyPwr> stormmore: i dont think we'll get it scheduled until mid spring.  jcastro might have more details as to when the next summit will be however
[20:02] <jcastro> we haven't really talked about it
[20:02] <magicaltrout> somewhere hot
[20:05] <stormmore> and of course finance want to know like yesterday :-/
[20:11] <stormmore> lazyPwr, fyi I think the better question is whether you guys want to suffer the pain of meeting me ;-)
[20:12] <magicaltrout> any idea how to debug a 504 on the ingress router, no kubernetes dashboard etc lazyPwr ?
[20:22] <stormmore> @jcastro, I will look forward to hearing about when you do have those discussions
[20:35] <jcastro> \o/
[21:04] <skayskay> hey, trying to remove a unit that is in an error state for the config-changed hook doesn't work, as far as I can tell
[21:05] <skayskay> there's ab ug about a failing upgrade state that already exists, maybe this is related
[21:07] <skayskay> oh, this may be something else. lp:1671476 is about destroying a model
[21:09] <skayskay> I'm unable to remove a unit or application
[21:10] <magicaltrout> you need to mark the unit resolved first skayskay
[21:10] <magicaltrout> juju resolved unit/0 --no-retry
[21:11] <skayskay> magicaltrout: thanks! that's it. I didn't know about that --no-retry option. handy
[21:18] <firl> hello all; anyone have an example bundle of openstack using network spaces ?
[21:22] <magicaltrout> oooh shiugar
[21:22] <magicaltrout> sooo lazyPwr i'm not convinced that each k8s worker should be on its own flannel subnet, am I right?
[21:25] <stormmore> this is really odd, having it hang during fetching juju agent
[21:26] <stormmore> I suspect a network issue but I can't log into the instance using the key that I added to the MaaS user! hmmmm
[21:28] <lazyPwr> magicaltrout: why not?
[21:29] <magicaltrout> okay in that case i'm just wrong :)
[21:29] <magicaltrout> i assumed they had to share a subnet
[21:30]  * magicaltrout returns to wondering why they aren't working
[21:30] <stormmore> magicaltrout, no each worker needs it's own subnet to manage it's containers with
[21:30] <magicaltrout> fair enough
[21:30] <magicaltrout> i'm spinning one up on aws for comparison, but i assumed they'd be on the same subnet. Obviously not :)
[21:33] <stormmore> anyone have an idea where to look when I can enlist and commission nodes in maas but I can't bootstrap juju?
[21:42] <rick_h> stormmore: juju bootstrap --debug and then check the maas logs during bootstrap.
[21:44] <stormmore> rick_h, thanks, I keep forgetting about that. building a "clean" environment to try again
[21:49] <zeestrat> firl: The #openstack-charm people have a bundle in their dev repo: https://github.com/openstack-charmers/openstack-bundles/blob/master/development/openstack-base-spaces/bundle.yaml
[21:49] <firl> zeestrat thanks!
[21:50] <zeestrat> firl: There's a OpenStack HA bundle laying around using networks defined in config (not the new juju network bindings): https://launchpadlibrarian.net/298175262/bundle.yaml
[21:50] <firl> interesting
[21:51] <firl> I am trying to figure out the best way to do the networking I need to, and I just finished configuring all of the physical net, so trying to make sure I have MAAS setup the way I Want to deploy the bundle
[21:52] <firl> it seems like “spaces” is where the bundles are going
[21:52] <firl> charms rather
[21:53] <zeestrat> firl: I recommend checking out #openstack-charm channel as well. I'm working on a HA bundle with spaces if you're interested. Send me a pm and I can get back to you
[21:53] <firl> I will jump on that channel too
[21:54] <firl> hrmm no one in that one.
[21:54] <zeestrat> firl: sorry, #openstack-charms
[21:54] <firl> perfect
[21:55] <zeestrat> there are also some docs on https://docs.openstack.org/developer/charm-guide/ with release notes for the latest stable releases of the openstack charms
[21:56] <zeestrat> I'm off for now, but pm me and I can get back to you
[21:56] <firl> thanks
[22:07] <stormmore> rick_h, http://paste.ubuntu.com/24179043/ shows the output from --debug, I am not seeing anything obvious in the regiond.log, rackd.log or the instance messages log to show why it isn't bootstrapping :-/
[22:10] <stormmore> rick_h, but this time I was able to log in, apparently I am missing a default gateway
[22:11] <stormmore> rick_h, which seem odd considering it did a apt update / apt dist-upgrade
[22:22] <stormmore> one problem down, no telling how many to go :-/
[22:29] <stormmore> gotta love weird networking issues


[00:01] <charlie-tca> I don't think that is quite ready yet
[01:33] <hajour> good night all.and happy new year for if i don't see you before
[01:34] <charlie-tca> Good night and you have a very good New Year, too


[13:07] <pmatulis> morning
[13:31] <Icey> howdy
[13:42] <Icey> jamespage do you  know if I can get juju + aws to automatically attach ebs drives for ceph to use as a block device?
[13:42] <jamespage> Icey, probably
[13:42] <jamespage> Icey, andrew is the right person to ask
[13:44] <marcoceppi> Icey: you'll want to use the experimental storage stuff axw has been working on
[13:51] <lathiat> Hi Folks.. can anyone help me with what's happening here? Hit this twice today in a setup that was previously working fine.. destroyed and re-created my environment (MAAS), deploying first service juju-gui to the same machine i bootstrapped onto (which is libvirt) .. stuck on "filter.go:137 tomb: dying -> leadership failure: leadership manager stopped" - there are some earlier errors about i/o errors/losing communication - full log; http://lathi.at/fil
[13:52] <lathiat> not entirely sure which of the errors is more related to the actual issue and what that is
[13:59] <marcoceppi> lathiat: didn't get teh full log link, could you supply it again?
[13:59] <lathiat> full log; http://lathi.at/files/juju-leadership.txt
[14:00] <lathiat> i am guessing the real issue is the EOF stuff much earlier but i'm a bit lost with it from there
[14:00] <lathiat> maybe related https://bugs.launchpad.net/juju-core/+bug/1493123
[14:00] <mup> Bug #1493123: Upgrade in progress reported, but panic happening behind scenes <landscape> <landscape-release-29> <upgrade-juju> <juju-core:Fix Released by ericsnowcurrently>
[14:00] <mup> <juju-core 1.24:Fix Released by ericsnowcurrently> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1493123>
[14:01] <marcoceppi> lathiat: that's odd, I've not seen that
[14:01] <lathiat> thing is i ran into this issue just before, but iw as also getting an error about machine 7 not existing, that i had previously force destroyed, assumed i had corrupted something.. decided to try and start over and hitting the same thing now.
[16:34] <bdx> beisner, lazyPower: deploying trusty-kilo-ha with next charms eliminated 99% percent of the problems I was experiencing :-)
[16:35] <beisner> hi bdx good to hear - we're feverishly working on the release process this wk.
[16:36] <bdx> beisner, lazyPower: Good to hear! There is one remaining issue I can't seem to get around that still exists out of the issues I was experiencing when deploying kilo-trusty-ha with trunk charms
[16:36] <bdx> that is, I can't query the keystone vip api endpoint....
[16:36] <beisner> bdx  grain of salt:  next charms not recommended for production as they are generally in active dev
[16:37] <beisner> bdx well that would be problematic ;-)
[16:37] <bdx> beisner: totally.
[16:37] <beisner> bdx, enabling keystone ssl by chance?
[16:38] <bdx> beisner: I'm totally down, what reasoning have you, if any?
[16:38] <bdx> besides security
[16:38] <bdx> ha
[16:39] <beisner> bdx, just wondering as the client connections get trickier.  if not specifically needed, it's less hassle (and less secure of course) to use the default non-ssl.
[16:39] <beisner> so nvm me
[16:39] <bdx> totally, ok
[16:40] <bdx> you have never experienced this?
[16:40] <beisner> bdx, gotta run.  if you'd like input, i'd start with inspecting your sanitized novarc / openstackrc file or env vars + keystone --debug catalog  + keystone --debug token-get.
[16:40] <beisner> that info might give insight
[16:41] <beisner> + juju stat --format tabular   :)
[16:42] <beisner> also might do a sanity check that the services are all running, and that the ips are in place in each unit's nic.
[16:42] <beisner> o/
[16:42] <bdx> beisner: charmconf.yaml <- http://paste.ubuntu.com/12886818/
[16:42] <bdx> juju status --format tabular <- http://paste.ubuntu.com/12886819/
[16:44] <bdx> im not worried about the dashboard relation, as I am currently troubleshooting it as it depends on the keystone api as well
[16:46] <bdx> which is why I think its giving me grief and status shows "Incomplete relations: identity "
[16:47] <bdx> beisner: oooh just saw ^^
[16:47] <bdx> nice, thanks
[16:47] <bdx> later
[16:55] <beisner> bdx yeah, that's the new workload status.  gives a lot better feedback as to what is going on throughout the deployment steps, and through managing the thing longer term.
[17:28] <jog> mgz, I made updates to https://code.launchpad.net/~jog/juju-ci-tools/centos_deploy_stack/+merge/275135
[17:31] <mgz> jog: landit
[17:31] <jog> mgz, thanks
[18:44] <bdx> jamespage, marcoceppi, gnuoy, beisner, lazyPower: After toying with failing openha deploys, most of the issues I was experiencing have been resolved. I have found the primary issue(s) that still exist in next charms concerning ha deploys....the issue is that service charms do not get keystone vip in their .conf files, also keystone endpoints get created for non vip service endpoints
[18:44] <bdx> ^^ resolved in next branches*
[18:46] <bdx> After manually making the needed modifications to the endpoints in the keystone.endpoints table and correcting each of the charms configs to include the keystone vip endpoint, I have a working ha stack
[18:46] <bdx> !
[18:46] <bdx> yea!
[18:48] <thedac> bdx: none of the service charms get the keystone vip? Or is there a specific charm? Also do you have the bundle you are deploying from so I can see?
[18:48] <bdx> I'll file bugs on these issues, It would be nice to see these things fixed in the 15.10 release so as those of us looking for HA stacks have a somewhat stable answere, instead of heading into the 15.10 release with HA borked still
[18:48] <thedac> bdx: fantastic. Let me know when those bugs are filed
[18:48] <bdx> thedac: juju status --format tabular <- http://paste.ubuntu.com/12887639/
[18:49] <bdx> thedac: deployer.yaml <- http://paste.ubuntu.com/12887642/
[18:49] <thedac> thanks
[18:50] <bdx> thedac: thats correct, none of the service charms get the keystone vip
[18:50] <bdx> also keystone.endpoints has all non vip entries
[18:51] <thedac> ok, I'll take a look today
[18:51] <bdx> thedac: awesome! thanks!
[19:05] <bdx> thedac, openstack-charmers, core: https://bugs.launchpad.net/charms/+source/keystone/+bug/1508575
[19:05] <mup> Bug #1508575: Keystone DB gets all non vip endpoints + openstack service conf files get keystone non vip <ha> <keystone> <openstack> <server> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1508575>
[19:05] <bdx> boom
[19:12] <thedac> bdx: thanks
[19:13] <bdx> thedac: NP, thanks for looking into this!
[19:29] <jamespage> hello bdx
[19:29] <jamespage> bdx, we're at bit late for 15.10 release for any more bugs today (as its tomorrow)
[19:30] <jamespage> bdx, I am keen to understand the problems you're having - as thedac and other have noted, we've run our own internal QA cloud for 1.5 years in a HA deployment through three openstack series upgrades
[19:45] <jamespage> bdx, I added a comment to that bug - really need to see the output of "sudo crm status" on any of the haclustered services
[20:10] <bdx> jamespage: heres the output of "sudo crm status" on a keystone node -> http://paste.ubuntu.com/12888152/
[20:11] <jamespage> bdx, ok - that looks fine
[20:11]  * jamespage thinks
[20:12] <jamespage> bdx, could you do the following and pastebint the output
[20:12] <bdx> of course :-)
[20:13] <jamespage> bdx, juju run --unit keystone/0 "relation-ids ha"
[20:13] <jamespage> and then
[20:13] <bdx> jamespage, ha:81
[20:13] <jamespage> juju run --unit keystone/0 "relation-get -r <id from previous command> - keystone-hacluster/0"
[20:14] <jamespage> bdx, for that next one you'll need to use ha:81 and the unit name for the paired hacluster unit
[20:14] <bdx> clustered: "yes"
[20:14] <bdx> private-address: <IP_ADDRESS>
[20:15] <jamespage> bdx, well again that looks ok - next link...
[20:15] <jamespage> clustered = yes is the good bit there
[20:16] <bdx> jamespage: let me note, a) this is a repeated issue across 15x deploys of trunk and next, and b) on every deploy, the service clusters form without error for each service
[20:17] <jamespage> bdx, yeah - just puzzled as to why thats not propagating out correctly
[20:18] <jamespage> bdx, the clustered=true triggers a re-run of relation hooks where things need to be changed, and the code that determines endpoint resolution should detect the same thing and start using the VIP's
[20:19] <bdx> jamespage: ok, good, how does this happen "the code that determines endpoint resolution should detect the same thing and start using the VIP" --> the vip isnt the same as private-address: <IP_ADDRESS>
[20:19] <jamespage> bdx, lets see what keystone is propagating
[20:20] <jamespage> bdx, there is an endpoint resolver in charmhelpers that figures that out consistently taking into account cluster status and configuration
[20:20] <bdx> I have modified all of my endpoints and .conf files to resolve the issue, and also as a proof of concept
[20:20] <jamespage> suffice to say with split networks, its gets quite hairy, but your deployment is not doring that
[20:20] <jamespage> bdx, you should categorically not need todo that
[20:21] <bdx> jamespage: where is the "endpoint resolver in charmhelpers"? if you don't mind?
[20:22] <jamespage> bdx, http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/openstack/ip.py#L106
[20:23] <jamespage> bdx, can you also do: juju run --unit keystone/1 'relation-ids identity-service'
[20:23] <jamespage> bdx, the log data from /var/log/juju/unit-keystone-1.log would also be useful
[20:23] <bdx> identity-service:41
[20:23] <bdx> identity-service:45
[20:23] <bdx> identity-service:57
[20:23] <bdx> identity-service:59
[20:23] <bdx> identity-service:70
[20:23] <bdx> identity-service:89
[20:23] <jamespage> bdx, ok and now
[20:24] <jamespage>  juju run --unit keystone/1 'relation-get -r identity-service:89 - keystone/1'
[20:24] <bdx> jamespage: /var/log/juju/unit-keystone-4.log <- http://paste.ubuntu.com/12888244/
[20:25] <bdx> private-address: <IP_ADDRESS>
[20:27] <jamespage> bdx, that's very light
[20:27] <jamespage> bdx, ok can I see this (need to know which unit is leader)
[20:27] <bdx> jamespage: I don't see how resolve_address could return the vip .....
[20:27] <jamespage> bdx, L132 should be in path
[20:29] <jamespage> bdx, juju run --service keystone 'is-leader'
[20:29] <bdx> jamespage: and also, keep in mind that I have destroyed two keystone units and re-add-units ....in case you are wonder why the log is light, and also the extra ids for past units...also I don't have debug, or verbose logging on....grrr ...my bad
[20:29] <bdx> jamespage: if not net_addr: will never execute ....
[20:29] <jamespage> bdx, oh the relation data was light, not the log
[20:29] <bdx> oh
[20:30] <jamespage> bdx, it will - if config is unset, None gets returned
[20:31] <jamespage> so not net_addr will equal True in that case
[20:31] <bdx> jamespage: what config must be unsetH?
[20:32] <jamespage> bdx, os-XXX-network
[20:32] <bdx> unset*
[20:32] <bdx> omg
[20:32] <jamespage> it has no default
[20:32] <bdx> jesus
[20:33] <jamespage> where XXX in public, internal, admin
[20:34] <bdx> this is totally my bad... I should of read into that weeks ago
[20:36] <bdx> jamespage: MAJOR revision to any and all docs concerning HA deploy to include ^^
[20:37] <bdx> I should of gotten to the bottom of this earlier on my own, by investigating, but ...thank god
[20:38] <bdx> jamespage: thanks for your help getting to the bottom of this
[20:39] <jamespage> bdx, have we?
[20:39] <jamespage> bdx, got to the bottom of this?
[20:39] <jamespage> just eating dinner as well biab
[20:39] <bdx> jamsepage: yes! You must leave the os-xxx-network unset for vip endpoints to get set anywhere!!!!
[20:40] <bdx> jamespage, openstack-charmers: that is the missing piece! you all have been keeping secretssssss!
[20:41] <bdx> not really though....I could of found it:-/
[20:41] <bdx> :-)
[20:49] <beisner> woot!
[20:50] <bdx> jamespage, beisner: thanks for your help concerning this
[20:51] <beisner> actually thedac is just uses aliases:  jamespage and beisner
[20:51] <beisner> jusssst kidding.
[20:51] <thedac> heh
[20:51] <bdx> thedac: ^^
[20:51] <thedac> bdx: fwiw, I just ran a test over lunch that proves this point. Services do get keystone's vip
[20:52] <jamespage> bdx, erm that's not quite true
[20:52] <bdx> jamespage: which?
[20:53] <jamespage> bdx, you can use vips with configurations that also use os-XXX-network
[20:53] <jamespage> configuration options
[20:53] <jamespage> bdx, vip can be a single VIP or a space delimited list, if you are splitting endpoints across networks
[20:53] <bdx> jamespage: concerning the resolve_address function, I don't see how that could happen....?
[20:53] <jamespage> bdx, L134
[20:54] <jamespage> for vip in vips:
[20:54] <jamespage>     check if in network for endpoint type
[20:54] <jamespage>     if it is, use this one
[20:54] <jamespage> basically
[20:54] <bdx> oooh I see
[20:54] <jamespage> bdx, looking at http://paste.ubuntu.com/12887642/
[20:55] <jamespage> I can't see that you are setting is os-XXX-network config options for the keystone charm
[20:56] <bdx> jamespage: shoot...your right....
[20:58] <bdx> jamespage: I must disclose ....initially 1 of the keystone endpoints was set to the vip in the database on my last deploy  .... the keystone admin endpoint of http://<IP_ADDRESS>:35357/v2.0
[20:59] <bdx> jamespage: every other endpoint was not set to the vip including the other keystone endpoints
[21:06] <jamespage> bdx, the charm would have blindley configured that anyway
[21:09] <jamespage> bdx, did you figure out which is the lead keystone unit? I really want to see the juju log file fromthat one
[21:15] <bdx> jamespage: here is the keystone log from the leader: http://paste.ubuntu.com/12888588/
[21:18] <bdx> unit-keystone-1.log*
[21:39] <bdx> jamespage, beisner, thedac: I propose I redeploy, and this time I will give the services 30mins to settle and ensure clusters form before I add any relations.... this could rule out any possibility of timing issues with clusters not being fully formed when relations are made.
[21:40] <bdx> thedac: Did you use juju-deployer in a once through to deploy all services and relations sequentially in your test?
[21:40] <thedac> bdx: yes
[21:41] <thedac> and I am testing one of our ha oneshot bundles right now. I'll let you know
[21:41] <bdx> thedac: sweeet!
[21:45] <bdx> thedac: are you deploying ha services on containers?
[21:47] <bdx> to containers*
[21:47] <thedac> let me confirm.
[21:48] <thedac> ah, no actually, so that may not be a valid test
[21:48] <thedac> I'll test with your bundle.
[21:50] <bdx> thedac: nice
[22:12] <bdx> thedac, jamespage, beisner: So...I haven't set the param 'vip_iface', hence I am assuming the default of 'eth0'. Seeing as I am deploying these services to containers, the primary interface is not 'eth0', but 'juju-br0'. This is a redherring to me, and looks like the ha-relation-joined hook could be affected.
[22:13] <bdx> http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/keystone/next/view/head:/hooks/keystone_hooks.py#L515
[22:15] <thedac>   vip_iface:
[22:15] <thedac>     type: string
[22:15] <thedac>     default: eth0
[22:15] <thedac>     description: |
[22:15] <thedac>       Default network interface to use for HA vip when it cannot be
[22:15] <thedac>       automatically determined.
[22:15] <thedac> so you may be on to something there
[22:19] <bdx> thedac, jamespage, beisner: WAAALAAA
[22:19] <bdx> thedac, jamespage, beisner: >>> import netifaces
[22:19] <bdx> >>> netifaces.interfaces()
[22:19] <bdx> ['lo', 'eth0', 'lxcbr0']YGT
[22:20] <bdx> no juju-br0!!!!!
[22:21] <bdx> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/network/ip.py#L156
[22:23] <thedac> bdx: so you might test with vip_iface set to juju-br0
[22:26] <bdx> thedac: entirely....what I'm pointing out....is that netifaces.interfaces() does not recognize the juju-br0!
[22:27] <bdx> which would implicate the call to netifaces.interfaces() in network/ip.py as the culprit
[22:31] <thedac> http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/keystone/next/view/head:/hooks/keystone_hooks.py#L515  get_iface_for_address *OR* vip_iface. I think setting vip_iface and vip_cider will fix this.
[22:36] <bdx> thedac: as example if "get_one()" returns "one" and "get_two()" returns "two"
[22:37] <bdx> thedac: and you have "one_or_two = (get_one() or get_two())"
[22:37] <bdx> thedac: one_or_two == "one"
[22:38] <bdx> thedac: so even if the 'vip_iface' is set it would still not return the correct iface
[22:38] <thedac> sorry, I am trying desperatly to get something up and running to actually validate this. But if get_iface_for_address does not retrun an address because juju-br0 is not in netifaces.interfaces() then the or would work. If it does return you are right.
[22:41] <bdx> thedac: entirely
[22:43] <thedac> Looking at lines 145-183 looks like it will return None http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/network/ip.py#L156
[23:08] <bdx> thedac: totally
[23:08] <bdx> thedac: I'm redeploying with 'vip_iface' configured to juju-br0
[23:08] <thedac> great, fyi, you may also need vip_cidr set


[04:06] <pavlushka> o/ all
[08:34] <elacheche> o/
[09:54] <Nuage> 'sup
[09:58] <elacheche> hey
[12:40] <Na3iL> \o
[12:51] <elacheche> o/
[16:09] <volkov> Hello !
[16:10] <elacheche> Hey volkov
[16:10] <elacheche> Na3iL: Check this out https://youtu.be/OSGv2VnC0go
[16:10] <elacheche> Na3iL: I just refactored > 20 lines to 4 because of that video x)
[16:11] <elacheche> volkov: welcome to ubuntu-tn, how can we help you :)
[16:12] <volkov> any idea how to avoid special characters without "eating the whole line" in the gnome terminal ?
[16:13] <volkov> during an ssh session
[16:14] <elacheche> volkov: an example please? I don't use Gnome Terminal so I don't getthe question :/
[16:16] <volkov> http://n40i.imgup.net/Screenshot225c.png
[16:17] <volkov> see the first line ? i got deleted since there are some special characters
[16:17] <volkov> it* got
[16:18] <elacheche> just a sec
[16:20] <elacheche> Did you tried an other terminal? or just try to change unicode in gnome-tterm
[16:20] <volkov> yeah, no luck
[16:21] <volkov> tried to setup the locale variable in distant machine, that didn't help too
[16:21] <volkov> variables* to utf-8
[16:24] <elacheche> Emm.. Try Terminator or Konsole..
[16:24] <elacheche> What script is that in the terminal?  Perfect! :D I use konsole (I hate KDE) becasue it read arabic..
[16:30] <elacheche> reads*
[16:30] <volkov> cool, no lines eating
[16:30] <volkov> he's not hungry
[16:30] <volkov> hehe
[16:31] <elacheche> :)
[16:31] <volkov> thanks anis, see you @SFD
[16:31] <elacheche> No need to launch a server then :)
[16:32] <volkov> have a good day
[16:32] <volkov> yeah, of course
[16:32] <volkov> it's solved
[16:32] <elacheche> Welcome :) But who are you x)
[16:32] <volkov> volkovmqx
[16:32] <elacheche> don't use sub nicknames :p
[16:32] <elacheche> See you @ISSAT :)
[16:32] <volkov> i was just trying irssi lol
[16:39] <Na3iL> Hello elacheche
[16:39] <Na3iL> That looks very interesting
[16:41] <elacheche> yep :)
[16:44] <Na3iL> I see an IRSSI user <3
[16:47] <elacheche> I like weechat :p
[19:08] <Nuage> 'sup
[19:12] <pavlushka> Hello Nuage :)


[04:41] <biker> philipballew: o/
[04:41] <biker> hey philipballew when im in mexico city maybe we can hang out
[04:42] <philipballew> biker, Assuming you get here before nexy Monday
[04:42] <philipballew> I fly out Monday to the creat city of Sacramento.
[04:42] <philipballew> *great
[04:43] <biker> philipballew: oo wow :O i thought you were going to be there for like 2 more weeks
[04:43] <philipballew> no.........
[04:43] <philipballew> Gotta o home and do things
[04:43] <philipballew> Though I am happy to be home on July 4th.
[04:43] <philipballew> America the beautiful my friend.
[04:44] <philipballew> biker, I am gonna see you at oscon
[04:44] <philipballew> if nothing else you can drive up.
[04:45] <biker> philipballew: im still not sure about going to oscon
[04:45] <biker> fedora hasnt said anything
[04:45] <philipballew> I'd let you go
[04:45] <biker> philipballew: hehe cool! (:
[04:45] <philipballew> Just call Robbin till she says yes
[04:45] <biker> yeah,., actually i think she will say yes
[04:46] <biker> the thing is that y arrive from mexico city on july 21
[04:46] <biker> so i would be arriving here on that sunday,., and if i go to oscon on the next monday i would be flying out to portland xD
[04:49] <philipballew> biker, fly back to San Diego and just go from there
[04:49] <philipballew> pay your way to san diego and have them pay for like a southwest flight or something
[04:51] <philipballew> I assume you are flying tj to Mexico city though. Cheaper and stuff.
[04:51] <biker> oo yeah philipballew ,., that wont be the problem (: the problem is that i think the dates are too tight :P
[04:52] <philipballew> biker, If there is a will, there is a way
[04:54] <biker> philipballew: well yeah (: the thing is with my parents :P because im almost leaving for long time,., they want me to stay here with them most of the time before going to europe
[04:54] <philipballew> biker, good point. I am with my parents this summer. I will tell them I am going to Portland the night before.
[04:54] <philipballew> I am a bad person...
[04:54] <philipballew> well maybe a few days.
[04:55] <biker> philipballew: lol xD
[04:55] <biker> philipballew: you are so mean :P
[04:55] <biker> better save the world
[04:55] <philipballew> then again, portland from sac is only an hour flight, so I am not worried they will care.
[04:56] <philipballew> biker, have you ever had mole?
[04:57] <biker> philipballew: yeap :p
[04:57] <philipballew> biker, It's something that takes some getting used to I think.
[04:59] <biker> philipballew: did you like it? :p
[04:59] <biker> actually im not a fan of it :p
[05:00] <philipballew> biker, I did not.
[05:00] <philipballew> I like Baja/San digo Mexican food more then here. More tacos, Less chili if you know what I mean.
[05:00] <biker> hahaha :p
[05:01] <philipballew> biker, You need to grab a California Burrito and tel me what you think.
[05:01] <biker> philipballew: where can i get one of those? xD
[05:01] <philipballew> Off Rosecrans is the best place imo.
[05:01] <biker> sweet
[05:01] <biker> ill go there
[05:02] <philipballew> biker, http://www.yelp.com/biz/adalbertos-mexican-food-san-diego-2
[05:02] <philipballew> Its a carne burrito with French Fries.
[05:02] <biker> nice :)
[05:03] <biker> philipballew: so you already have your ticket for oscon?
[05:03] <philipballew> biker, not yet. The money should come to me in a week or so for me to buy my plane ticket.
[05:03] <philipballew> Hopefully before i leave df
[05:04] <philipballew> Dont wanna have to worry about it back home
[05:04] <biker> philipballew: i mean the entry ticket
[05:05] <philipballew> biker, Yeah, someone is signing me up.
[05:06] <biker> nice (:
[05:06] <biker> philipballew: have you gone to oscon before?
[05:07] <philipballew> biker, yes.


[15:00] <barry> hi everyone.  meeting time!  for the next 45 minutes (or hopefully a lot less) we'll be conducting the ameu reviewers meeting for launchpad
[15:00] <barry> who's here today?
[15:00] <BjornT> me
[15:01] <mwhudson> me
[15:01] <barry> bac statik ddaa ping
[15:01] <statik> me
[15:01] <ddaa> me
[15:02] <statik> bac is in another time zone this week
[15:02] <barry> statik: right
[15:03] <barry> i expect we're a small group today given the holidays
[15:03] <barry> which is fine.  let's keep this short! :)
[15:03] <barry> == Agenda ==
[15:03] <barry>  * Roll call
[15:03] <barry>  * Next meeting
[15:03] <barry>  * Action items
[15:03] <barry>  * Queue status
[15:03] <barry>  * Mentoring update
[15:03] <barry>  * Review process changes
[15:03] <barry>    * Tool update
[15:03] <barry> So...
[15:03] <barry>  * Next meeting
[15:03] <barry> i propose we skip the next two weeks, so the next meeting would be 9-Jan
[15:03] <barry> any objections?
[15:04] <barry> 5...4...3...2...1
[15:04] <barry> :)
[15:04] <mwhudson> i'll be off by then
[15:04] <bac> me
[15:04] <ddaa> IIRC I'll be away then
[15:04] <mwhudson> so this is my last ameu reviewer meeting, sniff sniff
[15:04] <barry> mwhudson: noooooo!!!!
[15:04] <barry> mwhudson: good luck w/the move!  i'll see you at the asiapac meetings :)
[15:05] <mwhudson> barry: thanks :)
[15:05] <barry>  * Action items
[15:05] <barry> Actions from the last meeting:
[15:05] <barry>  * barry to edit him some wikis about on-call procedures
[15:05] <barry>  * intellectronica to work on a cover letter template
[15:05]  * barry sucks
[15:05]  * barry needs to edit him some wikis
[15:05] <barry> i don't believe intellectronica has written a cover letter template.  do you know mwhudson ?
[15:06] <mwhudson> barry: not to my knowledge
[15:06] <barry> okay, no biggie
[15:06] <barry>  * Queue status
[15:06] <barry> the general queue is clear
[15:08] <barry> 5 branches over sla, but not sure that the needs-replys look too bad
[15:08] <barry> (given the holidays and such)
[15:08] <barry> any comment on the queue?
[15:08] <barry> 5...4...3...2...1
[15:08] <barry>  * Mentoring update
[15:09] <barry> probably not much to say here, although i would like to invite a few new reviewers in january
[15:09] <mwhudson> the state ages on https://devpad.canonical.com/~jamesh/pending-reviews/ are insane, surely
[15:09] <barry> mwhudson: certainly for those first few!
[15:10] <mwhudson> the fix for 121363 claims to be older than the bug :)
[15:10] <barry> lol
[15:10]  * barry wonders who stole guido's time machine keys?
[15:10] <mwhudson> new recruits in january: good idea
[15:11]  * barry thinks about who mwhudson will mentor
[15:11] <barry>  * Review process changes
[15:11] <barry>    * Tool update
[15:12] <gmb> me (sorry barry)
[15:12] <barry> gmb: no worries
[15:12] <mwhudson> i made a couple of changes to the lpreview plugin, sent mail to the list
[15:12] <mwhudson> would still like more feedback
[15:12] <barry> mwhudson: btw, this seems like a great success, thanks!
[15:13] <flacoste> mwhudson: sorry, didn't have one branch cut in a week to test it :/
[15:13] <mwhudson> flacoste: no worries :)
[15:13] <barry> gmb: how's the server side going?
[15:13] <gmb> barry: Alas, with this cycle being so hectic I haven't done much work on it these last two weeks.
[15:13] <gmb> I'm planning to have a big push tomorrow and Friday assuming that nothing breaks bugs-wise.
[15:14] <barry> gmb: awesome
[15:14] <gmb> Hopefully we'll have something working to tie in with the client early in the next cycle.
[15:14] <barry> cool, then we can kill PendingReviews?
[15:14] <flacoste> wonderful!!!
[15:14] <gmb> Kill it dead.
[15:15] <flacoste> let's send it to the Torture Garden first
[15:15]  * gmb adopts the look of someone with whom it is suddenly nothing to do.
[15:15] <barry> we will have a party and dance over its rotting corpse
[15:16] <barry> well, i'm done for today.  anybody else have anything?
[15:16] <barry> i guess that's a sign
[15:16] <barry> MEETING ENDS
[15:16] <gmb> :)
[15:16] <mwhudson> thanks barry
[15:16] <barry> thanks everyone, have a great holiday!
[15:17] <gmb> You too barry.
[15:17] <barry> gmb: thanks!


[02:20] <thomi> I'm confused: Can I install a hook by placing it somewhere in the branch's .bzr folder?
[02:21] <thomi> in some places in the docs it says hooks need to be installed via ~/.bazaar/plugins, and in other places it seems to suggest tat you may be able to install the hook into the branch/repo directly
[03:00] <lifeless> thomi: you cannot install them in the branch/repo
[03:00] <thomi> :(
[03:00] <lifeless> thomi: it would be a huge security hole to run arbitrary code in something you clone; we permit /config/ but not /install/ there.
[03:00] <lifeless> thomi: if you want a plugin active for just one repo, the plugin should consult config in that repo.
[03:01] <lifeless> as in, branch.get_config() and drill in from there.
[03:03] <thomi> lifeless: I want to make peopel contributing to a particular project unable to commit code unless pep8 passes - it sounds like I can't do that without them having to install the plugin manually
[03:03] <thomi> I guess I can do it at package build time instead.
[03:03]  * thomi is feeling draconian today
[03:04] <lifeless> you could put the check in your test suite
[03:06] <thomi> lifeless: yup, but I'd still need to trust the developers to actually run the tests :-/
[03:13] <lifeless> thomi: ...
[03:13] <lifeless> thomi: your CI system should reject their merges before you see them, no?
[03:15] <thomi> Yeah, I'll implement the check at the CI level
[19:46] <dlpenguinlover> Hello, I'm having some trouble with a bazaar repo i'm trying to get working. I'm trying to install a launchpad instance on a virtual Ubuntu Server, however while i'm downloading a repo to install Launchpad, bazaar is erroring out saying the repo is corrupt. I do not want to redownload 400+ mbs of data, is there any way to "fix" the repo?
[19:59] <mathrick> dlpenguinlover: I'm not exactly sure what you ended up with, but if you have a bzr branch in an accessible state, you can bzr check it
[20:00] <mathrick> it will do so some sanity checks and tell you if/what issues there are
[20:04] <dlpenguinlover> "No working tree found at specified location."
[20:07] <mathrick> dlpenguinlover: bzr check --repo and possibly --branch
[20:10] <dlpenguinlover> mathrick: $ bzr check --repo --> Checking repository at 'file:///home/david/launchpad/lp-brakches/'. ----
[20:11] <mathrick> yes
[20:11] <mathrick> it will take time
[20:11] <dlpenguinlover> checked repository file:///home/david/launchpad/lp-branches/ format RepositoryFormat2a() -----> 0 revisions 0 file-ids
[20:11] <mathrick> uh
[20:12] <dlpenguinlover> $ bzr check --branch -------> No branch found at specified location.
[20:12] <mathrick> then it hasn't actually downloaded anything it seems
[20:12] <mathrick> dlpenguinlover: what does "du -hsc file:///home/david/launchpad/lp-branches/" say?
[20:12] <mathrick> err
[20:12] <mathrick> without file://
[20:13] <dlpenguinlover> 237M   /home/david/launchpad/lp-branches/       237M total
[20:14] <mathrick> well, not sure how to help you with that
[20:14] <mathrick> but it seems to be broken completely
[20:14] <mathrick> dlpenguinlover: how exactly did it error out in the first place, and is it consistent?
[20:16] <dlpenguinlover> mathrick: well, the launchpad installer (called rocketfuel-setup) was the one executing the bzr commands, but this is what it outputted. "bzr: error: No WorkingTree exists for "file:///home/david/launchpad/lp-branches/devel/.bzr/checkout"/ ERROR: Your trunk branch in /home/david/launchpad/lp-branches/devel is corrupt. Please delete /home/david/launchpad/lp-branches/devel and run rocketfuel-setup again."
[20:17] <mathrick> and did you do that?
[20:17] <dlpenguinlover> Yes, and it gives the same error message.
[20:20] <mathrick> dlpenguinlover: aight, so you have sub-branches under that dir
[20:20] <mathrick> what does bzr info file:///home/david/launchpad/lp-branches/devel give you?
[20:30] <jelmer> hi mathrick
[20:30] <jelmer> mathrick: there is also "co:" which behaves similarly to "colo:"
[20:43] <mathrick> jelmer: oh, I couldn't find that mentioned anywhere
[20:44] <jelmer> mathrick: it's undocumented - don't use development-colo, as it is unfinished
[20:44] <jelmer> (hence the "development-" bit :-)
[20:44] <mathrick> jelmer: I know, but it kinda beats having mysterious path errors when cloning colocated branches across OS
[20:47] <jelmer> mathrick: okay, up to you :) Just be wary of bugs
[20:47] <mathrick> I am!
[20:48] <mathrick> jelmer: in fact I ran into a couple where various things get horribly confused when I ask them to compare colocated branches
[20:48] <mathrick> diff says no changes, missing doesn't even understand what I'm asking it to do, etc.
[20:50] <jelmer> mathrick: please file bugs and tag them "colocated"
[20:50] <mathrick> OK


[10:31] <Postremus> Hey
[10:32] <Postremus> My app "UniTTT-Gui" is in Pending review state since 1 Month and 3 weeks.
[10:32] <Postremus> Can someone look after this?
[10:35] <commandoline> Postremus: I'm not canonical, but I'm not sure if they'll notice your request during the weekend. If not, it might be worth trying posting again somewhere next week.
[10:43] <Postremus> ok.
[10:43] <Postremus> thanks


[00:00] <rick_h> hml: hi, I just wanted to ping because I'm attempting to rain on a parade I guess.
[00:00] <hml> rick_h: :-(
[00:00] <rick_h> hml: and wanted to make sure my comment was coherent and make myself available if there were any questions/etc but please don't land https://github.com/juju/juju/pull/7449
[00:01] <hml> rick_h: okay - i’ll give it a look - we wanted to get something out there for feedback - expected input - you were on my list to ping.
[00:01] <rick_h> hml: k, I think the intent is <3 but the way the command is put together is a bad precedent imo
[00:05] <hml> rick_h: sounds like a chat is a good way to go.  do you have some time now? or tomorrow?
[00:08] <rick_h> hml: yes I can now
[00:08] <rick_h> Let me head my headphones
[00:09] <rick_h> hml: https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1 when you want
[01:39] <axw> wallyworld: do you know where I can find peer-xplod? jam's charm says unauthorized for me
[01:39] <axw> wallyworld: ISTR you used it recently
[01:39] <wallyworld> axw: yeah, i copied the source locally
[01:41] <wallyworld> axw: i go tthe source from juju acceptance tests
[01:41] <wallyworld> there's a copy of peer-xplod in there that is up to date
[01:42] <axw> wallyworld: cool, thanks
[04:31] <wallyworld> menn0: not sure how busy you are - it's ok if you won't get a chance to look at my recent cmr pr today - i'll bug someone else tomorrow. just need to know so that i can plan next steps
[04:38] <menn0> wallyworld: i'm in calls and usual household crazy period at the moment so am unlikely to be able to review today
[04:38] <menn0> wallyworld: I could do first thing tomorrow though
[04:38] <wallyworld> np, all good
[04:38] <wallyworld> i'll branch off that branch and continue work
[04:38] <menn0> wallyworld: email me with the link if you want me to take a look
[04:38] <wallyworld> will do ta
[04:38] <wallyworld> https://github.com/juju/juju/pull/7504
[04:39] <wallyworld> i asked you because we discussed a bit yesterday
[04:39] <wallyworld> the new controller details collection
[04:39] <menn0> wallyworld: cool cool
[04:39] <menn0> jam: i'm likely to be a bit late to the standup. have to pick up a child.
[04:39] <jam> menn0: understood
[05:13] <axw> wallyworld jam: I've just added some data to https://github.com/juju/juju/pull/7502#issuecomment-308411294, going for a ride - I'll land when I get back if you're happy
[05:14] <wallyworld> ok
[05:14] <wallyworld> looking
[07:10] <mup> Bug #1697175 changed: juju 2.1.2 trusty node put into recovery mode <juju-core:New> <https://launchpad.net/bugs/1697175>
[07:13] <mup> Bug #1697175 opened: juju 2.1.2 trusty node put into recovery mode <juju-core:New> <https://launchpad.net/bugs/1697175>
[07:19] <mup> Bug #1697175 changed: juju 2.1.2 trusty node put into recovery mode <juju-core:New> <https://launchpad.net/bugs/1697175>
[14:03] <rogpeppe> in case anyone's around, here's a PR that provides a drop-in replacement for context.WithDeadline that uses mockable clocks: https://github.com/juju/utils/pull/282
[14:09] <tvansteenburgh> thumper: wallyworld: can either of you clarify what, if any, logging changes were made in 2.2? i noticed yesterday, using a 2.2 client, that i was not getting charm logging by default like i used to. is that expected? if it is, we really need to announce that and explain how to turn it back on, because w/o those logs it's much harder to debug charm problems
[14:10] <tvansteenburgh> this was on a model that i created on an aws jaas controller
[16:58] <rogpeppe> this PR makes api.Open time out more reliably: https://github.com/juju/juju/pull/7507
[21:27] <anastasiamac> axw: any objections? https://github.com/juju/juju/pull/7508
[23:02] <menn0> wallyworld, axw: do you happen to know the prometheus collection interval?
[23:02] <menn0> typically
[23:02] <wallyworld_> menn0: 15s i think by default
[23:02] <wallyworld_> menn0: it depends on the yaml config
[23:02] <menn0> ok
[23:03] <wallyworld_> prometheus will poll juju
[23:03] <menn0> wallyworld_: b/c the state metrics collector is written in a fairly inefficient way
[23:03] <menn0> every poll it calls ForModel for every model
[23:03] <menn0> that's going to hurt
[23:04] <wallyworld_> yeah
[23:04] <wallyworld_> menn0: we have a todo to fix that, maybe it's a mental todo
[23:06] <menn0> wallyworld_: ok cool
[23:06] <menn0> wallyworld_: I'm going through where ForModel is used, looking into problems axino is seeing
[23:07] <menn0> I've found one bad and unnecessary use in the allwatcher
[23:07] <menn0> easy to fix too so i'll do that today
[23:08] <wallyworld_> menn0: yeah, there's no reason ti use for model anymore - state pool should be it. we just haven't updated evertything yet. we've been doing as a driveby
[23:08] <wallyworld_> as we find things
[23:10] <menn0> wallyworld_: the reason i'm looking is that axino is seeing query storms on txns.log
[23:11] <menn0> wallyworld_: this is when the txn watcher resyncs
[23:11] <menn0> he's seeing 300 at a time
[23:11] <menn0> there shouldn't be that many watcher instances
[23:12] <menn0> possible cause is lots of new State creation for some reason
[23:12] <menn0> hence me looking at ForModel calls
[23:13] <menn0> wallyworld_: I also have an idea for getting rid of all the txn watchers so there's just one
[23:13] <menn0> wallyworld_: without major code churn (I think)
[23:13] <menn0> wallyworld_: I'd like to chat about that later
[23:13] <menn0> wallyworld_: does your PR still need review?
[23:14] <wallyworld_> menn0: yeah it does :-)
[23:14] <wallyworld_> menn0: axw is also looking at txn watchers, so let's chat for sure
[23:40] <axw> anastasiamac: I fear that exposing that charm method will lead to misuse; it's just a convenience. maybe you can show how you would use it?
[23:43] <axw> wallyworld_: can you please take a look at https://github.com/juju/juju/pull/7505 when you have a few minutes?
[23:43] <wallyworld_> sure
[23:44] <axw> menn0: I'd love to know how you plan to have just one txn watcher. I spent some time on it, it got messy... but I was going for a more drastic refactor too
[23:46] <wallyworld_> menn0: standup?
[23:59] <axw> menn0: btw I started looking at using StatePool for the statemetrics code yesterday, happy to continue if you have other things you'd rather do


[01:28] <rick_h_> evening
[04:06] <greg-g> cmaloney: well, you shouldn't be browsing slashdot.org anyways
[10:43] <wolfger> greg-g: why the slashdot hate?
[12:33] <jcastro> greg-g: dude greg
[12:33] <jcastro> dude greg
[12:33] <jcastro> https://twitter.com/NeilShubin/status/636875524632150016/photo/1
[12:33] <jcastro> this reminded me of you
[12:57] <cmaloney> morning
[12:58] <cmaloney> greg-g: Funny enough it was just me trying to remember sites that I thought would be up
[12:59] <cmaloney> jcastro: That's um... morbid? :)
[12:59] <jcastro> http://www.yankeeairmuseum.org/airshow/performers/
[12:59] <jcastro> so I just found out the blue angels are in town
[13:00] <cmaloney> That's cool
[13:00] <cmaloney> Found out firsthand from them flying into Willow Run? :)
[13:00] <jcastro> no last year though I was driving
[13:00] <jcastro> and an F16 buzzed I-94
[13:00] <jcastro> and I vowed to never miss a show if I'm going to live by here
[13:00] <cmaloney> Awesome
[13:01] <cmaloney> That is one thing I miss about living in Belleville: having impromptu aircraft flying overhead
[13:01] <cmaloney> There's nothing quite like having a bomber fly over your apartment
[13:01] <cmaloney> Enough to put the fear of God into anyone, let alone someone who is on the business-end of thos bombs.
[13:02] <jcastro> A real B-29 is what I want to see
[14:08] <cmaloney> I'm back on Twitter.
[14:11] <brousch> I thought I felt a rumble. I assumed it was just indigestion.
[14:18] <cmaloney> Heh
[14:42] <greg-g> jcastro: except, you know, that's wrong :)
[14:42] <greg-g> wolfger: is there /. love?
[14:43] <jcastro> 35 seems high
[14:43] <greg-g> its low
[14:43]  * greg-g is looking for the articles
[14:44] <jcastro> http://www.pnas.org/content/108/4/1267.abstract
[14:44] <jcastro> someone linked to that
[14:44] <jcastro> greg-g: are you paleo for real? I was just guessing/trolling
[14:45] <greg-g> no
[14:45] <greg-g> I just had two donut holes for breakfast
[14:45] <greg-g> :P
[14:45] <jrwren> that isn't paleo
[14:45] <jrwren> its also not much food :)
[14:45] <greg-g> Hotel "breakfast" option
[14:45] <jrwren> ugh.
[14:45] <greg-g> there will be more food, and real food, at the office this morning
[14:46] <greg-g> I just want to drink some free coffee first :)
[14:46] <jrwren> hotel & office. Where are you at?
[14:46] <greg-g> SF
[14:46] <greg-g> :)
[14:46] <cmaloney> Tim Hortons is totally Paleo
[14:46] <cmaloney> Timbits FTW
[14:46] <jrwren> greg-g: why at hotel?  oh man, greg-g just woke with his mistress... not cool greg-g. you are married.
[14:46] <rick_h_> lol
[14:46] <rick_h_> greg-g: the playa
[14:47]  * rick_h_ is having a hard time seeing it
[14:47] <greg-g> so, I've been here 3 days (Tue/Wed/Thur), Wed/Thur are an "offsite" (but onsite) for engineering managers. I *could* bus home after dinner last night, but I wouldn't get back home until ~10:30, and then I'd have to et up at 5:45 to catch a 6:30 bus back
[14:47] <brousch> jrwren: He could be in an open relationship. Don't judge.
[14:47] <greg-g> jrwren: you don't know our arrangement, dont' judge ;)
[14:47] <jrwren> pffff
[14:47] <brousch> hah, see!
[14:47] <greg-g> :) :)
[14:47] <greg-g> rick_h_: a good number of our engineers sent out "heading to the burn today, see ya!" emails
[14:47] <rick_h_> brousch: was more trying to picture greg-g beard and all in a purple playa suit from the 60s/70s with a giant collar
[14:47] <jrwren> i always knew I liked your wife :p
[14:48] <cmaloney> I'm in a perfectly open relationship. If I ever cheated on JoDee she'd open me up like a fish
[14:48] <jrwren> leisure suit greg-g
[14:48] <cmaloney> rick_h_: I can totally see that
[14:48] <greg-g> 10 years ago? totally
[14:48] <greg-g> not so much any more
[14:48] <rick_h_> greg-g: and none of them invited me to go?
[14:49] <cmaloney> From Leisure Suit Playa to Leisure Suit Larry in 10 years.
[14:49] <greg-g> rick_h_: :)
[14:49] <greg-g> this hotel is weird. it's one where half the rooms share bathrooms (per floor), ie it's cheaper but not quite an SRO, but it's playing hardcore electronic music right now
[14:50] <greg-g> at 7:50 am
[14:50] <cmaloney> soma.fm?
[14:50] <jrwren> greg-g: WTF?!?! why are you at this hotel?  Also, what hotel? sounds awesome. I want to stay there if I ever go to SF
[14:50] <greg-g> heh, I am wearing my somafm hat right now
[14:50] <greg-g> jrwren: The Mosser
[14:50] <greg-g> good location, all told, really
[14:51] <cmaloney> I need to get some soma.fm wear at some point
[14:51] <greg-g> 3 blocks from my office, right near Market St (main downtown street)


[17:46] <bluesabre> Signing out to avoid the crushing amount of PM spam. Ping me elsewhere if you need something :)


[06:32] <pwnguin> how the hell does evdev work?
[06:55] <pwnguin> im getting pushback from scottk on closing a bug about requiring root prives to use uinput; im wondering if evdev solves anything
[07:20] <tjaalton> pwnguin: which bug
[07:22] <tjaalton> bryce: so is the pot file in the binary now or just the source package?
[07:22] <tjaalton> bryce: xkeyboard-config..
[07:29] <pwnguin> bug #312957
[07:32] <tjaalton> does it work in jaunty?
[07:32] <tjaalton> in intrepid evdev grabbed the input devices
[07:32] <tjaalton> but doesn't do that anymore in jaunty
[07:33] <pwnguin> it works as well in jaunty as it ever has
[07:33] <pwnguin> the problem is that the program uses uinput
[07:33] <pwnguin> which is a security black hole
[07:33] <tjaalton> ok
[07:33] <tjaalton> well, I don't know about that :)
[07:33] <pwnguin> the conclusion ive come to is to just use sudo and be done with it
[07:34] <pwnguin> user beware
[07:34] <tjaalton> well, the package could use policykit to use the plugdev group for the device
[07:34] <tjaalton> erm
[07:35] <tjaalton> no policykit needed there
[07:35] <tjaalton> PK adds the group for the active user
[07:35] <pwnguin> when i spoke with scott remnant a year or longer ago
[07:35] <tjaalton> or something like that
[07:36] <pwnguin> This implies to me that any user could insert input events to your X server, and thus click on any part of the screen, etc.
[07:36] <pwnguin> These permissions are definitely inappropriate.
[07:36] <tjaalton> heh, ok then
[07:36] <pwnguin> im not about to overrule the udev maintainer ;)
[07:36] <tjaalton> so the driver is faulty
[07:36] <pwnguin> there's no way from here to there
[07:36] <pwnguin> im wondering if evdev works substantially differently
[07:38] <tjaalton> doesn't use uinput
[07:38] <tjaalton> anyway, afk->
[07:38] <pwnguin> the uinput.h does say it's substantially copied from evdev
[07:38] <pwnguin> so they cant be all that different in practice ;)
[07:39] <pwnguin> g'nite or whatnot
[07:43] <tjaalton> night
[09:34] <bryce> tjaalton: just the source package
[09:35] <tjaalton> ok
[09:42] <bryce> I trust that's sufficient for rosetta
[09:42] <tjaalton> probably is
[09:42] <bryce> fwiw, it wasn't as simple as just running make <foo>.pot; it seems this part of the makefile has bit rotted some
[09:42]  * bryce -> bed
[13:12] <Ampelbein> tjaalton: hi. could you have a look at bug #352335, please?
[13:12] <Ampelbein> I added a patch and would like you to check if it's ok.
[13:18] <tjaalton> Ampelbein: the patch itself does, but it's a lot of changes for just a simple patch
[13:18] <tjaalton> I'll update them in debian so we can sync them
[13:18] <tjaalton> there are six input drivers that FTBFS, minus aiptek
[13:18] <Ampelbein> tjaalton: i had a little chat with bryce yesterday about using or not using quilt
[13:19] <Ampelbein> i've done the change for aiptek using quilt and he said it was ok.
[13:19] <tjaalton> sure
[13:19] <jcristau> Ampelbein: the fix should be as simple as updating to the new upstream
[13:19] <tjaalton> all those drivers got a new version because of xserver 1.6
[13:21] <Ampelbein> so do we wait until debian has the changes and sync?
[13:22] <tjaalton> it's the least effort (for you anyway ;)
[13:22] <Ampelbein> ok, just thought it would be helping.
[13:23] <tjaalton> np, it was just delayed on my part
[13:27] <tjaalton> heh, I already had the git repos cloned
[17:45] <PolitikerNEU> ah - maybe you can help me here: Is there a kernel including the openchrome-driver so VIA-chips work out of the box?
[17:45] <laanan> hello, i have a problem getting 3D acceleration with my Intel 945 gfx in Jaunty. i've asked in #ubuntu+1 and was directed here
[17:48] <tjaalton> PolitikerNEU: there is xserver-xorg-video-openchrome in jaunty, isn't it enough?
[17:48] <tjaalton> laanan: /var/log/Xorg.0.log plese
[17:48] <tjaalton> pleAse
[17:48] <laanan> ok, just a sec
[17:49] <laanan> tjaalton, (the Driver "intel" was added by me, no change from the default of nothing): http://pastebin.com/m6f83c26b
[17:50] <tjaalton> laanan: that's xorg.conf
[17:50] <laanan> tjaalton, oh sorry
[17:51] <laanan> tjaalton, http://pastebin.com/m29001fee
[17:52] <tjaalton> laanan: dri is used, so what doesn't work?
[17:53] <laanan> if it helps, i seemed to have the same problem with a fresh install of 8.10, and changing `Driver "vesa"` to `Driver "intel"` in xorg.conf fixed it. the problem is all 3D accel. apps seem software rendered
[17:54] <laanan> that is, it's more than just sluggish, frame rates are around 1-2hz for most gl screensavers and games
[17:54] <tjaalton> what does 'glxinfo| grep direct' say?
[17:55] <laanan> it says `direct rendering: Yes`, but it said that in 8.10 too and obviously it wasn't (again, adding Driver "intel" fixed it in 8.10)
[17:55] <tjaalton> adding that shouldn't do anything
[17:56] <laanan> ok
[17:56] <jcristau> just pastebin 'LIBGL_DEBUG=verbose glxinfo'
[17:56] <PolitikerNEU> tjaalton: At least in 8.10 (was openchrome there?) it was not enough - has the situation changed in 9.04?
[17:56] <tjaalton> PolitikerNEU: try the beta livecd
[17:57] <PolitikerNEU> tjaalton: I will - the problem it is not my laptop
[17:57] <laanan> tjaalton, http://pastebin.com/m1b3276ca
[17:58] <jcristau> so it's accelerated alright
[17:58] <tjaalton> yep
[18:01] <laanan> the advice i got for 8.10 did fix the problem, and from what i remember glxinfo was pretty much the same before and after the xorg.conf change
[18:01] <jcristau> it's not clear to me what the problem is.  you said you wanted 3d accel, you've got that already.
[18:02] <tjaalton> laanan: gnome or kde?
[18:02] <laanan> gnome
[18:03] <tjaalton> try with a new user or purge your compiz configuration
[18:03] <tjaalton> a livecd would do as well
[18:03] <laanan> well, for example, glxgears gives me around 300fps now, it was the same with 8.10 before the change. after the change glxgears in 8.10 runs at over 5 times the speed
[18:04] <tjaalton> glxgears is not a benchmark
[18:04] <jcristau> pick another example
[18:05] <laanan> it's just an indicator, the skyrocket screensaver gets around 1-2hz, GtkRadiant is almost unusable as well
[18:07] <laanan> tjaalton, could you explain purging my clmpiz configuration ?
[18:08] <tjaalton> laanan: probably in too many places I don't know.. just create a new user and try there
[18:08] <tjaalton> or try without the effects (ie. with metacity)
[18:09] <laanan> ok, well i have None checked in Appearance/Visual Effects.. i will try to create a new user
[18:10] <tjaalton> you need to log out and log back in as that user, quick switch to it basically means you got no DRI
[18:10] <tjaalton> in that session
[18:10] <laanan> ok
[18:15] <laanan> hmm, no change. this problem is not a large issue for me, as 8.10 works fine for the most part. i just wanted to try Jaunty since it seems there was a bug fixed in Mesa affecting one of my apps
[18:17] <laanan> thank you for the help though, i appreciate it
[18:18] <tjaalton> you could try the mesa packages at https://edge.launchpad.net/~tjaalton/+archive/ppa
[18:19] <laanan> i can use those with Intrepid ?
[18:19] <tjaalton> no
[18:21] <laanan> oh, well from what i gather the bug was unrelated to this current issue
[18:22] <laanan> (and i am a Linux newbie, so i'm a little over my head here anyway :))
[18:24] <tjaalton> try a livecd, it should work there
[18:24] <tjaalton> if not, then it's a bug
[18:25] <laanan> that's what i tried first (the daily build), same problem
[18:25] <tjaalton> ok
[18:28] <laanan> it was explained to me that my previous 8.10 install was using the generic vesa driver, and was slow even tho direct rendering was enabled. i figured it was the same situation here but apparently not
[18:28] <tjaalton> vesa doesn't support dri
[18:29] <laanan> yeah, that was the reason was everything crawled there
[18:31] <laanan> for me, apparently i need `Driver "intel"` in 8.10 for everything to work as it should.. are you saying that (if everything is goes well) i don't need that in 9.04 ?
[18:32] <tjaalton> you shoudn't need that in 8.10 either
[18:32] <tjaalton> just remove the line
[18:33] <laanan> ok, i will try that the next time i am in 8.10. (but the problem still remains with or without that line in 9.04)
[18:34] <laanan> anyway, if i have time and can get it sorted out, i will come back and let you know. thanks again
[18:34] <tjaalton> np
[18:38] <Ng> hmmmm
[18:38] <Ng> tjaalton: interesting data point, I just booted a live CD... compiz stuff seems fine :/
[18:39] <Ng> so something about my setup which has no appreciable xorg.conf, or .drirc or interesting compiz settings, is very much worse
[18:39] <tjaalton> Ng: there you go, upgrades ftl :)
[18:39] <Ng> this could also explain why the 965 belonging to the guy next to me is nowhere near as badly affected as mine
[18:47] <Ng> tjaalton: well, I'm not sure it's 100% conclusive, there will be a lot more happening on my install than a live CD
[18:47] <Ng> but I am now very tempted to do a full re-install ;)
[18:59] <tjaalton> heh
[19:03] <Ng> aha! a more comparable test from the live CD still shows the same juddering
[19:03]  * Ng feels vindicated and re-assured ;)
[20:13] <BUGabundo> bryce: ping
[20:13] <BUGabundo> how are we with support for intel 8x5 for jaunty?
[20:27] <bryce> BUGabundo: piss poor at the moment
[20:27] <bryce> BUGabundo: do you have feedback on it?  I asked on the list for input from any 8xx owners but no one responded
[20:34] <BUGabundo> thanks bryce
[20:34] <BUGabundo> i changed xorg to use DRI false
[20:34] <BUGabundo> and i can use this test PC
[20:34] <BUGabundo> i have a bunch of then to install until saturday
[20:34] <bryce> BUGabundo: what chipset?
[20:34] <BUGabundo> bryce: 865
[20:35] <BUGabundo> i comment on the bug
[20:35] <BUGabundo> do u need any further testing?
[20:35] <BUGabundo> i guess i could give u reverse ssh to it or something
[20:35] <bryce> I'm going to limit 304871 to just 845 graphics
[20:36] <bryce> which I think is fixed now
[20:36] <bryce> 865 will need a separate bug report
[20:36] <BUGabundo> ok
[20:36] <bryce> 317457 maybe
[20:36] <BUGabundo> is it opened yet?
[20:36] <bryce> BUGabundo: have you filed one for this issue?  If so I'd prefer making that the master since you're more active
[20:37] <BUGabundo> i did not
[20:37] <bryce> otherwise I guess we can use 317457
[20:37] <bryce> ok
[20:37] <BUGabundo> thats why i came here 1st
[20:37] <BUGabundo> ok, i'm subed to it now
[20:37] <bryce> 328528 is UXA lockup on 865
[20:38] <bryce> I've not decided if that's a dupe, I think it may be a separate issue.  You have that one too?
[20:39] <BUGabundo> let ne see
[20:40] <BUGabundo> bryce: i didnt mess much on this xorg
[20:40] <BUGabundo> just added dri
[21:18] <BUGabundo> bryce: is there any thing i can do to make this card run compiz?
[21:20] <bryce> BUGabundo: can you try the Legacy3D "false" option mentioned in the bug report?
[21:20] <bryce> BUGabundo: did you already try option "AccelMethod" "UXA"?
[21:21] <BUGabundo> no i did not
[21:21] <BUGabundo> let me see if i can do it
[21:22] <BUGabundo> ok now where do i need to add that stuff?
[21:22] <jcristau> device section of xorg.conf
[21:23] <BUGabundo> but keep dri false?
[21:23] <jcristau> not if you want compiz
[21:23] <BUGabundo> oh
[21:25] <bryce> you can try them both together if you want but disabling dri sort of cancels out uxa
[21:26] <BUGabundo> so i add legacy3d and uxa
[21:26] <BUGabundo> is this ok? http://paste.ubuntu.com/141679/
[21:27] <bryce> BUGabundo: can you also try each of those two options separately?
[21:27] <bryce> I'd like to know if Legacy3D will solve your issue without also having to go to UXA
[21:27] <BUGabundo> sure
[21:27] <BUGabundo> i'll just make dinner wait a bit more
[21:28] <bryce> no prob
[21:28] <BUGabundo> killing X now
[21:30] <BUGabundo> with both i can login
[21:30] <BUGabundo> commenting 3d
[21:30] <BUGabundo> spoke too soon
[21:30] <BUGabundo> system froze
[21:31] <BUGabundo> bryce: having both seems like a bad choice on 865
[21:31] <bryce> :-/
[21:31] <bryce> yeah not many good reports of UXA on 965
[21:32] <bryce> er 965
[21:32] <bryce> dah
[21:32] <bryce> 888865
[21:32] <bryce> BUGabundo: try with only Legacy3d
[21:32] <BUGabundo> rebooted
[21:32] <bryce> I don't expect that will work, but if it does we're golden since I have a patch for that already
[21:32] <BUGabundo> and repeated the same thing
[21:33] <bryce> ok so, the only thing that has worked has been disabling DRI?
[21:33] <bryce> (which disables compiz)
[21:33] <BUGabundo> bryce: now testing with only 3d
[21:34] <yow|x2> i dont use compiz, id be happy to test BUGabundo
[21:34] <BUGabundo> after that i can try wit only uxa
[21:34] <bryce> yow|x2: what chipset do you have?
[21:35] <yow|x2> intel ich7
[21:35] <BUGabundo> bah
[21:35] <BUGabundo> critical bug... Delete will not send to trash
[21:36] <yow|x2> 945gm / 945gms for video
[21:36] <bryce> yow|x2: we're only looking at 8xx for this, but thanks.
[21:36] <BUGabundo> bryce: just 3d i have a black background
[21:36] <BUGabundo> see top and bottom bars
[21:36] <BUGabundo> mouse moves
[21:36] <yow|x2> ack. gotta figure out why im getting freezing so much
[21:37] <BUGabundo> bryce: want me to test just UXA now?
[21:37] <BUGabundo> cant even jump to TTY
[21:37] <bryce> BUGabundo: if you'd like; we already decided we're not going to do UXA, and I'm pretty sure it won't work for you
[21:37] <BUGabundo> alt+sysqr+K just showed blue screen
[21:38] <BUGabundo> then black
[21:39] <bryce> yeah that's because the kernel kills X but doesn't know how to reset the graphics card to a sane state
[21:39] <bryce> probably have to reboot
[21:42] <BUGabundo> bryce: FAIL
[21:43] <BUGabundo> UXA wont work on this system
[21:43] <BUGabundo> just DRI
[21:43] <BUGabundo> any more combos u need me to test?
[21:44] <bryce> nope, that should do it
[21:44] <bryce> ok, I'll go with the disable DRI patch for 865 then
[21:44] <bryce> shame to lose compiz and 3D on that chipset, but better that it not freeze up
[21:44] <BUGabundo> so no compoiz?
[21:45] <BUGabundo> ohh my students wont be able to play with it!
[21:47] <bryce> BUGabundo: there was one reporter that said he resolved it on 865 by booting a 2.6.27 kernel
[21:47] <bryce> so you could try that, if you just want to be able to show it off
[21:47] <bryce> er wait that reporter was on 855
[21:48] <bryce> still, booting an earlier kernel might be worth trying if you have one handy
[21:53] <BUGabundo> bryce: no change. this is a daily jaunty image
[21:54] <bryce> hrm, too bad
[22:38] <bryce> tjaalton, superm1: either of you know if anyone is going to up us to the latest -nvidia?  Or should we be skipping it?
[22:42] <superm1> bryce, from the looks of it, it's bug fixes, but i'm not positive
[22:42] <bryce> I've seen several positive reports around it, and judging from the rate of new bugs against nvidia-180 so far, we could use bug fixes there
[22:43] <superm1> bryce, yeah especially KDE plasma fixes
[23:24] <bryce> good god, xorg is up to 35 bugs after just a couple weeks