Wednesday, 2018-07-11

openstackgerritTakashi NATSUME proposed openstack/nova master: Transform metrics.update notification  https://review.openstack.org/58056700:23
openstackgerritMerged openstack/nova master: update project/user for consumer in allocation  https://review.openstack.org/58113900:53
*** edmondsw has joined #openstack-placement01:05
*** edmondsw has quit IRC01:09
openstackgerritMatt Riedemann proposed openstack/nova master: Update some placement docs to reflect modern times  https://review.openstack.org/58115101:33
openstackgerritMerged openstack/nova master: unquiesce instance after quiesce failure  https://review.openstack.org/55086501:34
openstackgerritGhanshyam Mann proposed openstack/nova master: Use hard coded values in schema than reference  https://review.openstack.org/58128801:34
*** yikun has joined #openstack-placement01:52
*** mriedem has left #openstack-placement02:00
*** mriedem has joined #openstack-placement02:01
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add policy to InstanceGroup object  https://review.openstack.org/56337502:07
openstackgerritMatt Riedemann proposed openstack/nova master: Fix TypeError in prep_resize allocation cleanup  https://review.openstack.org/58154802:13
openstackgerritBrin Zhang proposed openstack/nova master: Add unshelve instance error info to fault table  https://review.openstack.org/57974702:15
*** tetsuro has joined #openstack-placement02:15
openstackgerritLei Zhang proposed openstack/nova master: Add method to get cpu traits  https://review.openstack.org/56031702:25
*** mriedem has quit IRC02:28
openstackgerritBrin Zhang proposed openstack/nova master: Add unshelve instance error info to fault table  https://review.openstack.org/57974702:34
*** edmondsw has joined #openstack-placement02:53
openstackgerritMerged openstack/nova master: Remove unused variable in migration  https://review.openstack.org/58146402:56
*** edmondsw has quit IRC02:57
openstackgerritZhenyu Zheng proposed openstack/nova master: Use ThreadPoolExecutor for max_concurrent_live_migrations  https://review.openstack.org/56350502:58
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add policy field to ServerGroup notification object  https://review.openstack.org/56340103:00
openstackgerritZhenyu Zheng proposed openstack/nova master: Compute: add support to abort queued live migration  https://review.openstack.org/56854204:05
openstackgerritZhenyu Zheng proposed openstack/nova master: Fix ServerMigrationSampleJsonTestsV2_24 to use its own sample file  https://review.openstack.org/58156204:18
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add policy field to ServerGroup notification object  https://review.openstack.org/56340104:22
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Change the ServerGroupAntiAffinityFilter to adapt to new policy  https://review.openstack.org/57116604:22
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Adapt _validate_instance_group_policy to new policy model  https://review.openstack.org/57146504:22
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Microversion 2.64 - Use new format policy in server group  https://review.openstack.org/56753404:22
*** deepak_mourya has joined #openstack-placement05:05
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add policy field to ServerGroup notification object  https://review.openstack.org/56340105:11
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Change the ServerGroupAntiAffinityFilter to adapt to new policy  https://review.openstack.org/57116605:11
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Adapt _validate_instance_group_policy to new policy model  https://review.openstack.org/57146505:11
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Microversion 2.64 - Use new format policy in server group  https://review.openstack.org/56753405:11
*** e0ne has joined #openstack-placement05:16
*** e0ne has quit IRC05:19
openstackgerritMerged openstack/nova master: Update some placement docs to reflect modern times  https://review.openstack.org/58115105:28
*** takashin has left #openstack-placement05:30
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/57801906:45
*** e0ne has joined #openstack-placement07:11
*** tssurya has joined #openstack-placement07:12
*** bhagyashri_s has quit IRC07:12
*** e0ne has quit IRC07:16
*** peereb has joined #openstack-placement07:17
*** e0ne has joined #openstack-placement07:19
openstackgerrithuanhongda proposed openstack/nova-specs master: Add .idea folder to .gitignore  https://review.openstack.org/58161107:37
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Microversion 2.64 - Use new format policy in server group  https://review.openstack.org/56753407:50
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Address nit in afc7650e64753ab7687ae2c4f2714d4bb78a4e5a  https://review.openstack.org/58161607:58
*** ttsiouts has joined #openstack-placement08:01
*** belmoreira has joined #openstack-placement08:13
openstackgerritZhenyu Zheng proposed openstack/nova master: Compute: add support to abort queued live migration  https://review.openstack.org/56854208:16
openstackgerritZhenyu Zheng proposed openstack/nova master: Fix ServerMigrationSampleJsonTestsV2_24 to use its own sample file  https://review.openstack.org/58156208:26
*** belmoreira has quit IRC08:26
*** belmoreira has joined #openstack-placement08:33
openstackgerritLee Yarwood proposed openstack/nova stable/ocata: libvirt: slow live-migration to ensure network is ready  https://review.openstack.org/55903409:12
openstackgerrithuanhongda proposed openstack/nova-specs master: Return "deleted" time of instance when vm_state is SOFT-DELETED  https://review.openstack.org/58163809:13
*** tetsuro has quit IRC09:29
*** belmoreira has quit IRC09:43
*** cdent has joined #openstack-placement09:44
*** belmoreira has joined #openstack-placement09:48
*** belmoreira has quit IRC09:57
*** ttsiouts has quit IRC10:04
*** ttsiouts has joined #openstack-placement10:06
*** ttsiouts has quit IRC10:10
openstackgerritTakashi NATSUME proposed openstack/nova master: Transform metrics.update notification  https://review.openstack.org/58056710:19
openstackgerritLee Yarwood proposed openstack/nova stable/ocata: libvirt: slow live-migration to ensure network is ready  https://review.openstack.org/55903410:28
openstackgerrithuanhongda proposed openstack/nova master: Microversion 2.64 - Add "deleted" time in GET server response  https://review.openstack.org/57415910:28
openstackgerritVan Hung Pham proposed openstack/nova master: convert py35 jobs to py3  https://review.openstack.org/58166310:44
openstackgerritSurya Seetharaman proposed openstack/nova master: Update queued-for-delete from the ComputeAPI during deletion.  https://review.openstack.org/56681310:46
openstackgerritSurya Seetharaman proposed openstack/nova master: Update queued-for-delete from the ComputeAPI during deletion/restoration  https://review.openstack.org/56681310:48
*** ttsiouts has joined #openstack-placement11:04
openstackgerrithuanhongda proposed openstack/nova master: Microversion 2.64 - Add "deleted" time in GET server response  https://review.openstack.org/57415911:28
*** e0ne has quit IRC12:03
*** e0ne has joined #openstack-placement12:22
*** edmondsw has joined #openstack-placement12:27
*** mriedem has joined #openstack-placement12:33
*** ttsiouts has quit IRC12:36
cdentmriedem, jaypipes : Is there a reason in install (not upgrade) docs we have people sync the database (run migrations), instead of allowing an option to base.metadata.create_all(engine)? Is it because we might have a migration that adds some required rows to even empty tables? Something else?12:39
jaypipescdent: good question. I *think* that we do that mostly to have a single, consistent DB setup/migrate/upgrade step. But not entirely sure, tbh12:41
*** e0ne has quit IRC12:41
mriedemi don't really understand the question12:42
mriedemwhat is base.metadata.create_all?12:42
cdentit creates all the tables12:42
jaypipesmriedem: it's the "normal" way of creatring the DB schema via SQLAlehcmy12:42
mriedemthe first migration also does that12:42
jaypipesmriedem: the first migration creates the *original* schema definition for the tables, and the following migrations change those definitions.12:43
mriedem216_havana or whatever12:43
jaypipesmriedem: right, at the start of each release we have a "savepoint"-like schema migration12:43
mriedemis the question why don't we just throw the models at sqla and have it do the migration rather than go through sqlalchemy-migrate?12:43
cdentIt came up because of the issues I was having yesterday with not being able to get some of the migrations to work, so thought: I don't care about migrations, I care about tables. So I did this: https://github.com/cdent/placedock/commit/b5ca753a0d97e0d9a324e196349e3a19eb62668b12:43
cdentmriedem: no the question is: we have table definitions in api_models.py (etc) so we can use those. we don't need to migrate.12:44
mriedemi think i'm asking the same question but w/o the proper words,12:45
mriedemand i think (forgot his name, guy from rax that did db stuff) at one point we were going down that route12:45
cdentOnce I did that, I thought: hmmm, I wonder if we can speed up any of our tests? And: I wonder if we could provide a lighter weight install for people12:45
mriedembut then it fell through12:45
cdent(not that the migrations are slow when the db is empty or anything, but they _do_ fail when you try to use weird dbs)12:46
openstackgerritMatt Riedemann proposed openstack/nova master: Skip ServerShowV257Test.test_rebuild_server for cells v1 job  https://review.openstack.org/58171712:49
cdentmriedem, jaypipes : is having a create_db command something we should consider for...$random_future?12:49
mriedemdansmith might remember what i'm trying to remember12:49
mriedemcreate_db as in create the actual database?12:50
cdentsorry create_db_tables12:51
*** ttsiouts has joined #openstack-placement12:51
*** e0ne has joined #openstack-placement12:51
*** e0ne has quit IRC12:52
mriedemi wanna say a guy was working on that so you could run things with alembic(?) but again, this was years ago and fell through12:53
*** e0ne has joined #openstack-placement12:55
*** belmoreira has joined #openstack-placement12:58
*** belmoreira has quit IRC12:59
jaypipescdent: I'd have to think about that for a bit.13:01
*** openstack has joined #openstack-placement13:06
*** ChanServ sets mode: +o openstack13:06
openstackgerritsahid proposed openstack/nova stable/queens: hardware: fix hugepages memory usage per intances  https://review.openstack.org/58173613:06
jaypipescdent, mriedem: "savepoint migrations" things like 206_havana etc13:07
jaypipesthe "consolidated migration" thingees13:07
jaypipessorry, terminology sucks13:07
cdentjaypipes: I'm aware of that file, but I don't understand how it fits in with, or compares to, doing a metadata.create_all()?13:09
mriedemit creates all the tables13:10
mriedemit was a compression of all of the db migrations up to havana13:11
mriedemwe haven't done one of those since though13:11
mriedemand we were told years ago that operators didn't like those compressed migrations anyway13:11
jaypipesoh? I thought for some reason we did that at each release... shows you how much I follow this.13:11
mriedemi forget the exact reasons why, might have had to do with skip level migrations13:11
mriedemsdague brought it back as feedback from an ops thing years ago13:12
cdenthmmm. I'm still confused. 216_havanna is huge. But you can create all the tables in three lines of code (assuming you already have the classes in the *models.py)13:13
mriedemcdent: yes and that's the thing i'm saying the guy from rax was doing13:13
mriedemi forget the name and forget why it was dropped - not sure if it works still or not13:13
mriedembut work was put into making that happen13:13
mriedembecause years ago it wasn't possible for some reason13:14
cdentyeah, my question was more directed at jaypipes saying "useful to have ... savepoint"13:14
mriedemprobably due to models that didn't match the migrations13:14
mriedemsavepoint isn't really a thing,13:14
mriedemwe don't do compacted migrations anymore,13:14
mriedemand we don't do downgrades13:14
mriedemi want to say we have a test (somewhere - maybe it's a fixture from oslo.db) that compares the schema *after* running the migration scripts to the models13:15
mriedemand fails if those aren't aligned13:15
mriedemso that one *can* deploy from just the models w/o running the scripts13:15
mriedemthe other thing you can't do with just the models on upgrades is stuff where we did blocker migrations, like in ocata13:16
mriedemwhich is necessary for times when we want to drop compat routines13:16
mriedemi.e. you haven't done your online data migratoins yet, so db sync fails until you do and then we can drop compat code13:16
* cdent nods13:16
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Fix TypeError in prep_resize allocation cleanup  https://review.openstack.org/58174113:17
cdentmy main focus with these questions is on fresh installs13:17
openstackgerritChris Dent proposed openstack/nova master: [placement] add error.code on a ConcurrentUpdateDetected  https://review.openstack.org/58174213:19
cdentefried, jaypipes, edleafe ^ not certain we want that, but it's there if we do13:20
cdentcame up because I was reading through code and saw https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L174813:21
efriedcdent: Yup13:23
openstackgerritChris Dent proposed openstack/nova master: Test for unsanitized consumer UUID  https://review.openstack.org/58113713:24
cdentgibi, efried : I rebased ^ because it appeared stuck, so gibi if you want to put your +W back on it13:25
efriedcdent: Arguably, we should resolve that TODO by raising Retry on *any* 409 though.13:25
efriedI guess it's a NOTE13:25
cdentefried: doing it on any 409 seems a bit dangerous because you can't know for certain what the conflict might be without further information13:26
efriedI take it back.  A 409 for a gen conflict wouldn't ...13:26
cdentthe world might change and a 409 might happen which is basically " you screwed"13:27
efriedcdent: to be clear, your change is going to set the same error code for gen conflicts *and* for non-gen "concurrent updates".13:30
efriedIMO it would be nice to be able to distinguish the two, but I seem to be the only one pulling for highly-granular error codes around here.13:31
cdentConcurrentUpdateDetected is only supposed to be used when there is a generation conflicdt13:32
cdentand in fact that is currently how it is sued13:32
cdentit is true that it is used for both consumer gen and rp gen13:34
cdentbut only that13:34
cdentor am I missing something efried ?13:34
efriedcdent: I thought you could also get ConcurrentUpdateDetected (and/or possibly DBDuplicateEntry?) if13:37
efriedyou start a transaction13:37
efriedanother thread starts and completes a transaction13:37
efriedyou complete your transaction13:37
efried...even if the conflict isn't caused by generation (i.e. you're using a pre-generation microversion, or calling an op that doesn't involve generations)13:37
cdentthere are exactly two places where ConcurrentUpdateDetected is raised13:38
cdentbut there are many places where it is caught13:38
cdentI added comment= in all the places where it is caught that I could find13:38
gibicdent: done13:40
cdentthanks gibi13:40
efriedcdent: So maybe I have this backwards.13:41
*** ttsiouts has quit IRC13:41
*** e0ne has quit IRC13:45
*** ttsiouts has joined #openstack-placement13:46
efriedcdent: There are two different classes of code path where we 409 for generation conflicts.13:47
efried1) Where we explicitly check in python with !=13:47
efried2) Where we implicitly check in the db UPDATE for generation with rowcount != 113:47
efriedWith the change as you've made it, only the latter will get the CONCURRENT_UPDATE code.13:47
efriedIs that the right thing?  I think it's not; I think to the API consumer, both of the above are the same and should appear thus.13:47
efriedBecause both mean that another transaction completed since we GETted our payload's generation.13:48
cdentefried: I think you're saying my change is not complete. That's correct. _All_ it is doing is adding a code when ConcurrentUpdateDetected is raised13:49
cdentthere are additional places where HTTPConflic is raised and means the same thing13:49
efriedcdent: okay, cool, we're in agreement on that point.  I think it's worth making the change complete in that sense, don't you?13:49
cdentI don't know, I'd be more inclined to do is separately13:50
cdentbut if you like I can do it together13:50
cdentefried: part of the reason for doing it separately is that the case I haven't covered is actually testable13:51
cdent(given the current ways we test)13:51
efriedcdent: Right, but the other kind is.13:51
cdenti'll do the second kind in a fup13:54
efriedcdent: Okay, +2 with notes on all of that.13:54
efriedcdent: Are you looking to do the consumer gen work on the report client side?13:56
cdentno13:56
efriedight13:56
cdentunless I had signed up for that and forgotten~?13:56
openstackgerritEric Fried proposed openstack/nova master: Delete orphan compute nodes before updating resources  https://review.openstack.org/57992213:57
efriedcdent: Updated commit message as suggested ^13:58
cdentefried: I think you would agree that this https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/util.py#L681-L684 is not a concurent update. (Just confirming because I'm cruising through HTTPConflictS)14:00
efriedcdent: Well.14:01
efriedIt is a generation conflict.14:01
*** mriedem has quit IRC14:01
efriedI get what you're saying that it's not strictly a "concurrent update".14:01
cdentit is also a special case of generation conflict14:02
cdentso it should not be the same code as anything else14:02
efriedBut I think this means the error code isn't perfectly named, not that we shouldn't mark it.14:02
cdentwe should not mark it with what is being marked now14:02
cdentso it's not a part of this change, I'd say14:02
*** mriedem has joined #openstack-placement14:02
efriedWhat do you mean "with what is being marked now"?14:02
efriedYou're saying it shouldn't even be a 409?14:03
cdentit is already 40914:03
efriedI know, I'm asking, are you saying it shouldn't be?14:03
cdentbut it should get a placerment.concurrent_update code14:03
efriedI'm confused.14:03
efriedwhich "this change" are we talking about, the one I just reviewed, or the new one where you're finding the non-concurrent gen conflicts?14:04
cdentI consider incoming gen != store gen also concurrent gen conflicts, the concurrency is happening in a broader domain than just the database. that's what generation conflict means14:05
cdentbut the issue at https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/util.py#L681-L684 is different14:05
efriedNo, it's not different.14:05
cdents/different/special/14:05
efriedIn real usage, this probably *does* represent a "normal" generation conflict, in fact. Thread A GETs allocation on an existing consumer (gen=5); thread B DELETEs allocations; thread A PUTs with gen=5 and bounces because we now expect gen=null.14:05
cdentthat's what's at the forefront of your mind because we've just just been in hell with regard to deleting consumers14:06
cdentbut what 'null' really means is "I want to create new allocations". It is is your first attempt14:06
*** e0ne has joined #openstack-placement14:07
cdentand if there is a stored gen, then your expectations about "new" were all wrong14:07
efriedThis code path isn't saying "you said null but it should be non-null".  It's saying the opposite.14:07
efriedIn this case you thought it WASN'T new, but it was.14:07
efriedAnd the race I described above is realistically how you would get there (other than just being an idiot and putting random garbage into a generation field, which could happen in any of these code paths)14:08
cdentblargh14:08
efriedEven if it was the opposite, my answer would be the same.14:08
cdentdouble blargh14:08
cdentwe're requiring far too much brains in both the client and the server for this stuff14:09
efriedYou say null but it's non-null, means you thought it was new but someone else came in and created it before you got there.  Generation conflict.14:09
efriedI'm not having trouble with the concept tbh.14:09
cdentI have trouble with consumers, so I'm started off on the wrong foot14:10
cdentbut my statement about brains was more about frustration with regard to how much we expect the client to do14:10
cdentI know it is where we are now but I really don't like it14:10
cdentI'll just go ahead and signal the issue here, and we'll see how it holds up14:11
openstackgerritMerged openstack/nova master: Remove irrelevant comment  https://review.openstack.org/57882114:12
efriedcdent: Goes back to the 404 thing. If we 404 on nonexistent consumer, the client should:14:14
efriedresp = GET /allocations/{u}14:14
efriedif resp.status == 404:14:14
efried    put_gen = None14:14
efried    existing_allocs = {}14:14
efriedelse:14:14
efried    put_gen = resp.json()['consumer_generation']14:14
efried    existing_allocs = resp.json()['allocations']14:14
efried<do stuff to existing_allocs>14:14
efriedPUT /allocations/{u} { payload including put_gen }14:14
cdentefried: some of my confusion above may be because of the comment being not quite right: https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/util.py#L676-L67714:14
cdent"None for the consumer generation if we get here"14:14
cdentefried: I don't think we should ever have to require a client to GET /allocations14:15
efriedIf we 200 { 'allocations': {} } on nonexistent consumer, it looks more like:14:15
efriedresp = GET /allocations/{u}14:15
efriedput_gen = resp.json().get('consumer_generation')14:15
efriedexisting_allocs = resp.json().get('allocations')14:15
efried...14:15
openstackgerritSurya Seetharaman proposed openstack/nova master: Update queued-for-delete from the ComputeAPI during deletion/restoration  https://review.openstack.org/56681314:16
efriedwhich is less code, I'll grant you, but it still doesn't mean we should do the 200 - that's still wrong imo.14:16
* cdent is not sure what efried is try8ing to say14:16
efriedI'm saying the burden on the client isn't especially onerous.14:16
cdenthow is that related to what we're talking about now? (I agree that 404 is the right response)14:16
efried...whether we 200 or 404.14:16
cdentyou're thinking about the client in terms of python code14:16
cdentI think about the client in terms of HTTP requests by any number of many systems14:17
efriedRegardless, the burden on the client isn't bad.14:17
cdentwe'll agree to disagree14:17
efriedAnd whoah, "I don't think we should ever have to require a client to GET /allocations" ??14:17
efriedIf you don't GET the existing allocations, you can't modify them intelligently; you can only replace them.14:18
cdentin the normal course of events the client should GET /allocation_candidates and PUT /allocations14:18
efriedUm, okay, then we're even less burdensome on the client.14:19
efriedBecause the allocation candidate will have the right generation in it.14:19
cdent"modifying allocations intelligently" is not something that should be done in the normal course of events14:19
efriedThis ^ seems like a nova statement14:19
cdent(I'm using "should" with powerful intent here)14:19
efriedBut anyway, okay, if the pattern *should* always be GET /a_c => PUT /allocations, then we're expecting nothing of the client wrt understanding generations, consumer or provider.14:20
efriedIf your PUT bounces 409, you either PUT a different candidate or you redo your GET /a_c.14:20
efriedIf you want to use error code to determine whether the 409 was caused by concurrent update or something else (e.g. inventory exceeded) it might inform which of those things you do.14:22
efriedwhich is why we should have different error codes for those things.14:22
efriedbut you don't have to do that, if you think it's too burdensome; you can just always redrive the GET /a_c => PUT /allocations procedure (or fail out).14:23
cdent"different error codes for those things" <- what are the different those things?14:24
efried[generation conflict] vs. e.g. [inventory exceeded]14:25
jaypipescdent: +Wallaby'd https://review.openstack.org/#/c/58174214:25
cdentefried: right, and that's what I'm doing, yes?14:26
efriedyup.14:26
cdentI had the impression you were trying to assert something else14:27
efriedI'm disputing that anything about the consumer model (at least in the form we're trying to shape it up to) is particularly onerous/burdensome to the API client.14:27
efriedconsumer or generation model14:28
cdentThe original model for allocations was that if there was room on the rps,  you could write the allocations. I liked that.14:29
cdentthat it is more complicated than that now (because we've decided it has to be) is frustrating14:29
cdentI continue to wonder if there were other ways "out"14:30
efriedShrug, we've made it more powerful such that you can now design a system that tolerates multiple threads interacting with the same consumers/allocations at the same if that's something you need/want to do. If it's not, you can use the old microversion and just blow away allocations without gen checking.14:31
cdentYeah, you say "we've made it more powerful such that you can now design a system that tolerates multiple threads interacting with the same consumers/allocations at the same if that's something you need/want to do" like it's a good thing.14:32
efriedGiven that HTTP APIs are supposed to be able to tolerate multiple threads hitting the same routes at the same time, yeah, I think it's a good thing.14:33
cdentIf we modelled consumers as a single locus of control, then we'd have a simplified system in many ways14:34
cdentin that (theoretical) model what provides thread safety for the HTTP APIs is unique (and opaque) ids14:34
efriedThen consumers would behave like resource providers do, in terms of generation etc., which would be okay.  The complexity arises from having tried to make consumers hidden/implicit/automatic, not from how we've done generations.14:36
cdentI think the opposite actually14:36
cdentby labelling allocation groups as "consumers" we walked into a trap14:37
cdentnova should conceptualize things as consumers14:37
cdentplacement should not14:37
cdentI, nova, am going to create an allocation for my uniquely identified consumer, which I'm controlling in this thread and this thread alone14:39
openstackgerritdo3meli proposed openstack/nova master: docs: add nova host-evacuate command to evacuate documentation  https://review.openstack.org/57804014:43
*** ttsiouts has quit IRC14:48
jaypipescdent: and what about when we have multiple services wanting to consume things from multiple providers in a single transaction? who gets to determine what the consumer is?14:51
cdentyou say that like it's a good thing too14:51
jaypipescdent: I'm asking you a question, nothing more.14:51
cdentabove when I said "should" with intent I was trying to indicate that reality is a pain in the ass14:51
cdentin this other reality the idea of "multiple services consuming things in a single transaction" wouldn't happen that way14:52
cdentconsumption would be a one (and only one) stop on a path14:53
cdentan early step in the path would be "determine the consumer"14:53
jaypipescdent: so something should create the consumer object ahead of time and then call PUT /consumers/{consumer_uuid}/allocations. I **completely** agree with you, Chris! :)14:53
cdentha! no :)14:53
jaypipes:)14:54
cdentwe already have something which creates the instance and its uuid. if we had this mythical nodelet thing that people are vaguely talking about, it would presumably use a something like that.14:55
cdentfrom the placement standpoint it would just be an identifier14:55
*** ttsiouts has joined #openstack-placement14:55
cdentfor the allocations14:55
jaypipescdent: I think the nodelet would be responsible for creating the providers, not the consumers, no?14:57
jaypipescdent: or am I misunderstanding what the nodelet is?14:57
jaypipesI thought nodelet was vaguely like kubelet?14:57
cdentone sec, writing a commit message, brb14:57
jaypipesnp14:57
cdentsorry, jaypipes, I was jumping steps in my writing. yeah, nodelet is vaguely like kubelet, but the idea is that it woudl coordinate activity on the node, such that it would be in charge (to large extent) of the entire suite of resource providers. When something needs to be built (whatever that is) a nodelet would eventually handle it. The thing which tells the nodelet to do stuff is responsible for creating the id15:02
cdentwhich would eventually be used when writing all the allocations for the thing being built15:02
openstackgerritChris Dent proposed openstack/nova master: Add placement.concurrent_udpate to generation pre-checks  https://review.openstack.org/58177115:02
cdentefried, jaypipes there's the followup15:02
efriedack15:03
cdentI guess that teller is the super super conductor15:03
* cdent shrugs15:03
cdentI dunno15:03
jaypipesefried, cdent: well, it's the requestspec.instance.uuid for nova at least. but could easily be heat or some other orchestrator I suppose.15:05
efriedcdent: +2, nice one guvnor15:10
openstackgerritMatt Riedemann proposed openstack/nova-specs master: Fix nits in the handling down cell spec  https://review.openstack.org/58124315:21
cdentefried, jaypipes, edleafe: reminder that I'll be gone much of tomorrow and all of friday. If any of my code needs adjustment, please feel free15:25
jaypipescdent: cheers, will do.15:27
cdentthe main one I'm thinking of is https://review.openstack.org/#/c/576927/ which is skeletal15:28
edleafecdent: enjoy!15:28
mriedemupdate on the udpate15:35
*** tssurya has quit IRC15:44
*** peereb has quit IRC15:46
openstackgerritdo3meli proposed openstack/nova master: docs: add nova host-evacuate command to evacuate documentation  https://review.openstack.org/57804015:47
*** ttsiouts has quit IRC16:09
efriedI'm going to take the afternoon off.16:18
mriedemenjoy16:23
*** efried is now known as efried_off16:23
openstackgerritMerged openstack/nova master: Test for unsanitized consumer UUID  https://review.openstack.org/58113716:27
*** efried_off has quit IRC16:31
*** efried_off has joined #openstack-placement16:31
openstackgerritMatt Rabe proposed openstack/nova master: Add destination MSP IP address to PowerVM migrate data  https://review.openstack.org/57967616:33
*** e0ne has quit IRC16:39
*** belmoreira has joined #openstack-placement17:39
*** mriedem1 has joined #openstack-placement18:02
*** mriedem has quit IRC18:05
*** edmondsw has quit IRC18:07
*** edmondsw has joined #openstack-placement18:07
*** mriedem1 is now known as mriedem18:12
*** e0ne has joined #openstack-placement18:16
openstackgerritMerged openstack/nova master: [placement] add error.code on a ConcurrentUpdateDetected  https://review.openstack.org/58174218:20
openstackgerritMatt Riedemann proposed openstack/nova master: Add nova-status upgrade check for request spec migrations  https://review.openstack.org/58181318:34
*** tssurya has joined #openstack-placement18:48
*** e0ne has quit IRC18:49
*** cdent has quit IRC18:52
*** e0ne has joined #openstack-placement19:01
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Add functional regressions tests for server_group_members OverQuota  https://review.openstack.org/58184519:06
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Fix server_group_members quota check  https://review.openstack.org/58184619:06
*** e0ne has quit IRC19:06
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Add functional regressions tests for server_group_members OverQuota  https://review.openstack.org/58186619:17
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Fix server_group_members quota check  https://review.openstack.org/58186719:17
*** e0ne has joined #openstack-placement19:17
*** belmoreira has quit IRC19:21
*** e0ne has quit IRC19:24
*** e0ne has joined #openstack-placement19:28
*** e0ne has quit IRC19:31
*** e0ne has joined #openstack-placement19:41
*** edmondsw has quit IRC19:42
*** edmondsw has joined #openstack-placement19:43
*** e0ne has quit IRC20:31
*** e0ne has joined #openstack-placement20:35
openstackgerritDan Smith proposed openstack/nova master: Avoid requesting DISK_GB allocation for root_gb on BFV instances  https://review.openstack.org/58072020:39
*** e0ne has quit IRC20:42
*** jaypipes has quit IRC21:09
openstackgerritDan Smith proposed openstack/nova master: Avoid requesting DISK_GB allocation for root_gb on BFV instances  https://review.openstack.org/58072021:10
openstackgerritMerged openstack/nova master: Add queued for delete to instance_mappings table.  https://review.openstack.org/56678821:32
openstackgerritMerged openstack/nova master: Fix TypeError in prep_resize allocation cleanup  https://review.openstack.org/58154821:32
openstackgerritMerged openstack/nova master: Add functional regressions tests for server_group_members OverQuota  https://review.openstack.org/58075521:33
openstackgerritMerged openstack/nova master: Fix server_group_members quota check  https://review.openstack.org/58068421:33
*** takashin has joined #openstack-placement21:39
openstackgerritTakashi NATSUME proposed openstack/nova-specs master: Create specs directory for Stein  https://review.openstack.org/57360222:00
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (5)  https://review.openstack.org/57084222:01
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (6)  https://review.openstack.org/57133022:01
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (7)  https://review.openstack.org/57199222:02
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (8)  https://review.openstack.org/57199322:02
*** tssurya has quit IRC22:05
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3)  https://review.openstack.org/57410422:21
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4)  https://review.openstack.org/57410622:22
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5)  https://review.openstack.org/57411022:22
*** edmondsw has quit IRC23:12
*** edmondsw has joined #openstack-placement23:13
*** edmondsw has quit IRC23:17
openstackgerritMatt Riedemann proposed openstack/nova master: Add another up-call to the cells v2 caveats list  https://review.openstack.org/58191023:23
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6)  https://review.openstack.org/57411323:24
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7)  https://review.openstack.org/57497423:25
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (5)  https://review.openstack.org/57084223:29
openstackgerritMatt Riedemann proposed openstack/nova master: Short-circuit targets_cell if already targeted  https://review.openstack.org/58191223:57
openstackgerritMatt Riedemann proposed openstack/nova master: Short-circuit targets_cell if already targeted  https://review.openstack.org/58191223:59

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