wesleymason | https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2 | 00:06 |
---|---|---|
wesleymason | doh, wrong channel | 00:06 |
=== frankban|afk is now known as frankban | ||
erik_lonroth | Great post! | 07:28 |
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:55 |
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 | 11:56 |
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:04 |
pranav_ | Hi Folks. Getting 403 forbidden error when using admin user credentials. | 12:32 |
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. | 12:33 |
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 | 13:42 |
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:14 |
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 :-) | 14:15 |
=== scuttle|afk is now known as scuttlemonkey | ||
=== scuttlemonkey is now known as scuttle|afk | ||
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. | 15:47 |
cory_fu | petevg: Comment'd | 16:41 |
petevg | cory_fu: thx. | 16:41 |
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:50 |
cory_fu | petevg: I had a follow-up comment about how to handle the changes in the object layer, if you missed that | 16:53 |
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:54 |
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:58 |
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? | 16:59 |
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:00 |
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:02 |
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:03 |
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:04 |
stormmore | o/ juju world | 17:24 |
=== frankban is now known as frankban|afk | ||
stormmore | hey marcoceppi I think I have figured out that replicaset issue | 18:18 |
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:49 |
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:50 |
bdx | urulama: does that mean the beta controller will rev too then? | 18:51 |
urulama | bdx: not sure i understand the question | 18:52 |
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:53 |
bdx | urulama: my bad I miss read above ... thx | 18:54 |
urulama | bdx: the upgrade to 2.2 will happen when it's out, and that is planned end of month, early May | 18:55 |
bdx | urulama: thats great news | 18:56 |
bdx | urulama: thanks for looking into this | 18:56 |
urulama | bdx: np, always looking to improve where we can scale better :) | 18:58 |
jose | marcoceppi: hey, do you have time for a quick call? | 19:00 |
=== smgoller is now known as Guest74578 | ||
marcoceppi | stormmore: I'm interested | 21:19 |
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:22 |
stormmore | https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/241 | 21:23 |
stormmore | marcoceppi, you lazy?!? :P | 21:24 |
marcoceppi | ;) | 21:25 |
stormmore | I thought lazyPower was the only lazy one in here | 21:25 |
stormmore | marcoceppi, let me if what I put in there makes sense as I have been pretty brain-foggy today | 21:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!