Wednesday, 2018-11-07

openstackgerritMatt Riedemann proposed openstack/nova-specs master: Spec for cross-cell resize  https://review.openstack.org/61603700:29
*** mriedem has quit IRC00:36
*** irclogbot_2 has quit IRC00:39
*** tetsuro has joined #openstack-placement00:42
*** takashin has joined #openstack-placement01:22
*** tetsuro has quit IRC01:33
*** tetsuro has joined #openstack-placement06:14
*** lyarwood has quit IRC06:53
*** e0ne has joined #openstack-placement07:49
*** helenafm has joined #openstack-placement08:19
*** dims has quit IRC08:52
*** dims has joined #openstack-placement08:53
*** lyarwood has joined #openstack-placement08:55
*** dims has quit IRC08:58
*** dims has joined #openstack-placement08:59
*** ttsiouts has joined #openstack-placement09:10
*** takashin has left #openstack-placement09:30
*** tetsuro has quit IRC09:33
*** ttsiouts has quit IRC09:44
*** ttsiouts has joined #openstack-placement09:44
*** ttsiouts_ has joined #openstack-placement09:48
*** ttsiouts has quit IRC09:49
*** cdent has joined #openstack-placement09:58
*** e0ne has quit IRC10:02
*** e0ne has joined #openstack-placement10:04
*** ttsiouts_ has quit IRC10:07
*** ttsiouts has joined #openstack-placement10:07
*** ttsiouts_ has joined #openstack-placement10:10
*** ttsiouts has quit IRC10:12
*** ttsiouts_ has quit IRC10:13
*** ttsiouts has joined #openstack-placement10:20
*** tssurya has joined #openstack-placement10:28
*** e0ne has quit IRC10:45
*** e0ne has joined #openstack-placement10:54
*** ttsiouts has quit IRC11:36
*** ttsiouts has joined #openstack-placement11:37
*** cdent has quit IRC11:40
*** ttsiouts has quit IRC11:42
*** e0ne has quit IRC12:04
*** ttsiouts has joined #openstack-placement12:08
*** e0ne has joined #openstack-placement12:08
*** e0ne has quit IRC12:09
*** e0ne has joined #openstack-placement12:27
*** cdent has joined #openstack-placement12:51
*** cdent has quit IRC13:37
*** ttsiouts has quit IRC13:39
*** e0ne has quit IRC13:41
openstackgerritMerged openstack/placement master: Add bandwidth related standard resource classes  https://review.openstack.org/61568713:42
*** e0ne has joined #openstack-placement13:45
*** ttsiouts has joined #openstack-placement13:57
*** mriedem has joined #openstack-placement13:58
*** e0ne has quit IRC14:13
*** e0ne has joined #openstack-placement14:14
*** cdent has joined #openstack-placement14:36
dansmithmriedem: so the thing I'm concerned about with the grenade change is just that (if) all grenade jobs will be using new placement implicitly under the covers,15:03
dansmithsince we install it in the upgrade step instead of during the new phase devstack15:03
dansmithI see that regular devstack jobs won't use new placement until the devstack change lands,15:04
dansmithbut we're kindof subverting the process it seems right?15:04
dansmithor will running new devstack after the grenade upgrade just revert us back somehow? although I don't see that happening in the logs so I would think not15:04
mriedemgrenade will still run new devstack after the upgrade script which until https://review.openstack.org/#/c/600162/ lands should be overwriting whatever the upgrade script did15:04
dansmithokay I did not see a third start of placement back to nova-placement in the logs, let me look again15:05
dansmithyeah, it's not there15:05
dansmithwe run with placement-uwsgi for the rest of the run15:05
mriedemlooking15:07
dansmiththe problem with that I see is that all new side grenade jobs run with new placement it seems, but there's no way for me to get a new placement devstack without doing a full upgrade cycle I think15:07
dansmithuntil the devstack patch lands15:07
mriedemok i guess you're right, this is first start of placement-api on the old side15:08
mriedemhttp://logs.openstack.org/54/604454/21/check/neutron-grenade/a0f5d15/logs/screen-placement-api.txt.gz#_Oct_24_15_25_01_94520115:08
mriedemOct 24 15:25:01.945201 ubuntu-xenial-inap-mtl01-0003381914 devstack@placement-api.service[21496]: uwsgi socket 0 bound to UNIX address /var/run/uwsgi/nova-placement-api.socket fd 415:08
mriedemand then the new side15:08
mriedemOct 24 15:42:59.207451 ubuntu-xenial-inap-mtl01-0003381914 devstack@placement-api.service[17536]: uwsgi socket 0 bound to UNIX address /var/run/uwsgi/placement-api.socket fd 415:08
dansmithI'm not really sure why devstack isn't configuring both to run, but I haven't looked15:08
dansmithyeah15:08
mriedemi'm glad i have https://review.openstack.org/#/c/600548/ so i can read this again15:10
dansmith+W15:11
cdentI guess I should read that, because I'm confused. What is "back to nova-placement"?15:11
mriedemfrom-base upgrade scripts run after installing stein code but before starting it15:11
mriedemso maybe that is the issue,15:11
mriedemand maybe the grenade change should be a within-stein upgrade script15:12
mriedemwhich runs before installing new code15:12
dansmithhow is the placement service even being started?15:12
mriedemand probably makes more sense for how the extraction is happening15:12
dansmithisn't it called something different?15:12
dansmithor is it being started by systemd because of a dep?15:12
dansmithand if that's the case, why aren't both being started?15:12
cdentthe systemd unit file is being changed15:13
cdentrun-process does that15:13
dansmiththe grenade change says a new unit file will be created15:13
dansmithbut also, isn't it new devstack that starts those services not grenade? so maybe that comment is wrong15:14
cdentgrenade does restart placement, but sounds you're thinking about a different restart than the one my comment was asserting?15:15
*** ttsiouts has quit IRC15:15
*** ttsiouts has joined #openstack-placement15:16
*** ttsiouts has quit IRC15:16
*** ttsiouts has joined #openstack-placement15:16
mriedemgrenade starts placement here https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/upgrade.sh#L9115:17
mriedemthe upgrade script runs here https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/upgrade.sh#L6815:17
dansmithah right I forgot, it has to start the services because it controls the order in some cases...  derp.15:17
cdentMy understanding was that we were doing something "special" here because we cannot do "New code should work with old configs"15:17
cdentthus the "theory of upgrade" doesn't fully apply15:18
mriedemthe from-rocky script runs after devstack installs placement on the new side15:18
mriedemthe within-rocky upgrade script, if we had one, would run here https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/upgrade.sh#L6115:18
mriedemi can push a change on top that moves from-rocky to within-rocky but i'm not sure if that will work15:19
dansmithcdent: yes we're definitely skirting the upgrade rules here, but my concern is just that all grenade jobs will now "secretly" run with new placement while there's no way to get a full devstack job or install running with new placement15:19
cdentisn't running with new placement what we want, secret or not?15:19
dansmithmriedem: can we not just gate this behavior on something set by devstack in cdent's patch?15:19
mriedemyou mean to noop if cdent's patch isn't merged, but also make his devstack change not fail grenade?15:20
mriedemyeah maybe15:20
dansmithjust the way we always do these interactions.. where we gate something in grenade on devstack config15:20
dansmithlike we did for the cells transitions, etc15:21
mriedemi.e. the NOVA_CONFIGURE_CELLSV2 flag15:22
dansmithyeah15:22
dansmithbecause we did the same thing, enabling grenade but not effecting that change until the devstack (and d-g, IIRC) things had landed15:22
mriedemwell, looking at cdent's devstack change, i could noop if $PLACEMENT_REPO is not defined15:22
mriedemhttps://review.openstack.org/#/c/600162/12/stackrc15:22
dansmithyup, that would be a good signal15:23
dansmithbecause that's what's telling us to get it from somewhere else15:23
mriedemor PLACEMENT_DIR https://review.openstack.org/#/c/600162/12/lib/placement15:23
mriedemlemme see what old matty can do here15:23
mriedemok updated https://review.openstack.org/60445415:34
cdentmriedem: that seems sane15:38
cdentand simple15:38
*** mriedem has quit IRC15:53
*** mriedem has joined #openstack-placement16:26
*** e0ne has quit IRC16:44
*** e0ne has joined #openstack-placement16:44
*** e0ne has quit IRC16:44
*** efried is now known as efried_rollin17:08
*** helenafm has quit IRC17:32
*** mriedem has quit IRC17:33
*** ttsiouts has quit IRC17:36
*** ttsiouts has joined #openstack-placement17:39
*** ttsiouts has quit IRC17:44
cdentdansmith, mriedem: looks like the grenade change behaves as expected: from placement on the devstack patch, not on the grenade patch for the second placement-api run18:19
dansmithcdent: yep, +218:29
cdentyay, progress18:29
*** e0ne has joined #openstack-placement18:36
*** e0ne has quit IRC18:38
*** mriedem has joined #openstack-placement18:38
edleafecdent: it looks from the docstring that you're running the migration tests under postgres. Correct?18:45
edleafeI'm getting a MySQL exception18:46
*** irclogbot_2 has joined #openstack-placement18:46
cdentthat's the docstrong that you copied from wherever it was copied. I've run it against both mysql and postgresql18:46
cdentwhat exception?18:46
edleafe    oslo_db.exception.DBError: (pymysql.err.InternalError) (1071, u'Specified key was too long; max key length is 767 bytes') [SQL: u'\nCREATE TABLE projects (\n\tcreated_at DATETIME, \n\tupdated_at DATETIME, \n\tid INTEGER NOT NULL AUTO_INCREMENT, \n\texternal_id VARCHAR(255) NOT NULL, \n\tPRIMARY KEY (id), \n\tCONSTRAINT uniq_projects0external_id UNIQUE (external_id)\n)\n\n'] (Background on18:46
edleafethis error at: http://sqlalche.me/e/2j85)18:47
*** tssurya has quit IRC18:47
edleafeIf I run the command with the MySQL cli I get the same thing18:47
cdentthat's a unicode related problem18:47
edleafeyeah, the multibyte issue18:48
cdenthow did you create your db? cuz it works for me18:48
openstackgerritsean mooney proposed openstack/placement master: Harden placement init under wsgi  https://review.openstack.org/61244418:48
cdentedleafe: you'll at some point need to rebase on ^18:49
edleafeI *thought* I had utf-8, but I dunno now. I'll re-create it and try again.18:49
edleafeWanted to run it by you first18:49
* edleafe curses heavy meeting days and their interruptions.18:50
cdenti'll try it here just to make sure it is still working18:50
cdent(and try p27, which I don't usually do anymore)18:51
sean-k-mooneycdent: edleafe the rebase may not be required as i did not chage the public interface in a syntaic way so there should be no merge confict later if you dont rebase18:51
sean-k-mooneythe semantics have change slightly however but they are more concreatly stated in comments now.18:53
cdentedleafe: yeah still works here18:53
cdentboth dbs18:53
edleafeMust have been a wonky database. It's working here now.18:54
cdentI don't think WonkyDB will pass jepsen18:54
cdentsean-k-mooney: will you be at summit?19:05
sean-k-mooneycdent: no. if i really wanted to be or needed to be i have a room i could stay in for the week but i was not planning on gong this time19:06
sean-k-mooneycdent: was there a topic you wanted to sync with me on?19:07
cdentprobably a wise choice. summits are weird.19:07
cdentno mostly just wanted to be sure to wave and say hi if you were there19:07
sean-k-mooneyi got a little burnt out with travel in the last 10 monts.19:08
cdentyeah19:08
sean-k-mooneydublin ptg (stuck for 2 days) , then vancover summit, then internal intel face to face 1 week later, then join redhat then denver ptg(stuck in phlidefa for a night with canceled flight), then new heir orentation in munich19:11
sean-k-mooneycdent: i actully kindo of feel rechared enough to go to the summit but that has only been in the last week or so but ill hopefully see you in denver19:12
*** e0ne has joined #openstack-placement19:24
*** e0ne has quit IRC19:31
*** mriedem is now known as mriedem_afk19:53
*** efried_rollin is now known as efried20:18
*** mnaser has quit IRC20:48
*** mnaser has joined #openstack-placement20:49
*** cdent has quit IRC21:19
*** mriedem_afk is now known as mriedem22:22

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