[00:06] <wesleymason> https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2
[00:06] <wesleymason> doh, wrong channel
=== frankban|afk is now known as frankban
[07:28] <erik_lonroth> Great post!
[11:55] <pranav_> Hi. Need help on keystone:identity-admin relation.
[11:55] <pranav_> Getting a 403 error when trying to list service/user with the admin user
[11:56] <pranav_> # /usr/bin/openstack --os-username admin --os-password "openstack" --os-project-name admin --os-auth-url http://172.101.101.9:5000/v3 --os-identity-api-version 3 project show service You are not authorized to perform the requested action: identity:list_projects. (HTTP 403) (Request-ID: req-f62bf819-b814-4335-a019-fd8cac60d433)
[11:56] <pranav_> keystone charm set with preffered-api-version 3
[12:04] <tardimctardyface> Hi all. Any thoughts on the best way to "refresh" all the juju machines after I restored the controller from a backup. Each machine/service is working fine but all agents show up as "lost" and all machines are "down". From bug-reports/docs I understand it's because each agent/machine doesn't know about the new controller IP address, but how do I force them to check a new one? Will "juju upgrade-juju" work?
[12:32] <pranav_> Hi Folks. Getting 403 forbidden error when using admin user credentials.
[12:33] <pranav_> # /usr/bin/openstack --os-username admin --os-password root123 --os-project-name admin --os-auth-url http://172.101.101.9:5000/v3 --os-identity-api-version 3 project show service You are not authorized to perform the requested action: identity:list_projects. (HTTP 403) (Request-ID: req-f453f64b-aa53-42f9-be36-49b3442faf3e)
[12:33] <pranav_> my charm creates a identity-admin relation.
[13:42] <urulama> bdx: so, i tried the replicate the "big bundle deploy" on a 2.2 tip and it passed without problems deploying on 100 machines
[13:42] <urulama> bdx: i'll verify on 2.1 and 2.0.2 now
[14:14] <petevg> cory_fu: I've got a lonely PR here: https://github.com/juju/python-libjuju/pull/105 (feel free to pull me into a hangout if you want to grill me on the approach -- I think that it's the Right Thing to do, but I'm open to arguments against :-) )
[14:15] <cory_fu> petevg: Yep, I have been looking at PRs all morning and that is on my list.  :)
[14:15] <petevg> cory_fu: cool. Thx :-)
=== scuttle|afk is now known as scuttlemonkey
=== scuttlemonkey is now known as scuttle|afk
[15:47] <cory_fu> petevg: LGTM.  I added a comment, but I'm +1 to merging it
[15:47] <petevg> cory_fu: cool. Will read the comment. Thank you.
[16:41] <cory_fu> petevg: Comment'd
[16:41] <petevg> cory_fu: thx.
[16:50] <petevg> cory_fu: left a comment on your comment. I think that you're right. There's a reason that I went the way that I did -- it avoids some potentially messy bits -- but having Python code that a dev can read is probably worth the cost of doing a bit of naughty magic with import.
[16:53] <cory_fu> petevg: I had a follow-up comment about how to handle the changes in the object layer, if you missed that
[16:54] <petevg> cory_fu: I missed it. And that's a good point, too. I assumed that the object layer would have the job of maintaining backwards compatibility. We could technically version it, too.
[16:58] <cory_fu> petevg: I definitely don't want to see the object layer versioned.  :p  Either conditionals in the object layer, or if it contains enough application logic (which I think it does) then a proper facade over the versioned API interfaces (what we're currently calling facades but which I think is inaccurate)
[16:58] <petevg> cory_fu: yeah. I'm writing a comment, but it's getting complex.
[16:59] <petevg> cory_fu: I think that you vision is good. I think that, practically speaking, we may have to drop in add-hoc fixes in the object layer to patch over the places where our Facades aren't really Facades.
[16:59] <cory_fu> petevg: Also, for making the import logic easier, what if we generate an __init__.py for the "facades" with an __all__ that lists the versions?  Then we just do a single normal import and a getattr  with the version number?
[17:00] <cory_fu> petevg: Our "facades" definitely aren't facades and will require translation, so I think we should start calling them versioned API interfaces ASAP
[17:00] <cory_fu> :)
[17:00] <petevg> cory_fu: That sounds like a good idea, though if I can figure out a way to do it without calling getattr, I'll be happier :-)
[17:02] <cory_fu> petevg: Also, I wasn't thinking that we'd do any monkey patching.  Rather, I was thinking of something like a get_versioned_api factory method or something.  Again, this should probably be wrapped in actual facades
[17:02] <petevg> cory_fu: yeah. The factory thing I mentioned in the notes sounds better and better.
[17:03] <petevg> cory_fu: ... and that almost makes these things into proper facades. The one missing piece is that your object layer might want to pass in extra args that only work with a newer version of juju, or might want to access properties on an object that don't exist in earlier versions.
[17:03] <cory_fu> petevg: When I say factory, I still mean that the Python code would be pre-generated.  There would just be a method responsible for returning you an instance of the right class by version.
[17:03] <petevg> cory_fu: exactly.
[17:03] <cory_fu> Ok
[17:03] <cory_fu> Just wanted to make sure we were talking about the same thing.  :)
[17:03] <cory_fu> Anyway, I have to run to an appointment
[17:03] <cory_fu> bbiab
[17:04] <petevg> cory_fu: so you do something like action = Action.connect, and you get the right version of an Action facade.
[17:04] <petevg> cory_fu: cool. Thx for all the comments, feedback, and generally making my life harder by bringing up things that I didn't thin about :-)
[17:04] <petevg> *think
[17:24] <stormmore> o/ juju world
=== frankban is now known as frankban|afk
[18:18] <stormmore> hey marcoceppi I think I have figured out that replicaset issue
[18:49] <bdx> urulama: thats awesome! the set of fixed bugs @anastasiamac listed looked pretty applicable to what we were seeing ... great news none the less
[18:49] <bdx> urulama: did you still experience the issue on 2.0.2 and 2.1?
[18:49] <urulama> bdx: yeah, 2.0.2 right now ... i need to manually remove around 100 machines from gce console :D
[18:50] <urulama> bdx: we'll upgrade controllers to 2.1.2 soon, and then to 2.2 in may when it's out
[18:50] <urulama> soon = this or latest next week
[18:50] <bdx> urulama: niceeeeee
[18:51] <bdx> urulama: does that mean the beta controller will rev too then?
[18:52] <urulama> bdx: not sure i understand the question
[18:53] <bdx> urulama: the hosted controller .... when will it get receive the upgrade to 2.1.2?
[18:53] <urulama> bdx: this or latest next week
[18:54] <bdx> urulama: my bad I miss read above ... thx
[18:55] <urulama> bdx: the upgrade to 2.2 will happen when it's out, and that is planned end of month, early May
[18:56] <bdx> urulama: thats great news
[18:56] <bdx> urulama: thanks for looking into this
[18:58] <urulama> bdx: np, always looking to improve where we can scale better :)
[19:00] <jose> marcoceppi: hey, do you have time for a quick call?
=== smgoller is now known as Guest74578
[21:19] <marcoceppi> stormmore: I'm interested
[21:22] <stormmore> marcoceppi, I updated the ticket with my notes on the issue
[21:22] <stormmore> marcoceppi, just seems odd that the install would cause heapster to be deployed 3 times
[21:22] <marcoceppi> stormmore: linky? (for the lazy)
[21:23] <stormmore> https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/241
[21:24] <stormmore> marcoceppi, you lazy?!? :P
[21:25] <marcoceppi> ;)
[21:25] <stormmore> I thought lazyPower was the only lazy one in here
[21:26] <stormmore> marcoceppi, let me if what I put in there makes sense as I have been pretty brain-foggy today