Friday, 2019-03-01

openstackgerritChris Dent proposed openstack/osc-placement master: Update tox and tests to work with modern setups  https://review.openstack.org/63971700:06
openstackgerritChris Dent proposed openstack/osc-placement master: Add support for 1.18 microversion  https://review.openstack.org/63973800:06
*** mriedem is now known as mriedem_away00:26
*** ttsiouts has quit IRC01:17
*** mriedem_away has quit IRC02:40
*** bhagyashris has joined #openstack-placement03:58
openstackgerritEric Fried proposed openstack/osc-placement master: Update tox and tests to work with modern setups  https://review.openstack.org/63971704:12
openstackgerritEric Fried proposed openstack/osc-placement master: Add support for 1.18 microversion  https://review.openstack.org/63973804:15
*** tetsuro has joined #openstack-placement04:53
openstackgerritMerged openstack/osc-placement master: Update tox and tests to work with modern setups  https://review.openstack.org/63971705:26
*** tetsuro has quit IRC06:20
*** e0ne has joined #openstack-placement07:28
*** tetsuro has joined #openstack-placement07:28
*** takashin has left #openstack-placement07:36
*** rubasov has quit IRC08:00
*** tetsuro has quit IRC08:01
*** tssurya has joined #openstack-placement08:25
*** mcgiggler has joined #openstack-placement08:39
*** ttsiouts has joined #openstack-placement08:56
*** rubasov has joined #openstack-placement09:00
*** bhagyashris has quit IRC09:49
*** rubasov has quit IRC10:07
*** rubasov has joined #openstack-placement10:09
*** cdent has joined #openstack-placement10:15
*** e0ne has quit IRC10:22
cdentmornin10:23
*** e0ne has joined #openstack-placement10:23
*** e0ne has quit IRC11:11
*** cdent has quit IRC11:12
*** e0ne has joined #openstack-placement11:14
*** ttsiouts has quit IRC11:18
*** cdent has joined #openstack-placement11:20
openstackgerritTetsuro Nakamura proposed openstack/placement master: Refactor _get_trees_matching_all()  https://review.openstack.org/63988811:40
openstackgerritTetsuro Nakamura proposed openstack/placement master: Adds debug log in allocation candidates  https://review.openstack.org/63988911:40
*** e0ne has quit IRC11:49
*** ttsiouts has joined #openstack-placement11:51
*** gibi is now known as giblet12:45
*** e0ne has joined #openstack-placement12:50
cdentefried: that ↑ is on my list, at first glance there's a fair bit of difference between the other *LIst classes and the one introduced there, so probably fine13:06
cdentalso, did you not go to bed, or stay up late, or get up early or some other kind of weird sleep13:07
cdentI put a special section in the pupdate just for mriedem13:19
efriedcdent: Yes, the RPCandidates list thingy is definitely not like our ex-OVO lists. I think it adds value. I'm not sure it's perfect in its current form, but it's better than what was there, as described in the commit message (p[N] list comps everywhere).13:30
efriedcdent: and, I've started doing more reviews on my phone, to try to keep up a bit better; so I go through a bunch of my openstack mail at odd times.13:31
cdentgerrit? on your phone? Or are you viewing with something else?13:32
*** mriedem has joined #openstack-placement13:32
efriedyeah, just review.o.o on safari on iphone.13:33
cdenthuh. that sounds painful.13:34
efriedI don't try to do it for large or complicated reviews, because I make no attempt to go look at code repositories there. But for small changes or incremental patch set updates it's okay.13:34
efriedMain objective is to delete emails.13:34
efriedwhich makes my time in front of real computer more productive13:35
sean-k-mooneycdent: what did ye replace OVOs with? json schema?13:36
efriedsean-k-mooney: PODs13:36
cdentsean-k-mooney: python. we don't need rpc in placement13:37
sean-k-mooneyah os no validation13:37
efriedexcept the lists, which are lists.13:37
sean-k-mooneyovo are not just for rpc13:37
cdentthe validation happens at the http api level, so yes, jsonschema, but that was already there13:37
sean-k-mooneybut ok13:37
efriedmore ovorhead than we needed13:37
efriedsee what I did there13:37
cdentsmh13:37
sean-k-mooneywe have discussed the idea of dropping ovo in os-vif but we still wanted a schema validation layer which is why i asked13:38
sean-k-mooneyfor now we are sticking with ovos13:38
cdentsean-k-mooney: the reason we used ovo in the first place was because of a "maybe someday there will be an rpc or other kind of objecty interface", but enough time has passed to say "no" to that13:38
cdentI think if you have an object interface that needs validation within that interface, ovo can make some sense13:39
sean-k-mooneyya that was/is on the cards for os-vif but aparenetly peopel dont like the idea of ovo over the rest api13:39
sean-k-mooneywhich if that is not going to happen in the future for os-vif raise the question do we need ovo at all13:40
sean-k-mooneyany thank back to reading your placement update13:40
* cdent nods13:40
cdentThe performance characteristics for the change measured there is probably not normal for many uses of ovo13:41
sean-k-mooney* anyway thanks13:41
sean-k-mooneyya maybe13:41
cdentthat's a response of /allocation_candidates from a set of 1000 resource providers13:41
cdentand with multiple objects created for each provider13:41
sean-k-mooneynot needint to add backleveling code would be nice however13:41
sean-k-mooneyovo have a lot of developer over head too13:41
efriedcdent: I don't think in_tree[N] was for bandwidth. It was for things like force-host and resize-to-same-host.13:43
gibletefried: in_tree in a_c can be used to attach ports with bandwidth to a running server13:43
cdentefried: please say so. It's hard to remember everything when there isn't a consistent thread of dialog (which is the real (unfulfilled) reason that I do the pupdates)13:44
sean-k-mooneygiblet: it can be but the motivating usecase wes for fost-host13:44
efriedgiblet: Ah, yeah, that makes sense.13:45
efriedand...13:45
*** efried is now known as fried_rice13:45
sean-k-mooneyfried_rice: beyond traditon do you thing the friday nics actully work to reduce the amount of pings cores get on fridays so they can focus on getting things done13:46
sean-k-mooneyfried_rice: i still like it but most people who are active on irc know the firday nics too13:47
cdentwas that the reason?13:47
cdentI thought it was to create an exclusionary and elitist club?13:47
cdentA fraternity of sorts13:47
gibletcasual friday maybe13:48
sean-k-mooneyi think it stared when jaypipes or one of the cores said they were going into bunker mode to get something done and it just became a thing13:49
sean-k-mooneyits been long enough that i dont remember the details13:49
* cdent thinks maybe we should clone both tetsuro and giblet 13:53
edleafeIt started as a joke about "casual Fridays". Since we're virtual, we had "casual nick Fridays"13:57
edleafeBut since then it has morphed to more of an insider thing, which is why I stopped using mine.13:57
* edleafe runs off to PT13:58
fried_ricecdent: I did it to play along, didn't really give it any deep thought.14:04
cdentI'm 1/3 joking above, but I'm definitely aware of loads of people who have found it exclusionary14:04
fried_riceHaving experienced it first as an outsider, I agree it was confusing. But it's not, like, secret or anything, and it doesn't take much to figure out, and (I think) it's "fun".14:05
fried_riceit's not exclusionary - anyone can have a friday nick.14:06
cdentour experience isn't the one that really matters here. it's the experience of people who have felt excluded by it14:06
cdentand I take people at their word when me tell me that14:06
fried_riceyeah, fair enough.14:06
* cdent goes to check why that osc-placement thing failed14:08
*** Sundar has joined #openstack-placement14:08
fried_ricecdent: ^ probably need a global trait cache :P14:08
fried_riceo/ Sundar14:08
* cdent kills all caches14:09
Sundaro/ Eric14:09
SundarHi cdent14:09
cdentI did try at one point to get rid of the string_to_id stuff but it was too embedded14:09
cdenthi Sundar14:09
SundarDid i stumble into some involved talk on trait caches?14:10
cdentthankfully no14:12
cdenti was being taunted by an overcooked bowl of fried_rice14:12
fried_riceovercooked? overcooked?!14:13
fried_riceI guess it could be worse, I could be half-baked.14:13
Sundarcdent: Thanks very much for taking the time to review.14:15
Sundarcdent: Unfortunately -- for you -- I have more responses and questions. If you don't mind.14:16
*** mcgiggler has quit IRC14:17
cdentSundar: no problem, can you remind me of the etherpad link please?14:18
fried_ricecdent: #link https://etherpad.openstack.org/p/nova-cyborg-api-objects14:20
cdentthanks14:20
cdentSundar: I'll respond on the etherpad14:21
Sundarcdent: One question to be highlighted: the APIs return a links field, with self and other links. That is of the form /resource/uuid for a specific object. Could I return /resource?property=value ?14:30
fried_ricehm, it seems like it would be weird for a link to contain a querystring14:31
cdentit does seem weird, but strictly speaking it is not wrong. From the web's standpoint the URI is the entire string14:31
fried_riceis it still not wrong if that link returned multiple resources?14:32
Sundarfried_rice: We return the URI for a specific object in the links.14:32
fried_riceright, I get it, but to me ?property=value generically looks like a search which might have the potential to return multiple results. For a specific key I get that it would be unique.14:34
Sundarfried_rice: i..e if you ask GET /device_profiles?name=mydp, the response contains a URI for that. Whereas, if you ask GET /device_profiles, I believe there is a generic href but not for any specific object or a collection.14:34
fried_riceyeah, so as long as the API has a constraint that device_profile.name is globally unique, that ^ returns at most one result.14:34
cdentI think the question needs to be around wether the structure of the response is of one resource or a list of one resource14:37
cdentif it is a list that's probably not ideal14:37
cdentbut, however14:37
cdentsince it appears to be a filtering operation it should be a list14:37
cdentthat's why I think it is important to have /device_profiles?filter and /device_profiles/{uuid} be different things with different structures14:38
cdent /device_profiles?{filter} should probalby always be a list14:38
cdentThe key thing here is to have a consistent grammar14:38
cdent(which I think the document pretty much does, so mostly we are talking about the future, not about the now)14:39
fried_ricethis is what I was getting at, yes14:41
Sundarcdent: IIUC, based on your comments in the doc and here, you seem to be kinda-sorta ok with the current API? If I add the proviso that we have versioning (and possibly microversioning), could we keep it as is *for now*? We could evolve it in the future based on operator feedback, but just trying to avoid having too many APIs to start with.14:43
fried_rices/possibly//14:44
fried_riceIMO setting up for microversioning is a must14:44
fried_ricetrying to use major versions is too much of a PITA, which is the whole reason microversions exist.14:45
cdentSundar: yes, as I said at the start: no red flags, just some things to think about as things evolve. As far as I can tell you're not painting yourself into bad corners14:45
Sundarfired_rice: ha -- I expected that! I am open to it. Seems like a good idea. It's just me being paranoid about what we are going to get done.14:45
Sundarfried_rice: ^14:46
cdentas fried_rice and I discussed yesterday, you can lay in a basic frame for future microversions without too much difficulty14:46
cdenthowever, one thing we didn't talk about is that I sometimes wish we had put off stamping the major version in placement until a bit later14:46
cdentplacement doesn't really "work" until about 1.11 or so14:47
fried_ricein this case we're intending v2.0 of the cyborg API will "work" for the initial pass of the nova integration code.14:48
cdentI'm glad we're all nice and conscious of fragile notion of our work "working"14:49
openstackgerritChris Dent proposed openstack/osc-placement master: Add support for 1.18 microversion  https://review.openstack.org/63973814:50
cdentfried_rice, mriedem ↑ should fix the intermittent failure but I haven't tested it yet as I don't have access to a cloud from where I am right now14:50
Sundarcdent, fried_rice: Cyborg folks already released v1 APIs in Rocky. So, we have to start with v2. So, yes, v2.0 would be the first to work with Nova. What is the equivalent of "put off stamping the major version"?14:51
fried_ricesort of.14:52
cdentI should clarify: we built microversioning into placement into the very start, and versioned changes to the api even before anything was using placement.14:52
cdentWhat I'm saying is that I think that was overkill14:52
cdentWhat we should have done was started versioning at the point at which there was a first client14:53
cdent(declared that moment in time 1.0)14:53
fried_ricecdent: what you're saying is, we could have just merged API changes to placement without bumping microversions, calling the whole API a WIP, until we got to the point where it was usable, at which point we could have said "no longer a WIP" and called that v1.0.14:53
cdentyes14:53
fried_ricemm14:53
cdentthat's only okay to do when there are no users14:54
cdentwhich was true initially14:54
cdentmelwitt: this change to use storyboard will probaby need your stamp: https://review.openstack.org/#/c/639445/14:57
*** jaypipes is now known as leakypipes15:01
melwittcdent: ok, will look15:02
cdentthanks15:02
*** Sundar is now known as DarthNau15:03
melwittdoes anyone know how to run osc-placement functional tests locally in a devstack? when I do a "source openrc admin admin" and then "tox -efunctional" I get weird errors like "'too few arguments' not in u"openstack: 'resource provider inventory set' is not an openstack command."15:31
cdentmelwitt: are you up to date with the recently mered (yesterday) fixes?15:35
cdentthere were lots of python3 problems that ought to be fixed15:35
melwittmaybe not15:35
melwittok, let me get them. thanks15:35
*** e0ne has quit IRC15:38
cdentmelwitt: are you working in python3 or 2? If 2, then something else is likely wrong. But if 3, then yeah, it never worked (until yesterday`)15:39
*** belmoreira has quit IRC15:39
*** e0ne has joined #openstack-placement15:39
melwittcdent: python3. working now, thank you15:42
cdenthuzzah!15:42
openstackgerritChris Dent proposed openstack/placement master: Factor listiness into an ObjectList base class  https://review.openstack.org/63732515:52
openstackgerritChris Dent proposed openstack/placement master: Move _set_objects into ObjectList  https://review.openstack.org/63732815:52
openstackgerritChris Dent proposed openstack/placement master: Move *List.__repr__ into ObjectList  https://review.openstack.org/63733215:52
openstackgerritChris Dent proposed openstack/placement master: Clean up ObjectList._set_objects signature  https://review.openstack.org/63733515:52
openstackgerritChris Dent proposed openstack/placement master: Move RC_CACHE in resource_class_cache  https://review.openstack.org/64011415:52
openstackgerritChris Dent proposed openstack/placement master: Use native list for lists of Usage  https://review.openstack.org/63939115:52
openstackgerritChris Dent proposed openstack/placement master: Move Allocation and AllocationList to own module  https://review.openstack.org/64018415:52
openstackgerritChris Dent proposed openstack/placement master: Make base test case file for object unit tests  https://review.openstack.org/64040615:52
*** tssurya has quit IRC15:59
leakypipesedleafe, sean-k-mooney, cdent: if one cannot have a little fun on Fridays, then what kind of world are we living in? :)16:01
cdenta dark and dismal one where brexit and trump exist?16:02
sean-k-mooneyouch16:03
sean-k-mooneycdent: your wit is sharp today16:04
cdentcoffee is working?16:04
sean-k-mooneyperhaps. politics is depressing currently? always?16:05
cdentI think it is because dr fried_rice sent me to get antibiotics and they are working16:05
* fried_rice tries to decide whether he wants that credit/blame16:06
cdentlife is hard16:10
*** e0ne has quit IRC16:14
*** e0ne has joined #openstack-placement16:15
*** e0ne has quit IRC16:17
fried_ricecdent: https://review.openstack.org/#/c/640184/ -- I can take a whack at factoring increment_provider_generation and slotting it in under that patch if you like.16:24
fried_ricefactoring out*16:24
fried_riceunless you're already embroiled16:24
cdentfried_rice: I'm not currently doing that, I'm doing the next step: killing AllocationList16:25
cdentthe exist of which is part of why I'm not too fussed about that ^ one being super clean (although I haven't read your commets yet)16:26
fried_ricecdent: okay, then I need to avoid changing the commit order. I'll put it on top for now and we can slot it in later (or not)16:26
cdentcool16:26
fried_ricecdent: I did note the one non-clean place that I figured was going away in 'kill AllocationList' - I'm okay leaving that one alone. The others (indents broken by renaming module) I think should be fixed here.16:27
cdentI'm not clear how a cut and paste can break an indent?16:27
fried_ricebecause you renamed a module, and the new name had a different length16:28
fried_riceso param lists aligned on that opening paren were shifted.16:28
fried_rice...which I suppose would be one reason to avoid that particular indent style in the first place, if one were inclined to be so anal at coding time. Cause it's not a pep violation until the refactor. (And at the moment it's not a pep violation at all because we're ignoring that rule.)16:29
openstackgerritMerged openstack/osc-placement master: Add support for 1.18 microversion  https://review.openstack.org/63973816:30
cdentoh16:31
fried_riceleakypipes: cdent: uhm, how do you feel about _increment_provider_generation(ctx, rp) being ResourceProvider.increment_generation(self) (using self._context) ?16:32
cdentfried_rice: how would you feel if we stop doing that horrible indent style that I keep breaking?16:32
cdentfried_rice: I'd be somewhat meh about that because it is not _that_ resource providers generation we are changing16:33
fried_riceI would be fine with it, though it would be challenging to (remember to) enforce. I also suggested inline that we switch off some of those pep ignores.16:33
cdentis it?16:33
fried_riceyes, absolutely.16:33
* cdent defers to leakypipes 16:34
cdentI don't have a strong opinion16:34
fried_riceit's not a classmethod, it's an instance method.16:34
fried_ricethis_rp.increment_generation()16:34
* fried_rice tries it16:34
cdentyeah, if it is an instance that's being inc'd I'd be fine with it16:34
cdentI had thought we were perhaps not in an object context, just an id, but I guess to have generation at all, we must be16:35
fried_ricethe only question is whether to use the context or pass from caller.16:36
fried_riceare they gonna be the same?16:36
fried_ricereally just needs to be a context that has a session in it.16:37
fried_riceWhich is what all of these contexts are for, right?16:37
fried_ricewe already have this for consumer (except it calls the _increment_consumer_generation method - will collapse that too)16:39
openstackgerritEric Fried proposed openstack/placement master: ResourceProvider.increment_generation()  https://review.openstack.org/64043316:43
fried_ricecdent, leakypipes: ^16:43
cdentit's the same conrtext16:44
fried_riceschweet16:46
fried_ricehm, why does _increment_consumer_generation have a @writer decorator on it, but _increment_provider_generation didn't?16:47
*** DarthNau has quit IRC16:47
cdentpresumably everything that calls inc_gen already has a writer on it16:48
cdentand it is likely that everything that call inc consumer does too16:48
cdentbut it was added anyway16:48
cdentwe should probably make sure16:49
cdentbut in most cases it is probably right to not waste the time16:49
cdentmore rocks, more bugs16:49
fried_riceDoes16:50
fried_rice @writer16:50
fried_rice ...16:50
fried_rice     @writer16:50
fried_rice     ...16:50
fried_ricedo anything or is the second one a no-op?16:50
fried_rice...as long as not .independent16:51
*** Sundar has joined #openstack-placement16:52
fried_ricehah, it's only called from one place. And it's right next to a rp.increment_generation. And that method is wrapped in a writer. This should be an easy refactor.16:52
cdentI used to think that @writer @writer opened another transactin within the existing one but last I heard that's not the case16:53
cdentI'm not 100% on that though16:54
fried_riceunrelated, tox -e py27 on the placement repo is now so quick it registers as 0.00000 seconds to stestr.16:55
cdent\o/16:55
fried_riceThe overall wallclock is still ~4.5s with the tox overhead. But that's acceptable.16:56
cdentI'm getting .2 seconds16:56
* cdent time to get a better computer16:57
openstackgerritEric Fried proposed openstack/placement master: Inline Consumer.increment_generation()  https://review.openstack.org/64043716:57
fried_ricecdent: ^16:57
cdentseems fair17:00
melwittin nova, we avoid nesting the database transaction contexts. you will have a problem if your outer method has @reader and the inner has @writer (we had a bug with that in the past by an accidental nest)17:01
melwittso just be on the lookout for that17:02
*** ttsiouts has quit IRC17:06
openstackgerritChris Dent proposed openstack/placement master: WIP: Use native list of list of Allocation  https://review.openstack.org/64045017:20
cdentfried_rice: you're going to find that cringey. leakypipes you might like it17:21
fried_riceack17:21
cdentit's not done because of the issues in the parent, but I need to go deal with dinner and related stuff17:21
stephenfincdent, fried_rice: bauzas noted that there was an issue with placement in Queens where the request IDs didn't match what nova was using. Any chance you know what the bug report for that was?17:24
cdentstephenfin: do you mean that nova wasn't passing along the request id to placement, or that the form of the ids that placement had was wrong?17:25
stephenfinThe former, I suspect17:25
stephenfinYou couldn't take the request ID from nova logs and simply grep for that in placement logs, to correlate what placement was doing for that request17:26
cdentstephenfin: maybe this: https://bugs.launchpad.net/nova/+bug/165209917:26
openstackLaunchpad bug 1734625 in OpenStack Compute (nova) queens "duplicate for #1652099 placement: Request IDs are not passed to placement service" [Medium,Fix committed] - Assigned to Takashi NATSUME (natsume-takashi)17:26
stephenfincdent++ That looks like the one17:27
cdentand this: https://bugs.launchpad.net/nova/+bug/173462517:27
openstackLaunchpad bug 1734625 in OpenStack Compute (nova) queens "placement: Request IDs are not passed to placement service" [Medium,Fix committed] - Assigned to Takashi NATSUME (natsume-takashi)17:27
cdentoh sorry, I guess the bot did that for me17:28
stephenfinclever bot17:28
* cdent goes home17:28
* cdent waves17:28
stephenfino/17:28
*** cdent has quit IRC17:28
fried_ricestephenfin:  this and associated bug? I306ac6f5c6b67d77d91a7ba24d4d863ab3e1bf5c17:29
fried_ricehttps://review.openstack.org/#/c/531299/17:29
fried_riceyeah, the bug cdent said17:29
stephenfinYup. I think that's the one17:30
*** mriedem is now known as mriedem_lunch17:56
*** edleafe_ has joined #openstack-placement18:09
*** irclogbot_2 has joined #openstack-placement18:10
*** cdent has joined #openstack-placement18:58
*** cdent has quit IRC18:58
*** e0ne has joined #openstack-placement19:12
*** purplerbot has quit IRC19:18
*** purplerbot has joined #openstack-placement19:18
*** mriedem_lunch is now known as mriedem19:28
*** e0ne has quit IRC19:31
*** edleafe_ has quit IRC19:36
openstackgerritMerged openstack/placement master: Use set instead of list  https://review.openstack.org/63988719:49
*** irclogbot_2 has quit IRC19:49
*** irclogbot_2 has joined #openstack-placement20:01
*** e0ne has joined #openstack-placement20:05
*** Sundar has quit IRC20:13
openstackgerritEric Fried proposed openstack/placement master: ResourceProvider.increment_generation()  https://review.openstack.org/64043321:35
openstackgerritEric Fried proposed openstack/placement master: Move Allocation and AllocationList to own module  https://review.openstack.org/64018421:35
openstackgerritEric Fried proposed openstack/placement master: Inline Consumer.increment_generation()  https://review.openstack.org/64043721:35
*** irclogbot_2 has quit IRC21:38
openstackgerritEric Fried proposed openstack/placement master: ResourceProvider.increment_generation()  https://review.openstack.org/64043321:50
openstackgerritEric Fried proposed openstack/placement master: Move Allocation and AllocationList to own module  https://review.openstack.org/64018421:50
openstackgerritEric Fried proposed openstack/placement master: Inline Consumer.increment_generation()  https://review.openstack.org/64043721:50
openstackgerritEric Fried proposed openstack/placement master: Move reshape() into placement.tasks.reshaper  https://review.openstack.org/64054021:50
mriedemfried_rice: can we mark this complete now? https://blueprints.launchpad.net/nova/+spec/alloc-candidates-in-tree21:59
fried_ricemriedem: Did the spec update merge?21:59
mriedemnot yet21:59
fried_ricemelwitt was talking about marking it complete anyway.21:59
fried_riceup to you.21:59
fried_riceThe code is done21:59
mriedemdone22:00
fried_rice\o/22:00
openstackgerritEric Fried proposed openstack/placement master: WIP: Use native list of list of Allocation  https://review.openstack.org/64045022:02
openstackgerritEric Fried proposed openstack/placement master: Inline Consumer.increment_generation()  https://review.openstack.org/64043722:02
openstackgerritEric Fried proposed openstack/placement master: Move Allocation and AllocationList to own module  https://review.openstack.org/64018422:20
openstackgerritEric Fried proposed openstack/placement master: WIP: Use native list of list of Allocation  https://review.openstack.org/64045022:20
openstackgerritEric Fried proposed openstack/placement master: Inline Consumer.increment_generation()  https://review.openstack.org/64043722:20
*** e0ne has quit IRC22:24
*** guilhermesp__ has joined #openstack-placement22:45
*** guilhermesp has quit IRC22:52
*** melwitt has quit IRC22:52
*** guilhermesp__ is now known as 18WAAFJGJ22:52
*** melwitt has joined #openstack-placement22:53
*** mriedem is now known as mriedem_afk23:08
openstackgerritEric Fried proposed openstack/placement master: Remove pep8 whitespace ignores  https://review.openstack.org/64055423:37
openstackgerritEric Fried proposed openstack/placement master: Nit collector  https://review.openstack.org/64055523:47
openstackgerritEric Fried proposed openstack/placement master: Factor listiness into an ObjectList base class  https://review.openstack.org/63732523:56
openstackgerritEric Fried proposed openstack/placement master: Move _set_objects into ObjectList  https://review.openstack.org/63732823:56
openstackgerritEric Fried proposed openstack/placement master: Move *List.__repr__ into ObjectList  https://review.openstack.org/63733223:56
openstackgerritEric Fried proposed openstack/placement master: Clean up ObjectList._set_objects signature  https://review.openstack.org/63733523:56
openstackgerritEric Fried proposed openstack/placement master: Move RC_CACHE in resource_class_cache  https://review.openstack.org/64011423:56
openstackgerritEric Fried proposed openstack/placement master: Use native list for lists of Usage  https://review.openstack.org/63939123:56
openstackgerritEric Fried proposed openstack/placement master: Make base test case file for object unit tests  https://review.openstack.org/64040623:56
openstackgerritEric Fried proposed openstack/placement master: Move reshape() into placement.tasks.reshaper  https://review.openstack.org/64054023:56
openstackgerritEric Fried proposed openstack/placement master: ResourceProvider.increment_generation()  https://review.openstack.org/64043323:56
openstackgerritEric Fried proposed openstack/placement master: Move Allocation and AllocationList to own module  https://review.openstack.org/64018423:56
openstackgerritEric Fried proposed openstack/placement master: WIP: Use native list of list of Allocation  https://review.openstack.org/64045023:56
openstackgerritEric Fried proposed openstack/placement master: Inline Consumer.increment_generation()  https://review.openstack.org/64043723:56
openstackgerritEric Fried proposed openstack/placement master: Remove pep8 whitespace ignores  https://review.openstack.org/64055423:56
openstackgerritEric Fried proposed openstack/placement master: Nit collector  https://review.openstack.org/64055523:56

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!