Friday, 2015-05-01

jogodansmith: o/00:00
*** salv-orlando has joined #openstack-nova00:00
cfriesengate-nova-python27 just failed with the following: testtools.matchers._impl.MismatchError: '5.5.5.5-g9ec3421' != '2015.2.0-g9ec3421'00:01
cfriesenis that a known thing?00:01
cfriesenfailed testcase is test_version_string_with_package_is_good00:01
jogocfriesen: sounds like maybe a PBR release?00:02
jogolifeless: ^00:02
*** IanGovett has quit IRC00:04
jogocfriesen: testing locally00:04
*** salv-orlando has quit IRC00:05
cfriesenfailed logs are at http://logs.openstack.org/27/169827/8/check/gate-nova-python27/2009c78/00:05
cfriesenbunch of other jenkins tests failed too00:06
dimsmelwitt: you forgot co-authored-by tag for yourself in https://review.openstack.org/#/c/159626/?00:06
alex_xucfriesen: thanks for your review on https://review.openstack.org/170397 :)00:06
*** Alexandra_ has quit IRC00:06
melwittdims: no need, only took a few minutes :)00:06
dimsbut, but, you should!00:07
melwittI just moved some stuff around a little :P00:07
dansmithdims: you can fix that in the web ui pretty easy :D00:07
dimsdansmith: y, doing that right now00:07
jogocfriesen: I think I have the fix, will be a  few minutes though00:08
*** emagana has quit IRC00:08
openstackgerritDavanum Srinivas (dims) proposed openstack/nova: Fix disconnect_volume issue when find_multipath_device returns None  https://review.openstack.org/15962600:09
eliqiao1hi dansmith: I put a comments on https://review.openstack.org/#/c/160075/ ,can you help to take a look at it?00:10
melwittheh, thanks dims00:10
jogomtreinish: ping00:10
mtreinishjogo: pong00:11
dims:)00:11
lifelesscfriesen: jogo: here, looking00:11
jogomtreinish: nova is hitting https://review.openstack.org/#/c/179278/1 as well00:11
jogohttp://logs.openstack.org/27/169827/8/check/gate-nova-python27/2009c78/console.html#_2015-04-30_23_29_19_40200:11
jogobut we don00:11
jogobut I don't think we want to move to version 5.5.5.500:11
openstackgerritChris Friesen proposed openstack/nova: ix "down" nova-compute service spuriously marked as "up"  https://review.openstack.org/16306000:12
lifeless2015 > 5 anyway00:12
jogothe test looks for a exact match it seems00:13
mtreinishjogo: yeah that looks like something with pbr or the test00:13
lifelessjogo: thats mocked out anyway00:13
*** Marga_ has joined #openstack-nova00:14
openstackgerritChris Friesen proposed openstack/nova: Conditionally expose "last_seen_up" in service list  https://review.openstack.org/16841800:14
lifelessjogo: at a high level it looks like nova has some version stuff that isn't inside pbr for some reason00:15
jogolifeless: so this is blocking nova00:15
lifelessjogo: and the mocking hasn't actually worked00:15
lifelessjogo: yes, and I'm here to help :)00:15
lifelessso it mocks version_info00:15
lifelessit doesn't mock package_string00:16
*** alanf-mc has quit IRC00:16
lifelessjogo: and no, this isn't https://review.openstack.org/#/c/179278/100:16
lifelessjogo: its not an enforcement thing, its just a unit test impacted by library changes in pbr00:17
jogolifeless: yeah I see that now00:17
lifelessso the 1.2.3.4-gx665656 stuff00:17
lifelessisn't what pbr returns now00:17
jogolifeless: can we just drop that test?00:17
*** ZZelle_ has quit IRC00:17
*** alanf-mc has joined #openstack-nova00:18
lifelessI don't know00:19
lifelesslike00:19
lifelessyou've got custom code there00:19
lifelessthe stub is setting version on the VersionInfo object00:20
lifelesswhat I think you actually want to stub out00:20
lifelessis the version_string call00:20
lifelessbecause thats the interface nova is depending on00:20
lifelessI'd like to see this code moved into pbr btw00:20
lifelesse.g. you register your config value with the VersionInfo object and get appropriately munged strings back00:21
lifelessso that other servers can do it and we can have it be consistent00:21
lifelessbut for now, changing the stub to stub out version.version_info 'version_string', lambda:'5.5.5'00:21
lifelessor however its spelt in Mox00:21
lifelessshould do it00:22
jogolifeless: testing that now00:23
*** eliqiao1 has quit IRC00:23
*** ssurana has quit IRC00:23
*** ssurana has joined #openstack-nova00:24
jogocfriesen: can you file a bug for this00:25
openstackgerritJoe Gordon proposed openstack/nova: Make test_version_string_with_package_is_good work with pbr 0.11  https://review.openstack.org/17930700:26
*** joefides has joined #openstack-nova00:27
*** ssurana has quit IRC00:28
jogoI'll file on then00:29
*** mrda is now known as cafepressbot00:33
jogolifeless: thanks for the help00:33
*** cafepressbot is now known as mrda00:33
openstackgerritJoe Gordon proposed openstack/nova: Make test_version_string_with_package_is_good work with pbr 0.11  https://review.openstack.org/17930700:33
jogodansmith: ^00:34
jogoany nova cores around?00:34
jogounbreak the gate patc00:34
lifelessyou'll probably want to backport that too00:36
lifelessto unbreak stable00:36
lifelesssince stable doesn't have (and can't sanely) a pbr pin00:36
*** annegentle has joined #openstack-nova00:37
jogoalready have the kilo patch up00:37
lifelessjuno too :)00:37
lifelessor should that be :/00:37
jogolifeless: checking juno now00:38
*** igordcard has quit IRC00:39
*** promulo has joined #openstack-nova00:40
jogobackporting to juno as well00:43
*** annegentle has quit IRC00:43
lifelessis i still supported?00:43
jogoyup00:43
lifelesshttps://review.openstack.org/#/c/179278/1 has merged. yay.00:43
*** promulo__ has quit IRC00:44
jogohttps://review.openstack.org/#/q/I4887b8000c9943c91f8add56fcc54fa18e78d683,n,z00:44
jogoon to icehouse ...00:45
*** davideagnello has quit IRC00:47
jogomikal: you around?00:49
*** harlowja has quit IRC00:50
jogoalaski: ^00:50
openstackgerritEli Qiao proposed openstack/nova-specs: Validate the service state before deleting it  https://review.openstack.org/16327400:50
jogolooking for a core review to help unbreak master00:50
jogoahh pep8!00:52
*** Sukhdev_ has quit IRC00:53
openstackgerritJoe Gordon proposed openstack/nova: Make test_version_string_with_package_is_good work with pbr 0.11  https://review.openstack.org/17930700:54
*** annegentle has joined #openstack-nova00:54
jogomriedem_away: thanks01:00
*** harlowja has joined #openstack-nova01:00
*** mriedem has joined #openstack-nova01:01
mriedemjogo: you're not going to have a pep8 failure here? https://review.openstack.org/#/c/179313/01:02
jogomriedem: just fixed it01:02
mriedemhawt01:03
mriedemwe should maybe be more aggressive with capping pbr in the future :)01:03
mriedemor per should release a 1.001:03
mriedem*br01:04
mriedemdamn01:04
mriedem*pbr01:04
mriedemjogo: how do you feel about getting the requirements sync job working again? https://review.openstack.org/#/c/179254/101:05
*** dsanders has quit IRC01:05
jogomriedem: maybe, this was a nova bug and easy to fix01:06
mriedemyeah i know01:06
*** angdraug has quit IRC01:06
jogorequirements sync? how is your patch related?01:06
jogoohh I see01:06
jogomriedem: heading out for a bit o/01:07
jogowant to babysit my patches?01:07
*** angdraug has joined #openstack-nova01:08
*** browne has quit IRC01:08
mriedemjogo: sure01:08
*** krak has quit IRC01:09
*** otter768 has joined #openstack-nova01:17
*** melwitt has quit IRC01:17
*** armax has joined #openstack-nova01:22
mriedemdansmith: re: previous discussion on wtf is going on with the neutron multi node job, looks like linuxbridge was made the neutron plugin by default in devstack http://lists.openstack.org/pipermail/openstack-dev/2015-April/061077.html01:24
mriedemso i'm not sure what that means for the event stuff or how it's still sending events w/o nova admin auth01:24
mriedemif i remember tomorrow i'll get in the neutron channel and ask around01:25
openstackgerritBrooks Kaminski proposed openstack/nova: Xenapi: Change generate-configdrive to use cdrom  https://review.openstack.org/17913501:26
*** annegentle has quit IRC01:26
*** mwagner_lap has joined #openstack-nova01:30
*** irenab has joined #openstack-nova01:34
*** kaufer has joined #openstack-nova01:34
openstackgerritFei Long Wang proposed openstack/nova: Fix nova backup for volume-backed instance  https://review.openstack.org/16449401:36
*** Marga_ has quit IRC01:37
*** jecarey has joined #openstack-nova01:37
*** Marga_ has joined #openstack-nova01:37
*** ferest has joined #openstack-nova01:37
*** irenab has quit IRC01:39
*** joefides_ has joined #openstack-nova01:41
*** joefides has quit IRC01:41
*** mriedem has quit IRC01:42
*** Marga_ has quit IRC01:42
*** alanf-mc has quit IRC01:46
*** vilobhmm1 has quit IRC01:48
*** kaufer has quit IRC01:54
*** patrickeast has quit IRC01:57
jogomriedem_away: multinode neutron is dvr now btw02:01
*** otter768 has quit IRC02:02
jogomtreinish: have a whole set of stable maint patches for nova that need a +W https://review.openstack.org/#/q/I4887b8000c9943c91f8add56fcc54fa18e78d683,n,z to unbreak the world02:07
*** yamahata has quit IRC02:07
*** annegentle has joined #openstack-nova02:13
*** whenry has quit IRC02:14
*** gyee has quit IRC02:15
openstackgerritDavanum Srinivas (dims) proposed openstack/nova: Remove version string from the setup.cfg  https://review.openstack.org/17932202:19
*** dave-mccowan has quit IRC02:20
*** ferest_ has joined #openstack-nova02:20
*** ferest has quit IRC02:21
dimsjogo: shouldn't we remove version from setup.cfg? ^^^02:21
*** VW_ has joined #openstack-nova02:22
*** ferest has joined #openstack-nova02:26
*** ferest_ has quit IRC02:27
*** annegentle has quit IRC02:27
*** baoli has joined #openstack-nova02:29
*** joefides_ has quit IRC02:32
*** unicell has quit IRC02:33
*** annegentle has joined #openstack-nova02:35
*** whenry has joined #openstack-nova02:35
*** joefides has joined #openstack-nova02:38
*** dsanders has joined #openstack-nova02:44
*** baoli has quit IRC02:50
jogodims: AFAIK no02:54
jogowe get the wrong version without it02:54
dimsjogo: with 0.11.0 it will work fine (get from git). if you see tempest just got rid of version from their setup.cfg after 0.11.0 was published02:56
alex_xuhow can I know whether a meeting channel free at specified time02:58
jogoon master 'nova-api --version' gives 2015.1.0 with your patch02:59
*** busterswt has joined #openstack-nova03:00
jogoand nova-api --version03:00
jogo2015.2.003:00
jogowithout your patch03:00
*** busterswt has quit IRC03:04
dimsjogo: interesting. thanks03:05
jogodims: I already tried that myself :)03:05
dimshehe03:05
*** busterswt has joined #openstack-nova03:06
*** achanda has quit IRC03:10
*** unicell has joined #openstack-nova03:11
*** unicell has quit IRC03:15
*** unicell has joined #openstack-nova03:16
*** isd has quit IRC03:17
*** annegent_ has joined #openstack-nova03:17
alex_xugilliard: I just send nova api meeting reminder out03:19
*** annegentle has quit IRC03:21
*** harlowja has quit IRC03:21
*** irenab has joined #openstack-nova03:23
*** dsanders has quit IRC03:25
*** fifieldt has joined #openstack-nova03:25
openstackgerritChris Friesen proposed openstack/nova: fix "down" nova-compute service spuriously marked as "up"  https://review.openstack.org/16306003:27
*** irenab has quit IRC03:28
*** busterswt has quit IRC03:31
*** zzzeek has quit IRC03:32
openstackgerritChris Friesen proposed openstack/nova: fix "down" nova-compute service spuriously marked as "up"  https://review.openstack.org/16306003:35
*** angdraug has quit IRC03:36
*** josecastroleon has joined #openstack-nova03:36
dansmithmriedem_away: I didn't think that neutron would send events with linuxbridge, so that's interesting, but the events *are* coming in.. I'm so confused03:38
*** dims has quit IRC03:38
*** vilobhmm1 has joined #openstack-nova03:39
*** josecastroleon has quit IRC03:39
*** VW_ has quit IRC03:43
*** VW_ has joined #openstack-nova03:44
*** yamahata has joined #openstack-nova03:44
*** marun has quit IRC03:46
*** whenry has quit IRC03:50
*** baoli has joined #openstack-nova03:51
*** baoli has quit IRC03:56
*** fifieldt has quit IRC03:59
*** isd has joined #openstack-nova04:02
*** mmedvede has quit IRC04:04
*** mmedvede has joined #openstack-nova04:08
*** VW_ has quit IRC04:10
*** achanda has joined #openstack-nova04:10
*** VW_ has joined #openstack-nova04:13
*** achanda has quit IRC04:15
*** annegent_ has quit IRC04:18
*** VW_ has quit IRC04:21
*** marun has joined #openstack-nova04:22
*** busterswt has joined #openstack-nova04:27
*** marun has quit IRC04:27
*** cfriesen has quit IRC04:28
*** achanda has joined #openstack-nova04:30
*** otter768 has joined #openstack-nova04:30
*** busterswt has quit IRC04:32
*** gtt116__ has joined #openstack-nova04:35
*** busterswt has joined #openstack-nova04:36
*** gtt116_ has quit IRC04:37
*** melwitt has joined #openstack-nova04:37
*** dims has joined #openstack-nova04:39
*** axpBen has joined #openstack-nova04:39
*** otter768 has quit IRC04:41
*** dims has quit IRC04:45
*** pixelb has quit IRC04:46
jogodansmith: we use DVR now AFAIK wonder what that does04:47
*** vilobhmm1 has quit IRC04:47
*** lpetrut has joined #openstack-nova04:52
*** xyang1 has quit IRC04:52
*** axpBen has quit IRC04:53
*** garyk has quit IRC04:55
*** busterswt has quit IRC05:01
*** flwang1 has quit IRC05:01
*** dsanders has joined #openstack-nova05:02
*** bkopilov has quit IRC05:08
*** ildikov has quit IRC05:19
*** isd has quit IRC05:20
*** emagana has joined #openstack-nova05:31
*** ildikov has joined #openstack-nova05:32
*** yamahata has quit IRC05:43
*** markvoelker has quit IRC05:48
*** emagana has quit IRC05:48
*** browne has joined #openstack-nova05:58
*** emagana has joined #openstack-nova06:03
*** yamahata has joined #openstack-nova06:04
*** emagana has quit IRC06:09
*** emagana has joined #openstack-nova06:10
*** emagana has quit IRC06:14
*** heyongli has quit IRC06:18
*** heyongli has joined #openstack-nova06:18
openstackgerritOpenStack Proposal Bot proposed openstack/nova: Imported Translations from Transifex  https://review.openstack.org/17805506:19
*** Longgeek_ has joined #openstack-nova06:24
*** Longgeek has quit IRC06:27
*** irenab has joined #openstack-nova06:27
*** alanf-mc has joined #openstack-nova06:28
*** irenab has quit IRC06:32
*** lpetrut has quit IRC06:34
*** hightall has joined #openstack-nova06:36
*** otter768 has joined #openstack-nova06:42
*** zul has joined #openstack-nova06:43
*** hightall has quit IRC06:43
*** otter768 has quit IRC06:46
*** melwitt has quit IRC06:50
*** alanf-mc_ has joined #openstack-nova06:54
*** alanf-mc has quit IRC06:58
*** achanda has quit IRC06:58
*** alanf-mc_ has quit IRC07:05
*** alanf-mc has joined #openstack-nova07:06
*** achanda has joined #openstack-nova07:08
*** dsanders has quit IRC07:12
gilliardalex_xu: Thanks!07:17
gilliardGood morning Nova07:18
*** bkopilov has joined #openstack-nova07:18
*** achanda has quit IRC07:23
*** zul has quit IRC07:25
*** zul has joined #openstack-nova07:25
*** oro has joined #openstack-nova07:34
*** browne has quit IRC07:34
*** alanf-mc has quit IRC07:35
*** jlanoux has joined #openstack-nova07:40
*** ildikov has quit IRC07:46
*** salv-orlando has joined #openstack-nova07:47
* gilliard checks calendar07:50
*** gilliard is now known as gilllliard07:50
*** Longgeek_ has quit IRC07:52
*** Longgeek has joined #openstack-nova07:56
*** arnaud____ has joined #openstack-nova07:56
*** sahid has joined #openstack-nova07:57
*** zul has quit IRC08:02
*** doron_afk has joined #openstack-nova08:04
*** romainh has joined #openstack-nova08:05
*** zul has joined #openstack-nova08:09
gilllliardWhat does 'nova resume' do? Different from 'unpause' or 'start' ?08:10
*** lucasagomes has joined #openstack-nova08:11
*** irenab has joined #openstack-nova08:13
*** boris-42 has joined #openstack-nova08:13
openstackgerritOpenStack Proposal Bot proposed openstack/nova: Updated from global requirements  https://review.openstack.org/17934008:14
alex_xugilllliard: np, good morning08:15
gilllliardHi alex_xu - thanks for the reminder email about the meeting.08:15
alex_xugilllliard: np, I can't find Ken'ichi, I'm afraid reminder email is too late, so I decide send it first :)08:16
*** irenab has quit IRC08:18
*** sahid has quit IRC08:23
*** arnaud____ has quit IRC08:25
*** derekh has joined #openstack-nova08:28
*** rook has quit IRC08:30
*** ferest has quit IRC08:31
*** zul has quit IRC08:31
*** otter768 has joined #openstack-nova08:42
*** Longgeek has quit IRC08:46
*** dsanders has joined #openstack-nova08:47
*** otter768 has quit IRC08:47
*** igordcard has joined #openstack-nova08:52
*** arnaud____ has joined #openstack-nova09:00
*** ndipanov has joined #openstack-nova09:02
johnthetubaguygilllliard: alex_xu: what time is the meeting again, I would like to join you, if possible, 1200UTC?09:03
alex_xujohnthetubaguy: yes, it is 1200UTC09:03
johnthetubaguyah, reads email, got it09:03
johnthetubaguyalex_xu: gilllliard: did you find a meeting room thats free, doesn't seems to have specified it there09:03
johnthetubaguyactually usual place looks good09:04
alex_xujohnthetubaguy: I checked at here, https://wiki.openstack.org/wiki/Meetings there isn't other meeting at the same time, is it correct way booking the meeting room?09:04
johnthetubaguyalex_xu: its the best way I know, there is an iCAL feed, but I don't remember where that is now09:05
*** arnaud____ has quit IRC09:05
alex_xujohnthetubaguy: ok09:05
*** zul has joined #openstack-nova09:07
*** gtt116_ has joined #openstack-nova09:08
*** ociuhandu has joined #openstack-nova09:08
*** gtt116__ has quit IRC09:12
*** ociuhandu has quit IRC09:12
gilllliardjohnthetubaguy: Yeah there's no conflicts that I saw. IDK how to update the iCal though. It's at https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics09:13
*** rotbeard has joined #openstack-nova09:14
*** ferest has joined #openstack-nova09:20
*** Murali has joined #openstack-nova09:24
*** Murali_ has joined #openstack-nova09:29
*** markvoelker has joined #openstack-nova09:29
*** lucasagomes has quit IRC09:29
*** Murali has quit IRC09:32
*** Murali_ is now known as Murali09:32
*** dsanders has quit IRC09:43
openstackgerritMatthew Gilliard proposed openstack/nova-specs: Allow more instance operations during live migration  https://review.openstack.org/17934609:46
*** lucasagomes has joined #openstack-nova09:48
openstackgerritJohn Garbutt proposed openstack/nova: devref: add information to clarify nova scope  https://review.openstack.org/17862309:55
*** sdake_ has joined #openstack-nova09:55
*** IanGovett has joined #openstack-nova09:58
*** sdake_ has quit IRC09:58
*** sdake has quit IRC09:59
*** irenab has joined #openstack-nova10:02
*** IanGovett has quit IRC10:06
*** irenab has quit IRC10:06
*** josecastroleon has joined #openstack-nova10:09
*** Murali has quit IRC10:10
*** exploreshaifali has joined #openstack-nova10:14
*** exploreshaifali has quit IRC10:17
*** romainh has left #openstack-nova10:18
alex_xugilllliard: it may need mac? I don't have mac :(10:24
gilllliardThe ICS feed? You can add it to your google calendar if you have one.10:24
gilllliardOther Calendars > Add by URL10:24
alex_xugilllliard: oh, thanks let me try10:25
*** Murali has joined #openstack-nova10:28
*** IanGovett has joined #openstack-nova10:28
openstackgerritDaniel Berrange proposed openstack/nova: tests: make API signature test also check static function  https://review.openstack.org/15570710:35
*** josecastroleon has quit IRC10:37
*** otter768 has joined #openstack-nova10:43
*** pixelb has joined #openstack-nova10:44
*** zul has quit IRC10:44
*** otter768 has quit IRC10:48
*** arnaud____ has joined #openstack-nova10:50
*** arnaud____ has quit IRC10:54
*** Hosam has joined #openstack-nova10:55
*** irenab has joined #openstack-nova11:03
*** Murali has quit IRC11:03
lxslidanpb: do you know how libvirt could return memory_total = 0 here please? https://review.openstack.org/#/c/171079/11:03
gilllliardeliqiao: ^^ ?11:04
*** rotbeard has quit IRC11:05
*** irenab has quit IRC11:07
*** Hosam has quit IRC11:18
*** dave-mccowan has joined #openstack-nova11:22
*** dprince has joined #openstack-nova11:30
*** markvoelker has quit IRC11:30
*** kaufer has joined #openstack-nova11:31
*** lucasagomes is now known as lucas-hungry11:38
*** arnaud____ has joined #openstack-nova11:51
*** dprince has quit IRC11:52
gilllliardNova API meeting in 5 minutes in #openstack-meeting11:53
*** arnaud____ has quit IRC11:55
alex_xuand 3 minutes left...11:57
gilllliardjohnthetubaguy jaypipes oomich alex_xu ^^11:58
*** oomichi has joined #openstack-nova11:59
*** markvoelker has joined #openstack-nova12:01
*** eliqiao1 has joined #openstack-nova12:03
openstackgerritJohn Garbutt proposed openstack/nova: devref: add information to clarify nova scope  https://review.openstack.org/17862312:03
*** markvoelker has quit IRC12:06
*** Sukhdev has joined #openstack-nova12:07
*** markvoelker has joined #openstack-nova12:12
*** irenab has joined #openstack-nova12:18
*** jaypipes is now known as leakypipes12:21
*** irenab has quit IRC12:23
*** joefides_ has joined #openstack-nova12:27
*** zul has joined #openstack-nova12:30
*** joefides has quit IRC12:31
*** hightall has joined #openstack-nova12:32
*** hightall has quit IRC12:33
*** bwensley has joined #openstack-nova12:34
*** zul has quit IRC12:35
*** dprince has joined #openstack-nova12:39
*** bwensley has quit IRC12:39
*** otter768 has joined #openstack-nova12:44
*** baoli has joined #openstack-nova12:45
*** baoli has quit IRC12:47
*** baoli has joined #openstack-nova12:48
*** cbader has quit IRC12:49
*** otter768 has quit IRC12:49
*** lucas-hungry is now known as lucasagomes12:49
*** zzzeek has joined #openstack-nova12:53
*** annegentle has joined #openstack-nova12:54
*** ivasev has joined #openstack-nova12:58
leakypipesbauzas, gilllliard, edleafe, sandywalsh: for your Friday amusement: http://bit.ly/existential-excuses12:59
*** dboik_ has quit IRC12:59
*** rfolco has joined #openstack-nova12:59
*** xyang1 has joined #openstack-nova13:03
*** moshele has joined #openstack-nova13:04
sdagueoh, hey, new time. I'll have to remember that one13:05
leakypipessdague: mornin.13:05
sdaguemoring13:05
sdaguegilllliard: the google calendar ics is updated by ttx manually based on the wiki13:05
*** alaski is now known as lascii13:06
gilllliardsdague: Thanks13:06
* gilllliard goes to double-check the wiki13:06
*** READ10 has joined #openstack-nova13:06
*** vladikr has joined #openstack-nova13:06
*** iamjarvo_ has joined #openstack-nova13:07
*** oomichi has quit IRC13:07
*** burt has joined #openstack-nova13:10
*** artom has joined #openstack-nova13:11
*** iamjarvo_ has quit IRC13:11
*** unicell1 has joined #openstack-nova13:14
*** edleafe is now known as figleaf13:16
*** unicell has quit IRC13:16
lxsliDearest cores, I added 20 trivial bugs here: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking13:16
*** eliqiao1 has quit IRC13:17
*** dboik has joined #openstack-nova13:18
*** dboik has quit IRC13:18
*** dboik has joined #openstack-nova13:19
*** irenab has joined #openstack-nova13:19
*** neelashah has joined #openstack-nova13:19
*** sdake has joined #openstack-nova13:24
*** irenab has quit IRC13:24
*** VW_ has joined #openstack-nova13:25
figleafleakypipes: I enjoyed that, but my life drifts on unchanged.13:26
dansmithjogo: oh, hmm13:28
*** sdake has quit IRC13:29
*** joefides_ has quit IRC13:29
*** joefides has joined #openstack-nova13:29
*** busterswt has joined #openstack-nova13:29
*** dims has joined #openstack-nova13:30
*** kaufer has quit IRC13:31
johnthetubaguyjogo: dansmith: as promised, been attempting to document what we don't want nova to do here, reviews welcome: https://review.openstack.org/#/c/178623/13:32
dansmithjohnthetubaguy: cool13:33
dansmithjohnthetubaguy: on the api stuff I just missed, the reason we dropped v3 was that it wasn't worth making most of the changes, which were just cleanliness13:34
dansmithjohnthetubaguy: the worst offenders were the renames, capitalization changes, - to _, etc13:34
dansmithjohnthetubaguy: I understand leakypipes' argument, and think that some such changes are definitely worth it13:35
dansmithjohnthetubaguy: this lock one doesn't seem like it is to me, based on the behavior and what a client would really be doing in either case13:35
dansmithbut that's all, just opinion13:35
*** cfriesen has joined #openstack-nova13:36
johnthetubaguydansmith: I am with you there13:37
johnthetubaguydansmith: although if we agree a standard that says we should do 409s like that, then I wouldn't stop people adding that I guess, assuming they did it everywhere for consistency, but I do have a slight preference for the current approach myself13:38
*** packet has joined #openstack-nova13:39
* gilllliard just writing an api-wg patch for the 409 case.13:39
johnthetubaguydansmith: I mean if you snapshot a deleted instance, thats a 409, and indeed snapshot a snapshotting instance is also 409, but for lock, I duno, seems like locking a locked being a success is useful13:39
gilllliardI would also prefer locking a locked instance to be a success. You asked for it to be locked and it is locked.13:39
*** arnaud____ has joined #openstack-nova13:40
dansmithjohnthetubaguy: it seems idempotent to me, yeah13:40
dansmiththe question is whether locking an instance that was locked by an admin needs to be a 40913:40
johnthetubaguygilllliard: right, its borderline I guess, but I kinda prefer the current behaviour13:40
dansmithand to me, if I want it locked, I just want to know that it's locked13:40
dansmithI might care who locked it when I unlock, but that's different13:40
dansmithand I get an indication of that on unlock13:41
johnthetubaguydansmith: yeah13:41
johnthetubaguydansmith: unlocking and already unlocked thing, meh, similar really13:41
dansmithyeah13:41
dansmithso again, this goes to "is it worth it" IMHO, and the behavior here might not be ideal,13:42
johnthetubaguydansmith: frankly my biggest issue is spending our time debating this13:42
johnthetubaguyright13:42
dansmithbut changing it for people already used to one just doesn't seem like a huge deal13:42
dansmithjohnthetubaguy: yep, I'm happy to drop it13:42
*** zzzeek has quit IRC13:42
dansmithjust 'splainin' my feelins' :)13:42
johnthetubaguydansmith: yeah, sorry I wasn't really meaning that13:43
dansmithsuuuure :P13:43
johnthetubaguydansmith: I mean its more, I don't want to spend the whole of liberty discuss small API tweaks :)13:43
dansmithheh, yeah13:43
*** kaufer has joined #openstack-nova13:44
*** arnaud____ has quit IRC13:45
*** lpetrut has joined #openstack-nova13:48
*** packet has quit IRC13:48
*** thangp has joined #openstack-nova13:49
*** packet has joined #openstack-nova13:49
*** openstackgerrit has quit IRC13:51
*** openstackgerrit has joined #openstack-nova13:52
leakypipesfigleaf: yes, I had a chuckle. and then realized how pointless laughing is, and decided to stop.13:55
*** dansmith is now known as superdan13:57
*** dboik_ has joined #openstack-nova13:59
openstackgerritSean Dague proposed openstack/nova: Add ability to inject routes in interfaces.template  https://review.openstack.org/11540913:59
openstackgerritDan Smith proposed openstack/nova-specs: Add admin-query-any-keypair.rst  https://review.openstack.org/17557913:59
mtreinishjogo: +A14:01
openstackgerritBaodong (Robert) Li proposed openstack/nova: Handle port delete event  https://review.openstack.org/17939014:02
*** dboik has quit IRC14:03
*** iamjarvo has joined #openstack-nova14:04
*** iamjarvo has quit IRC14:05
*** iamjarvo has joined #openstack-nova14:05
*** lpetrut has quit IRC14:06
superdanleakypipes: gilllliard: do the two changes proposed against the api-wg repo actually apply to what we have here?14:07
*** Sukhdev has quit IRC14:07
superdanor rather, the 409 clarification14:07
leakypipessuperdan: just that one, not the 500 one14:07
superdanthe 200 one does and I think we're all on board with that14:07
superdanleakypipes: the 500 on/14:08
superdanI see one about 200 and one about 40914:08
superdanhttps://review.openstack.org/#/c/179386/2/guidelines/http.rst,cm14:08
*** ndipanov is now known as ndipanoff14:08
leakypipessuperdan: the 500 one is a dep of the 409..14:08
*** mriedem_away is now known as mriedem14:08
superdanoh okay14:08
leakypipessuperdan: but it does not need to be.14:08
leakypipesI blame gilllliard :)14:09
superdanso the 409 one doesn't seem to apply to the locking situation, or is too vaguely related14:09
superdanbecause reading that, I'd still think the current behavior is right14:09
leakypipessuperdan: the current behaviour returns a 404 not a 409.14:09
superdanleakypipes: I don't think it does, did you see my comments?14:10
* leakypipes goes back for the fifth time...14:10
superdansorry man, feel free to ignore me14:10
*** markvoelker has quit IRC14:10
leakypipessuperdan: no, 99% of the time you are right and I am wrong.14:10
superdanreading the code, I don't see how it can yield a 40414:10
superdanEli's analysis after that comment of mine seems to indicate that it's not a 404, if I'm reading the broke-ass gerrit formatting right14:11
*** oro has quit IRC14:12
superdanI mean, 404 if the instance is deleted, but that's correct I think14:12
leakypipessuperdan: are you looking at the v3 plugin or the v2 contrib/admin_actions.py module?14:12
superdanleakypipes: it's mostly compute/api that matters I think, but let me pull it back up14:13
superdanI'm sure I was looking at the v3 plugin because v2 is frozen and irrelevant now :)14:13
leakypipessuperdan, eliqiao: well, this: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/admin_actions.py#L215 is in direct violation of this: http://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/http.rst#n4714:13
superdanyeah, v3/plugins/lock_server.py14:14
*** markvoelker_ has joined #openstack-nova14:14
superdanleakypipes: but that code is frozen, not changing, slated for deletion14:14
superdanand not what this change is talking about at all14:14
leakypipessuperdan: even though it correctly returns a 202 Accepted :(14:14
superdanleakypipes: it's going to be deleted! :)14:14
superdanthe 202->200 change is fine with me, I'm talking about the 409 here14:15
leakypipesya14:15
sdagueleakypipes: so, someone is going to get rid of that 405 thing right?14:15
*** oro has joined #openstack-nova14:15
leakypipessdague: apparently that code is being deleted?14:15
*** markvoel_ has joined #openstack-nova14:15
sdaguewell, it's the same wrong reading of "method" in an http context14:15
sdagueI was just looking at the http guidline14:15
leakypipessuperdan: k, looking at compute api now... sorry for distraction14:15
superdanhttps://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/lock_server.py#L3414:16
superdanreturns 202 right now, should be 200, totally agreed14:16
superdanI don't think we need a microversion to make that change14:16
sdagueleakypipes: if there isn't a patch up, I can post one14:16
leakypipessuperdan: I disagree. it's a change that is backwards incompatible. plus, microversion bumps are cheap now.14:17
johnthetubaguysuperdan: mind you, micro versions are almost free, so we could bump for that, if we wanted I guess? Although I suppose that means keeping all old requests as 202, which is a bit silly, there is devref patch to review about this: https://review.openstack.org/#/c/177778/14:18
leakypipessuperdan: w.r.t. the 409, that would be an additional change that could be done in the same microversion bump, IMO14:18
leakypipesChanging 202 -> 200 is a backwards incompatible change.14:18
superdanleakypipes: why?14:19
*** signed8bit has joined #openstack-nova14:19
*** markvoelker_ has quit IRC14:19
leakypipesThat's not the same thing as fixing something that erroneously returns a 500 to be the correct response code.14:19
superdanleakypipes: I think that we specifically said that such things don't need microversions14:19
superdanhttps://github.com/openstack/nova/blob/master/doc/source/devref/api_microversions.rst14:19
superdanleakypipes: we *could* make the 409 change, but I don't think we should14:19
leakypipessuperdan: because clients check for the 202 now. if that changes, with NO version bump, then clients will not view the 200 as a successful return.14:19
superdanleakypipes: when/where do we return a 500?14:19
superdanleakypipes: when we were determining what needed to be versioned, I feel pretty confident we said that things like 200->202 were standard http behaviors and if you consider 200 successful and 202 failure (or the other way around) then your client is broken14:20
leakypipessuperdan: sorry, the 500 is a separate issue that came up this morning at the Nova API meeting. I was explaining that there is a difference between not needing to bump the microversion if fixing a bug where the server is returning a 500 erroneously due to a user-initiated action.14:20
sdagueoh, never mind, the 405 thing is right there14:21
sdagueI was reading wrong14:21
superdanleakypipes: that's a api-wg change, nothing about this lock code, right?14:21
leakypipessuperdan: I know that's what was in the API Change Guidelines. But that is wrong, IMO14:21
leakypipessuperdan: it's a Nova bug and an API WG change (the 500 thing), yes. unrelated to this bug (the 409/202 thing)14:21
superdanwell, fine, allocate a microversion for the 200 change then14:22
leakypipessuperdan: I bring the 500 thing up because it's the only occasion where I believe it is fine to change the return code without doing a bump.14:22
*** claudiub has joined #openstack-nova14:22
superdanso, aren't we free to do or queue anything we want?14:23
sdagueleakypipes: so... we've got that API compat guideline wiki page14:23
superdanlike, if we can't do your thing right away (200) can't we queue (202) it at our discretion?14:23
leakypipessuperdan: I was advocating doing *both* the 200 and 409 changes in the same microversion bump because they are in the same API call...14:23
leakypipessdague: that part is and always has been wrong, IMO.14:23
sdagueis that going to come back into the api-wg repo?14:23
superdanleakypipes: right, but I think the 409 change is not necessary, and TBH, it goes against the 200 advice in that api-wg change14:23
superdanleakypipes: which says if it's already locked, return 2xx14:24
leakypipessdague: about changing success codes is a "backwards compatible" thing. It's definitely not.14:24
sdagueleakypipes: hey, no complaints from me14:24
sdagueI was against that being an allowed change, tempest actually trips up on it14:24
sdaguebecause we check for specific codes that are in the docs14:24
leakypipessuperdan: Dan...14:25
superdansdague: so you know that means that if we have to change something from being sync to async in the code, we can't honor our own API anymore, right?14:25
sdaguebut... it seems like that change guideline should be put in the api-wg repo instead of random wiki14:25
leakypipessuperdan: it does not say 2XX. It says 200. https://review.openstack.org/#/c/179386/2/guidelines/http.rst14:25
*** ferest has quit IRC14:25
superdanleakypipes: Jay, I know man, I'm saying 2xx instead of 40914:25
sdaguesuperdan: if we've changed the behavior of an endpoint from sync to async, I think that's an API change14:25
*** ferest has joined #openstack-nova14:26
sdaguebecause it's definitely going to trip people up with existing code that assumes things are good14:26
sdagueand moves onto the next action14:26
leakypipessuperdan: ah, sorry, yes, I see what you're saying now about the conflicting bullet in https://review.openstack.org/#/c/163275/5/specs/liberty/approved/improve-lock-api.rst, line 1914:26
sdaguewhen they are now not14:26
*** BadCub_Hiding is now known as BadCub14:26
superdansdague: well, I get that, but it seems like the kind of thing that has to apply within context14:27
leakypipessuperdan: w.r.t. "so you know that means that if we have to change something from being sync to async in the code, we can't honor our own API anymore, right?" <-- yes, as sdague says, a semantic behavior change like that *should* trigger a bump, IMO14:27
superdansdague: if we return 200, people don't assume the instance is booted, they assume it's recorded.. if we return 202, they need to maybe check for it again if they care14:28
*** pkoniszewski has joined #openstack-nova14:28
superdanwhatever, I really REALLY don't care about the 200 thing here, I care about the 409 thing14:28
superdanthe thing I'm trying to get at with the 200 thing I guess is that if they request v2.1.0 we're not going to make the locking async, so we're just lying14:30
*** ferest has quit IRC14:30
superdanbut if the microversion is the doc penalty we have to take, then that's fine14:30
*** zz_jgrimm is now known as jgrimm14:31
*** oro has quit IRC14:31
johnthetubaguyI think we should all review this one: https://review.openstack.org/#/c/177778/14:31
johnthetubaguyif its the wrong place, lets move it, but I think we need to write this down14:31
leakypipessuperdan: I added a comment about https://review.openstack.org/#/c/163275/ being non-aligned with the guidance on 409 in https://review.openstack.org/#/c/179386/2/guidelines/http.rst14:32
johnthetubaguyopen to other ideas, as always14:32
superdanleakypipes: thanks, I'll STFU now14:32
leakypipessuperdan: no, as I mentioned above, you are right 99% of the time and I am wrong. as was mostly the case here.14:32
*** oro has joined #openstack-nova14:33
* leakypipes self-removes from nova-core and api-wg14:33
superdanpfft14:33
* leakypipes soothes superdan with soothing voice and demeanor.14:34
sdagueso, I think the interesting point that superdan raises is about changing the v2.1 behavior inconsistently before this bump14:34
leakypipesnow now superdan14:34
* superdan soothes self by smashing things14:34
leakypipesrofl14:34
sdagueit's a code green!14:34
* sdague watched new avengers last night14:35
leakypipessdague: any good?14:35
sdagueif you are into marvel super hero movies, yes14:36
leakypipessdague: I am, so good :)14:36
*** achanda has joined #openstack-nova14:37
*** cfriesen is now known as cfriesen_away14:41
*** joefides_ has joined #openstack-nova14:42
*** achanda has quit IRC14:43
*** joefides_ has quit IRC14:45
*** otter768 has joined #openstack-nova14:45
*** joefides has quit IRC14:45
*** otter768 has quit IRC14:50
*** tonytan4ever has joined #openstack-nova14:51
*** cbader has joined #openstack-nova14:53
superdanjohnthetubaguy: I was extra picky about grammar in that doc, just because I think it's likely to be read by a lot of folks, just FYI :)14:57
dimsjohnthetubaguy: can you please restore the docker spec? https://review.openstack.org/#/c/128753/ when you get a chance14:57
*** dims is now known as dimsum__14:58
openstackgerritGeorge Shuklin proposed openstack/nova: If rescue failed set instance to ERROR If rescue operation failed in the middle set to ERROR state instead leave it broken and 'ACTIVE'.  https://review.openstack.org/15512014:58
openstackgerritGeorge Shuklin proposed openstack/nova: If rescue failed set instance to ERROR  https://review.openstack.org/15512014:59
johnthetubaguydims: submitter should be able to restore, but I can do that if you want to update it :)14:59
dimsum__johnthetubaguy: yes, please14:59
dimsum__i have a change ready to go15:00
johnthetubaguydimsum__: I am hungry now I saw your nick15:00
dimsum__haha15:00
*** sdake has joined #openstack-nova15:01
openstackgerritDavanum Srinivas (dims) proposed openstack/nova-specs: Add the docker hypervisor plugin to Nova  https://review.openstack.org/12875315:01
johnthetubaguydimsum__: how are the tests going now?15:02
openstackgerritDavanum Srinivas (dims) proposed openstack/nova-specs: Add the docker hypervisor plugin to Nova  https://review.openstack.org/12875315:03
johnthetubaguysuperdan: my grammar is terrible, appreciate the help with that! I will take a look at how thats going15:03
superdancool15:04
dimsum__johnthetubaguy: warning - docker ci jobs don't run on nova changes. so just for the nova-docker reviews, the jobs seem to be fine15:04
mriedemsuperdan: you might enjoy this https://review.openstack.org/#/c/179406/15:04
*** dboik_ has quit IRC15:05
dimsum__johnthetubaguy: occasional hiccups with the CI changes, but nothing out of the ordinary15:05
leakypipessdague: how do I see who's on the horizon core team?15:05
superdanmriedem: hah, nice15:05
*** dboik has joined #openstack-nova15:05
dimsum__leakypipes: https://review.openstack.org/#/admin/groups/43,members15:05
*** emagana has joined #openstack-nova15:05
leakypipesthx dimsum__15:06
johnthetubaguydimsum__: can we try running them on all Nova jobs for a bit, non voting I guess, just to show stability? maybe thats silly, not sure15:06
mriedemleakypipes: do you need a horizon person to yell at?15:06
mriedemi work with one15:06
dimsum__johnthetubaguy: i'd be very happy to15:06
leakypipesmriedem: no, just wondereing.15:06
superdansigh, are we really doing the docker thing again?15:06
mriedemtell nova-docker to get their own translation domain and i18n module15:07
dimsum__mriedem: not needed if folded back into nova. right?15:07
*** irenab has joined #openstack-nova15:08
figleafmriedem: if your sensibilities are really that delicate, you should quote the id string in that line.15:08
*** nelsnelson has joined #openstack-nova15:08
* figleaf has even more delicate grammar sensibilities15:08
*** emagana has quit IRC15:09
*** hemna_ has joined #openstack-nova15:12
*** irenab has quit IRC15:12
johnthetubaguyleakypipes: didn't see we had code up for reivew on this, can we get this BP reapproved for you? https://blueprints.launchpad.net/nova/+spec/lock-free-quota-management15:12
openstackgerritGeorge Shuklin proposed openstack/nova: If rescue failed set instance to ERROR  https://review.openstack.org/15512015:14
leakypipesjohnthetubaguy: I'm afraid that particular work won't be possible to complete in liberty. I still need to do benchmarking of it, and the colleague who was assigned it has been doing other things...15:14
*** moshele has quit IRC15:16
johnthetubaguyleakypipes: ah, OK, we have a summit session scheduler to discuss pushing this forward at the moment, maybe its time to get more help, if that works? Although given we have such a concrete plan, its maybe not worth a summit session15:16
johnthetubaguyleakypipes: well, I guess it was only ever a side note in that session, but anyways15:17
leakypipesjohnthetubaguy: yeah, I don't recommend taking up a sesion on it.15:18
*** READ10 has quit IRC15:19
johnthetubaguyleakypipes: cool, it was a quota next steps and database next steps rolled into one, I need to go back and make sure I know whats left is worth bothering about!15:20
*** dprince has quit IRC15:20
*** yamahata has quit IRC15:24
*** pkoniszewski has quit IRC15:27
*** arnaud____ has joined #openstack-nova15:28
*** jbernard has quit IRC15:29
*** dimsum__ has quit IRC15:31
*** jbernard has joined #openstack-nova15:31
*** dimsum__ has joined #openstack-nova15:31
*** dsanders has joined #openstack-nova15:31
*** arnaud____ has quit IRC15:33
*** hemna_ has quit IRC15:36
*** iamjarvo has quit IRC15:38
*** jbernard has quit IRC15:39
*** hemna_ has joined #openstack-nova15:40
*** jbernard has joined #openstack-nova15:42
*** jogo is now known as flashgordon15:45
*** nelsnels_ has joined #openstack-nova15:47
*** yamahata has joined #openstack-nova15:47
*** nelsnelson has quit IRC15:47
*** nelsnels_ has quit IRC15:47
*** nelsnelson has joined #openstack-nova15:48
*** bnemec has quit IRC15:48
*** iamjarvo has joined #openstack-nova15:48
*** xyang1 has quit IRC15:49
*** bnemec has joined #openstack-nova15:51
*** ferest has joined #openstack-nova15:52
*** tonytan4ever has quit IRC15:53
*** dsanders has quit IRC15:57
*** zzzeek has joined #openstack-nova15:58
*** rfolco has quit IRC16:00
*** angdraug has joined #openstack-nova16:01
*** Nic has joined #openstack-nova16:01
*** annegentle has quit IRC16:04
*** browne has joined #openstack-nova16:04
*** busterswt has quit IRC16:04
*** jlanoux has quit IRC16:05
*** arnaud____ has joined #openstack-nova16:09
*** Marga_ has joined #openstack-nova16:09
*** busterswt has joined #openstack-nova16:09
*** dave-mccowan has quit IRC16:13
*** angdraug has quit IRC16:15
*** unicell1 has quit IRC16:16
*** IanGovett1 has joined #openstack-nova16:19
*** IanGovett has quit IRC16:21
*** Marga_ has quit IRC16:22
*** Marga_ has joined #openstack-nova16:22
*** iamjarvo has quit IRC16:23
*** hemna_ has quit IRC16:23
*** claudiub has quit IRC16:24
*** hemna_ has joined #openstack-nova16:24
*** gokrokve has joined #openstack-nova16:25
*** arnaud____ has quit IRC16:26
*** gokrokve has quit IRC16:26
*** gokrokve has joined #openstack-nova16:27
*** derekh has quit IRC16:28
*** tjones2 has joined #openstack-nova16:31
*** hemna_ has quit IRC16:33
*** Nic has quit IRC16:34
*** hemna_ has joined #openstack-nova16:34
*** busterswt has quit IRC16:36
*** Nic has joined #openstack-nova16:36
*** marun has joined #openstack-nova16:37
*** unicell has joined #openstack-nova16:41
*** melwitt has joined #openstack-nova16:41
superdanmelwitt: mind leaving a few +1s for the rest of us? kthx16:43
*** ajo has joined #openstack-nova16:45
melwittsuperdan: ... :)16:45
superdanheh16:45
*** otter768 has joined #openstack-nova16:46
*** iamjarvo has joined #openstack-nova16:47
*** alanf-mc has joined #openstack-nova16:48
*** markmcclain has quit IRC16:49
jrollI'm trying to get network info in a virt driver method, what's the best way to do that, just instantiate network.API() and use it?16:51
*** otter768 has quit IRC16:51
*** gokrokve has quit IRC16:51
superdanjroll: for an instance?16:51
jrollsuperdan: yes16:52
superdaninstance.info_cache.network_info should have what you want16:52
jrollah, perfect16:52
superdanyou definitely should not instantiate a network.API :)16:52
*** dave-mccowan has joined #openstack-nova16:52
jrollI should have known that, thank you :)16:52
*** exploreshaifali has joined #openstack-nova16:52
superdannp16:52
*** HenryG is now known as floccinaucinihil16:54
*** lucasagomes is now known as lucas-beer16:54
*** ssurana has joined #openstack-nova16:55
*** patrickeast has joined #openstack-nova16:55
*** floccinaucinihil is now known as HenryThe8th16:55
*** jecarey has quit IRC16:56
*** irenab has joined #openstack-nova16:57
*** emagana has joined #openstack-nova16:59
*** vilobhmm1 has joined #openstack-nova16:59
*** markvoel_ has quit IRC16:59
*** vilobhmm1 has quit IRC16:59
*** vilobhmm1 has joined #openstack-nova17:00
*** markvoelker has joined #openstack-nova17:00
*** irenab has quit IRC17:01
*** harlowja has joined #openstack-nova17:02
*** cfriesen_away is now known as cfriesen17:03
*** markmcclain has joined #openstack-nova17:03
*** annegentle has joined #openstack-nova17:04
*** josecastroleon has joined #openstack-nova17:06
*** Marga_ has quit IRC17:07
*** achanda has joined #openstack-nova17:07
*** Marga_ has joined #openstack-nova17:07
*** salv-orlando has quit IRC17:10
*** josecastroleon has quit IRC17:12
*** Marga_ has quit IRC17:13
*** Marga_ has joined #openstack-nova17:13
*** dsanders has joined #openstack-nova17:16
*** gokrokve has joined #openstack-nova17:18
*** claudiub has joined #openstack-nova17:19
*** gokrokve_ has joined #openstack-nova17:20
*** subscope has joined #openstack-nova17:21
*** gokrokve has quit IRC17:22
*** gokrokv__ has joined #openstack-nova17:22
*** gokrokve_ has quit IRC17:22
johnthetubaguysdague: lascii and I just had a good conversation with Vek about quotas, I think we identified quite a few things we can do to simplify things, quite exciting, will can roll that into the summit session we have scheduled on that17:22
*** busterswt has joined #openstack-nova17:23
flashgordonjohnthetubaguy: woot any solution that involves simplifying quotas sounds like a step in the right direction17:25
johnthetubaguyflashgordon: :)17:25
flashgordonjohnthetubaguy: for too long the default reaction was: they don't work lets complicate things17:26
*** welldannit has quit IRC17:27
vilobhmm1johnthetubaguy : ping17:28
vilobhmm1hey john17:28
johnthetubaguyvilobhmm1: hi17:28
vilobhmm1must be late at your end will you be around for some time ?17:28
* jlk is back again to talk resize17:28
johnthetubaguyvilobhmm1: its half six, just finishin up, but happy to help if its quick17:29
vilobhmm1johnthetubaguy : so regarding https://review.openstack.org/#/c/138607/17:29
johnthetubaguyjlk: ah, resize, I like all things resize17:29
jlkso a resize scenario. I've issued a resize to take a server from flavor 2 to 3. It's now in VERIFY_RESIZE, should the IP of the instance be reachable at that point?17:29
vilobhmm1you wanted a precsise plan17:29
jlkit was reachable before the resize attempt17:29
vilobhmm1so here i what i am experimenting with17:29
superdanjlk: yes17:29
jlkwell.... poo.17:29
vilobhmm11. For non-db drivers zc.py : change tooz to make sure the data format understood by nova servicegroup driver and tooz zk driver are same for seemless migration17:30
jlkit's not reachable while in verify, but is reachable once again after revert.17:30
johnthetubaguyvilobhmm1: hi, really just need pick one of the options you already described, it seemed to have most things covered17:30
dimsum__johnthetubaguy: re: quotas, we should ping Salvatore (https://review.openstack.org/#/c/132127/1/specs/kilo/review_quota_module.rst,unified)17:30
*** thangp has quit IRC17:31
vilobhmm12. For mc.py…its tough as it keeps info at 2 places heartbeat in memcache whereas services info in mysql db…so may be come with a migration script to move service info from mysql db to memcache to make sure that tooz mc can start using it17:31
*** marun has quit IRC17:32
johnthetubaguydimsum__: ah, I wondered who was driving that effort, thanks for the heads up17:32
*** marun has joined #openstack-nova17:34
vilobhmm1johnthetubaguy : still need to unify the admin interface and the API interface as the admin interface still acts on the db (services table)17:34
johnthetubaguyvilobhmm1: disabled is different to up vs down, we might not be too bad in there, but yeah, need to check17:39
johnthetubaguyvilobhmm1: I like the approaches though, but honestly it might be overkill given the state of the current drivers, but I think its worth keeping that plan listed as a possible extension idea to help us remove the old drivers quicker17:40
*** burt has quit IRC17:40
johnthetubaguyvilobhmm1: thank you for pushing on this by the way, I think its a good idea, and I support it17:40
johnthetubaguyvilobhmm1: the other bit is just making it clear we keep the db driver when reading through the spec17:41
vilobhmm1johnthetubaguy : thank you ! given the response on the mailing list looks like no one is using mc,zk driver but yeah can't completely rely on it17:41
vilobhmm1so will have a migration plan in place17:42
vilobhmm1but again will verify the admin path17:42
vilobhmm1bcz its critical for making sure that mc and zk driver function properly17:42
johnthetubaguyvilobhmm1: yeah, lets document a plan for a migration, I mean just have a non-live upgrade work might be good enough for now, then lets get operator feedback on that to see if that good enough17:42
vilobhmm1dont want to end up in a situation where we have 2 sources of truth17:42
jlkoh, no, it does eventually ping, just took a while for ARP to clear out I guess17:43
johnthetubaguyvilobhmm1: totally agreed17:43
johnthetubaguyvilobhmm1: lets keep it simple (switch over from one to the other across a global service restart)17:43
vilobhmm1johnthetubaguy : i have proposed a session on this in liberty-nova-design session….will it be a good idea to get feedback in the summit on this topic let me know what you and other cores think about it17:43
johnthetubaguyvilobhmm1: then see how it goes after that17:43
vilobhmm1so that we have a concrete plan17:44
vilobhmm1sure17:44
vilobhmm1ok17:44
johnthetubaguyvilobhmm1: cools, we can give you a 10 min unconference if we don't get the spec merged, does that sound OK?17:44
*** dprince has joined #openstack-nova17:44
vilobhmm1unconference ? what does that mean ?17:44
johnthetubaguyvilobhmm1: but please remind me I promised you that while I can still follow through on that :)17:44
johnthetubaguyvilobhmm1: it just means we have an etherpad of 10 min slots really, let me get you the link17:45
johnthetubaguyvilobhmm1: http://libertydesignsummit.sched.org/event/a065a336855290d06a8949bac5d9f8be17:45
harlowjasup17:45
johnthetubaguyvilobhmm1: sorry, I have to run how, I hope that helps17:45
johnthetubaguyharlowja: sorry, I have to run, ill be honest, I am going to the cinema and if I don't go seen I don't get to eat desert! so its like really important :)17:46
vilobhmm1ok…have a good weekend17:46
johnthetubaguyharlowja: I am keen on the hole tooz thing, just need to get the plan clear in the spec, we are almost there17:46
johnthetubaguyvilobhmm1: and you when it happens!17:46
*** ajo has quit IRC17:47
superdanvilobhmm1: unconf sessions are where you can just sign up to talk for ten minutes on a thing17:47
superdanthat doesn't require a full session17:47
harlowjajohnthetubaguy sweet17:47
superdanand is good for getting people on board with a thing like this17:47
harlowjasuper vilobhmm1 weill have it under control17:47
harlowja*will17:48
jlksuperdan: so I did a manual test of the resize with your patch. Resize up, after a period of time, networking works on the resized instance (on a new host). Revert the resize and almost immediately networking works again back on the original host.17:48
superdanjlk: are you looking for dansmith? he doesn't work on fridays17:48
tjones2haha17:48
jlklol17:48
*** penick has joined #openstack-nova17:49
jlkyou should change /whois info if you're going to play that game17:49
superdanjlk: after a period of time, networking works on the new host?17:49
superdanheh17:49
jlksuperdan: yeah it's not right away. I'm guessing it's an ARP timeout at play17:49
superdanyeah17:49
vilobhmm1harlowja : lets see..aw…focus back to migration script now …17:49
harlowjak17:49
jlkthe vif gets plugged but arping just can't find it from the router network namespace17:50
cfriesenjlk: shouldn't something be doing GARP?17:50
superdanjlk: probably a question for some neutron person that understands your network driver17:50
vilobhmm1thanks for all the help harlowja. much appreciated17:50
jlkresolves fairly quick.17:50
*** annegentle has quit IRC17:50
harlowjavilobhmm1 and mess around more of that old-zk (run at same time as tooz-new zk)17:50
jlkcfriesen: maybe? I vaguely know what that term means, but this is black neutron magic, so I don't know for sure17:50
superdancfriesen: with nova-net we do I think, but that's why I'm saying: ask a neutron person17:50
vilobhmm1harlowja : sure..trying it out17:50
superdanjlk: either poisoning the arp cache, or sending a gratuitous update for the new thing17:50
jlksuperdan: I don't have a question actually. I'm providing data, in that I think the patch is good and does the right thing17:51
superdanjlk: i.e. just broadcasting an ARP packet from the new location17:51
superdanjlk: ah, okay17:51
jlktempest doesn't do anything to verify that the networking is functional, so I did it manually17:51
superdanI see, I thought you were concerned about the delay17:51
jlknah. frankly, that networking works at all is amazing to me17:51
jlkbut I'll save that observation for a later tweet ;)17:51
superdanare you on the same L2 as the instance or going through a switch/router?17:52
superdanheh17:52
superdanbecause if you are, you're probably seeing a greater delay than would be expected17:52
*** ZZelle has quit IRC17:52
jlkSame L2. I'm arpinging from the controller node where neutron services are running, the router and dhcp agents17:52
superdangeneral-purpose operating systems have some weird arp caching algorithms I think17:52
*** ZZelle has joined #openstack-nova17:52
jlkI should try giving it a floating IP and see how that all works out17:53
superdanin the neutron case, I'm really not sure who is responsible and for what on this kind of stuff17:53
jlk"it depends"17:53
superdanI would think the OVS could be told what is happening so that there is no delay and no need for gARP17:53
jlkdepends on which driver you've thrown your money at.17:54
superdanright17:54
superdanwell, I know *that* :)17:54
superdanI figured you were using normal OVS17:54
jlkin this cluster, it's linux-bridge and VLAN17:54
superdanoh, so,17:54
superdanlinux-bridge is wholly unsupported by neutron and not recommended, as I understand it17:54
superdanlike "don't use it at all" unsupported17:54
jlkthe ml2?17:54
jlkI thought that was The Future17:54
*** marun has quit IRC17:55
superdanI think "the future" is ovs, no?17:55
jlkI thought we were all running away from the OVS black box17:55
jlkbut maybe I'm wrong.17:55
jlkall our stuff has dropped OVS, we're all ml2 and either vlan or vxlan17:55
superdanI'm clearly showing my ignorance17:55
jlkme too17:55
superdanwhen people say "linux bridge" in neutron, I think that's usually the bad one I thought17:55
cfriesenjlk: isn't ml2 able to work with either ovs or linuxbridge17:55
superdanbut who knows, it's all bad to me :)17:55
jlkcfriesen: yes, that's correct17:56
superdanmestery: can you save us?17:56
mriedemsuperdan: except it's the default in devstack now17:56
superdanmriedem: for specific reasons right?17:57
cfriesenjlk: I had thought that linuxbridge was being proposed as a simple starting point, but OVS was necessary for "real" stuff17:57
mriedemto get people over from nova-network?17:57
jlkI guess it depends on your definition of "real"17:57
* mestery tries to catchup to save you guys17:57
*** isd has joined #openstack-nova17:57
jlkfor giant clusters, maybe. OVS or some other SDN17:57
*** irenab has joined #openstack-nova17:57
jlkfor 3~20 node clusters...?17:57
superdanmestery: I thought ml2 + linuxbridge was not recommended for anyone in prod17:57
mesteryLB is only unsupported in that nothing we gate on uses it. PEr sc68cal, it does actually work now, last I heard.17:57
superdanokay, I thought it was also a thing you didn't want to support17:58
mesterysuperdan: That's a pretty valid statement right now, though things may work. We just don't gate on it, so it's current state isn't fully known.17:58
*** dprince has quit IRC17:58
mesterysuperdan: I think we have to support it, we've heard from enough ops they want to use it.17:58
superdanmestery: okay excellent, I agree with *that* :)17:58
mesterylol17:58
superdanmestery: so is linuxbridge maybe missing some gARP bits to make migrations work seamlessly17:59
mesterysuperdan: sc68cal has done some work (with others) to revivie support recently17:59
superdanwithout arp delays?17:59
superdanmestery: excellent17:59
mesterysuperdan: That's entirally possible, yes.17:59
superdanjlk: ^17:59
mriedemmestery: so what does this mean?17:59
mriedemhttp://logs.openstack.org/06/179406/1/check/check-tempest-dsvm-neutron-full/2f7d58a/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz17:59
*** packet has quit IRC17:59
mriedemmechanism_drivers = openvswitch,linuxbridge17:59
*** dprince has joined #openstack-nova17:59
*** dprince has quit IRC17:59
mriedemfirewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver18:00
mesterymriedem: That means the ML2 plugin has the logic for LB and OVS enabled18:00
mriedemwell ignore firewall18:00
* jlk will make it a point to ask all the ops show-and-tell folks to tell us what network driver they're using.18:00
*** dprince has joined #openstack-nova18:00
sc68calhaving both openvswitch and linuxbridge in the mechanism_drivers setting is misleading, as I have learned recently18:00
mesterysc68cal: ++18:00
sc68calsince you can only run either the OVS agent or LB agent18:00
*** kaufer has quit IRC18:01
mesterysc68cal: Well, per host, but you can run different agents on different hosts with ML2.18:01
superdansc68cal: if you read back far enough, you'll see a question from jlk that sounds like he's not getting gARP after a migration with linuxbridge18:01
superdansc68cal: which he seems altogether unfazed about, but thought I'd mention it :)18:02
*** irenab has quit IRC18:02
mriedemmestery: sc68cal: was also wondering how in here http://logs.openstack.org/06/179406/1/check/check-tempest-dsvm-neutron-full/2f7d58a/logs/etc/neutron/neutron.conf.txt.gz - none of the nova_admin* options are set but notify_nova_on_port_status_changes = True and events are showing up in nova-compute,18:02
*** busterswt has quit IRC18:02
jlkheh18:02
mriedemhow does that work if neutron doesn't know the credentials to talk to nova api?18:02
superdanyeah, I wanna know that too :)18:02
* mestery looks18:02
* sc68cal needs coffee if he's going to solve mysteries18:02
mriedemscooby snacks?18:03
sc68cal:)18:03
jlkkeystone_authtoken18:03
jlkthat's where the data is18:03
isdHey, so I'm a newbie trying to get familiar with the nova codebase, and I was going through the developer guide. The bit about adding a method to the API references something called ApiRouter, but it's not where it says it should be, and grepping the source tree for it only yields the line in that document. I poked through the history, and I'm not sure this was *ever* correct -- even in the commit that added that document, it isn't there.18:03
jlkwait, not quite18:03
superdanjlk: no18:03
superdanjlk: unless something has changed18:03
* sc68cal tries to think of the apropriate channel to talk about sane linux bridge defaults 18:05
jlkyeah I'm wrong, it's in the [DEFAULT] block18:05
*** busterswt has joined #openstack-nova18:05
*** igordcard has quit IRC18:05
*** ajo has joined #openstack-nova18:05
*** packet has joined #openstack-nova18:05
*** dprince has quit IRC18:05
*** dprince has joined #openstack-nova18:06
*** igordcard has joined #openstack-nova18:06
* mriedem has to reboot18:06
*** mriedem has quit IRC18:06
*** annegentle has joined #openstack-nova18:07
melwittisd: there is APIRouter (different capitalization), which might be what it's talking about18:07
superdanlascii: replied18:08
*** isd has quit IRC18:08
*** lucas-beer has quit IRC18:08
superdanlascii: oh damn, that notification got delayed18:09
*** hemna_ has quit IRC18:09
superdanlascii: I was trying to keep up the impression that I had your system rooted.. oh well :)18:09
*** sdake_ has joined #openstack-nova18:09
*** marun has joined #openstack-nova18:09
*** hemna_ has joined #openstack-nova18:10
*** annegentle has quit IRC18:10
*** annegentle has joined #openstack-nova18:11
*** salv-orlando has joined #openstack-nova18:11
*** mriedem has joined #openstack-nova18:12
*** sdake has quit IRC18:13
ndipanoffsuperdan, bauzas https://review.openstack.org/#/c/163440/18:14
ndipanoffI think Bart is actually right there18:14
ndipanoffthough it's a subtle matter18:14
*** neelashah has quit IRC18:15
*** sdake has joined #openstack-nova18:15
*** mriedem has quit IRC18:16
*** mriedem has joined #openstack-nova18:16
superdanndipanoff: I don't understand that at all18:16
cfriesenndipanoff: I work with Bart...we've got a version of what he's proposing working internally, needed it to get CPU pinning working properly over migration/evac/resize/rebuild/etc.18:17
superdanndipanoff: the state is persisted in the instance object's numa_topology, right?18:17
ndipanoffwell the state for the compute host it's currently on18:17
ndipanoffbut not the state for the "target"18:17
ndipanoffsuperdan, in theory this could be persisted on the instance similar to the old_ and new_ flavors18:19
superdanI guess I don't see why they're different18:19
*** salv-orlando has quit IRC18:19
*** sdake_ has quit IRC18:19
superdanndipanoff: I *hate* putting it on the migration object, just FYI18:19
ndipanoffso it does not _have_ to be on the migration18:19
cfriesensuperdan: for pci and CPU pinning, we need to know the exact cpus/devices that were claimed18:19
*** dprince_ has joined #openstack-nova18:19
ndipanoffright18:19
ndipanoffcfriesen,18:19
ndipanoffthis is what I tried to explain on the last comment18:19
*** dprince has quit IRC18:19
cfriesenndipanoff: yeah, just reading that.18:20
ndipanoffwhere it goes in the DB is a different matter18:20
ndipanoffthe point is it has to go somewhere18:20
cfriesenndipanoff: something similar is needed for live migration too..have to update the xml of the instance being migrated with the new pinning/numa information18:20
ndipanoffcfriesen, right - but that is a bigger problem since we don't even have claims18:21
cfriesensuperdan: the nice thing about putting it on the migration object is that it's preserved if we abort the migration18:21
superdanndipanoff:  you mean we have to save both copies just so that if we succeed, we can start reporting that those resources are taken, and if we revert, the same?18:21
*** dprince_ has quit IRC18:21
lasciisuperdan: hah.  you were 18 minutes delayed18:22
cfriesensuperdan: the scheduler thinks those resources are taken, so we need to actually use the specific resources that were reserved18:22
superdanlascii: not me, the notification :)18:22
lasciisuperdan: heh18:22
ndipanoffsuperdan, once there is a migration going on - we report usage on both hosts18:22
*** isd has joined #openstack-nova18:23
ndipanoffbut we need to report _that exact_ usage that was claimed18:23
superdanndipanoff: so, is this just the cpu_topology element of instance_numa_topology?18:23
*** isd has quit IRC18:23
ndipanofflemme check, but yes18:23
ndipanoffonly the dict that maps to host cpus is what changes18:23
*** packet has quit IRC18:23
ndipanoffweeeelll18:23
cfriesensuperdan: ndipanoff: wouldn't pci devices be included as well?18:23
ndipanoffactually we could have a completely different topology18:23
ndipanoffmore cells etc18:23
ndipanoffbased on the flavor18:24
superdancfriesen: I'm talking the numa bits now18:24
ndipanoffso if it's migrate then yes18:24
ndipanoffif it's resize - then no18:24
openstackgerritChris Friesen proposed openstack/nova: Conditionally expose "last_seen_up" in service list  https://review.openstack.org/16841818:25
ndipanofffwiw - when cfriesen and bart sent the email to the list18:25
ndipanoffI also complained about it being on the migration object/table18:25
* ndipanoff read the email again18:25
ndipanoffsuperdan, so - no it does not actually have to be on the migration18:25
*** bwensley has joined #openstack-nova18:27
superdanwe're talking about some actual stuff here now, so saving it forever on the migration object doesn't seem ideal to me18:28
superdanand, I'll say, keeping two copies at all doesn't seem great either18:28
ndipanoffwell at some point we need both of them18:29
superdanit's just frustrating that this stuff has gaps this large :/18:29
cfriesensuperdan: so what's the proposal?  where would we keep the information about the old/new numa topology (and pci devices) to allow for reverting a resize/migration18:29
ndipanoffsuperdan, lol - you haven't read the scheduler code in a while then if you think these are gaps18:29
*** neelashah has joined #openstack-nova18:29
ndipanoffcfriesen, fwiw - pci devices don't have this same problem18:30
superdancfriesen: we keep those on the instance right now18:30
cfriesenndipanoff: when you can't migrate a pinned instance, I think that's a gap. :)18:30
*** neelashah1 has joined #openstack-nova18:30
ndipanoffbecause18:30
superdancfriesen: it would have been nice if the numa object had an old_set and new_set so that we were set up for this, is kinda what I'm getting at18:30
ndipanoffpci devices are already stateful objects18:30
superdanI think the pci_requests object has a flag for "next"18:30
superdanfor this reason, but I could be wrong18:31
leakypipesgotta love when you go to get a link to something in nova and discover two bugs in glance. :(18:31
*** Marga_ has quit IRC18:31
ndipanoffi.e. every pci device is a row in the db with a state18:31
ndipanoffno such thing for cpus18:31
*** kaufer has joined #openstack-nova18:31
cfriesensuperdan: I think we'd need duplicate cpu_pinning_raw then18:31
ndipanoff(maybe that would have been a better design?)18:31
*** Marga_ has joined #openstack-nova18:31
cfriesensuperdan: and as ndipanoff said for resize we need new everything18:31
ndipanoffcfriesen, superdan the problem with that is the whole topology can change18:31
mriedemmestery: sc68cal: did you figure out the mystery of the missing nova api credentials and events thing while i was rebooting?18:31
ndipanoffi.e. resize from 1 to 2 cell instance18:32
superdancfriesen: ndipanoff: well, then I guess we need current and new_ or something directly on instance18:32
superdanndipanoff: yeah18:32
ndipanoffthat would work yes18:32
superdanndipanoff: I just don't want to duplicate any higher than we need18:32
cfriesensuperdan: for resize you need new InstanceNUMATopology so I think it makes sense to reuse that for migration too18:33
sc68calmriedem: nope - still a mystery me18:33
superdancfriesen: obviously they'd both use the same temp storage yeah18:33
superdanso,18:33
ndipanoffIMHO 2 things that we want to consider - what the python api looks like, and that there is consistency18:33
ndipanofffrom consistency pov - it should be old_ and new_18:34
superdanwell,18:34
ndipanofflike flavor really18:34
superdando there need to be three?18:34
*** neelashah has quit IRC18:34
cfriesenndipanoff: what about the one currently in use?18:34
superdanbecause it's terrible that flavor has three, but that's how it is18:34
ndipanoffit's old_18:34
superdanshould be current and _temp or something18:34
ndipanoffok cool18:34
cfriesensuperdan: agreed18:34
superdanat one point _temp is the one you will roll to, and then _temp becomes what you roll back to18:34
ndipanoffsounds good18:35
superdanso, I know this sounds just like using the migration object, but:18:35
superdanI wonder if what we really want is a MigrationContext object,18:35
superdanthat holds a spare flavor, a numa, a pcithing, etc18:35
superdanand when we're doing a migration, that holds the things we want,18:35
superdanand when we're done it all goes away, no waste18:35
ndipanoffthat does sound like the migration object :)18:36
superdanthe difference is it's not a big join to a thing that never gets deleted18:36
superdanit's a column in instancextra that we null out when we're done18:36
*** Mike_D_laptop has joined #openstack-nova18:36
ndipanoffsounds good18:36
superdanif we're going to get to actually deleting stuff, we have to start doing that kind of thing18:36
*** iamjarvo has quit IRC18:37
ndipanoffcfriesen, ^ makes sense to you?18:38
bwensleyDo we care that the resource audit on compute nodes is going to be doing more DB lookups?18:38
ndipanoffbwensley, it won't it will get it with the instance18:38
bwensleyIt already has the migration objects, but now will be digging around in instance extra as well.18:38
*** Marga_ has quit IRC18:38
ndipanoffand we join on instance extra already18:38
superdanright, using extra is much better for overhead18:38
*** Marga_ has joined #openstack-nova18:38
bwensleyOK - I'm not keen on the current and temp naming.18:39
bwensleyUsing source and dest makes the code a LOT easier to read.18:39
superdanbwensley: you'll say Instance.get_by_uuid( ... , expected_attrs=[migrationstuffs])18:39
ndipanoffbwensley, well if we have migration context18:39
bwensleyIf we're deleting these anyways after the migration is done...18:39
ndipanoffit can just be same as on instance18:39
ndipanoffso mig_ctxt.numa_topology18:39
superdanright18:39
superdannice symmetry there18:40
superdanbecause at least with flavors,18:40
ndipanoffyes I like this18:40
superdanyou need to switch the new to the current at some point18:40
ndipanoffwell same here18:40
superdanand then the temp stash becomes the old one if you need to rollback18:40
cfriesenpresumably we'd delete the hypothetical migration context when doing the confirm migrate/resize?18:41
superdanndipanoff: so let me ask18:41
superdancfriesen: right18:42
superdanndipanoff: it's not that we need to be able to rebuild the old topo if we revert, but that the old host needs to continue to report the old topo for minutes while the migration is going on, right?18:42
superdans/not/not just/18:43
cfriesensuperdan: we don't want to rebuild it, we want to be able to revert back to it if desired18:43
ndipanoffso it definitely needs to report it while the mig is happening18:43
cfriesensuperdan: but yeah, the resources are in use until migration/resize is confirmed18:43
*** salv-orlando has joined #openstack-nova18:43
superdanndipanoff: how does that work with flavors? does the old compute host know to start reporting instance.old_flavor magically?18:43
ndipanoffand revert also uses it no?18:43
ndipanoffsuperdan, look at usage_from_migration18:44
ndipanoffin instance tracker18:44
ndipanoffer18:44
ndipanoffresource_tracker18:44
*** ajo has quit IRC18:44
ndipanoffor rather _update_usage_from_migration18:44
ndipanoffit's nicely commented18:44
ndipanoffeven18:44
superdanokay18:45
superdanI see, yeah18:45
*** burt has joined #openstack-nova18:45
ndipanoffso we need to hold both so that we can revert18:46
superdanso wait18:46
superdanoh right18:46
superdannevermind18:46
*** salv-orlando has quit IRC18:46
*** leakypipes has quit IRC18:46
*** lpetrut has joined #openstack-nova18:46
ndipanoffbasically once a claim is made on the target host18:47
ndipanoffwe are double booking the migrating instance18:47
*** Mike_D_laptop has quit IRC18:47
*** otter768 has joined #openstack-nova18:47
superdanso the scheduler doesn't ever look at instance.numa_topology, right? It just looks at the usage that we send from the compute node, right?18:47
ndipanoffyes18:47
ndipanoffwell18:47
ndipanoffit tries to place the instance it is scheduling18:47
superdanso it seems to me like maybe it's a flawed design in the first place to store the topo that we assigned like we do, such that we have this state we have to sync,18:47
ndipanoffok let me parse that again18:48
superdanand instead let the hypervisor driver build up the details we need to report18:48
ndipanoffwell that's not how RT works18:48
superdanbecause all the scheduler cares about is what cpus and nodes are used/free right?18:48
superdan"how RT works" is a really weak argument IMHO :)18:48
ndipanoffRT loops on instances from the db18:48
ndipanoffand accumulates the usage18:49
bwensleyThe hypervisor may not have up-to-date info18:49
superdanbwensley: WAT18:49
ndipanoffsuperdan, but yeah18:49
*** hemna_ has quit IRC18:49
bwensleyIf several things are migrating to a node and haven't actually spawned yet.18:49
superdanbwensley: for the instances actually running it better :)18:49
bwensleyagreed18:49
bwensleyBut not for things scheduled but not yet running.18:49
cfriesenthe scheduler technically only needs to know how many cpus are available on which numa nodes, not which specific CPUs are in use.18:49
ndipanoffcfriesen, well18:49
*** iamjarvo has joined #openstack-nova18:50
*** ivasev has quit IRC18:50
ndipanoffnow - yes - but if we add the sibling preference feature that we cut from the orriginal BP then no18:50
superdanso this seems like it would be massively simpler if we didn't store anything about the topo we assigned, build that from the HV's knowledge of reality, and then just support placing a claim on the resources of the incoming compute node18:50
*** iamjarvo has joined #openstack-nova18:50
ndipanoffsuperdan, well that kind of completely invalidates the  premise of how RT works now18:51
cfriesensuperdan: but once we've claimed those resources we need to preserve that claim.18:51
ndipanoffwhich is - Nova DB is the truth18:51
superdancfriesen: we could do that in memory or in the db if desired18:51
ndipanoffeverything else is lies damn lies18:51
superdanndipanoff: well, it does that for instance usage information maybe not not for host usage yes?18:51
*** otter768 has quit IRC18:51
ndipanoff?18:52
superdanndipanoff: even still, we could run a single thing before we do an update cycle that built the numa context, and just update that as we go along18:52
superdanndipanoff: we report actual host memory usage, disk usage, etc, not just what we think we've used based on the instances18:52
ndipanoffnope18:52
ndipanoffwe only log it18:52
superdanwell, another good example of using RT's current behavior as a counterexample :)18:53
bwensleysuperdan: what does using the hypervisor info buy us?18:53
*** salv-orlando has joined #openstack-nova18:53
superdanbwensley: not having to store it, sync it, etc18:53
bwensleyWe still need the DB info for instances not yet launched (or migrating)18:53
superdanbwensley: we have that, that's the point18:53
superdanbwensley: we're keeping this info in a lot of places18:54
superdanbwensley: only one of them matters18:54
*** marun has quit IRC18:54
superdanbwensley: we're *going* to store the request spec, which has it, and the hypervisor has it, and we store the assigned version of it, and we're going to now store the next/planned version of it18:54
bwensleyThe only duplication there is between the hypervisor and the assigned version in the instance.18:56
bwensleyThe request spec is not the same as the assigned topology.18:56
superdanright, I get that the four copies are different in very tiny ways :)18:57
bwensley:)18:57
bwensleyI like the idea that nova is in charge - it should be telling the hypervisor what it should be running - not relying on the hypervisor to tell it what is running.18:58
*** irenab has joined #openstack-nova18:58
superdanwell, that's the opposite approach we take for things like instance state18:58
superdanthey're different things for sure18:58
superdanbut the HV state is the only one that matters, and storing it doesn't really make any sense to me. it's not like the HV can avoid the duplication of storing it18:59
*** signed8bit is now known as signed8bit_ZZZzz19:00
ndipanoffI kinda agree with bwensley here - nova's job is to do these things19:00
ndipanoffit's the "management" software19:00
bwensleyAnd if the instance dies in the hypervisor, nova needs to be able to re-create it.19:00
ndipanoffit should manage stuff19:01
ndipanoff:)19:01
superdananyway, it sounds like the migration context is the shortest path here, which I think everyone was okay with19:01
*** achanda has quit IRC19:01
*** penick has quit IRC19:02
superdanthis also reminds me that at one point there was a suggestion for each compute node to have some local persistent storage for things like this19:02
*** irenab has quit IRC19:02
*** sdake_ has joined #openstack-nova19:04
*** subscope has quit IRC19:04
*** sdake__ has joined #openstack-nova19:05
*** sdake has quit IRC19:05
*** ijw has joined #openstack-nova19:07
*** busterswt has quit IRC19:08
*** Marga_ has quit IRC19:09
*** Marga_ has joined #openstack-nova19:09
*** sdake_ has quit IRC19:09
*** emagana has quit IRC19:10
cfriesensuperdan: on the topic of "cpu model per flavor", you had mentioned letting users define their own "cpu flavor".  How would that work without requiring detailed knowledge of what features are supported by what hypervisor?  I'm envisioning a setup where a user makes a flavor but only one compute node in the entire cluster can actually run it.19:11
*** pixelb has quit IRC19:11
cfriesensuperdan: would we need a "how many compute nodes can run this flavor" query?19:11
cfriesencpu flavor, rather19:12
superdancfriesen: I wasn't completely serious about us doing that, but more for the exercise19:12
*** signed8bit_ZZZzz is now known as signed8bit19:12
superdancfriesen: you'd create it, and it would succeed if it didn't violate policy, and then yeah, it might seriously limit what you can boot on,19:12
superdancfriesen: but so will requesting a very specific set of flags through your current approach19:12
superdancfriesen: right now providers mask out flags for reasons I mentioned,19:13
cfriesensuperdan: our "actual" current approach just allows specifying one of a half-dozen cpu models. :)19:13
superdancfriesen: so if you want a consistent cpu model in your guest, it's really hard to know whether you can get that or what something that is compatible actually looks like19:13
*** emagana has joined #openstack-nova19:13
superdancfriesen: yes, and those models differ per provider even though they seem like they should be the same19:14
*** isd has joined #openstack-nova19:15
ndipanoffsuperdan, re: local storage on compute nodes - interesting idea19:15
*** marun has joined #openstack-nova19:15
cfriesensuperdan:  the main issue is that I want end-users to be able to build with "gcc -march=<model>" and be able to specify something equivalent.  And maybe it'll need a bit of tweaking.  I don't know that it's realistic to expect it to work across all hypervisors or all providers.19:15
superdanndipanoff: I forget what the original reason for it was, but there were some interesting things we could do better if we had it19:15
isdack, connection dies right after I ask a question...19:16
superdancfriesen: I know that that's what you want19:16
superdancfriesen: the point of our API is to get us to the goal of being as provider and hypervisor-agnostic as possible19:16
superdancfriesen: since these flags are not fluid things, we shouldn't punt here, IMHO19:16
cfriesensuperdan: how can we possibly do that if different providers mask arbitrary features?  Or do we do like Alex'19:17
cfriesenAlex19:17
cfriesengrr, can't type19:17
cfriesenAlex's suggestion and have each hypervisor report supported model/features.19:18
superdancfriesen: well, the point of the cpu flavor thing was that we could check whether a specific set of flags was possibly supported on a cloud19:18
superdancfriesen: and of course, there would be default flavors they provide19:18
ndipanoffsuperdan, maybe woudl be cool to respond on https://review.openstack.org/#/c/163440/ and -2->-1 it19:19
*** isd has quit IRC19:19
superdancfriesen: so maybe your application says "I have three clouds, and I need to run a thing that does transcoding which needs a foobar cpu, so that means two of the three are candidates"19:19
*** marun has quit IRC19:21
*** bkopilov has quit IRC19:21
*** Marga_ has quit IRC19:22
*** Marga_ has joined #openstack-nova19:23
cfriesensuperdan: yeah, so it sounds like you're literally talking about nova using a whole new "cpu flavor" object that corresponds to a set of low-level features (since model names aren't precise enough)19:23
cfriesensuperdan: and then each compute node would export what features it supports?19:24
*** marun has joined #openstack-nova19:24
cfriesensuperdan: when booting an instance the hypervisor driver could map a bunch of features to a model if it wants, or just use a feature list19:24
*** isd has joined #openstack-nova19:24
*** VW_ has quit IRC19:25
superdancfriesen: well, the model mapping would just be a sample flavor19:25
superdanlike the regular flavors we have today19:25
cfriesensuperdan: yeah, but if we're trying to be generic then the nova "model" wouldn't necessarily map 1:1 to a hypervisor "model"19:26
superdanthe thing is, encoding this all in a 255 char metadata string really sucks19:26
superdancfriesen: right19:26
*** arnaud____ has joined #openstack-nova19:27
superdancfriesen: again I'm not really suggesting we do this as my preference for solving the problem,19:27
cfriesensuperdan: stick it in the DB and query it from the compute node?19:27
*** marun has left #openstack-nova19:27
superdanI'm sure people like jaypipes will freak if they read my comment19:27
superdanbut encoding all of intel's history in 255 chars is dumb, IMHO :)19:28
cfriesensuperdan: it seems like either we need something like your cpu flavor idea, or else we need to accept that a model name will give different results on different hypervisors19:28
superdanwell, I don't think that the latter is doable19:29
superdaneven danpb didn't like that idea, IIRC :)19:29
superdanand when danpb and I agree on something.. holy crap, look out :)19:29
* superdan employs hyperbole19:29
cfriesendanpb just suggested having all the other hypervisors use the libvirt model names, so that's cheating a bit. :)19:30
*** Marga_ has quit IRC19:30
superdanwell, it is because libvirt ain't the only game in town19:30
*** Marga_ has joined #openstack-nova19:30
*** VW_ has joined #openstack-nova19:31
superdanIIRC, xen even had some fictitious cpu flags it used to expose hypervisor characteristics19:31
*** arnaud____ has quit IRC19:32
*** bkopilov has joined #openstack-nova19:32
cfriesenlots of different ideas here...I'm a bit worried that we'll end up with something so generic (but complicated) that it takes three releases to get done19:34
*** hemna_ has joined #openstack-nova19:34
*** isd has quit IRC19:38
*** bkopilov has quit IRC19:39
*** annegentle has quit IRC19:43
superdancfriesen: on the other hand, it's extremely likely we'll end up with something so naive that it's not really useful, yet it's codified in our API forever19:43
superdanso, you know, pick your poison19:43
*** alanf-mc_ has joined #openstack-nova19:48
*** penick has joined #openstack-nova19:49
*** HenryThe8th has quit IRC19:50
*** ajo has joined #openstack-nova19:50
*** bkopilov has joined #openstack-nova19:51
*** alanf-mc has quit IRC19:51
*** ajo has quit IRC19:52
*** ajo has joined #openstack-nova19:52
*** HenryG has joined #openstack-nova19:54
*** HenryG has quit IRC19:55
*** HenryG has joined #openstack-nova19:56
cfriesensuperdan: yeah, fair enough.  maybe we need operator input. :)19:56
*** cfriesen is now known as cfriesen_away19:56
superdanoh, that'll help for sure :)19:56
* superdan runs19:56
*** bkopilov has quit IRC19:57
*** irenab has joined #openstack-nova19:59
*** penick has quit IRC19:59
*** achanda has joined #openstack-nova19:59
*** dave-mccowan has quit IRC19:59
*** isd has joined #openstack-nova20:00
*** jecarey has joined #openstack-nova20:02
*** xyang1 has joined #openstack-nova20:03
*** irenab has quit IRC20:03
*** whenry has joined #openstack-nova20:05
*** bwensley has quit IRC20:06
*** VW_ has quit IRC20:06
*** yamahata has quit IRC20:07
*** lpetrut has quit IRC20:10
*** annegentle has joined #openstack-nova20:10
openstackgerritJosh Gachnang proposed openstack/nova: Reschedules sometimes do not allocate networks  https://review.openstack.org/17747020:11
*** baoli has quit IRC20:12
*** baoli has joined #openstack-nova20:13
*** krak has joined #openstack-nova20:13
*** alanf-mc has joined #openstack-nova20:14
*** isd has quit IRC20:16
*** HenryG has quit IRC20:16
*** penick has joined #openstack-nova20:17
*** alanf-mc_ has quit IRC20:19
*** emagana has quit IRC20:21
*** HenryG has joined #openstack-nova20:21
*** dave-mccowan has joined #openstack-nova20:21
*** isd has joined #openstack-nova20:22
openstackgerritOpenStack Proposal Bot proposed openstack/nova: Updated from global requirements  https://review.openstack.org/17934020:22
*** isd has quit IRC20:22
*** emagana has joined #openstack-nova20:23
*** mwagner_lap has quit IRC20:23
*** isd has joined #openstack-nova20:24
*** isd has quit IRC20:25
*** isd has joined #openstack-nova20:26
*** isd has quit IRC20:26
*** igordcard has quit IRC20:26
*** sdake__ is now known as sdake20:27
*** isd has joined #openstack-nova20:29
*** isd has quit IRC20:29
*** isd has joined #openstack-nova20:31
*** emagana has quit IRC20:32
*** isd has quit IRC20:32
*** isd has joined #openstack-nova20:35
*** isd has quit IRC20:35
*** jgrimm is now known as zz_jgrimm20:37
*** exploreshaifali has quit IRC20:38
*** mriedem has quit IRC20:38
*** mriedem has joined #openstack-nova20:39
*** isd has joined #openstack-nova20:41
*** isd has quit IRC20:41
*** isd has joined #openstack-nova20:44
*** isd has quit IRC20:45
*** isd has joined #openstack-nova20:46
*** isd has quit IRC20:46
*** otter768 has joined #openstack-nova20:48
*** burt has quit IRC20:48
*** claudiub has quit IRC20:49
*** burt has joined #openstack-nova20:51
*** isd has joined #openstack-nova20:51
*** isd has quit IRC20:52
*** otter768 has quit IRC20:52
openstackgerritChris Friesen proposed openstack/nova: Conditionally expose "last_seen_up" in service list  https://review.openstack.org/16841820:52
*** isd has joined #openstack-nova20:53
*** isd has quit IRC20:53
*** salv-orlando has quit IRC20:59
*** IanGovett1 has quit IRC21:00
*** ndipanoff has quit IRC21:01
*** mriedem has quit IRC21:03
*** mriedem has joined #openstack-nova21:03
*** penick has quit IRC21:04
*** emagana has joined #openstack-nova21:06
*** ijw has quit IRC21:06
*** ajayaa has joined #openstack-nova21:07
*** ijw_ has joined #openstack-nova21:08
*** neelashah1 has quit IRC21:09
*** ajo has quit IRC21:09
*** salv-orlando has joined #openstack-nova21:09
*** packet has joined #openstack-nova21:13
*** ajo has joined #openstack-nova21:15
*** iamjarvo has quit IRC21:15
*** ajo has quit IRC21:18
*** boris-42 has quit IRC21:18
*** burt has quit IRC21:18
*** achanda has quit IRC21:19
*** burt has joined #openstack-nova21:19
*** achanda has joined #openstack-nova21:20
*** browne has quit IRC21:21
*** iamjarvo has joined #openstack-nova21:21
*** iamjarvo has quit IRC21:21
*** iamjarvo has joined #openstack-nova21:22
*** oro has quit IRC21:23
*** packet has quit IRC21:23
*** emagana has quit IRC21:28
*** iamjarvo has quit IRC21:28
*** cbader has quit IRC21:28
*** emagana has joined #openstack-nova21:31
openstackgerritVladik Romanovsky proposed openstack/nova: libvirt: introduce libosinfo library to set hardware policy  https://review.openstack.org/14962521:33
openstackgerritVladik Romanovsky proposed openstack/nova: libvirt: use osinfo when configuring network model  https://review.openstack.org/14962721:33
openstackgerritVladik Romanovsky proposed openstack/nova: libvirt: adding libosinfo configuration  https://review.openstack.org/14962621:33
openstackgerritVladik Romanovsky proposed openstack/nova: libvirt: use osinfo when configuring the disk bus  https://review.openstack.org/14962821:33
*** tjones2 has quit IRC21:41
*** tjones2 has joined #openstack-nova21:41
*** melwitt_ has joined #openstack-nova21:43
*** melwitt has quit IRC21:46
*** mriedem has quit IRC21:46
*** melwitt_ is now known as melwitt21:46
*** baoli has quit IRC21:47
*** baoli has joined #openstack-nova21:48
*** irenab has joined #openstack-nova21:48
*** kaufer has quit IRC21:49
*** irenab has quit IRC21:53
superdanJoshNang: does this mean that it worked?21:54
*** dimsum__ has quit IRC21:56
*** penick has joined #openstack-nova21:56
JoshNangsuperdan: oh shoot forgot to put that in my comments. yup as far as i can tell! even after adding a 50% artifical fail rate in the virt driver to cause more reschedules21:56
superdanJoshNang: that is...excellent news :)21:56
*** dimsum__ has joined #openstack-nova21:56
JoshNangthanks for the help!21:56
superdannp!21:57
*** dboik has quit IRC21:59
*** nelsnelson has quit IRC22:02
*** bkopilov has joined #openstack-nova22:08
*** bkopilov has quit IRC22:13
*** bkopilov has joined #openstack-nova22:14
*** patrickeast has quit IRC22:16
*** emagana has quit IRC22:21
*** bkopilov has quit IRC22:21
*** Marga_ has quit IRC22:21
*** bkopilov has joined #openstack-nova22:21
*** Marga_ has joined #openstack-nova22:22
*** ijw has joined #openstack-nova22:24
*** artom has quit IRC22:25
*** artom has joined #openstack-nova22:26
flashgordonmikal: you around?22:27
flashgordonjohnthetubaguy: ping22:27
flashgordonre: nova-ci want to stop the hpyerv from voting as its broken22:27
*** ijw_ has quit IRC22:28
*** ajayaa has quit IRC22:30
*** Marga_ has quit IRC22:31
*** Marga_ has joined #openstack-nova22:32
morganfainbergjohnthetubaguy: have a question re: stable maint nova group if you have a few moments (specifically do you have the ability to edit people in the nova-stable-maint group)?22:32
*** bkopilov has quit IRC22:33
flashgordonmorganfainberg: I am 99% johnthetubaguy just forgot to become zz_johnthetubaguy22:34
morganfainbergflashgordon: haha22:34
flashgordonI don't think he is online at 10PM on a friday night22:35
*** ijw has quit IRC22:36
*** annegentle has quit IRC22:36
*** Marga_ has quit IRC22:36
*** Marga_ has joined #openstack-nova22:36
morganfainbergfair enough22:37
morganfainbergUK?22:37
*** dboik has joined #openstack-nova22:37
*** emagana has joined #openstack-nova22:38
*** dboik_ has joined #openstack-nova22:38
flashgordonyup22:39
*** Marga_ has quit IRC22:40
*** bkopilov has joined #openstack-nova22:40
*** dboik has quit IRC22:42
*** Marga_ has joined #openstack-nova22:44
flashgordonsuperdan: you ever see this: http://logs.openstack.org/98/179398/2/experimental/check-tempest-dsvm-multinode-full/d44f762/logs/screen-n-cpu.txt.gz?level=TRACE22:46
*** bkopilov has quit IRC22:46
*** cfriesen_away is now known as cfriesen22:47
*** bkopilov has joined #openstack-nova22:47
*** packet has joined #openstack-nova22:47
cfriesenso I'm working on https://review.openstack.org/#/c/168418/  and I'm getting a weird error in the functional tests: http://logs.openstack.org/18/168418/9/check/gate-nova-tox-functional/81b0de3/testr_results.html.gz22:48
cfriesenanyone have any ideas where this is coming from?22:48
*** markvoelker has quit IRC22:48
*** otter768 has joined #openstack-nova22:49
*** Marga_ has quit IRC22:49
*** Marga_ has joined #openstack-nova22:50
*** artom has quit IRC22:51
*** otter768 has quit IRC22:53
*** Marga_ has quit IRC22:54
*** packet has quit IRC22:56
*** gokrokv__ has quit IRC22:58
openstackgerritChris Friesen proposed openstack/nova: Conditionally expose "last_seen_up" in service list  https://review.openstack.org/16841822:59
*** dave-mccowan has quit IRC22:59
*** penick has quit IRC23:00
*** signed8b_ has joined #openstack-nova23:01
*** bkopilov has quit IRC23:04
*** signed8bit has quit IRC23:04
*** Marga_ has joined #openstack-nova23:08
*** bkopilov has joined #openstack-nova23:11
*** hemna_ has quit IRC23:11
*** IanGovett has joined #openstack-nova23:12
*** boris-42 has joined #openstack-nova23:18
*** signed8bit has joined #openstack-nova23:19
*** IanGovett has quit IRC23:20
*** achanda_ has joined #openstack-nova23:21
*** signed8b_ has quit IRC23:22
*** achanda has quit IRC23:25
*** achanda_ has quit IRC23:26
*** figleaf is now known as edleafe23:29
*** browne has joined #openstack-nova23:34
*** sdake_ has joined #openstack-nova23:36
*** irenab has joined #openstack-nova23:38
*** sdake has quit IRC23:39
*** sdake has joined #openstack-nova23:39
*** josecastroleon has joined #openstack-nova23:41
*** sdake_ has quit IRC23:42
*** irenab has quit IRC23:43
*** josecastroleon has quit IRC23:44
alex_xucfriesen: looks like you already fixed https://review.openstack.org/168418? tested it works in my local23:45
alex_xucfriesen: ok, you fixed it. new patchset updated the version api sample file23:46
*** emagana has quit IRC23:52
*** pixelb has joined #openstack-nova23:52
*** flwang has quit IRC23:58

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