| *** gyee has quit IRC | 00:14 | |
| *** markvoelker has quit IRC | 00:32 | |
| *** markvoelker has joined #openstack-keystone | 00:33 | |
| *** markvoelker has quit IRC | 00:38 | |
| *** jmccrory has quit IRC | 00:46 | |
| *** jmccrory has joined #openstack-keystone | 00:46 | |
| *** joshualyle has joined #openstack-keystone | 00:54 | |
| *** joshualyle has quit IRC | 00:58 | |
| *** gagehugo has quit IRC | 01:21 | |
| *** markvoelker has joined #openstack-keystone | 01:21 | |
| *** gagehugo has joined #openstack-keystone | 01:30 | |
| *** whoami-rajat has joined #openstack-keystone | 01:35 | |
| *** joshualyle has joined #openstack-keystone | 01:35 | |
| *** joshualyle has quit IRC | 01:39 | |
| *** lbragstad has quit IRC | 01:40 | |
| *** joshualyle has joined #openstack-keystone | 01:46 | |
| *** joshualyle has quit IRC | 01:51 | |
| *** awalende has joined #openstack-keystone | 01:55 | |
| *** awalende has quit IRC | 02:00 | |
| *** shyamb has joined #openstack-keystone | 02:51 | |
| *** dave-mccowan has quit IRC | 03:15 | |
| *** shyamb has quit IRC | 04:09 | |
| *** pcaruana has joined #openstack-keystone | 05:00 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 05:55 | |
| openstackgerrit | Vishakha Agarwal proposed openstack/python-keystoneclient master: [WIP] update keyring version https://review.opendev.org/661897 | 06:28 |
|---|---|---|
| openstackgerrit | Vishakha Agarwal proposed openstack/python-keystoneclient master: Blacklist bandit 1.6.0 & cap sphinx for 2.7 https://review.opendev.org/660609 | 06:29 |
| *** markvoelker has quit IRC | 07:01 | |
| *** markvoelker has joined #openstack-keystone | 07:01 | |
| *** markvoelker has quit IRC | 07:06 | |
| *** tobias-urdin has quit IRC | 07:09 | |
| *** adriant has quit IRC | 07:10 | |
| *** rcernin has quit IRC | 07:10 | |
| *** adriant has joined #openstack-keystone | 07:10 | |
| *** xek_ has joined #openstack-keystone | 07:23 | |
| *** tkajinam has quit IRC | 08:33 | |
| *** markvoelker has joined #openstack-keystone | 09:02 | |
| *** markvoelker has quit IRC | 09:35 | |
| *** markvoelker has joined #openstack-keystone | 10:24 | |
| *** rcernin has joined #openstack-keystone | 11:10 | |
| *** dave-mccowan has joined #openstack-keystone | 11:10 | |
| *** raildo has joined #openstack-keystone | 12:05 | |
| *** rcernin has quit IRC | 12:10 | |
| *** niceplace has quit IRC | 12:26 | |
| *** niceplace has joined #openstack-keystone | 12:29 | |
| *** jdwidari has joined #openstack-keystone | 12:58 | |
| *** lbragstad has joined #openstack-keystone | 13:02 | |
| *** pcaruana has quit IRC | 13:23 | |
| *** pcaruana has joined #openstack-keystone | 13:47 | |
| lbragstad | lifeless o/ qq on using fixtures | 14:19 |
| lbragstad | in keystone we use fixtures for a bunch of things https://opendev.org/openstack/keystone/src/branch/master/keystone/tests/unit/core.py#L619-L655 | 14:21 |
| lbragstad | in that case - we run setUp, init a bunch of fixtures for keystone, and then load the application (keystone in this case) | 14:22 |
| lbragstad | but that all happens per test - and we'd like to refactor it so that loading the app happens per test class (setUpClass instead of setUp) | 14:23 |
| lbragstad | the documentation for fixtures references that use case https://pypi.org/project/fixtures/ | 14:23 |
| lbragstad | and says it's possible to setup fixture per test class | 14:23 |
| lbragstad | but right now we're using `self.useFixture` which i think has to be called on an instance of the test class itself, and not a class method | 14:24 |
| lbragstad | is there a recommended way to make that transition? | 14:24 |
| johnthetubaguy | lbragstad: thanks for looking at the patch, current plan is really just server related limits, so that simpler wrapper should be enough for us | 14:30 |
| lbragstad | johnthetubaguy ok | 14:30 |
| lbragstad | johnthetubaguy i suppose that would just be an internal change to nova in the future to add support for other resource types | 14:32 |
| johnthetubaguy | yeah, right now it supports counting servers and any resource class that is claimed in placement | 14:33 |
| johnthetubaguy | claimed via a flavor, anyways | 14:33 |
| * lbragstad nods | 14:37 | |
| *** itlinux has quit IRC | 14:48 | |
| *** gyee has joined #openstack-keystone | 15:28 | |
| *** pcaruana has quit IRC | 15:33 | |
| *** itlinux has joined #openstack-keystone | 15:46 | |
| kmalloc | lbragstad: we might not get around the self.useFixture because the way setup/teardown happens | 16:04 |
| kmalloc | lbragstad: we probably need to tool our own class-level one. | 16:05 |
| lbragstad | yeah... | 16:05 |
| lbragstad | i have some of it wired up | 16:05 |
| kmalloc | with that said, we can be smarter about setup/teardown | 16:05 |
| lbragstad | i'm just wondering what to do with these self.useFixture($fixture) bits | 16:05 |
| kmalloc | do a "build-once" kind of thing in init and if it exists carry it forward. and do a ref-count tracker for teardown | 16:06 |
| kmalloc | so teardown ++ and --, when you hit zero actually call teardown | 16:06 |
| kmalloc | it requires a subclass/metaprogramming for the fixtures | 16:06 |
| kmalloc | but would generally work. | 16:06 |
| lbragstad | ok - that's a couple steps ahead of what i'm at i think | 16:06 |
| lbragstad | useFixture is an instance method | 16:07 |
| kmalloc | yup | 16:07 |
| lbragstad | we can't call that from within a classmethod i don't think | 16:07 |
| kmalloc | no you can't | 16:07 |
| lbragstad | because we use fixtures for things like the database | 16:08 |
| lbragstad | we need to set that up before we call bootstrap | 16:08 |
| lbragstad | (which we want in setUpClass) | 16:08 |
| lbragstad | so - we have a weird order of operations problem | 16:08 |
| kmalloc | i think you need to implement a thing similar to a fixture that is called once in setup overally | 16:08 |
| kmalloc | overall* | 16:08 |
| lbragstad | so - we need to reimplement useFixture? | 16:09 |
| kmalloc | yeah a class-based one. | 16:09 |
| lbragstad | bah | 16:09 |
| lbragstad | ok - digging it up | 16:09 |
| kmalloc | also keep in mind the class-based one will carry state forward | 16:09 |
| kmalloc | soooooo | 16:09 |
| kmalloc | so, what are you trying to fix atm? DB sync? | 16:10 |
| lbragstad | no | 16:10 |
| lbragstad | i'm trying to implement a classmethod (setUpClass) that runs bootstrap | 16:10 |
| lbragstad | bootstrap currently requires some basic fixtures in place | 16:11 |
| lbragstad | be in place* | 16:11 |
| kmalloc | so we're going to be ok with carrying db state forward. | 16:11 |
| kmalloc | between test cases. | 16:11 |
| lbragstad | theoretically | 16:11 |
| lbragstad | because bootstrap is the absolute minimum of things guaranteed in a deployment | 16:11 |
| lbragstad | if tests need additional stuff - they should be setting that up in setUp | 16:12 |
| lbragstad | or in the test itself | 16:12 |
| lbragstad | IMO | 16:12 |
| kmalloc | right but it means if we add a user (say identity.add_user test) that new user will carry forward to subsequent tests | 16:12 |
| lbragstad | if we add that in the setUpClass method | 16:12 |
| kmalloc | unless you explicitly have a cleanup/delete step | 16:12 |
| kmalloc | s/add_user/create_user | 16:12 |
| lbragstad | right | 16:13 |
| kmalloc | so, the way i would do this is make a *new* class emthod that pulls in the db stuff (dropping the fixtures needed) | 16:13 |
| kmalloc | and does the bootstrap, and holds onto the sqlite handle | 16:13 |
| kmalloc | you'll need to call it in a way to assign the value to the class and if it's been assigned noop | 16:14 |
| kmalloc | and forget about cleaning that up, it'll GC/fall off the end when the test runs finish | 16:14 |
| kmalloc | so something like: | 16:14 |
| lbragstad | this is what i have so far | 16:15 |
| lbragstad | https://pasted.tech/pastes/4e078bb260db6ad9c7b6e0134a27e7914555443e.raw | 16:15 |
| lbragstad | which is being used from https://pasted.tech/pastes/365ec732feed65ad764773585b0e0e98ec937c91.raw | 16:15 |
| kmalloc | yeah yank all the fixtures apart and just implement that directly | 16:15 |
| lbragstad | so - to be clear, we're not using fixtures going forward? | 16:16 |
| kmalloc | not in the setupclass method | 16:16 |
| kmalloc | that is a onetime setup. | 16:16 |
| kmalloc | there is no teardown | 16:16 |
| lbragstad | there is a tearDownClass() method | 16:17 |
| kmalloc | not needed | 16:17 |
| lbragstad | but you're justing thinking it'll get cleaned up when nothing is referenced anymore? | 16:17 |
| lbragstad | just thinking* | 16:17 |
| kmalloc | when the tests exit, it should cleanup | 16:17 |
| kmalloc | the reason to have teardown/cleanup in a fixture is to ensure greenfield per test. | 16:17 |
| lbragstad | right - everything in setUpClass() should be specific to the test case running it | 16:17 |
| lbragstad | well - teardown can happen at the test level (tearDown) or the class level (tearDownClass) or the module level (tearDownModule) | 16:18 |
| lbragstad | at least according to the brochure i'm reading | 16:18 |
| kmalloc | sure. feel free to cleanup at the module level | 16:19 |
| kmalloc | or the instace __del__ level | 16:19 |
| kmalloc | but really, should just GC when the instance/class is no longer refed. | 16:19 |
| kmalloc | for sure you can't use the useFixture() method | 16:19 |
| lbragstad | yeah... | 16:19 |
| kmalloc | so start with doing it as a single standup in your @classmethod | 16:20 |
| lbragstad | so we have to reimplement fixtures | 16:20 |
| lbragstad | all of our ksfixtures | 16:20 |
| kmalloc | not all. | 16:20 |
| lbragstad | er - the basic ones | 16:20 |
| kmalloc | just the bootstrap related ones. | 16:20 |
| kmalloc | but yes | 16:20 |
| lbragstad | database, keystone repository, configuration | 16:20 |
| lbragstad | key repository* | 16:21 |
| kmalloc | that should be easy | 16:21 |
| kmalloc | since the ksfixtures already show you what they do | 16:21 |
| kmalloc | just migrate the code out of the fixture itself. | 16:21 |
| lbragstad | ksfixtures is implemented to assume fixtures | 16:21 |
| lbragstad | ok | 16:21 |
| lbragstad | for database and key repositories, that shouldn't be bad... | 16:22 |
| lbragstad | but oslo config might be different | 16:22 |
| lbragstad | i'm less familiar with what happens with that | 16:22 |
| * lbragstad bets that bnemec probably has all the answers | 16:22 | |
| kmalloc | oslo.config will be hard. | 16:22 |
| lbragstad | :'( | 16:23 |
| kmalloc | the way oslo.config works you're going to run into issues. but in this case, mock the sql and repo paths | 16:23 |
| lbragstad | mock - reimplement? | 16:23 |
| kmalloc | you should be able to mock patch the config object, even if it isn't setup | 16:23 |
| lbragstad | good ole copy/pasta | 16:23 |
| kmalloc | all you care about is db connection string and repo paths | 16:24 |
| lbragstad | ok - lemme give that a shot with the database and key repository fixtures | 16:24 |
| kmalloc | the rest of oslo config stuff will remain the same | 16:24 |
| kmalloc | so you wont need to touch it | 16:24 |
| kmalloc | frankly i would mock out the key repo to be an in-memory thing that just returns the strings/keys | 16:25 |
| kmalloc | and the dbstring you might be able to do the same by making a method called ".db_connection()" thjat just returns olso.config values | 16:25 |
| kmalloc | it's a little more work, but would make this super easy. | 16:26 |
| lbragstad | hmmm | 16:26 |
| kmalloc | so insead of calling oslo.config, call a @classmethod whever you get config.sql.connection or whatever it is | 16:27 |
| kmalloc | and mock that in your tests. | 16:27 |
| kmalloc | or at least in bootstrap. | 16:28 |
| bnemec | Why do you need to mock oslo.config? We provide a fixture so you can override config values on a per-test basis. | 16:28 |
| kmalloc | bnemec: class-level mocking | 16:28 |
| kmalloc | bnemec: you can't use the fixture if you rely on the config but you only want to stand up the db say once | 16:28 |
| kmalloc | because that is class level not instance level. | 16:28 |
| kmalloc | you don't want .teardown ever called. | 16:28 |
| kmalloc | this is highly specific to the keystone db and key repository bits. | 16:29 |
| kmalloc | not *all* config values. | 16:29 |
| bnemec | Okay, highly keystone-specific sounds like I should go grab lunch and leave it to you. :-) | 16:30 |
| kmalloc | bnemec: no lunch for you :P unless you're sharing with the whole channel :P | 16:30 |
| kmalloc | ;) | 16:30 |
| kmalloc | have a good lunch man! | 16:31 |
| * kmalloc eats breakfast. | 16:31 | |
| bnemec | I have a feeling you might not like the result if I tried to mail food items cross-country. ;-) | 16:31 |
| bnemec | Although I recently found out you can mail ice cream, so who knows? | 16:32 |
| kmalloc | depends on the food items. i mean spam (in a can) probably would be fine. | 16:32 |
| kmalloc | i also found out i can fedex ripe maui pineapples to my front door... | 16:32 |
| bnemec | Nice | 16:33 |
| cmurphy | ayoung: hrybacki: kmalloc: please fill out the poll for the m-1 review meeting https://doodle.com/poll/hyibxqp9h8sgz56p | 17:11 |
| cmurphy | bnemec: you too if you like | 17:11 |
| hrybacki | cmurphy: I'll be in Brno for a team hackfest both of those weeks :( | 17:44 |
| cmurphy | hrybacki: ah ok :( | 17:45 |
| hrybacki | cmurphy: I'm operating life on a Julian calendar these days | 17:46 |
| bnemec | Filled out the poll, but don't schedule around me if it's inconvenient. | 18:02 |
| openstackgerrit | Michael McCune proposed openstack/keystoneauth master: add handling for multiple error returns https://review.opendev.org/662281 | 18:19 |
| *** pcaruana has joined #openstack-keystone | 18:24 | |
| openstackgerrit | Michael McCune proposed openstack/keystoneauth master: add handling for multiple error returns https://review.opendev.org/662281 | 18:26 |
| kmalloc | cmurphy: filled out availability | 19:01 |
| lifeless | lbragstad: hi | 19:31 |
| lbragstad | lifeless o/ | 19:42 |
| lbragstad | earlier i was trying to figure out if there was a setUpClass-level equivalent to useFixture for a refactor we're doing in keystone | 19:43 |
| lbragstad | we use a whole bunch of fixtures in keystone to setup things during setUp(), but we'd like to try and refactor the majority of it to be in setUpClass() | 19:45 |
| lbragstad | i wasn't sure if what we were doing was all that common and wanted to double check with someone else | 19:48 |
| lbragstad | someone more familiar with the library* | 19:48 |
| *** xek_ has quit IRC | 20:34 | |
| *** pcaruana has quit IRC | 21:18 | |
| *** itlinux has quit IRC | 21:23 | |
| *** whoami-rajat has quit IRC | 21:24 | |
| *** raildo has quit IRC | 21:35 | |
| openstackgerrit | Michael McCune proposed openstack/keystoneauth master: add handling for multiple error returns https://review.opendev.org/662281 | 21:36 |
| *** jdwidari has quit IRC | 21:51 | |
| *** itlinux has joined #openstack-keystone | 22:42 | |
| openstackgerrit | Michael McCune proposed openstack/keystoneauth master: add handling for multiple error returns https://review.opendev.org/662281 | 23:03 |
| openstackgerrit | Michael McCune proposed openstack/keystoneauth master: add handling for multiple error returns https://review.opendev.org/662281 | 23:03 |
| *** tkajinam has joined #openstack-keystone | 23:05 | |
| *** rcernin has joined #openstack-keystone | 23:17 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!