Thursday, 2019-05-30

*** gyee has quit IRC00:14
*** markvoelker has quit IRC00:32
*** markvoelker has joined #openstack-keystone00:33
*** markvoelker has quit IRC00:38
*** jmccrory has quit IRC00:46
*** jmccrory has joined #openstack-keystone00:46
*** joshualyle has joined #openstack-keystone00:54
*** joshualyle has quit IRC00:58
*** gagehugo has quit IRC01:21
*** markvoelker has joined #openstack-keystone01:21
*** gagehugo has joined #openstack-keystone01:30
*** whoami-rajat has joined #openstack-keystone01:35
*** joshualyle has joined #openstack-keystone01:35
*** joshualyle has quit IRC01:39
*** lbragstad has quit IRC01:40
*** joshualyle has joined #openstack-keystone01:46
*** joshualyle has quit IRC01:51
*** awalende has joined #openstack-keystone01:55
*** awalende has quit IRC02:00
*** shyamb has joined #openstack-keystone02:51
*** dave-mccowan has quit IRC03:15
*** shyamb has quit IRC04:09
*** pcaruana has joined #openstack-keystone05:00
*** Dinesh_Bhor has joined #openstack-keystone05:55
openstackgerritVishakha Agarwal proposed openstack/python-keystoneclient master: [WIP] update keyring version
openstackgerritVishakha Agarwal proposed openstack/python-keystoneclient master: Blacklist bandit 1.6.0 & cap sphinx for 2.7
*** markvoelker has quit IRC07:01
*** markvoelker has joined #openstack-keystone07:01
*** markvoelker has quit IRC07:06
*** tobias-urdin has quit IRC07:09
*** adriant has quit IRC07:10
*** rcernin has quit IRC07:10
*** adriant has joined #openstack-keystone07:10
*** xek_ has joined #openstack-keystone07:23
*** tkajinam has quit IRC08:33
*** markvoelker has joined #openstack-keystone09:02
*** markvoelker has quit IRC09:35
*** markvoelker has joined #openstack-keystone10:24
*** rcernin has joined #openstack-keystone11:10
*** dave-mccowan has joined #openstack-keystone11:10
*** raildo has joined #openstack-keystone12:05
*** rcernin has quit IRC12:10
*** niceplace has quit IRC12:26
*** niceplace has joined #openstack-keystone12:29
*** jdwidari has joined #openstack-keystone12:58
*** lbragstad has joined #openstack-keystone13:02
*** pcaruana has quit IRC13:23
*** pcaruana has joined #openstack-keystone13:47
lbragstadlifeless o/ qq on using fixtures14:19
lbragstadin keystone we use fixtures for a bunch of things
lbragstadin that case - we run setUp, init a bunch of fixtures for keystone, and then load the application (keystone in this case)14:22
lbragstadbut 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
lbragstadthe documentation for fixtures references that use case
lbragstadand says it's possible to setup fixture per test class14:23
lbragstadbut 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 method14:24
lbragstadis there a recommended way to make that transition?14:24
johnthetubaguylbragstad: thanks for looking at the patch, current plan is really just server related limits, so that simpler wrapper should be enough for us14:30
lbragstadjohnthetubaguy ok14:30
lbragstadjohnthetubaguy i suppose that would just be an internal change to nova in the future to add support for other resource types14:32
johnthetubaguyyeah, right now it supports counting servers and any resource class that is claimed in placement14:33
johnthetubaguyclaimed via a flavor, anyways14:33
* lbragstad nods14:37
*** itlinux has quit IRC14:48
*** gyee has joined #openstack-keystone15:28
*** pcaruana has quit IRC15:33
*** itlinux has joined #openstack-keystone15:46
kmalloclbragstad: we might not get around the self.useFixture because the way setup/teardown happens16:04
kmalloclbragstad: we probably need to tool our own class-level one.16:05
lbragstadi have some of it wired up16:05
kmallocwith that said, we can be smarter about setup/teardown16:05
lbragstadi'm just wondering what to do with these self.useFixture($fixture) bits16:05
kmallocdo a "build-once" kind of thing in init and if it exists carry it forward. and do a ref-count tracker for teardown16:06
kmallocso teardown ++ and --, when you hit zero actually call teardown16:06
kmallocit requires a subclass/metaprogramming for the fixtures16:06
kmallocbut would generally work.16:06
lbragstadok - that's a couple steps ahead of what i'm at i think16:06
lbragstaduseFixture is an instance method16:07
lbragstadwe can't call that from within a classmethod i don't think16:07
kmallocno you can't16:07
lbragstadbecause we use fixtures for things like the database16:08
lbragstadwe need to set that up before we call bootstrap16:08
lbragstad(which we want in setUpClass)16:08
lbragstadso - we have a weird order of operations problem16:08
kmalloci think you need to implement a thing similar to a fixture that is called once in setup overally16:08
lbragstadso - we need to reimplement useFixture?16:09
kmallocyeah a class-based one.16:09
lbragstadok - digging it up16:09
kmallocalso keep in mind the class-based one will carry state forward16:09
kmallocso, what are you trying to fix atm? DB sync?16:10
lbragstadi'm trying to implement a classmethod (setUpClass) that runs bootstrap16:10
lbragstadbootstrap currently requires some basic fixtures in place16:11
lbragstadbe in place*16:11
kmallocso we're going to be ok with carrying db state forward.16:11
kmallocbetween test cases.16:11
lbragstadbecause bootstrap is the absolute minimum of things guaranteed in a deployment16:11
lbragstadif tests need additional stuff - they should be setting that up in setUp16:12
lbragstador in the test itself16:12
kmallocright but it means if we add a user (say identity.add_user test) that new user will carry forward to subsequent tests16:12
lbragstadif we add that in the setUpClass method16:12
kmallocunless you explicitly have a cleanup/delete step16:12
kmallocso, the way i would do this is make a *new* class emthod that pulls in the db stuff (dropping the fixtures needed)16:13
kmallocand does the bootstrap, and holds onto the sqlite handle16:13
kmallocyou'll need to call it in a way to assign the value to the class and if it's been assigned noop16:14
kmallocand forget about cleaning that up, it'll GC/fall off the end when the test runs finish16:14
kmallocso something like:16:14
lbragstadthis is what i have so far16:15
lbragstadwhich is being used from
kmallocyeah yank all the fixtures apart and just implement that directly16:15
lbragstadso - to be clear, we're not using fixtures going forward?16:16
kmallocnot in the setupclass method16:16
kmallocthat is a onetime setup.16:16
kmallocthere is no teardown16:16
lbragstadthere is a tearDownClass() method16:17
kmallocnot needed16:17
lbragstadbut you're justing thinking it'll get cleaned up when nothing is referenced anymore?16:17
lbragstadjust thinking*16:17
kmallocwhen the tests exit, it should cleanup16:17
kmallocthe reason to have teardown/cleanup in a fixture is to ensure greenfield per test.16:17
lbragstadright - everything in setUpClass() should be specific to the test case running it16:17
lbragstadwell - teardown can happen at the test level (tearDown) or the class level (tearDownClass) or the module level (tearDownModule)16:18
lbragstadat least according to the brochure i'm reading16:18
kmallocsure. feel free to cleanup at the module level16:19
kmallocor the instace __del__ level16:19
kmallocbut really, should just GC when the instance/class is no longer refed.16:19
kmallocfor sure you can't use the useFixture() method16:19
kmallocso start with doing it as a single standup in your @classmethod16:20
lbragstadso we have to reimplement fixtures16:20
lbragstadall of our ksfixtures16:20
kmallocnot all.16:20
lbragstader - the basic ones16:20
kmallocjust the bootstrap related ones.16:20
kmallocbut yes16:20
lbragstaddatabase, keystone repository, configuration16:20
lbragstadkey repository*16:21
kmallocthat should be easy16:21
kmallocsince the ksfixtures already show you what they do16:21
kmallocjust migrate the code out of the fixture itself.16:21
lbragstadksfixtures is implemented to assume fixtures16:21
lbragstadfor database and key repositories, that shouldn't be bad...16:22
lbragstadbut oslo config might be different16:22
lbragstadi'm less familiar with what happens with that16:22
* lbragstad bets that bnemec probably has all the answers16:22
kmallocoslo.config will be hard.16:22
kmallocthe way oslo.config works you're going to run into issues. but in this case, mock the sql and repo paths16:23
lbragstadmock - reimplement?16:23
kmallocyou should be able to mock patch the config object, even if it isn't setup16:23
lbragstadgood ole copy/pasta16:23
kmallocall you care about is db connection string and repo paths16:24
lbragstadok - lemme give that a shot with the database and key repository fixtures16:24
kmallocthe rest of oslo config stuff will remain the same16:24
kmallocso you wont need to touch it16:24
kmallocfrankly i would mock out the key repo to be an in-memory thing that just returns the strings/keys16:25
kmallocand the dbstring you might be able to do the same by making a method called ".db_connection()" thjat just returns olso.config values16:25
kmallocit's a little more work, but would make this super easy.16:26
kmallocso insead of calling oslo.config, call a @classmethod whever you get config.sql.connection or whatever it is16:27
kmallocand mock that in your tests.16:27
kmallocor at least in bootstrap.16:28
bnemecWhy do you need to mock oslo.config? We provide a fixture so you can override config values on a per-test basis.16:28
kmallocbnemec: class-level mocking16:28
kmallocbnemec: you can't use the fixture if you rely on the config but you only want to stand up the db say once16:28
kmallocbecause that is class level not instance level.16:28
kmallocyou don't want .teardown ever called.16:28
kmallocthis is highly specific to the keystone db and key repository bits.16:29
kmallocnot *all* config values.16:29
bnemecOkay, highly keystone-specific sounds like I should go grab lunch and leave it to you. :-)16:30
kmallocbnemec: no lunch for you :P unless you're sharing with the whole channel :P16:30
kmallochave a good lunch man!16:31
* kmalloc eats breakfast.16:31
bnemecI have a feeling you might not like the result if I tried to mail food items cross-country. ;-)16:31
bnemecAlthough I recently found out you can mail ice cream, so who knows?16:32
kmallocdepends on the food items. i mean spam (in a can) probably would be fine.16:32
kmalloci also found out i can fedex ripe maui pineapples to my front door...16:32
cmurphyayoung: hrybacki: kmalloc: please fill out the poll for the m-1 review meeting
cmurphybnemec: you too if you like17:11
hrybackicmurphy: I'll be in Brno for a team hackfest both of those weeks :(17:44
cmurphyhrybacki: ah ok :(17:45
hrybackicmurphy: I'm operating life on a Julian calendar these days17:46
bnemecFilled out the poll, but don't schedule around me if it's inconvenient.18:02
openstackgerritMichael McCune proposed openstack/keystoneauth master: add handling for multiple error returns
*** pcaruana has joined #openstack-keystone18:24
openstackgerritMichael McCune proposed openstack/keystoneauth master: add handling for multiple error returns
kmalloccmurphy: filled out availability19:01
lifelesslbragstad: hi19:31
lbragstadlifeless o/19:42
lbragstadearlier i was trying to figure out if there was a setUpClass-level equivalent to useFixture for a refactor we're doing in keystone19:43
lbragstadwe 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
lbragstadi wasn't sure if what we were doing was all that common and wanted to double check with someone else19:48
lbragstadsomeone more familiar with the library*19:48
*** xek_ has quit IRC20:34
*** pcaruana has quit IRC21:18
*** itlinux has quit IRC21:23
*** whoami-rajat has quit IRC21:24
*** raildo has quit IRC21:35
openstackgerritMichael McCune proposed openstack/keystoneauth master: add handling for multiple error returns
*** jdwidari has quit IRC21:51
*** itlinux has joined #openstack-keystone22:42
openstackgerritMichael McCune proposed openstack/keystoneauth master: add handling for multiple error returns
openstackgerritMichael McCune proposed openstack/keystoneauth master: add handling for multiple error returns
*** tkajinam has joined #openstack-keystone23:05
*** rcernin has joined #openstack-keystone23:17

Generated by 2.15.3 by Marius Gedminas - find it at!