Friday, 2015-11-20

*** EinstCrazy has joined #openstack-nova00:01
*** akshai has quit IRC00:01
*** gjayavelu has quit IRC00:01
*** markvoelker has quit IRC00:01
*** mylu has quit IRC00:02
*** mylu has joined #openstack-nova00:02
*** ijw has quit IRC00:02
*** xyang1 has quit IRC00:03
*** signed8bit is now known as signed8bit_ZZZzz00:03
*** Piet has quit IRC00:03
*** bapalm has quit IRC00:03
*** russellb has quit IRC00:03
*** bapalm has joined #openstack-nova00:04
*** russellb has joined #openstack-nova00:04
*** mylu_ has joined #openstack-nova00:04
*** gjayavelu has joined #openstack-nova00:05
*** mylu has quit IRC00:05
*** amotoki has joined #openstack-nova00:06
*** Piet has joined #openstack-nova00:06
*** amotoki has quit IRC00:06
*** baoli has joined #openstack-nova00:07
*** n0ano has joined #openstack-nova00:08
*** penick has joined #openstack-nova00:10
*** ssurana has quit IRC00:11
*** mc_nair has quit IRC00:11
*** ctrath has quit IRC00:12
*** EinstCrazy has quit IRC00:12
openstackgerritDan Smith proposed openstack/nova: Make libvirt driver return migrate data objects for source and dest checks  https://review.openstack.org/24772000:14
openstackgerritDan Smith proposed openstack/nova: Add transitional support for migrate data objects to compute manager  https://review.openstack.org/24771900:14
openstackgerritDan Smith proposed openstack/nova: Add xenapi support for XenapiLiveMigrateData objects  https://review.openstack.org/24785300:14
*** zhangjn has quit IRC00:15
*** zenoway has joined #openstack-nova00:15
*** aginwala has quit IRC00:17
*** zenoway has quit IRC00:20
*** mylu_ has quit IRC00:20
*** shaohe_feng has joined #openstack-nova00:21
*** mylu has joined #openstack-nova00:21
*** pratikmallya has quit IRC00:21
*** oomichi has joined #openstack-nova00:21
*** mylu_ has joined #openstack-nova00:24
*** rook has joined #openstack-nova00:25
*** mylu has quit IRC00:25
*** edtubill has joined #openstack-nova00:26
*** annegentle has quit IRC00:27
*** markus_z has joined #openstack-nova00:29
*** shaohe_feng has quit IRC00:29
*** otter768 has joined #openstack-nova00:30
*** electrocucaracha has quit IRC00:31
*** jamielennox|away is now known as jamielennox00:32
*** loquacities has quit IRC00:33
*** loquacities has joined #openstack-nova00:33
*** markus_z has quit IRC00:34
*** otter768 has quit IRC00:35
*** edtubill has quit IRC00:36
*** zenoway has joined #openstack-nova00:39
*** electrocucaracha has joined #openstack-nova00:40
*** mylu_ has quit IRC00:40
*** zenoway has quit IRC00:44
*** penick has quit IRC00:51
*** rk4n has quit IRC00:53
*** apuimedo has joined #openstack-nova00:54
*** salv-orl_ has joined #openstack-nova00:55
*** apuimedo has quit IRC00:55
*** salv-orlando has quit IRC00:58
*** apoorvad has quit IRC00:58
*** aginwala has joined #openstack-nova00:59
*** jaypipes has quit IRC00:59
*** rook has quit IRC00:59
*** armax_ has joined #openstack-nova01:00
*** RichardRaseley has quit IRC01:01
*** EinstCrazy has joined #openstack-nova01:01
*** gjayavelu has quit IRC01:02
*** armax has quit IRC01:02
*** zhenq1 has quit IRC01:02
*** armax_ is now known as armax01:02
*** zenoway has joined #openstack-nova01:03
*** ccard__ has quit IRC01:04
*** zhangjn has joined #openstack-nova01:05
*** ssurana has joined #openstack-nova01:07
*** zenoway has quit IRC01:07
*** zhenguo has joined #openstack-nova01:08
*** jinxing has joined #openstack-nova01:08
*** mylu has joined #openstack-nova01:09
*** flip214 has quit IRC01:09
*** ssurana has quit IRC01:10
*** flip214 has joined #openstack-nova01:11
*** flip214 has joined #openstack-nova01:11
*** markvoelker has joined #openstack-nova01:17
*** thorst has joined #openstack-nova01:17
*** thorst has quit IRC01:20
*** thorst has joined #openstack-nova01:20
*** pixelbeat has quit IRC01:22
*** markvoelker has quit IRC01:22
*** pixelbeat has joined #openstack-nova01:22
*** tonyb has quit IRC01:23
*** tonyb has joined #openstack-nova01:23
*** tonyb has quit IRC01:24
*** thorst has quit IRC01:24
*** tonyb has joined #openstack-nova01:24
*** tonyb has quit IRC01:26
*** tonyb has joined #openstack-nova01:26
*** ijw has joined #openstack-nova01:26
*** rook has joined #openstack-nova01:30
*** shaohe_feng has joined #openstack-nova01:30
*** jinxing has quit IRC01:30
*** electrocucaracha has quit IRC01:31
*** tonyb has quit IRC01:32
*** tonyb has joined #openstack-nova01:33
*** tonyb has quit IRC01:34
*** tonyb has joined #openstack-nova01:34
openstackgerritZhang Ni proposed openstack/nova-specs: Add local-to-instance to create server api  https://review.openstack.org/24106601:35
*** ccard_ has joined #openstack-nova01:36
*** chhavi has joined #openstack-nova01:37
*** Daisy_ has joined #openstack-nova01:37
*** mylu has quit IRC01:38
*** zenoway has joined #openstack-nova01:39
*** mriedem has joined #openstack-nova01:41
*** daemontool_ has quit IRC01:41
*** daemontool_ has joined #openstack-nova01:42
*** exploreshaifali has quit IRC01:42
*** Daisy_ has quit IRC01:43
*** zenoway has quit IRC01:43
*** mylu has joined #openstack-nova01:44
*** suro-patz has quit IRC01:49
*** chenzeng has joined #openstack-nova01:50
*** markvoelker has joined #openstack-nova01:50
*** pratikmallya has joined #openstack-nova01:51
chenzenghello, every one! I have a question: suppose I create a volume by cinder, can I mount this volume to the host machine, and how? Thanks.01:55
*** tpatil_ has quit IRC01:55
chenzengLooking forward to the answer,Thanks.01:56
*** ccard_ has quit IRC01:56
*** aginwala has quit IRC01:58
*** apoorvad has joined #openstack-nova01:58
*** ccard_ has joined #openstack-nova01:59
mriedemhttp://docs.openstack.org/cli-reference/content/novaclient_commands.html#novaclient_subcommand_volume-attach01:59
mriedemdocs ftw01:59
mriedemoh host machine02:00
*** ljxiash has joined #openstack-nova02:03
*** apoorvad has quit IRC02:03
*** zenoway has joined #openstack-nova02:05
*** rfolco_ has joined #openstack-nova02:07
*** aginwala has joined #openstack-nova02:08
*** zenoway has quit IRC02:09
*** aginwala has quit IRC02:11
*** mylu has quit IRC02:12
*** jwcroppe has quit IRC02:12
*** otter768 has joined #openstack-nova02:14
*** ijw has quit IRC02:14
*** jerrygb has quit IRC02:14
*** rfolco_ has quit IRC02:14
*** aginwala has joined #openstack-nova02:15
*** apoorvad has joined #openstack-nova02:16
chenzengmriedem:thanks very much!02:16
*** unicell1 has quit IRC02:21
*** jerrygb has joined #openstack-nova02:24
*** vilobhmm has quit IRC02:27
*** vilobhmm has joined #openstack-nova02:28
*** vilobhmm has quit IRC02:29
*** apoorvad has quit IRC02:30
*** mylu has joined #openstack-nova02:31
mriedemjroll: i will apologize ahead of time https://review.openstack.org/#/c/237067/02:31
*** mylu has quit IRC02:32
*** haomaiwang has joined #openstack-nova02:32
*** pratikmallya has quit IRC02:34
*** pixelbeat has quit IRC02:35
*** mylu has joined #openstack-nova02:35
*** nic has quit IRC02:36
*** nithyag_ has joined #openstack-nova02:36
*** haomaiwang has quit IRC02:37
*** nithyag__ has quit IRC02:37
*** mylu has quit IRC02:38
*** haomaiwang has joined #openstack-nova02:38
*** mylu has joined #openstack-nova02:38
*** dims_ has quit IRC02:39
*** mylu has quit IRC02:43
*** mylu has joined #openstack-nova02:44
*** aginwala has quit IRC02:45
*** klkumar has joined #openstack-nova02:45
*** pratikmallya has joined #openstack-nova02:48
*** aginwala has joined #openstack-nova02:48
*** aginwala has quit IRC02:48
*** Kevin_Zheng has joined #openstack-nova02:49
*** markus_z has joined #openstack-nova02:51
*** armax has quit IRC02:56
*** sacharya has joined #openstack-nova02:57
*** c00281451 has joined #openstack-nova03:00
*** otter768 has quit IRC03:01
*** tonyb has quit IRC03:01
*** tonyb has joined #openstack-nova03:01
*** yamahata has quit IRC03:01
*** venkat_p has joined #openstack-nova03:01
*** rushiagr_away is now known as rushiagr03:02
*** chenzeng has quit IRC03:02
*** jdurgin1 has quit IRC03:03
*** fawadkhaliq has joined #openstack-nova03:08
*** markus_z has quit IRC03:14
openstackgerritZhenyu Zheng proposed openstack/nova-specs: Add pagination and timestamp filtering support for os-migrations API  https://review.openstack.org/23986903:14
*** pratikmallya has quit IRC03:19
openstackgerritBo Chi proposed openstack/nova: Fix some usage for exception  https://review.openstack.org/24789803:19
*** edmondsw has quit IRC03:19
*** dims has joined #openstack-nova03:21
*** mylu_ has joined #openstack-nova03:22
*** mylu has quit IRC03:22
openstackgerritZhenyu Zheng proposed openstack/nova-specs: Add pagination and changes since filter support for os-isntance-action API  https://review.openstack.org/24040103:23
*** hparekh2 has quit IRC03:23
*** takashin has joined #openstack-nova03:27
*** gcb has quit IRC03:35
*** gcb has joined #openstack-nova03:35
*** otter768 has joined #openstack-nova03:36
*** sacharya has quit IRC03:37
*** sacharya has joined #openstack-nova03:37
*** sacharya has quit IRC03:38
*** hparekh has joined #openstack-nova03:38
*** baoli has quit IRC03:40
openstackgerritJianghua Wang proposed openstack/nova: xenapi: OVS agent updates the wrong port when using XenServer + Neutron  https://review.openstack.org/24284603:42
*** vilobhmm has joined #openstack-nova03:42
*** chhavi has quit IRC03:44
*** vilobhmm1 has joined #openstack-nova03:47
*** zhenq has joined #openstack-nova03:48
*** vilobhmm has quit IRC03:49
*** sacharya has joined #openstack-nova03:50
*** thangp has joined #openstack-nova03:51
*** thangp has quit IRC03:53
*** mriedem has quit IRC03:59
*** gyee has quit IRC04:00
*** fawadkhaliq has quit IRC04:01
*** zenoway has joined #openstack-nova04:04
*** vilobhmm1 has quit IRC04:06
*** jhesketh has quit IRC04:06
*** dave-mccowan has quit IRC04:07
*** cfriesen__ has quit IRC04:08
*** jeblair has quit IRC04:08
*** suro-patz has joined #openstack-nova04:08
*** cfriesen__ has joined #openstack-nova04:08
*** zenoway has quit IRC04:08
*** josh6627 has joined #openstack-nova04:08
*** EmilienM has quit IRC04:08
*** jeblair has joined #openstack-nova04:09
*** EmilienM has joined #openstack-nova04:10
*** Sree has joined #openstack-nova04:10
*** Sree has quit IRC04:11
*** Sree has joined #openstack-nova04:11
*** venkat_p has left #openstack-nova04:13
*** zhangjn has quit IRC04:14
*** otter768 has quit IRC04:17
*** zhenq has quit IRC04:20
*** mc_nair has joined #openstack-nova04:23
*** achanda has joined #openstack-nova04:23
*** rajesht has quit IRC04:27
*** gjayavelu has joined #openstack-nova04:28
*** zhangjn has joined #openstack-nova04:29
*** yamahata has joined #openstack-nova04:32
*** dims has quit IRC04:36
*** armax has joined #openstack-nova04:37
*** zenoway has joined #openstack-nova04:39
*** signed8bit_ZZZzz is now known as signed8bit04:41
*** signed8bit has quit IRC04:42
*** vilobhmm has joined #openstack-nova04:42
*** zenoway has quit IRC04:43
*** jinxing has joined #openstack-nova04:44
*** rushiagr is now known as rushiagr_away04:44
*** richm has quit IRC04:45
*** zhangjn has quit IRC04:45
*** achanda_ has joined #openstack-nova04:46
*** mylu_ has quit IRC04:47
*** jinxing has quit IRC04:48
*** suro-patz has quit IRC04:49
*** achanda has quit IRC04:50
*** kutyamutya has quit IRC04:50
*** suro-patz has joined #openstack-nova04:51
*** suro-patz1 has joined #openstack-nova04:52
*** suro-patz has quit IRC04:52
*** daemontool_ has quit IRC04:58
*** daemontool_ has joined #openstack-nova04:58
*** gjayavelu has quit IRC04:58
*** fawadkhaliq has joined #openstack-nova04:59
*** gjayavelu has joined #openstack-nova04:59
*** vilobhmm has quit IRC05:00
*** fawadkhaliq has quit IRC05:00
*** fawadk has joined #openstack-nova05:00
*** armax has quit IRC05:00
*** oomichi_ has joined #openstack-nova05:01
*** oomichi has quit IRC05:03
*** gjayavelu has quit IRC05:04
*** RuiChen has quit IRC05:05
*** RuiChen has joined #openstack-nova05:06
*** zhangjn has joined #openstack-nova05:11
*** zhangjn has quit IRC05:12
*** zhangjn has joined #openstack-nova05:18
*** mc_nair has quit IRC05:21
*** achanda_ has quit IRC05:21
*** sacharya has quit IRC05:23
*** mylu has joined #openstack-nova05:24
*** jinxing has joined #openstack-nova05:25
*** mylu has quit IRC05:25
*** mylu has joined #openstack-nova05:26
*** mylu has quit IRC05:27
*** mylu has joined #openstack-nova05:28
*** jerrygb has quit IRC05:29
*** sacharya has joined #openstack-nova05:29
openstackgerritMD NADEEM proposed openstack/nova: Updating nova config-reference doc  https://review.openstack.org/23932105:29
*** sacharya has quit IRC05:30
*** rushiagr_away is now known as rushiagr05:32
*** stevemar_ has quit IRC05:34
*** stevemar_ has joined #openstack-nova05:35
*** armax has joined #openstack-nova05:35
*** stevemar_ has quit IRC05:38
*** mylu has quit IRC05:39
*** suro-patz1 has quit IRC05:40
*** ildikov has quit IRC05:43
*** haomaiwang has quit IRC05:46
*** suro-patz has joined #openstack-nova05:47
*** mylu has joined #openstack-nova05:57
*** CORTEX\krfa has quit IRC05:57
*** haomaiwang has joined #openstack-nova05:59
*** unicell has joined #openstack-nova06:01
*** vilobhmm has joined #openstack-nova06:01
*** sudipto has joined #openstack-nova06:03
*** oomichi_ has quit IRC06:04
openstackgerritOpenStack Proposal Bot proposed openstack/nova: Imported Translations from Zanata  https://review.openstack.org/24272706:04
*** aginwala has joined #openstack-nova06:07
*** suro-patz has quit IRC06:07
*** amotoki_ has joined #openstack-nova06:07
*** jkraj has joined #openstack-nova06:08
*** yonglihe has quit IRC06:09
*** lpetrut has joined #openstack-nova06:10
*** mylu has quit IRC06:12
*** mylu has joined #openstack-nova06:12
*** haomaiwang has quit IRC06:14
*** suro-patz has joined #openstack-nova06:14
*** oomichi has joined #openstack-nova06:15
*** amotoki_ has quit IRC06:17
*** otter768 has joined #openstack-nova06:18
*** mylu has quit IRC06:18
*** haomaiwa_ has joined #openstack-nova06:18
*** penick has joined #openstack-nova06:23
*** otter768 has quit IRC06:23
*** eliqiao_ has joined #openstack-nova06:26
*** achanda has joined #openstack-nova06:26
*** suro-patz has quit IRC06:26
*** eliqiao has quit IRC06:28
*** rcernin has joined #openstack-nova06:30
*** jerrygb has joined #openstack-nova06:30
*** sacharya has joined #openstack-nova06:31
*** jerrygb has quit IRC06:36
*** sacharya has quit IRC06:36
*** abhishekk has joined #openstack-nova06:42
*** achanda has quit IRC06:42
*** achanda has joined #openstack-nova06:43
*** haomaiwa_ has quit IRC06:43
*** penick has quit IRC06:43
*** unicell has quit IRC06:44
*** unicell has joined #openstack-nova06:45
*** achanda has quit IRC06:48
*** rushiagr is now known as rushiagr_away06:52
*** haomaiwang has joined #openstack-nova06:53
openstackgerritlyanchih proposed openstack/python-novaclient: Help msg about libvirt always default device names  https://review.openstack.org/24795106:54
*** salv-orlando has joined #openstack-nova06:54
*** mjura has joined #openstack-nova06:57
*** jinxing has quit IRC06:58
*** salv-orl_ has quit IRC06:58
*** jinxing has joined #openstack-nova06:59
*** haomaiwang has quit IRC07:01
*** haomaiwang has joined #openstack-nova07:02
*** eliqiao has joined #openstack-nova07:09
*** eliqiao_ has quit IRC07:10
*** ildikov has joined #openstack-nova07:13
*** rubasov has quit IRC07:14
*** cfriesen__ has quit IRC07:15
*** eliqiao has quit IRC07:18
*** eliqiao has joined #openstack-nova07:20
*** Kevin_Zheng has quit IRC07:22
*** nkrinner has joined #openstack-nova07:23
*** haomaiwang has quit IRC07:25
*** haomaiwang has joined #openstack-nova07:26
*** achanda has joined #openstack-nova07:29
*** AJaeger has joined #openstack-nova07:31
AJaegernova stable cores, could you give the import of translations for liberty another try, please? This change was approved several times but then failed to merge due to other problems - and it's an important metadata update: https://review.openstack.org/#/c/237411/07:32
AJaegerjohnthetubaguy: can you help, please? ^07:32
*** armax has quit IRC07:34
*** sahid has joined #openstack-nova07:34
*** ankit_ag has joined #openstack-nova07:37
*** vilobhmm has quit IRC07:39
*** alexschm has joined #openstack-nova07:40
*** achanda has quit IRC07:41
*** zhangjn has quit IRC07:47
*** mpavone has joined #openstack-nova07:48
garyk1johnthetubaguy: dhellmann: please see https://review.openstack.org/247705 for release notes for m-107:53
AJaegergaryk1: could you check 237411, please? See above07:54
*** moshele has joined #openstack-nova07:55
AJaegergaryk1: looking at releasenotes, this looks ugly - http://docs-draft.openstack.org/05/247705/1/check/gate-nova-releasenotes/a23f3bf//releasenotes/build/html/unreleased.html07:55
AJaegergaryk1: indeed, the release note is broken. Let me have a look quickly...07:55
*** takashin has left #openstack-nova07:56
AJaegergaryk1: add a bullet point before it!07:56
*** ttx has quit IRC07:57
*** ttx has joined #openstack-nova07:57
*** pratikmallya has joined #openstack-nova07:58
*** haomaiwang has quit IRC07:59
*** haomaiwang has joined #openstack-nova08:02
garyk1AJaeger: thanks!08:05
*** ildikov has quit IRC08:06
openstackgerritOleg Bondarev proposed openstack/nova: Live migration: wait for vif-plugged event on pre live migration  https://review.openstack.org/24691008:07
openstackgerritgaryk proposed openstack/nova: Add relnote for change in default setting  https://review.openstack.org/24770508:10
AJaegergaryk1: did you see my comment above for translations and can help getting them in, please? https://review.openstack.org/#/c/237411/08:10
*** markus_z has joined #openstack-nova08:11
garyk1AJaeger: looking now. sorry i missed it before08:11
AJaegergaryk1: thanks!08:11
garyk1AJaeger: done!08:11
AJaegergaryk1: thanks!08:12
AJaegernow waiting for an approval ;)08:12
*** rotbeard has joined #openstack-nova08:15
*** moshele has quit IRC08:16
*** achanda has joined #openstack-nova08:17
garyk1AJaeger: its my first time doingt he reno stuff. so it make take a few iterations :)08:17
*** rubasov has joined #openstack-nova08:17
*** zhangjn has joined #openstack-nova08:18
*** otter768 has joined #openstack-nova08:18
*** matrohon has joined #openstack-nova08:19
AJaegergaryk1: we're all learning with it. We should tell dhellmann that you fall into a trap and figure out a way to make it more robust08:20
*** paul-carlton1 has joined #openstack-nova08:20
*** fawadk has quit IRC08:21
openstackgerritgaryk proposed openstack/nova: Add relnote for change in default setting  https://review.openstack.org/24770508:21
*** fawadkhaliq has joined #openstack-nova08:22
*** otter768 has quit IRC08:23
*** rushiagr_away is now known as rushiagr08:26
garyk1AJaeger: :)08:26
*** oomichi has quit IRC08:27
*** Savemech has quit IRC08:27
*** markus_z has quit IRC08:28
*** Savemech has joined #openstack-nova08:31
openstackgerritOleg Bondarev proposed openstack/nova: Live migration: wait for vif-plugged event on pre live migration  https://review.openstack.org/24691008:31
*** zhangjn has quit IRC08:32
*** lpetrut has quit IRC08:35
*** daemontool_ has quit IRC08:36
*** amotoki_ has joined #openstack-nova08:36
*** zhangjn has joined #openstack-nova08:36
*** pratikmallya has quit IRC08:38
*** daemontool_ has joined #openstack-nova08:39
*** jichen has joined #openstack-nova08:41
openstackgerritsahid proposed openstack/nova: libvirt: make detach_device to return an async object  https://review.openstack.org/21768008:42
*** gcb has quit IRC08:43
*** jlanoux has joined #openstack-nova08:43
*** gcb has joined #openstack-nova08:44
bauzasgood morning Nova08:44
tonybbauzas: Good morning to you!08:46
openstackgerritsahid proposed openstack/nova: libvirt: add policy check to avoid using qga in realtime context  https://review.openstack.org/24758508:47
openstackgerritsahid proposed openstack/nova: libvirt: add realtime support  https://review.openstack.org/19756908:47
* tonyb goes to get a beer before trying to write his first spec ... what could *possibly* go wrong ;P08:47
*** amotoki_ has quit IRC08:47
*** oomichi has joined #openstack-nova08:48
*** ihrachys has joined #openstack-nova08:50
*** zhangjn has quit IRC08:51
*** rk4n has joined #openstack-nova08:52
*** ihrachys has quit IRC08:53
*** fawadkhaliq has quit IRC08:53
*** fawadkhaliq has joined #openstack-nova08:53
*** rotbeard has quit IRC08:53
*** markus_z has joined #openstack-nova08:54
markus_zgaryk1: Could you check my question to your feedback in https://review.openstack.org/#/c/242064/ please?08:55
*** aginwala has quit IRC08:56
*** tdurakov is now known as Guest1465708:56
markus_zjohnthetubaguy: Do you think it makes sense to split out the creation of the "nova/conf" package here: https://review.openstack.org/#/c/244177/ ?08:56
*** Guest14657 has joined #openstack-nova08:57
markus_zjohnthetubaguy: If that would then merge, I could create other patch sets which only depend on that.08:57
*** paul-carlton1 has quit IRC08:57
*** rk4n has quit IRC08:58
*** nkrinner has quit IRC08:58
*** yamahata has quit IRC08:58
bauzastonyb: oh man, I also have to write a spec, thanks for the reminder !08:58
*** nkrinner has joined #openstack-nova08:58
tonybbauzas: your welcome.  That was probably the most productive thing I've done today :D08:59
bauzasthat, and mentioning a beer09:00
*** ihrachys has joined #openstack-nova09:00
*** tdurakov has joined #openstack-nova09:00
tdurakovpaul-carlton, hi, are you around?09:00
bauzasbut drinking a beer at 10:00am doesn't sound really social, unfortunately09:00
*** haomaiwang has quit IRC09:01
*** matrohon has quit IRC09:01
markus_zbauzas: We have a thing here called "morning pint". It's basically wine for breakfast and socially acceptable :)09:01
*** haomaiwang has joined #openstack-nova09:01
* bauzas considers relocating09:01
bauzasoh, my manners09:02
*** bauzas is now known as bauwser09:02
*** ndipanov has joined #openstack-nova09:06
*** rotbeard has joined #openstack-nova09:07
*** nkrinner has quit IRC09:10
*** matrohon has joined #openstack-nova09:13
*** nkrinner has joined #openstack-nova09:14
*** achanda has quit IRC09:17
*** yassine__ has joined #openstack-nova09:18
*** chhavi has joined #openstack-nova09:19
*** yassine__ has quit IRC09:19
*** yassine__ has joined #openstack-nova09:19
*** jnclyz12483 has joined #openstack-nova09:23
*** danpb has joined #openstack-nova09:25
*** achanda has joined #openstack-nova09:25
*** haomaiwang has quit IRC09:25
*** ihrachys_ has joined #openstack-nova09:25
*** ihrachys has quit IRC09:25
*** jinxing has quit IRC09:25
*** haomaiwang has joined #openstack-nova09:27
*** jnclyz12483 has quit IRC09:28
*** ihrachys_ is now known as ihrachys09:28
*** jinxing has joined #openstack-nova09:29
*** markvoelker has quit IRC09:30
*** e0ne has joined #openstack-nova09:31
*** zhangjn has joined #openstack-nova09:31
*** pkoniszewski has quit IRC09:35
openstackgerritTimofey Durakov proposed openstack/nova: DO NOT MERGE NFS setup for multinode job  https://review.openstack.org/24708109:35
*** zenoway has joined #openstack-nova09:35
*** haomaiwang has quit IRC09:37
*** jinxing has quit IRC09:37
*** achanda has quit IRC09:37
*** pkoniszewski has joined #openstack-nova09:41
johnthetubaguymarkus_z: I think thats fine as a single patch, but I could be missing something?09:42
*** haomaiwang has joined #openstack-nova09:42
*** zhangjn has quit IRC09:44
AJaegerjohnthetubaguy: could I bother you again for getting Nova stable translations in, please?  https://review.openstack.org/#/c/237411/  That's an important metadata change...09:44
*** jistr has joined #openstack-nova09:44
openstackgerritTang Chen proposed openstack/nova-specs: Support soft reboot and poweroff in nova ironic driver.  https://review.openstack.org/22928209:45
johnthetubaguyAJaeger: hmm, I didn't know it worked like that, I thought we would be translating trunk and backporting, but I guess that doesn't work? or that happens as well?09:46
AJaegerjohnthetubaguy: this is new since liberty release, the translators are  translating on a branch since you make changes to master for strings...09:47
AJaegerso, no backports here09:47
AJaegerDaisy,i18n PTL, wanted to reach out to all stable teams, seems that didn't happen properly ;(09:47
openstackgerritJohn Garbutt proposed openstack/nova: config options: enhance help text of section "serial_console"  https://review.openstack.org/24646509:48
*** EinstCrazy has quit IRC09:49
AJaegerjohnthetubaguy: the translators - and our translation server - take care of syncing translated strings between releases.09:49
johnthetubaguyAJaeger: so I may have been told, and just forgotten, thanks for the update on that.09:50
*** amotoki_ has joined #openstack-nova09:50
abhishekkjohnthetubaguy: hi, I have replied to your comments on nova-specs, https://review.openstack.org/135387 I will be grateful if you could have a look at it, Thank you in advance.09:51
*** Sree has quit IRC09:53
johnthetubaguyabhishekk: I really want alaski to take a look at that ASAP, I will try ping him again to see if he has chance to take another look a tthat09:53
AJaegerjohnthetubaguy: feel free to reach out to Daisy or the i18n mailing list and discuss further.09:53
abhishekkjohnthetubaguy: just got to know that non-priority spec freeze is approaching (3 December) and I will be happy if this gets approved for Mitaka :)09:54
AJaegerThis metadata change was important for me - getting rid of old URL for translation server09:54
abhishekkjohnthetubaguy: thank you09:54
*** alex_klimov has joined #openstack-nova09:55
johnthetubaguyAJaeger: so we have finish changing strings for you folks to have a chance to translate it, and that that justifies the approach, yeah, I should catch up with Daisy09:55
*** c00281451 has quit IRC10:00
*** zhenguo has quit IRC10:01
*** lpetrut has joined #openstack-nova10:01
*** ljxiash has quit IRC10:04
*** fawadkhaliq has quit IRC10:05
bauwserjohnthetubaguy: FYI, in case you missed markus_z's email https://review.openstack.org/#/c/247775/10:06
*** amotoki_ has quit IRC10:06
*** aix has joined #openstack-nova10:07
johnthetubaguybauwser: yeah, we need to get going with reno soon, and adding some details that we have already missed, etc10:07
bauwserjohnthetubaguy: that's my next week's duty, I promised mriedem to take a look at all UpgradeImact merged changes since we need a reno file for all of them by m-110:07
bauwserjohnthetubaguy: but now, we're fully gating on reno10:08
bauwserjohnthetubaguy: so we should -1 any change not providing relnotes when needed, hence my change10:08
bauwserjohnthetubaguy: I'll respin a new PS based on markus's point, by trying to explain further how to build a note10:09
markus_zbauwser: There is also a good chance that I'm overthinking this.10:09
bauwserheh10:10
*** haomaiwang has quit IRC10:10
bauwserdon't tell me *you* are overthinking, it's generally my case :)10:10
markus_z:D10:10
*** nagyz has joined #openstack-nova10:11
johnthetubaguybauwser: cools, I need to read through the meeting notes, not done that yet10:11
*** lpetrut1 has joined #openstack-nova10:13
*** jinxing has joined #openstack-nova10:13
*** lpetrut has quit IRC10:13
*** lpetrut1 is now known as lpetrut10:13
*** ptm_away is now known as PaulMurray10:13
*** haomaiwang has joined #openstack-nova10:16
openstackgerritAdelina Tuvenie proposed openstack/nova: Added support for new block device format in Hyper-V  https://review.openstack.org/24629810:18
*** pixelbeat has joined #openstack-nova10:19
*** otter768 has joined #openstack-nova10:19
*** ihrachys has quit IRC10:24
*** jinxing has quit IRC10:24
*** otter768 has quit IRC10:24
*** mpavone has quit IRC10:24
*** rk4n has joined #openstack-nova10:27
*** chinmay_ has joined #openstack-nova10:27
*** gcb has quit IRC10:28
*** ihrachys has joined #openstack-nova10:28
*** haomaiwang has quit IRC10:28
*** haomaiwang has joined #openstack-nova10:28
*** gcb has joined #openstack-nova10:28
*** amotoki_ has joined #openstack-nova10:29
*** fawadkhaliq has joined #openstack-nova10:30
*** amotoki_ has quit IRC10:30
*** shaohe_feng has quit IRC10:30
*** markvoelker has joined #openstack-nova10:31
*** ildikov has joined #openstack-nova10:31
openstackgerritBalazs Gibizer proposed openstack/nova: Add service status notification  https://review.openstack.org/24567810:32
openstackgerritBalazs Gibizer proposed openstack/nova: Add infra for versioned notifications  https://review.openstack.org/24702410:32
openstackgerritBalazs Gibizer proposed openstack/nova: Make emitting versioned notifications configurable  https://review.openstack.org/24756410:32
*** gongysh__ has joined #openstack-nova10:32
alex_xujohnthetubaguy: morning, re: https://review.openstack.org/245543, we can totally get rid of disk_over_commit afer we get this http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/check-destination-on-migrations.html. So we have two choice, one is depend on that, sencond is change disk_over_commit next time.10:32
alex_xujohnthetubaguy: hope to hear your opinion which choice is beter10:32
alex_xus/beter/better/10:32
AJaegermarkus_z, current release notes are always visible at http://docs.openstack.org/releasenotes/nova/10:33
AJaegerindex page will come later once more projects have adopted it...10:33
johnthetubaguyalex_xu: I was thinking we just make it default to false, for now?10:33
johnthetubaguyalex_xu: it should all be done by claims in the resource tracker, not really by the scheduler, I think ndipanov had some plans around that10:33
alex_xujohnthetubaguy: emm...why not choice true, as the when booting instance, we count the disk_over_commit10:33
markus_zAJaeger: Is this always current?10:33
*** moshele has joined #openstack-nova10:34
markus_zAJaeger: Or a regular job, done every 1 week or so?10:34
alex_xujohnthetubaguy: emm...that sounds good, I didn't notice ndipanov works10:34
AJaegermarkus_z: it gets updated after each merge - a post job10:34
markus_zAJaeger: Yeahhh, awesome, thanks!10:34
AJaegermarkus_z: note that releasenotes/notes/ebtables-version-fde659fe18b0e0c0.yaml renders broken, see http://docs.openstack.org/releasenotes/nova/unreleased.html.10:35
*** gongysh has quit IRC10:35
*** gongysh_ has quit IRC10:35
AJaeger"ebtables and libvirt requirements"  is not the subsection header...10:35
*** gongysh has joined #openstack-nova10:35
alex_xujohnthetubaguy: ok, I'm ok with default as false, let me update the spec10:35
johnthetubaguyalex_xu: really? I have never really dug into disk management as we only do RAM management right now10:35
johnthetubaguyalex_xu: I was just thinking false as it matches block_migration10:36
*** markvoelker has quit IRC10:36
markus_zAJaeger: What's causing this?10:36
AJaegermarkus_z: misunderstanding on what prelude does ;)10:36
alex_xujohnthetubaguy: yea, I checked the code, we use flavor's disk size to consume the resource10:36
johnthetubaguyalex_xu: ideally we default to "resource tracker does its thing" I guess10:36
ndipanovalex_xu, so like johnthetubaguy says - I really don't think that check_destination makes sense10:36
ndipanovwe either claim10:37
AJaegermarkus_z: let me sent a fix...10:37
ndipanovor we say - admin knows what they are doing so let them do it10:37
ndipanovafter talking to HP/rax folks in Tokyo10:37
johnthetubaguyndipanov: I think we need both, check_destination just doesn't fix the disk issue10:37
ndipanovjohnthetubaguy, what does check destination give us10:37
alex_xundipanov: actually disk_over_commit option in live-migration is buggy10:37
bauwserndipanov: have you read the spec ? :)10:38
*** rk4n has quit IRC10:38
johnthetubaguyndipanov: its for the case when the admin is making a free host, it checks the affinity10:38
ndipanovin a racy way10:38
johnthetubaguyndipanov: anti-affinity is the only useful check10:38
openstackgerritAndreas Jaeger proposed openstack/nova: Fix ebtables-version release note  https://review.openstack.org/24801310:39
AJaegermarkus_z: ^10:39
johnthetubaguyndipanov: yep10:39
ndipanovI really don't get it - we go for obviously wrong but kinda easy to do currently10:39
bauwserndipanov: the idea is to make sure that we call the scheduler, even if the scheduler can make wrong decisions10:39
markus_zAJaeger: thanks! I'm really glad we are using this. It's a great tool.10:40
ndipanovok I will read the spec10:40
AJaegermarkus_z: yep, it is - great work by dhellmann10:40
alex_xundipanov: there is force option in bauwser's propose, so that can resolve your concern as my understand10:40
bauwserndipanov: because that's not the role of claims to select a destination, right?10:40
markus_zAJaeger: And it doesn't interrupt my workflow10:40
ndipanovagain10:40
johnthetubaguyndipanov: its really just the starting point, we need to get the API working properly, reducing the race window, etc, totally need the resource tracker claims, etc10:40
AJaegermarkus_z: wow! That's an extra +3 ;)10:40
bauwserndipanov: but of course, that still needs claims able to get the Reqspec and do a good call10:40
markus_zAJaeger: :)10:41
tdurakovsdague, johnthetubaguy, hi10:41
ndipanovso it;s like this - the only way to make this stuff not racy is to re-check the schduler decision on a host holding a global host lock10:41
ndipanovcurrently10:41
johnthetubaguyalex_xu: I was really just thinking about doing it all in one API microversion, I could be pushing that too far, just curious if its possible really :)10:41
ndipanoveverything else is broken10:41
tdurakovhttps://review.openstack.org/#/c/247081/ - nfs shared storage for live-migration job10:41
ndipanov(if jay moves claims to the scheduler then it's a different story)10:42
bauwserndipanov: I'm not sure you read the spec when talking about a check_destination() method10:42
alex_xujohnthetubaguy: ok, no problem.10:42
ndipanovbauwser, ok re-reading10:42
*** ihrachys has quit IRC10:43
alex_xujohnthetubaguy: you still prefer default value?10:43
*** e0ne has quit IRC10:43
*** rk4n has joined #openstack-nova10:44
alex_xujohnthetubaguy: actually I prefer get rid of disk_over_commit, but it depends on bauwser's spec, and that spec depend requestspec obj persisnt, and that depends on requestspec obj works...:(10:44
alex_xusuch long dependence~10:44
bauwseryeah, that's a big and massive change10:44
bauwserI should work on check-destinations BP soon10:45
johnthetubaguyalex_xu: I am OK with just going for a default for now, so we break the dependency chain10:45
ndipanovbauwser, so your spec makes no mention of the fact that the result of the check_destination is meaningless without the claim10:45
ndipanovso I stopped reading10:45
bauwserthere is *no* check_destination call10:45
*** ihrachys has joined #openstack-nova10:45
ndipanovbauwser, "We should modify that logic to explicitly call the Scheduler any time a move (ie. either a live-migration or an evacuation) is requested (whether the destination host is provided or not) so that the Scheduler would verify the destination host thru all the enabled filters and if successful consume the instance usage from its internal HostState."10:46
bauwserthere is a call which is already existing, but under specific constraints, ie. select_dest()10:46
*** ankit_ag has quit IRC10:46
ndipanovthat is literally the same as not calling it unless you plan to do the claim-retry dance10:46
alex_xujohnthetubaguy: ok, I will choice disk_over_commit default value as True, because booting instance counting the flavor's disk size.10:46
alex_xujohnthetubaguy: does sounds ok?10:46
bauwserndipanov: right, and what's the problem here? we already do that, but only if no host is provided10:46
ndipanovso why do you want to add more code that does not fix anything?10:46
*** rushiagr is now known as rushiagr_away10:46
*** ankit_ag has joined #openstack-nova10:47
bauwserokay, I'm going to take a coffee10:47
ndipanovit literally does not fix a problem10:47
*** jianghuaw has joined #openstack-nova10:48
openstackgerritTimofey Durakov proposed openstack/nova: DO NOT Merge NFS setup for live-migration job  https://review.openstack.org/24708110:48
*** sacharya has joined #openstack-nova10:48
bauwserndipanov: you're persisting on thinking about a different problem IMHO10:48
ndipanovbauwser, the only bit of the spec that makes sense is to mark the forced instances10:48
bauwserndipanov: I'm not saying I'll fix all the problems, but just the fact that when calling a destination, we don't verify the scheduler, that's it10:48
ndipanovbauwser, I am reading your problem description10:48
ndipanovso my answer to that is: "don't do it because it's useless"10:49
bauwserwell, I'm very glad to see your point now that I showed you that spec for like 6 months ago10:49
bauwserI don't pretend to fix the claim issue10:49
ndipanovI said the same thing several times in the past10:49
ndipanovnot sure if it was 6 months ago10:50
* bauwser whispers10:50
*** tdurakov has quit IRC10:50
bauwserwell, okay, what do you recommend ?10:50
*** rk4n has quit IRC10:50
*** tdurakov has joined #openstack-nova10:51
bauwserstop doing that, not persisting the spec and calling the scheduler, and just fixing claims rather?10:51
*** e0ne has joined #openstack-nova10:51
*** sacharya has quit IRC10:52
ndipanovbauwser, so still calling the scheduler makes sense only if you do a claim on the compute host even if that claim would normally fail10:52
ndipanovbauwser, it needs to recalculate some stuff in the general case10:53
bauwserI never said the contrary :)10:53
*** tdurakov has quit IRC10:53
*** AJaeger has left #openstack-nova10:54
*** EinstCrazy has joined #openstack-nova10:54
ndipanovbauwser, so the spec would make sense if it also includes modifications to the claim such that it would still happen but just not fail if it otherwise would10:55
bauwserndipanov: so I feel it's another spec IMHO10:55
ndipanovbauwser, well I am not sure this one makes any sense without it really ...10:56
*** mpavone has joined #openstack-nova10:56
bauwserI got that - but my thoughts are that it's still a benefit anyway10:56
*** gszasz has joined #openstack-nova10:56
ndipanovthere is benefit in the fact that now we know which instances are forced10:57
*** rk4n has joined #openstack-nova10:58
bauwserndipanov: consider the AZ case10:58
*** ihrachys_ has joined #openstack-nova10:58
bauwserndipanov: that's not a claim thing, right?10:58
*** lpetrut has quit IRC10:58
bauwserndipanov: but we still have an AZFilter10:59
*** lpetrut has joined #openstack-nova10:59
*** tdurakov has joined #openstack-nova10:59
bauwserndipanov: https://bugs.launchpad.net/nova/+bug/145256810:59
openstackLaunchpad bug 1452568 in OpenStack Compute (nova) "nova allows to live-migrate instance from one availability zone to another" [Low,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza)11:00
johnthetubaguymy take is folks have been asking for this for a while, and this is a good step in the right direction, sure it has bit limitations, but live-migrate generally has bigger ones right now, that we are working through11:00
bauwserndipanov: don't you feel that the spec would help that?11:00
ndipanovbauwser, well that is a bit of a grey area because AZ of the host does not change often in reality11:00
*** ihrachys has quit IRC11:00
bauwserndipanov: heh, that's an hypothesis which is really huge11:01
bauwserndipanov: I mean, hosts can easily move from one agg to another, nope?11:01
johnthetubaguyhang on, this is upside down right?11:01
bauwserthat's not racy in the terms of what you think11:01
bauwserjohnthetubaguy: when moving an host from one agg to another, we check the instances11:02
bauwserjohnthetubaguy: so that's a safe operation11:02
johnthetubaguybauwser: right11:02
bauwserjohnthetubaguy: well, probably racy tho if we consider instances being scheduled tho11:03
ndipanovyes11:03
ndipanovso I am thinking about what johnthetubaguy said11:03
*** ihrachys_ has quit IRC11:04
ndipanovthere definitely is some usefulness to the spec - the fact that we track which ones got force-migrated11:04
*** ihrachys has joined #openstack-nova11:05
bauwserndipanov: tbh, I was also thinking of proposing another spec for getting rid of force_hosts and do the same for boot11:05
bauwserndipanov: which would mean that you'd get a requested_destination field set for boot too11:06
bauwseratm, I'm very frustrated by how we deal with force_hosts11:06
openstackgerritAlex Xu proposed openstack/nova-specs: Make block_migration and host flags in live-migration API  https://review.openstack.org/24554311:06
ndipanovwhat annoys me is that instead of working towards a cleaner abstraction - we keep working around these special cases11:06
*** alex_klimov has quit IRC11:07
bauwserI don't get what could be a cleaner abstraction ?11:07
bauwserI got that the spec should make sure that object goes down to the compute manager, so that at the end, the claim is able to read it11:08
*** haomaiwang has quit IRC11:08
*** fawadkhaliq has quit IRC11:08
bauwserbut we're using an object which is well-formatted, and where we identify whether a destination was proposed or not11:09
ndipanovso there's a ton of stuff we need to check before building on a compute host, some of them we have to recalculate and persist11:09
ndipanovcurrently we don't do it for some things11:10
ndipanovwe use a completely different code path for some (instance groups)11:10
*** ihrachys has quit IRC11:10
alex_xujohnthetubaguy: I guess know why you think disk_over_commit default value should be false. Actually disk_over_commit isn't related to disk overcommit ratio. It's just about count disk size as image actual size or image virtual size11:11
alex_xuhere is the code reference https://github.com/openstack/nova/blob/3e0bbc332726a5df3031628b71ef3517b5209fb6/nova/virt/libvirt/driver.py#L532511:11
johnthetubaguyalex_xu: yeah, sorry, I should have linked you to that, yeah11:11
johnthetubaguyalex_xu: it seems odd really, that is not just managed by the resource tracker11:11
bauwserndipanov: right, that's why I think it's another spec to consider11:11
alex_xujohnthetubaguy: yea, very odd11:11
ndipanovbauwser, well that spec is approved so11:12
johnthetubaguyalex_xu: don't think the other virt drivers implement it anyway, its tempting to drop it all together, but I wish I knew why it was added...11:12
ndipanovyeah we need another spec11:12
alex_xujohnthetubaguy: yea, hope we can drop it future11:13
* bauwser needs to go afk11:13
*** ihrachys has joined #openstack-nova11:13
*** tdurakov has quit IRC11:15
openstackgerritAlex Xu proposed openstack/nova-specs: Make block_migration and host flags in live-migration API  https://review.openstack.org/24554311:19
johnthetubaguyalex_xu: yeah, I wonder if we should just drop it in your spec, or does that seem too soon?11:20
*** alex_klimov has joined #openstack-nova11:20
*** jianghuaw has quit IRC11:20
alex_xujohnthetubaguy: oops, sorry, I must miss understand your words again. So let's depend on bauwser's spec?11:21
alex_xujohnthetubaguy: we can't drop it directly, there will be no disk size checking for user specify a host in the api11:22
johnthetubaguyalex_xu: ah, I am not sure I am clear in my own head right now, I think we could just drop that, independent of bauwser's spec11:22
alex_xujohnthetubaguy: emm...it is ok without disk size check?11:22
*** gongysh__ has quit IRC11:23
*** ihrachys_ has joined #openstack-nova11:23
*** rushiagr_away is now known as rushiagr11:23
*** dims has joined #openstack-nova11:24
*** zenoway has quit IRC11:24
*** ihrachys has quit IRC11:24
*** zenoway has joined #openstack-nova11:24
bauwseralex_xu: johnthetubaguy: sorry I wasn't following that spec so I don't have very much context11:24
bauwserI can't really say whether my spec is needed or not, but we can discuss11:25
bauwserand see why it came up in the discussion11:25
bauwseralex_xu: I'll try to review your spec asap once I'm done with lunch11:26
alex_xujohnthetubaguy: ok, I got another idea, remove the disk_over_commit, and add right disk size check in the code.11:26
johnthetubaguyalex_xu: hmm, well it will end up defaulting to something I guess, in the libvirt driver, so it just keeping do that for new API calls?11:26
alex_xubauwser: thanks :) it's about remove the disk_over_commit flag in the live-migrate api11:26
bauwseralex_xu: sure, that I understood but I need to understand more the problem11:26
bauwserand how/if my spec could help, to answer your question11:27
johnthetubaguyalex_xu: honestly I would OK leaving the current check, for now, and just let the other specs on the live-migrate add the proper resource tracker checks11:27
johnthetubaguyalex_xu: so leaving the current check, but removing the config option for that check from the API, basically11:27
alex_xujohnthetubaguy: ok, no problem, that sounds good choice11:28
johnthetubaguybauwser: basically, make live-migrate API be {live-migrate: null}, rather than it asking silly questions you can't really answer11:28
*** salv-orlando has quit IRC11:28
alex_xubauwser: the current disk_size check in live migrate is buggy, but after you spec use scheduler check the disk size, then everything is good.11:28
*** salv-orlando has joined #openstack-nova11:29
bauwserjohnthetubaguy: oh that, sure11:29
johnthetubaguycan you spot my "love" of the current API in my text :)11:29
bauwseralex_xu: the 'host' flag is mentioned in the check-destinations spec11:29
*** fawadkhaliq has joined #openstack-nova11:30
bauwseralex_xu: not sure it needs to be scoped by your spec?11:30
*** rushiagr is now known as rushiagr_away11:30
*** achanda has joined #openstack-nova11:31
alex_xubauwser: it looks like no conflict in our specs. I just make host optionl in the api , and the default value is None11:31
*** markus_z_bnc has joined #openstack-nova11:31
openstackgerritAdelina Tuvenie proposed openstack/nova: Added support for new block device format in Hyper-V  https://review.openstack.org/24629811:33
openstackgerritAdelina Tuvenie proposed openstack/nova: Added support for new block device format in vmops  https://review.openstack.org/24629911:33
openstackgerritAdelina Tuvenie proposed openstack/nova: Add support for setting boot order in Hyper-V  https://review.openstack.org/24802911:33
bauwseralex_xu: right my spec was vague about the difference between evacuate and live-migrate11:33
bauwseralex_xu: evacuate makes host optional, while live-migrate provides an empty string for host IIRC11:33
*** ociuhandu has quit IRC11:34
bauwseralex_xu: so your spec just unifys both behaviours, which I'm fine11:34
*** Sree has joined #openstack-nova11:34
bauwserunifies even11:34
alex_xubauwser: yea :)11:34
*** smatzek has joined #openstack-nova11:35
bauwseralex_xu: tbh, I was a bit okay with providing the options, given that the default policy was for admins - it meant that when wanting to live-migrate, you were having to know the physical infrastructure, but since we can have nullable hosts, then it would mean that you would need to have an homogenous infrastructure11:37
bauwseralex_xu: so your spec is okay - to be clear, the problem is more than the admin is not sure that the destination will have the options he said11:38
*** tdurakov has joined #openstack-nova11:39
*** tdurakov has quit IRC11:39
mdboothpaul-carlton: Hey, I'm getting a bit ratholed trying to work out the scope of the migrate libvirt volumes spec.11:40
mdboothGot a sec?11:40
markus_zpkholkin: Could it be that your bug is superseded? https://bugs.launchpad.net/nova/+bug/151050411:40
openstackLaunchpad bug 1510504 in OpenStack Compute (nova) "Keypairs list results not limited on database server-side" [Low,New] - Assigned to Pavel Kholkin (pkholkin)11:40
*** doug-fish has quit IRC11:42
alex_xubauwser: yea, agree with you11:42
mdboothpaul-carlton: The issue is I'm not sure where the libvirt storage pools spec ends. It's not clear to me if that spec implies that copying to the correct location on a remote host is already implemented, but using existing copy methods.11:42
mdboothIf it does imply that, then the migrate libvirt storage pools spec becomes trivial.11:42
*** doug-fish has joined #openstack-nova11:42
bauwseralex_xu: so, about the disk_over_commit flag, I don't see how my spec can help, because it sounds that something which isn't read by the scheduler anyway, right?11:43
*** moshele has quit IRC11:44
alex_xubauwser: emm...my understand is your spec will use scheduler to check the user specified host. Then scheduler will ensure the host whether have enough disk.11:44
bauwseralex_xu: johnthetubaguy: meh, the disk_over_commit option sounds like a libvirt hack :/11:44
johnthetubaguybauwser: +111:45
bauwserthat's a bit more complicated11:45
alex_xubauwser: yea, very strange behaviour11:45
*** salv-orlando has quit IRC11:45
bauwseralex_xu: so IIUC, that hacks allows you to count only the real size of the disk, not the allocated size11:45
bauwserbecause QCOW2 does compression11:45
alex_xubauwser: yea11:45
bauwserbut that's a very terrible way to pass that info IMHO :/11:46
bauwserthat should be a RT thing like johnthetubaguy said11:46
bauwserie.11:46
*** doug-fish has quit IRC11:47
bauwsercompute nodes should have a libvirt CONF flag saying whether the disk space is taking real size or allocated size, and the virt driver should report accordingly the disk size to RT11:47
bauwserbecause you could decide to have a different policy of counting disks based on your compute node11:47
bauwserexactly like allocation ratios11:47
alex_xubauwser: I more prefer just get rid of it11:47
bauwseralex_xu: but that's a feature, we can't just pretend it never existed :/11:48
alex_xubauwser: just use the resource tracker and scheduler way to count resource11:48
bauwseralex_xu: sure, but you need to provide that ability to either count on real size or allocated size11:48
bauwser(speaking of the metrics that the libvirt driver reports to Rt)11:48
bauwseroh man, I don't know when it has been introduced in the REST API, but I would have been preferred to have never seen it11:49
johnthetubaguybauwser: yup, we have a few specs around "improving" that somewhere11:50
johnthetubaguythe metrics API that is11:50
bauwserjohnthetubaguy: any idea of what happens if you have a different hypervisor ? it's passed as part of the body, so I guess that if you don't care for your virt driver, you ignore it, right?11:50
johnthetubaguybauwser: yeah, its generally ignored by everyone else, AFAIK11:50
bauwserargh11:51
johnthetubaguybauwser: to me, what it should be is like the CPU and RAM allocation ratios11:51
bauwsertotally agreed11:51
johnthetubaguyits just totally broken in its current form11:51
bauwsernow the ratios are per compute11:51
johnthetubaguyright11:51
bauwserbut ideally we should even not report them to the scheduler11:51
ndipanovjohnthetubaguy, bauwser this might be related https://bugs.launchpad.net/nova/+bug/151744211:51
openstackLaunchpad bug 1517442 in OpenStack Compute (nova) "libvirt/xenapi: disk_available_least reported by the driver does not take into account instances being migrated to/from the host" [High,New]11:51
bauwserjohnthetubaguy: we should just give the calculated size of the disk to the RT11:52
johnthetubaguyso I could see a case where you might want to push a few things together real close for a little bit, but thats not what this really enables11:52
bauwserjohnthetubaguy: no need to pass a ratio11:52
bauwserjohnthetubaguy: so there are 2 possibilites11:52
johnthetubaguyndipanov: thats back to needing claims I think11:52
ndipanovyes11:52
bauwserjohnthetubaguy: either we consider that we provide the disk size *and* the flag info to the scheduler so that the DiskFilter does the right thing - but we also need to claim that correctly like ndipanov said11:53
*** tdurakov has joined #openstack-nova11:53
*** fawadkhaliq has quit IRC11:53
bauwserjohnthetubaguy: or, we just provided a consolidated view of the disk size hiden by the virt logic11:53
bauwserthe latter has my preference11:54
openstackgerritdstepanenko proposed openstack/nova: WIP: This is 3rd part of changes according to pci-generate-stats blueprint.  https://review.openstack.org/24769211:54
johnthetubaguyso the feature makes no sense, I think we just drop it11:54
bauwserjohnthetubaguy: well, the feature can make sense11:54
johnthetubaguyregardless, we need to fix up the claims to match migrate/resize11:54
bauwserjohnthetubaguy: but people can use a disk allocation ratio for that11:54
ndipanovbauwser, that bug is precisely about the fact that we can't do that11:55
bauwserjohnthetubaguy: agreed11:55
*** ihrachys_ has quit IRC11:55
* bauwser reads the bug11:55
johnthetubaguywhat I mean is, that API isn't needed in any of the sensible features here11:55
openstackgerritTimofey Durakov proposed openstack/nova: NFS setup for live-migration job  https://review.openstack.org/24708111:56
bauwserjohnthetubaguy: oh totally agreed11:56
bauwserby no way, it should have been landed as an API option11:56
bauwserndipanov: so agree with you too11:57
*** zenoway has quit IRC11:57
*** ihrachys has joined #openstack-nova11:57
bauwserndipanov: disk_available_least is terrible for operators11:57
bauwserndipanov: because the logic is different based on which virt driver you use11:57
*** zenoway has joined #openstack-nova11:57
tdurakovjohnthetubaguy, can i ask you to review this https://review.openstack.org/#/c/247081/11:58
*** markus_z is now known as markus_z_meeting11:58
*** daemontool_ has quit IRC11:58
pkholkinmarkus_z: yes, it relates to my spec but it is not approved11:58
pkholkinI spoke to Matt some days ago and he marked it -1 because of related spec, see comments there11:59
openstackgerritAlex Xu proposed openstack/nova-specs: Make block_migration and host flags in live-migration API  https://review.openstack.org/24554311:59
bauwseralex_xu: johnthetubaguy: so the problem I see with removing disk_over_commit in the request body is that we don't provide a migration path for operators wanting that feature11:59
pkholkinjohnthetubaguy: Hello John, I have a question about use_slave concept, is it true that it removed?12:00
alex_xubauwser: emm...does admin really need migrate instance without consider overcommit?12:00
pkholkinjohnthetubaguy: it relates to our enginefacade patches12:00
bauwseralex_xu: that's not a request thing12:00
bauwseralex_xu: that's a resource usage thing12:01
johnthetubaguypkholkin: I haven't had chance to dig into that properly12:01
johnthetubaguypkholkin: I hope we don't remove it, but it looked like the current patches were going that way12:01
*** daemontool_ has joined #openstack-nova12:01
alex_xubauwser: yea, we need resource tracker to do that right?12:01
johnthetubaguybauwser: what does the feature do for them?12:01
bauwseralex_xu: that's one proposal12:02
pkholkinjohnthetubaguy: yes, so the question is that in enginefacade there is async decorator, please look this patch https://review.openstack.org/#/c/243496/2/12:02
bauwserjohnthetubaguy: eg. say that you asked for a 10GB instance12:02
*** zhangjn has joined #openstack-nova12:02
*** zhangjn has quit IRC12:02
pkholkinjohnthetubaguy: using this decorator we will try to use slave_connection if it is in conf file12:02
*** zenoway has quit IRC12:02
bauwserjohnthetubaguy: the first time you're booting your instance, the real consumed disk space on the hypervisor is 2GB12:02
bauwserjohnthetubaguy: because QCOW2 is a compressed format12:03
tdurakovalex_xu, read your spec about api for live-migration, imho it's good idea to make things optional, not sure about overcommit flag, will leave comment later:)12:03
johnthetubaguypkholkin: but thats a problem, it covers every use of that DB API12:03
pkholkinjohnthetubaguy: but previously it can be managed by develepor using use_slave parameter12:03
*** zhangjn has joined #openstack-nova12:03
alex_xutdurakov: thanks :)12:03
bauwserjohnthetubaguy: so I guess that operators want to have the ability to say "I don't care, only count the real disk size"12:03
pkholkinjohnthetubaguy: yes, using async will always try to use slave_connection12:03
bauwserjohnthetubaguy: here, the features makes that decision per-request12:04
johnthetubaguypkholkin: right that my problem with it, I feel we need to explicitly select that on a per call basis, which is why we added the parameter12:04
bauwserbut since RT claims don't do that, the feature is broken12:04
alex_xubauwser: if mean RT can only count real disk size?12:04
*** haomaiwa_ has joined #openstack-nova12:05
alex_xus/if/you/12:05
bauwseralex_xu: RT counts what the driver says12:05
tdurakovalex_xu, tbh, I don't like live-migration with user-provided host, as it could break a lot of things12:05
* bauwser *really* needs to eat some food12:06
pkholkinjohnthetubaguy: do you think if use_slave really helps with performance or maybe we can continue removing it?12:06
alex_xubauwser: go for food first :)12:06
johnthetubaguypkholkin: I totally didn't see this in the spec somehow :( just came up in discussion on IRC the other day when I -1ed a patch for adding use_slave12:06
johnthetubaguypkholkin: so the async decorator is doing a similar thing, as I understand it, its the slightly lagging read slave12:07
johnthetubaguypkholkin: its really about readability, in some ways12:08
johnthetubaguypkholkin: the change you linked is good, because there is no major change, as I understand it12:08
johnthetubaguypkholkin: the problem is when someone re-uses that DB API call in some other bit of code, and it starts doing use_slave=False, and that causes bugs12:09
*** zenoway has joined #openstack-nova12:09
johnthetubaguypkholkin: well I mean when it gets used, and they didn't realise that was accessing the async read slave12:10
*** ihrachys has quit IRC12:11
*** zenoway has quit IRC12:12
*** ihrachys has joined #openstack-nova12:12
*** zenoway has joined #openstack-nova12:12
*** hparekh has quit IRC12:12
tdurakovjohnthetubaguy, ping12:13
johnthetubaguytdurakov: hey12:13
tdurakovthere is a patch for nfs shared storage of dedicated l-m job12:13
tdurakovcould you review it?12:13
johnthetubaguytdurakov: we really, really, really need to specify the host for live-migrate, from an operator perspective, we should make sure we document those usecases better, I think PaulMurray has a patch up for that somewhere.12:14
johnthetubaguytdurakov: I can do, whats the link?12:14
johnthetubaguytdurakov: I don't see when I am added to reviews, that has turned into SPAM12:14
tdurakovjohnthetubaguy, https://review.openstack.org/#/c/247081/12:15
PaulMurrayjohnthetubaguy, we do need the host - absolutely12:15
tdurakovabout target host, i'm not talking that we should remove this option12:16
tdurakovbut we could rewrite implementation for that in conductor12:16
PaulMurrayjohnthetubaguy, I spent some time this morning looking at that disk_over_commit option BTW12:16
johnthetubaguytdurakov: oh, totally agreed with that12:16
PaulMurrayjohnthetubaguy, we have used it and I think I understand why now - adding to the list of reviews on it12:16
openstackgerritjichenjc proposed openstack/nova-specs: Add ips-add-max-and-type.rst  https://review.openstack.org/24749612:17
*** salv-orlando has joined #openstack-nova12:17
johnthetubaguyPaulMurray: the first idea was making it optional, and defaulting to False12:17
pkholkinjohnthetubaguy: it would be nice if we remove using use_slave and use only @reader, but as I understand it is not good for performance12:17
tdurakovi'm big + for making all params these param in api optional12:18
PaulMurrayjohnthetubaguy, it looks out of whack with the usual way of controlling over commit12:18
johnthetubaguypkholkin: yes, the idea is when folk shave a DB read slave, we can send some of the traffic there, so the primary DB nodes have less load12:18
pkholkinjohnthetubaguy: if we still want it we can try to manage it in layer above but it is not beautiful or maybe try to change smth in oslo.db12:18
openstackgerritAnkit Agrawal proposed openstack/nova: Remove redundant migration status update  https://review.openstack.org/24751912:18
PaulMurrayand seems that is because libvirt checks available disk in the check_destinations callsa12:18
PaulMurrayso its needed to control that one check12:18
*** e0ne has quit IRC12:19
PaulMurrayI'd like to see it go personally12:19
johnthetubaguyPaulMurray: yeah, we were discuss how that should all be resource tracker really12:19
*** e0ne has joined #openstack-nova12:19
johnthetubaguyyeah, I think the debate is optional or kill it, at this point12:19
johnthetubaguyI am leaning towards kill it12:19
johnthetubaguyforce is a better metaphor, where that means: if its at all possible, put it there12:20
*** Sree_ has joined #openstack-nova12:20
*** otter768 has joined #openstack-nova12:20
tdurakovPaulMurray, correct me if i wrong disk_over_commit is used only here: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L532512:20
*** Sree_ is now known as Guest4343112:20
*** ihrachys has quit IRC12:21
PaulMurrayjohnthetubaguy, I saw something else in there too,12:21
PaulMurraytdurakov, ^12:22
johnthetubaguytdurakov: thats the only of it I found12:22
tdurakovPaulMurray, well, i couldn't find any12:23
johnthetubaguyso I should run away and get some lunch, getting low blood sugar, back soon ish12:23
PaulMurrayFrom discussions with mdbooth and danpb about the way qcow2 is handled I believe they make files to the full size of the image dispite the qcow2 being smaller12:23
pkholkinjohnthetubaguy: I also want to point that NO patches removing use_slave were already merged12:23
PaulMurrayI wonder if that is related12:23
*** Sree has quit IRC12:23
PaulMurraySo even if you have enough disk space for the actual size, libvirt might grab more, so its hard to over commit12:24
PaulMurrayhard to allow it ^^12:24
johnthetubaguypkholkin: ah, OK, thats good, so we should decide about this ASAP, have you spoken to dansmith about this?12:24
PaulMurray(That is more of a question than a statement)12:24
PaulMurrayjohnthetubaguy, ^^12:24
tdurakovjohnthetubaguy, PaulMurray, if nfs is being merged what about moving l-m job from experimental to check pipeline12:24
danpbPaulMurray: yep, that's correct, if preallocation is turned on12:24
pkholkinjohnthetubaguy: that's why I write to you to come to the decision. No, I speak only to you right now12:25
*** otter768 has quit IRC12:25
johnthetubaguyPaulMurray: yeah, its probably broken anyways, although depends on your storage system, as zeros may take up no space12:25
johnthetubaguypkholkin: cool, appreciate you reaching out12:25
pkholkinwe marked all suspicious patches as wip12:26
johnthetubaguypkholkin: so the use case was really that we needed a way to move DB load from the primary servers to the read slaves, those slaves will have a slight lag in updates, depending on how they are setup, so we need to be careful about how they are used, if that makes sense?12:26
pkholkinjohnthetubaguy: yes, the idea was clear12:27
PaulMurraytdurakov, are there any tests being exercised yet?12:28
*** jianghuaw has joined #openstack-nova12:28
johnthetubaguypkholkin: just checking what we wrote in here: http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/juno-slaveification.html12:28
PaulMurrayor would it be effetively an empty job12:28
tdurakovPaulMurray, well, it's already tests l-m with no-shared storage and nfs patch is on review12:29
*** sudipto has quit IRC12:29
tdurakovso, it's definitely not empty job:)12:29
*** alejandrito has joined #openstack-nova12:30
PaulMurraytdurakov, I don't actual know the the policy for adding a non-voting check job - johnthetubaguy ?12:30
johnthetubaguypkholkin: I think the main argument against the decorator approach, is really just that it fixes that DB call to always read from the slave, which might not make sense, and its less explicit where its used that its possibly reading stale data, hence the use_slave parameter approach, its very ugly, but was the best way to meet all the requirements12:30
markus_z_meetingmelwitt: Is your name here still valid? https://wiki.openstack.org/wiki/Nova/BugTriage#Step_2:_Triage_Tagged_Bugs12:30
johnthetubaguyPaulMurray: usually its do experimental first to make sure its working12:30
PaulMurraytdurakov, what were the next things you were going to add - nfs was the first of a list wasn't it?12:31
markus_z_meetingmelwitt: There are 7 bugs for the novaclient which aren't triaged, would be cool if you could have a look. If you're the wrong contact here, please let me know.12:31
tdurakovPaulMurray, it's only cep left12:31
tdurakov*ceph12:32
pkholkinjohnthetubaguy: ok, we will think for some time how to support use_slave and make the code good12:32
* johnthetubaguy really has to go get food now, hungry12:32
*** markvoelker has joined #openstack-nova12:32
johnthetubaguypkholkin: thanks, it would be good to end up with something better than the current approach12:32
*** ihrachys has joined #openstack-nova12:32
pkholkinjohnthetubaguy: ok, we will try and share the results12:32
*** eglynn has joined #openstack-nova12:32
johnthetubaguypkholkin: maybe a new method called slave_something_something, so its explicit, is possible?12:32
pkholkinjohnthetubaguy: we are thinking about it right now)12:33
tdurakovjohnthetubaguy, do we have some criteria that job works? stats maybe?12:33
*** Sree has joined #openstack-nova12:33
PaulMurraytdurakov, I'd be inclined to add ceph first - and ideally tests that use nfs and ceph before moving to check12:35
PaulMurrayas a way to make sure everything is working12:35
PaulMurraythen move to check, then start increasing coverage12:35
PaulMurraydoes that sound reasonable tdurakov johnthetubaguy ?12:35
*** Guest43431 has quit IRC12:36
*** aix has quit IRC12:36
tdurakovPaulMurray, well, there is no technical blockers to wait for ceph, but I'm ok with finishing all of this12:36
*** markvoelker has quit IRC12:37
*** raildo-afk is now known as raildo12:39
*** ihrachys has quit IRC12:39
*** ihrachys has joined #openstack-nova12:40
PaulMurraytdurakov, I'd like someone who's gone through adding jobs before to make a suggestion, but that seems to be sensible to me12:40
PaulMurrayThe other idea is to start testing as soon as a test works - which is what you have now, so I can go either way12:40
johnthetubaguytdurakov: not seeming broken, I guess, its depends how new the job is really, and how many resources it would burn12:41
*** rotbeard has quit IRC12:41
johnthetubaguyPaulMurray: we already have a ceph job, I guess, the NFS job would be new I guess?12:41
* johnthetubaguy really should get some food, actually goes this time...12:41
*** baoli has joined #openstack-nova12:41
PaulMurraytdurakov, your call, what would you prefer?12:42
tdurakovjohnthetubaguy, it's not separate job for nfs, but separate job for live-migration here is description: https://github.com/openstack/nova/blob/master/nova/tests/live_migration/hooks/run_tests.sh12:42
PaulMurraytdurakov, what's in my mind is it would be good not to start using resources on every commit before we are reasonably sure it will work12:43
tdurakovPaulMurray, well, there is another way, we could leave it in experimental and make announcement for mailing list12:44
PaulMurraytdurakov, and it would be good not see failures12:44
*** jianghuaw has quit IRC12:44
tdurakovso evereyone who need to check live-migration could type "check experimental"12:44
PaulMurrayso I think johnthetubaguy's comment about ceph vs nfs is that if there is a ceph job already we might be more sure that adding ceph is unlikely to have surprises12:45
*** jianghuaw has joined #openstack-nova12:45
*** Sree has quit IRC12:45
PaulMurraybut adding nfs has value12:45
tdurakovunfortunately it's single-node ceph job12:45
*** Sree has joined #openstack-nova12:46
tdurakovbut yes, it's already done, so no surprises should be:)12:46
*** baoli has quit IRC12:46
*** rotbeard has joined #openstack-nova12:46
PaulMurraySo if there is a risk that it may start spuriously breaking because we haven't got the configuration quite right first time, it would be better to keep it in experimental12:46
*** thorst has joined #openstack-nova12:46
PaulMurray(I mean start breaking when you add ceph)12:46
tdurakovPaulMurray, ok, let's go with my proposal about about mailing list announcement then?12:47
PaulMurraytdurakov, sounds like a good plan12:47
tdurakovas folks merge my nfs patch i'll write mail12:47
tdurakovcall it beta-testing, lol12:47
*** baoli has joined #openstack-nova12:48
PaulMurraynow I'm getting lunch too - its that time around here12:48
tdurakovbon appétit12:48
PaulMurraytdurakov, BTW - good job so far - I'm very glad to see your progress12:49
pkholkinjohnthetubaguy: what about some custom decorator in nova? I mean smth like @choose_reader_or_async depending on use_slave12:54
*** salv-orl_ has joined #openstack-nova12:54
*** jianghuaw has quit IRC12:55
*** wuhg has joined #openstack-nova12:55
*** jwcroppe has joined #openstack-nova12:55
*** lucas-dinner is now known as lucas-hungry12:56
*** salv-orlando has quit IRC12:57
*** signed8bit has joined #openstack-nova12:58
openstackgerritjichenjc proposed openstack/nova: Change some wording on server_concepts.rst  https://review.openstack.org/24806312:58
*** jaypipes has joined #openstack-nova13:00
*** achanda has quit IRC13:01
*** achanda has joined #openstack-nova13:02
*** MVenesio has joined #openstack-nova13:04
johnthetubaguypkholkin: its the approach of using a decorator that I think is problematic, not what the decorator says13:08
*** tdurakov is now known as tdurakov_afk13:08
mdboothjohnthetubaguy pkholkin: The problem with removing use_slave is that I didn't consider what happens when a request crosses an rpc boundary13:08
johnthetubaguymdbooth: ah, good point, I forgot that important detail!13:09
mdboothThe decorator itself is ok, because you can put it in the appropriate scope13:09
*** salv-orl_ has quit IRC13:09
mdboothThe problem is that if that scope does rpc, the context is lost13:09
*** salv-orlando has joined #openstack-nova13:09
mdboothSo you still need use_slave to be passed so that the context isn't lost13:09
*** claudiub has joined #openstack-nova13:09
mdboothBecause we're tracking it in the request context automatically, though, we might still be able to get rid of a bunch of use_slave arguments13:10
mdboothBecause we can just pull it out of the request context immediately before making an rpc call13:10
johnthetubaguymdbooth: so the current proposal is OK with that actually, it doesn't cross RPC, but yeah, we can't just store it in the context near where its called because of that13:10
johnthetubaguyhttps://review.openstack.org/#/c/243496/213:11
johnthetubaguyis the link13:11
*** tdurakov_afk has quit IRC13:12
mdboothIt occurs to me that there's a potential race here which we thought we'd addressed before13:13
mdboothWhen using Galera13:14
mdboothIf you write data on host a, which goes to write connection db node X13:14
mdboothAnd then rpc to host b, which reads from db node Y13:14
mdboothThe rpc can read read state before it was written on host a13:15
claudiubjohnthetubaguy: hello. we've talked before about implementing a wait for a neutron event in the hyper-v driver, so it can start the VM after its ports have been bound. You said it can be a specless blueprint, since it is already implemented in libvirt. Here's the blueprint: https://blueprints.launchpad.net/nova/+spec/hyper-v-spawn-on-neutron-event13:15
*** signed8bit is now known as signed8bit_ZZZzz13:15
*** salv-orlando has quit IRC13:16
mdboothWe addressed that in the single node case by caching a write context in the current request context, and ensuring that a subsequent read context would always go to the same db connection13:16
mdboothBut I don't think we can do that across rpc13:16
mdboothIncidentally, this problem isn't just theoretical13:16
johnthetubaguyclaudiub: is that on the list of proposed spec-less blueprints yet?13:16
mdboothIt's pretty easy to reproduce13:16
*** salv-orlando has joined #openstack-nova13:16
claudiubjohnthetubaguy: no, sorry.13:16
*** tdurakov_afk has joined #openstack-nova13:16
*** tdurakov_afk has quit IRC13:17
claudiubjohnthetubaguy: putting it now.13:17
*** mkoderer has quit IRC13:18
johnthetubaguyclaudiub: cool, thank you13:19
mdboothMulti-master galera is a nightmare for races13:19
*** sacharya has joined #openstack-nova13:20
*** ryandahp_ has joined #openstack-nova13:20
pkholkinmdbooth: Matthew, so what do you think about supporting use_slave?13:20
mdboothpkholkin: I think we have to, because there's no other way to retain that context when doing an rpc.13:21
mdboothWe're not using it well right now, but that's not the point. The enginefacade is a single node solution.13:22
*** mkoderer has joined #openstack-nova13:22
mdboothWe *can* remove use_slave for non-remotable apis13:22
mdboothBecause the recipient can decorate the request context immediately, and that will propagate until there's another rpc13:23
*** rpodolyaka1 has joined #openstack-nova13:23
*** ryandahp has quit IRC13:24
*** jkraj has quit IRC13:24
johnthetubaguyso there are methods that only get used with use_slave=True13:24
johnthetubaguythe proposed decorator approach would work just fine right now13:24
bauwseryup13:24
*** sacharya has quit IRC13:24
*** rk4n has quit IRC13:24
johnthetubaguyas the remote method is the object call, and the decorator is in the DB api that is called on the conductor13:25
*** jkraj has joined #openstack-nova13:25
johnthetubaguybut my worry is that its very unclear in the code that you are accessing a read slave, if we hide use_slave=True13:25
johnthetubaguynow we do have the RPC context issue, which constrains the possible alternative approaches we could take13:25
*** jkraj has quit IRC13:26
johnthetubaguyat least that is what is in my head around this right now13:26
mdboothjohnthetubaguy: Anything running under the async_reader context is readonly13:26
*** abhishekk has quit IRC13:26
mdboothIf it wasn't, it wouldn't work13:26
mdboothSo the code just need to return data13:26
johnthetubaguymdbooth: yes, sorry, not sure I understand why thats important?13:26
mdboothIt's up to the caller to say they can handle old data13:27
johnthetubaguyagreed13:27
mdboothThe decorator doesn't need to be in the db/api.py13:27
mdboothIt can be in objects/instance.py13:27
mdboothThis is one of the great benefits of this patch13:27
johnthetubaguyso it could be in the DB API for things that are *always* assumed to be reading from the slave13:27
johnthetubaguywhich is the current proposal being made13:27
mdboothI don't think the db api should ever assume that13:28
openstackgerritAlexis Lee proposed openstack/nova: Remove SoftDeleteMixin from BandwidthUsage  https://review.openstack.org/24036113:28
mdboothIt should use its current context13:28
mdboothIf it's async, it will read from async13:28
johnthetubaguyso I agree, it shouldn't assume that, hence my push to keep read_slave=True13:28
*** achanda has quit IRC13:28
*** rk4n has joined #openstack-nova13:28
mdboothread_slave isn't required in the db api, though13:28
mdboothbecause that's not an rpc call13:28
johnthetubaguyagreed13:29
mdboothAnd the caller can already decorate the current context with async reader if that's what they want13:29
mdboothbefore calling the db api, that is13:29
mdboothThe beauty of that is that it will automatically use the same async connection for all db calls in the current context13:30
*** aix has joined #openstack-nova13:30
mdboothEven if the db call is embedded in an object read13:30
*** dave-mccowan has joined #openstack-nova13:30
mdboothAs long as it wasn't remoted :)13:30
*** achanda has joined #openstack-nova13:31
*** zenoway has quit IRC13:31
*** dane-fichter has joined #openstack-nova13:33
mdboothjohnthetubaguy: So let's be specific: _check_instance_build_time13:34
openstackgerritClaudiu Belu proposed openstack/nova: Hyper-V: refines the exceptions raised in the driver  https://review.openstack.org/21210213:34
openstackgerritClaudiu Belu proposed openstack/nova: Hyper-V: adds os-win library  https://review.openstack.org/24772913:34
johnthetubaguymdbooth: so this is the patch pkholkin and I were discussing: https://review.openstack.org/#/c/24349613:34
mdboothjohnthetubaguy: Even better :)13:35
pkholkinmdbooth: if I understand you correctly, you want to use reader as default and the decorate method as async if needed in objects, yes?13:35
*** markvoelker has joined #openstack-nova13:35
openstackgerritClaudiu Belu proposed openstack/nova: Hyper-V: removes *Utils modules and unit tests  https://review.openstack.org/21591713:35
mdboothpkholkin: No. I think we would decorate the function as async. If the admin configures async it will be used. If not it will use the reader connection.13:36
johnthetubaguypkholkin: so my issue here is really to keep the objects contract the same, however best we do that, I don't mind too much.13:36
* mdbooth reads the review in question13:36
*** bochi-michael has joined #openstack-nova13:36
johnthetubaguymdbooth: pkholkin: so I am totally confused now...13:36
openstackgerritClaudiu Belu proposed openstack/nova: Converting nova.virt.hyperv to py3  https://review.openstack.org/23255413:36
openstackgerritClaudiu Belu proposed openstack/nova: Replaces longs with ints  https://review.openstack.org/23823913:37
johnthetubaguyfeels like we are talking at cross purposes, maybe lets add comments in the review, and loop back here?13:37
*** achanda has quit IRC13:37
mdboothjohnthetubaguy: k13:37
*** zenoway has joined #openstack-nova13:38
mdboothpkholkin: I think we may hit an invalid assumption in the oslo.db stuff here13:38
openstackgerritClaudiu Belu proposed openstack/nova: Fixes dict keys and items references for Python 3  https://review.openstack.org/23258513:38
mdboothpkholkin: Which we may have to work round13:38
*** ociuhandu has joined #openstack-nova13:38
pkholkinmdbooth: the problem in our patch right now is that if slave_connection is configured we will always use it and ignore any developer's use_slave parameter in code13:38
*** achanda has joined #openstack-nova13:38
*** richm has joined #openstack-nova13:39
*** tdurakov has joined #openstack-nova13:39
mdboothRight. So lets get specific again. Lets consider _check_instance_build_time in compute manager13:39
mdboothpkholkin: ^^^13:39
mdboothI believe that function should be decorated with async13:40
mdboothBecause that's where that context is relevant13:40
mdboothIt then does:13:40
mdbooth        building_insts = objects.InstanceList.get_by_filters(context,13:40
mdbooth                           filters, expected_attrs=[], use_slave=True)13:40
*** leseb has quit IRC13:40
mdboothThat use_slave is redundant, because it's already there in the context13:40
*** ihrachys has quit IRC13:40
mdboothHowever, that function is presumably also remotable13:41
mdboothIf we assume that it gets rpc'd to conductor, conductor needs a way to know that the context is async13:41
mdboothSo we need to put it back for the rpc call.13:42
mdboothThinking on my feet, it might actually be possible to do that automatically in the remotable decorator...13:42
mdboothAnyway, when it crosses the wire, use_slave needs to be there13:42
mdboothWhen that results in a call into the db api, it should use the current context. If that's async it should use that.13:43
*** edleafe is now known as figleaf13:43
lxsliLinked http://docs.openstack.org/developer/nova/code-review.html on https://wiki.openstack.org/wiki/How_To_Contribute#Reviewing and https://wiki.openstack.org/wiki/Nova/CoreTeam#Review_Expectations13:43
*** klkumar has quit IRC13:43
*** Piet has quit IRC13:44
mdboothThe problem I think we'll hit is that iirc we assume a hierarchy of writer->reader->async reader13:44
raildohey guys, me and some guys are working in the nested quota driver (https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z) in addition, we want start discuss the re-design of the quota implementation on nova and in other projects, like cinder and neutron. I now that we already have a base spec for this here in nova: https://review.openstack.org/#/c/182445/4/specs/backlog/approved/quotas-13:44
raildoreimagined.rst13:44
raildo*https://review.openstack.org/#/c/182445/4/specs/backlog/approved/quotas-reimagined.rst13:44
mdboothSo I have a sneaking suspicion that if an async context hits @reader it will raise an exception13:44
raildoSo was I thinking on reate a subteam to speed up the code review in the nested quota implementation and discuss this re-design of quotas. Someone have interest to participate in this subteam?13:44
pkholkinmdbooth: yes it will be13:45
rpodolyaka1it will13:45
mdboothIf so, we'll need to either fix that, or introduce a new decorator13:45
mdboothwhich checks to see if something is async already, and makes it reader only if it isn't13:45
pkholkinhttps://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/enginefacade.py#L560-L56113:46
rpodolyaka1maybe decorators just don't make sense at db/sqlalchemy/api level?13:46
rpodolyaka1as we don't have enough information there13:46
rpodolyaka1if it should be async vs reader13:46
mdboothrpodolyaka: I think you're right13:46
mdboothWe obviously know reader vs writer13:46
rpodolyaka1yeah13:46
mdboothBut reader vs async reader is a higher context thing13:46
rpodolyaka1so the only problem with that is that objects level will know about the implementation details, i.e. sqlalchemy based db api impl13:47
mdboothHehe13:48
*** tdurakov has quit IRC13:48
johnthetubaguyrpodolyaka1: mdbooth: thats my main complaint, async vs reader should not be hidden down at the DB API layer13:48
mdboothWe should totally ditch the notion that we might replace sqlalchemy :)13:48
rpodolyaka1heh13:48
*** ihrachys has joined #openstack-nova13:48
rpodolyaka1I thought, rax or someone else had their own implementation13:48
alex_xubauwser: actually disk_over_commit is removed by microverions, so I think we needn't deprecated it first13:48
johnthetubaguyrpodolyaka1: use_slave is fairly abstract though, in concept, I wish it was allow_update_lag or something13:49
mdboothjohnthetubaguy: Yup. This is actually *better* at that.13:49
rpodolyaka1agreed13:49
mdboothBecause you can create a db context at any scope13:49
mdboothIt's not confined to the db api13:49
johnthetubaguyrpodolyaka1: not really, for nova-cells workers a few calls have been re-implemented to speed it up, but mostly because we don't use pymysql13:49
alex_xubauwser: the disk_over_commit is almost at here very long time in old version13:49
rpodolyaka1johnthetubaguy: ack, I must have confused rax with someone else then13:50
*** ankit_ag has quit IRC13:50
bauwseralex_xu: I'd prefer a more gentle approach where we keep it optional but raise a warning if someone uses it13:51
*** rk4n has quit IRC13:51
bauwseralex_xu: I don't want to have the operators thrown under the bus because of that13:51
bauwsertbh, I don't feel the warning right, but a relnote is certainly good13:51
bauwseralex_xu: for sure we could say "eh, you just have to ask for an earlier microversion" but that's a bit bad IMHO - because what if they want a bugfix ?13:51
bauwseralex_xu: sure but imagine the following case : disk_over_commit is removed by v2.25 but a new feature or bugfix is modifying an API by v2.2613:52
*** rk4n has joined #openstack-nova13:52
bauwseralex_xu: is this fromage or desert?13:52
rpodolyaka1mdbooth:  ok, so looks like we'll need something similar to async/reader/writer in db/api and allow to use that up the stack at objects level13:52
bauwseroops13:52
bauwsercheese or desert I mean13:52
*** salv-orlando has quit IRC13:52
*** markus_z_bnc has quit IRC13:52
rpodolyaka1mdbooth: I'm just a bit confused, why that wouldn't work with remote calls?13:52
*** salv-orl_ has joined #openstack-nova13:52
* bauwser not sure that this expression is well known abroad13:52
alex_xubauwser: emm...probably more clear your point13:53
*** Sree has quit IRC13:53
mdboothrpodolyaka: Because the db context isn't serialised on the wire13:53
mdboothThe remote end doesn't have the db context of the caller13:53
*** lucas-hungry is now known as lucasagomes13:53
mdboothIt'll have to be explicit13:53
rpodolyaka1aha13:53
bauwseralex_xu: so, sure the operator can get the option by calling an earlier version, right?13:53
*** tdurakov has joined #openstack-nova13:54
rpodolyaka1so, maybe leave use_salve in rpc calls13:54
rpodolyaka1and then use context managers?13:54
mdboothYup13:54
rpodolyaka1on the remote end13:54
alex_xulet me think more minutes13:54
mdboothYes. The receiver can just set the context according to what it received13:54
*** annegentle has joined #openstack-nova13:54
rpodolyaka1aha, makes sense now, thanks!13:54
*** klkumar has joined #openstack-nova13:54
alex_xubauwser: yes, and that old behavior will keep at here13:54
*** ihrachys has quit IRC13:55
bauwseralex_xu: okay, so they will be stuck with that earlier version if they want to use disk_over_commit, right?13:55
*** paul-carlton has quit IRC13:55
*** jianghuaw has joined #openstack-nova13:55
alex_xubauwser: yes13:56
*** claudiub has quit IRC13:57
alex_xubauwser: just to be clear, you expect RT can provide similar functionality in the future, right?13:57
bauwseralex_xu: before talking about the implementation, I'm just trying to explain why I want to deprecate :)13:58
*** jaypipes has quit IRC13:59
bauwseralex_xu: so if the operator is stuck with an earlier version, how can he get the latest API features, given it's monotonic?13:59
*** jianghuaw has quit IRC13:59
alex_xubauwser: if operator want to upgrade his client to support latest api, he need prepare all the things he need change, including disk_overcommit get rid of.14:00
bauwseralex_xu: to be clear, I'm thinking of a 'grace period' where we could admit that we made something wrong but that it would need time to implement the feature differently before removing the posibility to use it14:00
bauwseralex_xu: I think I see your point, what just worries me is that we remove a feature without waiting a deprecation cycle14:00
bauwser(to summarize)14:01
bauwseralex_xu: that's not like if we change the API contract but we're still providing the possibility to count against real disk usage14:01
*** rlrossit has joined #openstack-nova14:01
*** klkumar has quit IRC14:02
alex_xubauwser: yea, I see your point. I'm also think about we already have microversion that is used to advert api change, why we still need other way to deprecated feature14:02
*** ihrachys has joined #openstack-nova14:02
bauwseralex_xu: it's your expertise, so lemme ask you a question14:02
alex_xubauwser: but API contract changed, something means the feature changed, like add feature and remove feature14:02
bauwseralex_xu: did you already bump a microversion for removing a feature without providing another way to get that feature?14:02
bauwsernot speaking of the EC2 endpoint for example14:03
bauwserjust microversions14:03
*** alex_klimov has quit IRC14:03
alex_xubauwser: at least for now, we don't have such case14:03
bauwseralex_xu: tbc, I'm not particularly concerned by that14:03
bauwseralex_xu: I just want to make sure it's something agreed14:04
alex_xubauwser: yea, I see14:05
*** klkumar has joined #openstack-nova14:05
bauwseralex_xu: maybe I'm overthinking tho :)14:05
*** zhenq has joined #openstack-nova14:06
alex_xubauwser: so what is deprecated propose for? deprecated is for admin after upgrade his code, his tools or client won't break, and get chance find something instead14:06
bauwseryeah that14:06
bauwsera migration path14:07
alex_xubauwser: emm...next thing is think about, whether microversion provide that.14:07
bauwseralex_xu: so, my take is that it's just a matter of providing a release note14:08
bauwseralex_xu: you keep the attribute but you make it optional14:08
alex_xumicroversion is different, microversion tell people there are something removed, but you still can use old version before you are ready14:08
*** ildikov has quit IRC14:08
*** ijuwang has joined #openstack-nova14:08
bauwseralex_xu: so that when the new cycle begins, you provide a microversion for removing that attribute14:08
bauwseralex_xu: a-ha I see14:08
*** claudiub has joined #openstack-nova14:09
bauwserwell, if you feel microversioning the removal is fine, then I'm okay :)14:09
*** mjura has quit IRC14:10
*** klkumar has quit IRC14:11
*** achanda has quit IRC14:11
*** ildikov has joined #openstack-nova14:12
alex_xubauwser: after thinking, yea, I think it is ok. And the new feature is thing to encourage people upgrade to deprecated the old api.14:12
*** stevemar_ has joined #openstack-nova14:13
*** achanda has joined #openstack-nova14:13
*** eharney has joined #openstack-nova14:15
*** signed8bit_ZZZzz is now known as signed8bit14:16
*** mriedem has joined #openstack-nova14:16
*** salv-orl_ has quit IRC14:17
*** signed8bit is now known as signed8bit_ZZZzz14:17
*** mdrabe has joined #openstack-nova14:18
bauwseralex_xu: okay, you mean we can go straight and just remove the attribute in a microversion ? fair enough then14:20
*** salv-orlando has joined #openstack-nova14:21
alex_xubauwser: yea, that is my understand microversion is used to14:21
*** jerrygb has joined #openstack-nova14:21
*** doug-fish has joined #openstack-nova14:21
*** otter768 has joined #openstack-nova14:21
*** jichen has quit IRC14:22
*** burt has joined #openstack-nova14:22
alex_xuPaulMurray: just saw your commit, do you mean hp need that feature? or that is a feature can be depreacted by microversion?14:23
*** signed8bit_ZZZzz is now known as signed8bit14:23
*** mrkz has joined #openstack-nova14:24
alex_xumaybe I should bring this up to livemigration weekly meeting14:25
*** klkumar has joined #openstack-nova14:26
*** otter768 has quit IRC14:26
*** ihrachys has quit IRC14:26
*** artom has joined #openstack-nova14:26
*** achanda has quit IRC14:26
*** rubasov has quit IRC14:29
*** Piet has joined #openstack-nova14:29
mriedembauwser: i'm spilling the reno madness over into other projects now :) https://review.openstack.org/#/c/247906/14:30
bauwser\o/14:30
bauwsermriedem: FYI, I just saw the current relnotes in a draft build, and I'm a bit sad about the current prelude section, so I'll also try to update the YAML files next week14:31
bauwserfor the moment, trying to get my brain focused on specs more than 10 mins14:32
*** ihrachys has joined #openstack-nova14:32
mriedemgood luck14:32
mriedemi do spec reviews at night14:32
bauwserI know14:32
mriedemand you work at night :)14:32
bauwserI'd rather say I work at Australia morning14:32
*** jianghuaw has joined #openstack-nova14:32
*** jianghuaw has quit IRC14:33
*** daemontool has joined #openstack-nova14:35
*** rpodolyaka1 has quit IRC14:35
*** smatzek has quit IRC14:35
*** akshai has joined #openstack-nova14:35
*** tdurakov has quit IRC14:37
*** rpodolyaka1 has joined #openstack-nova14:37
*** daemontool_ has quit IRC14:37
*** annegentle has quit IRC14:38
*** tdurakov has joined #openstack-nova14:38
mriedemsuperdan?!14:41
*** fawadkhaliq has joined #openstack-nova14:41
dansmithomg is it friday?14:41
*** dansmith is now known as superdan14:41
mriedemit's tgif14:41
sdaguejohnthetubaguy: why did you want this as an action instead of a resource - https://review.openstack.org/#/c/228828/ ?14:43
*** paul-carlton has joined #openstack-nova14:43
sdagueon the live migrations cancel14:43
*** achanda has joined #openstack-nova14:44
*** chinmay_ has quit IRC14:45
*** burgerk has joined #openstack-nova14:46
*** xyang1 has joined #openstack-nova14:46
*** cfriesen__ has joined #openstack-nova14:46
*** aix has quit IRC14:47
*** aix has joined #openstack-nova14:49
*** ctrath has joined #openstack-nova14:49
PaulMurrayalex_xu, do you mean the comment about disk_over_commit ?14:50
*** paul-carlton1 has joined #openstack-nova14:50
*** ihrachys has quit IRC14:51
*** ihrachys has joined #openstack-nova14:54
*** paul-carlton has left #openstack-nova14:54
*** paul-carlton has joined #openstack-nova14:54
*** xek has quit IRC14:55
*** nkrinner has quit IRC14:55
openstackgerritBalazs Gibizer proposed openstack/nova: Handle race in allocate_for_instance  https://review.openstack.org/22180314:55
*** paul-carlton has left #openstack-nova14:55
*** gwei3 has joined #openstack-nova14:56
*** pumaranikar has joined #openstack-nova14:56
*** ccarmack has joined #openstack-nova14:57
*** vladikr has joined #openstack-nova14:58
*** mhickey has joined #openstack-nova14:58
openstackgerritYingxin Cheng proposed openstack/nova: Use stevedore for scheduler host manager  https://review.openstack.org/24647614:58
*** markus_z_meeting is now known as markus_z14:59
*** paul-carlton2 has joined #openstack-nova14:59
johnthetubaguysdague: good question, I think its that I wanted to drop the migration endpoint really14:59
dimsmhickey : can you please paste a github link to the deprecated opt and we can ask folks here?14:59
sdaguejohnthetubaguy: right, that's fine, but as a sub resource on servers this seems to make more sense15:00
sdagueI just hate openning up another action if there is a restful way to model this15:00
*** mpavone has quit IRC15:01
*** boris-42 has joined #openstack-nova15:01
mhickeydims: Sure. Here it is: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L13215:01
*** mgoddard_ has joined #openstack-nova15:02
dimsjohnthetubaguy : when do we clean up deprecated options? like the one above ^^^15:02
johnthetubaguysdague: true15:02
*** kfarr has joined #openstack-nova15:02
johnthetubaguydims: depends when we deprecated them15:02
*** breitz has joined #openstack-nova15:03
johnthetubaguysdague: my thinking we add the action, so it matches everything else for now, while we sort out tasks more generally15:03
dimsjohnthetubaguy : "Aug 31, 2014"15:03
sdaguejohnthetubaguy: then we have to support the action largely forever15:03
sdaguedims: + 3 months15:03
johnthetubaguydims: so we can do that last release then, I guess15:03
sdagueoh, 2014,15:03
dimssdague :)15:04
johnthetubaguysdague: yeah, we do, but at least is consistently terrible as other things, rather than a new thing on the side, that gets turned into another new ish thing later?15:05
sdaguejohnthetubaguy: I really think we should avoid the actions interface whenever possible15:05
johnthetubaguysdague: maybe I am over thinking this15:05
*** smatzek has joined #openstack-nova15:05
sdagueyou don't think we'd continue to want to have access to the migrations this way?15:05
*** mgoddard has quit IRC15:05
sdaguealso, at this point I consider tasks to be duke nukem 315:05
sdagueI don't believe it's happening in any reasonable time frame15:06
johnthetubaguyso we have instance actions for some things and migrations for other things15:06
johnthetubaguynow thats not quite the same thing, granted15:06
johnthetubaguybut its a way to get status on an async task15:06
sdaguea migration is a subresource of a server15:07
sdaguewe model it that way in our database even15:07
johnthetubaguyhttp://developer.openstack.org/api-ref-compute-v2.1.html#os-migrations-v2.115:08
sdagueright, the search is not15:08
*** jasondotstar is now known as jasondotstar_afk15:08
sdagueI don't want to add it to that resource15:08
johnthetubaguyah, so thats the proposal I was against15:09
johnthetubaguyat least in my head15:09
sdagueI want that resource to return search results which include links to /server/{id}/migrations/{mid}15:09
sdagueand DELETE / GET on /server/{id}/migrations/{mid}  is a thing15:09
paul-carlton2the problem as I see it is that the migrations list returns migration ids, we'd need to convert this to migration uuid to move forward with this plan15:10
johnthetubaguyoh, didn't know that existed, my bad15:10
*** stevemar_ has quit IRC15:10
sdaguejohnthetubaguy: it doesn't15:10
openstackgerritPavel Kholkin proposed openstack/nova: enginefacade: 'migration'  https://review.openstack.org/24349615:10
johnthetubaguyoh, now I get you15:10
sdaguethat's the way I think this API should work though, instead of a new action15:10
*** yonglihe has joined #openstack-nova15:10
johnthetubaguywhat about GET on /server/{uuid}15:11
johnthetubaguyarg15:11
sdaguepaul-carlton2: why would we need to change the id?15:11
paul-carlton2I dropped the idea of doing cancel migration on migration object when https://review.openstack.org/#/c/243587/ got rejected15:11
johnthetubaguyGET on /server/{uuid}/action/{request-id}15:11
*** e0ne has quit IRC15:11
paul-carlton2We hse uuids everywhere else so I assumed we'd want to do that for migrations too15:12
*** haomaiwa_ has quit IRC15:12
sdaguepaul-carlton2: we use them because of potential uniqueness constraints, there is no reason why you'd have to change it here15:12
sdaguejohnthetubaguy: and GET /server/{uuid}/actions returns what?15:13
johnthetubaguybasically you get something like this, but complete: /v2.1/​{tenant_id}​/servers/​{server_id}​/os-instance-actions15:13
johnthetubaguya record for every action call on the instance, and its current status15:13
sdagueok, so now this is basically tasks light15:14
johnthetubaguylive-migrate, snapshots, soft-reboot, can then all get cancelled in a similar way15:14
johnthetubaguyI suppose, yeah15:14
sdagueok, so what is the objection to exposing /server/{id}/migrations long term?15:15
sdagueI guess that's the resistance I don't understand15:15
paul-carlton2so I'd get this back15:15
paul-carlton2RESP BODY: {"instanceActions": [{"instance_uuid": "9d266594-5f13-43b9-b9dd-28c8ee92a534", "user_id": "5bf0029a20f24149810cafed6d820ca7", "start_time": "2015-11-19T07:24:18.000000", "request_id": "req-7bd61401-433f-48cc-9419-a9d32a8fd5de", "action": "live-migration", "message": null, "project_id": "bf941e97250e49cab47d07767c62c15a"}, {"instance_uuid": "9d266594-5f13-43b9-b9dd-28c8ee92a534", "user_id": "0e86d465eadf4615:15
johnthetubaguysdague: we could, I just slightly prefer a full list of tasks, rather that having to go to different places depending on the action you take15:16
*** krtaylor has joined #openstack-nova15:16
johnthetubaguylist of actions, I guess I mean15:16
sdaguejohnthetubaguy: ok, but that's the tasks api (more or less), which has been stalled for 2 years15:16
*** sneti has joined #openstack-nova15:16
sdaguealso, with instance actions you have the visibility concerns as well right. A normal user probably shouldn't know their instance is getting live migrated15:18
paul-carlton2sdague: The cat is out of the bag when they do get on server, task state of migrating gives it away!15:19
johnthetubaguysdague: so I thought about that more, they actually have to know, because it stops a snapshot being taken, but, pathologically, you sort of don't want to tell them the live-migrate happened if they didn't spot it while it was happening15:19
johnthetubaguypaul-carlton2: and that, good point15:20
sdagueyeh, honestly, I think that if we start overloading instance actions to be tasks light we're just going to end up with gorp that we're all going to regret down the road15:20
*** rlrossit has quit IRC15:20
*** pradk has joined #openstack-nova15:21
*** annegentle has joined #openstack-nova15:21
sdagueI personally hate actions because all the logging by url becomes useless15:21
sdagueso you have to build a whole additional toolchain to figure out what's going on postmortem15:21
lxsliHave requirements on the tasks API been written up somewhere?15:21
bauwserlxsli: on it15:21
sdaguemade worse so by putting things under apache15:21
bauwserlxsli: for the moment, we have old stuff and my manifesto15:22
*** rlrossit has joined #openstack-nova15:22
bauwserlxsli: so I'm writing a Tasks API spec15:22
lxslibauwser: cool cool15:22
sdaguebauwser: for which I salute you15:22
bauwser(keeping in mind the deadline, for sure)15:22
sdaguehowever, it's still a long ways off15:22
*** jerrygb has quit IRC15:22
bauwsersdague: totally agreed15:23
bauwsersdague: I don't pretend to boil the ocean15:23
bauwsersdague: :)15:23
*** jerrygb has joined #openstack-nova15:23
lxsliAnyone for https://review.openstack.org/#/c/240361/ please?15:23
*** pratikmallya has joined #openstack-nova15:23
*** kfarr has quit IRC15:23
bauwserso, yeah, it seems there is a consensus on having a Tasks object - that's why I'm writting a spec to discuss that and confirm that15:23
mriedembauwser: hmmm15:24
mriedemso,15:24
paul-carlton2We really need to re do every action on an instance as a task but we can't stop all enhancements till task API is done15:24
bauwsermy personal target for Mitaka is just write the object, that's it15:24
mriedemlxsli: if that's never soft deleted, how do we ever purge it?15:24
bauwserno further actions15:24
lxslimriedem: huh?15:24
sdaguelxsli: a table drop like that probably should have a reno15:25
mriedemlxsli: see the thread on archive15:25
bauwserI mean, I could do some tyromancy to know if I'm right15:25
bauwserhttp://closetprofessor.blogspot.fr/2011/01/word-of-week-tyromancy.html15:25
mriedemlxsli: for tables that are never soft deleted, what are we doing to allow operators to actually prune those tables?15:25
sdaguemriedem: yeh, I don't think this ever deleted15:25
mriedemright, like instance_actions15:25
mriedemi'm finding out we have more skeletons in the closet than i though15:25
mriedem*thought15:25
lxslimriedem: it's hard-deleted sometimes, I think? I'd have to check to be sure15:26
*** pratikma_ has joined #openstack-nova15:26
*** kfarr has joined #openstack-nova15:26
mriedemdoubtful15:26
mriedemunless there is a task that's purging them after they are so old15:26
sdaguemriedem: there is no delete interface at all from what I can see15:27
sdaguethis is another one that should be a cascade delete from instances15:27
lxslimriedem: is that really my problem though? Today they're not deleted, after my patch they're still not deleted15:27
mriedemlxsli: well,15:27
mriedemas is posed in the ML,15:28
mriedemthe same is true for instance_acitons15:28
mriedemand the questoin is, should we start soft deleting those15:28
mriedemso the same question applies for this table now15:28
*** sneti has quit IRC15:28
mriedembauwser: do you have a link handy to the ML thread where dhellmann talks about integrating reno with each project?15:28
*** ctrath has quit IRC15:28
sdaguemriedem: I actually don't think we should softdelete subresources of instances15:28
*** pratikmallya has quit IRC15:28
sdaguewe should delete them when archiving instances15:29
mriedemsdague: that was one of the options i laid out in the ML15:29
openstackgerritClaudiu Belu proposed openstack/nova: Hyper-V: refines the exceptions raised in the driver  https://review.openstack.org/21210215:29
openstackgerritClaudiu Belu proposed openstack/nova: Hyper-V: adds os-win library  https://review.openstack.org/24772915:29
mriedemand is the easier to implement15:29
sdaguemriedem: yeh, I responded on ML with basically that this morning as well15:29
bauwsermriedem: sure, sec15:29
mriedemah http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html15:30
sdaguemriedem: or, archive them with the instances15:30
mriedemjust found it15:30
bauwsermriedem: http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html15:30
sdagueinstance_actions honestly is probably useful in the archive15:30
bauwserbusted AGAIN15:30
sdaguethis table is definitely not15:30
*** ihrachys has quit IRC15:30
bauwsercome'on !15:30
mriedembauwser: thanks though, i've been looking for it for like 20 minutes15:30
bauwsermriedem: okay, ping me anytime you look for your keys or something like that, it seems my call makes you find it faster15:31
mriedemha15:31
mriedemi don't lose things at home b/c i use a system, like a sane OCD person15:31
*** ihrachys has joined #openstack-nova15:31
mriedemunlike my wife that leaves things where she last used them15:31
mriedemso we have 20 bottles of glass cleaner stashed around the house15:31
*** ctrath has joined #openstack-nova15:31
*** mc_nair has joined #openstack-nova15:32
sdaguemriedem: it's high availability15:32
mriedemit's maddening15:32
*** nikhil has quit IRC15:32
mriedemcostco doesn't help because you can buy glass cleaner in bulk15:32
*** nikhil has joined #openstack-nova15:32
*** thumpba has joined #openstack-nova15:33
*** annegentle has quit IRC15:33
*** alexschm has quit IRC15:33
*** e0ne has joined #openstack-nova15:33
lxslisdague: I'm probably being dumb but I can't see a relation between BandwidthUsage and Instance from looking at db/sqlalchemy/models.py ? Can you explain please?15:33
openstackgerritClaudiu Belu proposed openstack/nova: Hyper-V: removes *Utils modules and unit tests  https://review.openstack.org/21591715:34
mriedemlxsli: there isn't one15:34
lxslimriedem: then how is this class like instance_actions?15:34
mriedemit's just a periodic task that is only enabled for xenserver to poll stats from the hypervisor15:34
*** rcernin has quit IRC15:34
*** tdurakov has quit IRC15:34
mriedemlxsli: in that it's not ever deleted15:34
*** gwei3 has quit IRC15:34
*** thangp has joined #openstack-nova15:35
mriedemlxsli: the bigger picture is we are gd pack rats15:35
mriedemarchive was meant to help with part of that, but we're finding we have other tables that we don't soft delete so archive won't archive them15:35
*** yamahata has joined #openstack-nova15:35
mriedemwhich is also why we have ctrath's purge command work15:35
lxslimriedem: right, so the question is whether removing SoftDeleteMixin should be blocked behind having a purge strategy15:35
sdagueit's looking up by instance mac address, right?15:35
*** hparekh has joined #openstack-nova15:35
mriedembut the purge command only purges soft deleted things15:35
*** nithyag_ has quit IRC15:36
sdaguehttps://github.com/openstack/nova/blob/1734ce7101982dd95f8fab1ab4815bd258a33744/nova/notifications.py#L315-L32715:36
sdaguethe uuid in the table is the instance uuid15:36
garyk1mriedem: https://review.openstack.org/#/c/247705/15:36
mriedemwith no foreign key?15:36
mriedemnice15:36
sdaguemriedem: remember, all the db experts said foreign keys are evil15:37
lxslihmmm... I might add a foreign key and pick an easier class to start with then15:37
*** sneti has joined #openstack-nova15:37
lxslio.O15:37
mriedemsdague: what's more evil is being completely incosistent about using them15:37
sdaguemriedem: sure, I just never understood the fk are evil standpoint myself :)15:37
sdaguemaybe we can throw mordred under a bus on that one again15:37
mordredaroo?15:38
mordredok. fk's are not scalable - and you can't shard vertically when you use db fks15:38
mordredapp level fks are great15:38
sdaguesure, we don't shard vertically anyway15:38
mordredright15:38
*** tdurakov has joined #openstack-nova15:38
mordredbut as people talk abot GIANT SCALE things, one of the ways to alleviate db scaling is by sharding15:39
sdagueapp level fks mean you have to implement cascade delete manually15:39
mordredwhich fks remove as an option15:39
mordredand yes. they do mean that15:39
sdaguemordred: ok, it still seems like very premature scaling optimization15:39
openstackgerritPavel Kholkin proposed openstack/nova: enginefacade: 'migration'  https://review.openstack.org/24349615:40
mordredsdague: we have a rabbitmq in our architecture15:40
mordredsdague: that was a premature scaling optimization15:40
sdaguemordred: sure15:40
mordredand is also a scaling bottleneck15:40
sdaguebut lets not do more of them15:40
mordredright15:40
sdaguebecause this has created an actual operator problem15:40
mordredreally?15:40
sdaguein their db filling up with crap15:40
mriedemsdague: ftr, we don't implement cascading delete automatically in our db schema either :/15:41
sdaguemriedem: I know15:41
sdaguebut a bunch of these would be well served by that15:41
mriedemwe implement pain15:41
mriedemPaaS15:41
mordredwell, it would be served well by something implementing delete15:41
*** ihrachys has quit IRC15:41
mordredthat could be implemented as a FK with cascading delete15:41
mordredor it could just be implemeted at the data model layer15:41
openstackgerritAndrey Kurilin proposed openstack/nova-specs: Update novaclient-api-microversions spec  https://review.openstack.org/21120615:42
openstackgerritAndrey Kurilin proposed openstack/nova-specs: Move novaclient-api-microversions spec to implemented  https://review.openstack.org/24814215:42
mordredwhich, btw, is in python15:42
mordredand given how little everyone around here claims to know sql - I'd recommend locating the logic in python personally15:42
sdagueyes, but now needs to handle all the transaction logic15:42
mordredyeah. "begin transaction. delete tihng. delete second thing. commit"15:42
mordredthat should be a delete method on the data model15:43
*** ihrachys has joined #openstack-nova15:43
sdaguealso lock the table to ensure no new rows show up that could break the constraint15:43
mordrednope15:43
mordredyou do not need to do that15:43
mordredand should not15:43
mordredthe MVCC support in innodb does the right thing quite happily15:44
sdagueif the db has no constraints on it, how do you prevent that coming in on a different worker?15:44
*** mgoddard_ has quit IRC15:44
*** mgoddard has joined #openstack-nova15:44
*** MVenesio has quit IRC15:45
pkholkinjohnthetubaguy, mdbooth: guys, take a look please https://review.openstack.org/#/c/243496/, fixed this patch as an example15:46
mordredoh - sorry - a row being added that references a thing that the transaction is deleting? yeah, you still have to protect for that app side, but you can do it without a table lock15:46
*** ihrachys has quit IRC15:46
pkholkinleave your comments and questions there15:47
mordred(basically, ANY time the words "table lock" are uttered, it's the wrong approach)15:47
*** shaohe_feng1 has joined #openstack-nova15:47
sdaguemordred: sure, but now you have to synchronize across API servers15:47
*** ihrachys has joined #openstack-nova15:47
openstackgerritClaudiu Belu proposed openstack/nova: Converting nova.virt.hyperv to py3  https://review.openstack.org/23255415:47
mordredno you don't15:47
sdaguemordred: ok15:47
sdagueexplain please15:47
mriedemdidn't people talk about DLM at the summit?15:47
mdboothpkholkin: I think you need a decorator15:48
mriedemi heard we're converting to java?15:48
mdboothI was thinking that the new decorator would replace *all* reader decorators15:48
mdboothWhich is why we might be better of fixing it in oslo.db, tbh15:48
sdagueAPI1 starts this transaction, res1 plus subres1,2,3,4 being deleted. API2 gets a request to add subres5 in the middle of it.15:48
mdboothAlthough an expedient fix here would be fine15:48
mordredsdague: you have the add record logic check the referant after the insert, and if it's been invalidated, you delete the record and send back a fail15:48
mordredsdague: in either case it's a thing trying to add a record that references something someone else is trying to delete15:49
sdaguemordred: right15:49
mordredso it's an application logic race condition15:49
mordredand has to be dealt with in either case15:49
mordredin terms of expectations of the consumes15:49
mordredconsumers15:49
sdagueso without the constraint, the delete succeeds, you don't know anything is wrong. If the delete finishes before the insert, you can fail the insert15:50
sdagueif the insert gets in first it looks successufl15:50
*** ihrachys has quit IRC15:50
sdagueso you need to check again on the delete that life is really actually good15:50
sdagueand stop or fail or leak15:51
mdboothAs a general design principal, if a compute host knows it can side-load an image from another compute host, should it do that, or go straight to glance anyway?15:51
mordredyup.15:51
mdboothThat is, both options are open, which is better?15:51
openstackgerritAlexis Lee proposed openstack/nova: Note that BandwidthUsage relates to Instance  https://review.openstack.org/24814615:51
mordredit is more logic in the application15:51
mordredbut the application is already scale out15:51
sdagueI guess I'm just old school and like dbs that you can't fill with crud15:51
mdboothGetting it from glance seems cleaner, but side-loading seems like it scales better.15:51
mordredright15:51
mordredbut that's the old-school oracle/db model where you have a GIANT machine your database is on and there are no apps that will ever exceed the dbs capabilities15:52
sdagueassuming the db is the bottleneck15:52
mordredeverything logic-wise emantes from the db, and in fact stored procedures are used to further put the model layer directly in the db15:52
mriedemsdague: replied to the ML, i'm basically in agreement. we archive instance_actions when archiving instances - it's a yucky side path but it is what it is, it's the right thing to do for postmortems. and i'll push up a spec for making os-instance-actions read deleted instances15:52
*** ihrachys has joined #openstack-nova15:52
*** stevemar_ has joined #openstack-nova15:52
mordredsdague: the DB is always going to be the bottleneck ultimately in any scale out application15:52
sdaguemordred: ok15:53
mordredor, rather, "the persistance layer" - because it's the thing that's constrained by the physics of physical media15:53
pkholkinmdbooth: I think that integration with use_slave should be on nova side, oslo.db doesn't know anything about use_slave15:53
mordredat some point _something_ has to write the data to an actual local and then guarantee that it's there15:53
pkholkincould you please leave comments in the patch15:53
mdboothpkholkin: Yes, I mean sync/async15:53
mdboothpkholkin: Ok15:54
pkholkinor maybe give some your example15:54
mordredthat's the part that mongo played fast and loose with - although they're doing much better with that these days15:54
pkholkinwe will continue working on it15:54
sdaguemordred: sure, it just seems that there are many many many layers of bottlenecks before we get there15:54
sdaguewe seem very focussed on step 3715:54
mordredsure. but it we've designed the application to be scale out (which we have)15:54
mordreddesigning the db interaction to be consistent with that seems non-insane15:55
mordredif we hadn't - if we'd designed this as a more synchornous system without a ton of scale out components15:55
mordredthen I would not beat this drum as often15:55
pkholkinjohnthetubaguy: please look at the updated patch too, thanks!15:55
mordredforeign keys behind vmware vcenter for instance? makes total sense15:55
*** bochi-michael has quit IRC15:55
sdaguemordred: sure, it's just we've introduced actual performance issues in people's environments because of no sane cleanup15:56
mordredyes. I agree. we should have sane cleanup15:56
sdaguebecause after FK were more or less dropped no one followed up with that15:56
mordredwell, yeah. there are many problems at the DB layer15:56
mordredand to be fair - I'm not actually pushing hard on getting rid of them or blocking them15:57
mriedemi hope to have sane cleanup by the end of this release :)15:57
mriedemor die trying15:57
*** rpodolyaka1 has quit IRC15:57
mordredI'm just saying in the corner that they'r enot scalable15:57
sdaguemriedem: ok, so on cleanup, it actually seems like we should probably come up with a way of annotating the models15:57
mordredsometimes to get to where we need to be, taking a step backwards is super useful15:57
mdboothpkholkin: Replied15:57
sdaguebecause some set of them are "archive with instances" and another set are "delete when instances archive"15:57
paul-carlton2sdague: re cancel live migration, not sure I understand what you are suggesting, the os-instance-actions only returns a list of actions on the instance, with no indication of the status and there is no task id, just a req-id15:57
*** e0ne_ has joined #openstack-nova15:57
mdboothI believe the lack of FKs has caused us a great deal of pain.15:58
* mdbooth would prefer to see the code fail at source, so we can fix it.15:58
*** e0ne has quit IRC15:58
*** stevemar_ has quit IRC15:58
mriedemsdague: instance_actions are the former and bw_usage_cache is the latter15:59
sdaguepaul-carlton2: I'm not suggesting anything really about os-instance-actions15:59
sdaguemriedem: right15:59
*** stevemar_ has joined #openstack-nova15:59
sdaguemriedem: which I think are 2 cases the tool needs to handle15:59
mriedemyeah, and will15:59
mriedemarchive and purge15:59
sdagueand once it knows how to do that generically, we can just annotate things15:59
sdagueand hopefully it's not massive gross to make that all come together15:59
*** rcernin has joined #openstack-nova16:00
*** rcernin is now known as rcernin|dinner16:00
mriedemsdague: i have to write the changes to archive first to see how gross it is16:00
pkholkinmdbooth: ok, thank you! will work on it)16:00
*** rpodolyaka1 has joined #openstack-nova16:00
mriedemthen we can iterate and make it generic and nifty16:00
mdboothpkholkin: Does that make sense?16:00
sdaguelike fixed ips16:00
sdaguethat's a purge16:00
*** mgoddard_ has joined #openstack-nova16:01
pkholkinmdbooth: I understand your idea but I don't know if we can do it in oslo.db, will also speak to rpodolyaka16:01
mdboothpkholkin: K16:02
johnthetubaguysdague: your totally right about the url logging thing, hmm, I think I was fundamentally just being a coward with the live-migrate thing, trying to not open this debate, but you are right, it would be better this way.16:02
lxslisdague mriedem: so if we're purging bw_usage_cache, can I remove SoftDeleteMixin from it?16:02
lxsligreat discussion btw, +1 to all that16:03
*** rpodolyaka1 has quit IRC16:03
andrearosalxsli: agree, very intersting discussion16:03
mriedemsdague: we actually don't touch fixed_ips16:03
*** rpodolyaka1 has joined #openstack-nova16:03
mriedemsdague: nova-network creates those on startup16:03
mriedemsdague: if you delete those, upgrade fails16:04
*** mgoddard has quit IRC16:04
mriedemi found that out when writing the db migration that made instances.uuid non-nullable16:04
*** rpodolyaka1 has quit IRC16:04
*** rpodolyaka1 has joined #openstack-nova16:04
sdaguemriedem: oh, right, we just need to make sure that uuid is nulled out16:05
*** ihrachys has quit IRC16:05
mriedemyup16:05
*** rpodolyaka1 has quit IRC16:05
sdaguesorry, I was just looking through model definitions16:05
*** albertom has joined #openstack-nova16:05
mriedemso...do we want to add a fkey on bw_usage_cache? or just know it's a thing that needs to be handled special?16:06
*** rpodolyaka1 has joined #openstack-nova16:06
*** rpodolyaka1 has quit IRC16:06
mriedemi kind of like consistency in the data model...16:06
*** rpodolyaka1 has joined #openstack-nova16:06
mriedemthat could also be a separate ML thread16:06
mriedemccarmack: if you're looking for something to do, i've been meaning to scrub through python-novaclient looking for any python 2.6 compat code that we can remove16:07
*** zenoway has quit IRC16:08
*** rpodolyaka1 has quit IRC16:08
*** hparekh has quit IRC16:10
*** zenoway has joined #openstack-nova16:11
*** ihrachys has joined #openstack-nova16:13
*** rlrossit has quit IRC16:14
*** mhickey has quit IRC16:14
mdboothdanpb ndipanov: Can the libvirt driver have a disk with a backing file which isn't an image? If not, is that ever likely to change?16:14
* mdbooth doesn't want to over-engineer for a situation which will never happen16:15
mdboothThis is a local disk, btw, not a volume16:15
ndipanovmdbooth, what do you mean a backing file which isn't an image?16:15
*** zenoway has quit IRC16:15
*** ccarmack has quit IRC16:15
mdboothSpecifically a local disk which would have to be copied in cold migration with no shared storage16:16
danpbmdbooth: i don't think we ever do that currently16:16
mdboothIs it possible that one of those disks might be an overlay with a backing file which isn't an image?16:16
ndipanovmdbooth, no16:16
*** venkat_p has joined #openstack-nova16:16
mdboothDidn't think so. Can you think of anything which might change that?16:16
*** ctrath has quit IRC16:17
mdboothIt would be convenient of the answer was no :)16:17
ndipanovmdbooth, why would you want to change that16:17
*** venkat_p has quit IRC16:17
mc_nairsahid: can you review https://review.openstack.org/#/c/227851/ when you get a chance16:17
mdboothndipanov: I wouldn't16:17
danpbmdbooth: i cna't imagine us doing that16:17
mdboothCool. That means I can have an optional backing file attribute which is just an image id16:17
mdboothRather than something more complex16:18
*** armax has joined #openstack-nova16:18
*** rlrossit has joined #openstack-nova16:19
*** ihrachys has quit IRC16:20
*** jianghuaw has joined #openstack-nova16:21
*** vageli has joined #openstack-nova16:21
*** otter768 has joined #openstack-nova16:22
mriedemmordred: didn't you have a patch that fixes this typo? https://github.com/openstack/nova/blob/12.0.0/nova/api/openstack/compute/servers.py#L32216:22
mriedems/images/instances/16:22
mordredmriedem: yes16:23
mordredmriedem: I believe it is in recheck hell16:23
mordredmriedem: was approved a month ago16:23
mriedemoh nvm, i'm looking at 12.0.016:24
mriedem:( ignore16:24
mordredmriedem: oh! it landed16:24
mordredhttps://review.openstack.org/#/c/242102/16:24
mriedemhot dog16:24
mriedemATC!16:24
*** ccarmack has joined #openstack-nova16:24
*** ctrath has joined #openstack-nova16:25
mriedemha16:26
mriedemnova list --deleted returns a 50016:26
mriedemnice16:26
ccarmackmriedem:  I'll work on that.  Does it mean we don't support 2.6 anymore?16:26
*** stevemar_ has quit IRC16:26
mriedemccarmack: we're moving to drop support for py26 in libs and clients16:26
mriedemoslo is already dropping it16:26
*** otter768 has quit IRC16:27
ccarmackAre all the projects scrubbing their code?16:27
mriedemi assume so, or should16:27
ccarmackok16:27
mriedemsince most projects rely on oslo and if oslo drops it, then the consuming project can't claim it supports it16:27
*** mdrabe has quit IRC16:27
*** jianghuaw has quit IRC16:27
dimsccarmack : infra is dropping testing nodes for py26, so oslo has stopped testing against py26 and will release versions without 2.7 support next week16:28
dimsright16:28
ccarmackdims: I guess all the users are on 2.716:29
*** jdurgin1 has joined #openstack-nova16:31
*** ihrachys has joined #openstack-nova16:31
*** eharney has quit IRC16:33
dimsy16:33
*** armax has quit IRC16:34
*** mylu has joined #openstack-nova16:34
*** jlanoux has quit IRC16:34
*** ctrath has quit IRC16:34
*** paul-carlton1 has quit IRC16:35
openstackgerritShaoHe Feng proposed openstack/nova-specs: Attach/detach SR-IOV interface  https://review.openstack.org/13991016:35
*** mylu has quit IRC16:38
*** stevemar_ has joined #openstack-nova16:39
openstackgerritBalazs Gibizer proposed openstack/nova: Adds json sample for the versioned notifications  https://review.openstack.org/24816716:41
*** ildikov has quit IRC16:41
*** mdrabe has joined #openstack-nova16:41
mriedemthis is fun https://bugs.launchpad.net/nova/+bug/151838216:41
openstackLaunchpad bug 1518382 in OpenStack Compute (nova) "nova list --deleted fails with a 500 response" [Medium,Triaged]16:41
*** burgerk has quit IRC16:41
*** jlanoux has joined #openstack-nova16:41
openstackgerritAndrey Kurilin proposed openstack/python-novaclient: Drop python 2.6 classifier  https://review.openstack.org/24816816:42
mriedemi think lazy load of the instance flavor is trying to load the instance which is deleted, but it's not using read_deleted='yes'16:42
*** rcernin|dinner is now known as rcernin16:42
*** stevemar_ has quit IRC16:44
*** unicell1 has joined #openstack-nova16:44
*** dims_ has joined #openstack-nova16:44
*** dims has quit IRC16:44
*** mylu has joined #openstack-nova16:44
*** stevemar_ has joined #openstack-nova16:45
johnthetubaguymriedem: we have a --deleted flag, oh my, I forgot about that one16:45
mriedemyup16:45
mriedemremember melwitt schooling superdan about that in YVR?16:45
mriedem:P16:45
superdanI think that was dansmith, not me16:45
mriedemoh right16:45
johnthetubaguyheh16:45
mriedemclark kent16:46
*** unicell has quit IRC16:46
johnthetubaguyI bet loads of people do that do double check the instance got deleted16:46
mriedemthis is the same devstack i was testing arhive on, so i'm not sure yet if that screwed up the db to the point that it's causing this to fail16:47
mriedem*archive16:47
*** mylu has quit IRC16:48
*** mylu has joined #openstack-nova16:48
mriedembut no, i see the issue16:48
*** mylu has quit IRC16:50
*** mylu_ has joined #openstack-nova16:50
*** ihrachys has quit IRC16:51
sahidmc_nair, mriedem done16:52
*** burgerk has joined #openstack-nova16:52
*** Piet has quit IRC16:53
*** sahid has quit IRC16:54
*** kfarr has quit IRC16:55
johnthetubaguymriedem: there is a vague plan to use the doc generation to check our tempest coverage, I hope we get that working16:55
*** shaohe_feng1 has quit IRC16:56
*** ihrachys has joined #openstack-nova16:56
*** ctrath has joined #openstack-nova16:56
openstackgerritAndrew Laski proposed openstack/nova: Add persistence to the RequestSpec object  https://review.openstack.org/21175316:57
*** ssurana has joined #openstack-nova16:57
*** sbezverk has joined #openstack-nova16:57
*** e0ne_ has quit IRC16:58
*** daemontool has quit IRC16:59
*** stevemar_ has quit IRC16:59
*** stevemar_ has joined #openstack-nova17:00
*** chhavi has quit IRC17:00
*** vageli has quit IRC17:00
*** flyingtt has quit IRC17:01
*** nic has joined #openstack-nova17:01
*** daemontool has joined #openstack-nova17:02
*** armax has joined #openstack-nova17:02
*** eharney has joined #openstack-nova17:03
*** stevemar_ has quit IRC17:04
*** tdurakov has quit IRC17:04
*** suro-patz has joined #openstack-nova17:04
*** mgoddard_ has quit IRC17:05
*** mgoddard_ has joined #openstack-nova17:05
*** jlanoux has quit IRC17:05
*** tdurakov has joined #openstack-nova17:06
sbezverkHello, appreciate if somebody from nova could comment if nova still requires a port to have associated IP address, before it can be used by instance.17:06
*** suro-patz has quit IRC17:09
openstackgerritPushkar Umaranikar proposed openstack/nova: Modify VM's updated_at field on volume actions  https://review.openstack.org/24717617:09
*** pratikma_ is now known as pratikmallya17:10
*** ctrath has quit IRC17:13
*** scheuran has quit IRC17:13
*** paul-carlton has joined #openstack-nova17:14
*** ctrath has joined #openstack-nova17:15
*** mylu_ has quit IRC17:16
*** mylu has joined #openstack-nova17:16
*** ildikov has joined #openstack-nova17:16
*** PaulMurray is now known as ptm_away17:16
*** bnemec has quit IRC17:20
*** tdurakov has quit IRC17:23
*** tdurakov has joined #openstack-nova17:23
*** tdurakov has quit IRC17:27
openstackgerritLudovic Beliveau proposed openstack/nova: Update binding:profile for SR-IOV ports  https://review.openstack.org/24257317:29
openstackgerritClaudiu Belu proposed openstack/nova: Hyper-V: adds os-win library  https://review.openstack.org/24772917:29
albertomHi17:29
*** yonglihe has quit IRC17:29
albertomwho is working with wsgi nova-api ?17:29
*** jdurgin1 has quit IRC17:29
albertomwho can take a look at https://bugs.launchpad.net/nova/+bug/150695817:29
openstackLaunchpad bug 1506958 in OpenStack Compute (nova) "TypeError: object.__new__(thread.lock) is not safe, use thread.lock.__new__()" [Undecided,New]17:30
*** bnemec has joined #openstack-nova17:30
*** wuhg has quit IRC17:31
*** tdurakov has joined #openstack-nova17:32
*** ihrachys has quit IRC17:32
*** edtubill has joined #openstack-nova17:32
*** nic has quit IRC17:32
*** nic has joined #openstack-nova17:33
*** claudiub has quit IRC17:33
*** suro-patz has joined #openstack-nova17:33
*** unicell1 has quit IRC17:34
*** sudipto has joined #openstack-nova17:34
*** leseb has joined #openstack-nova17:37
*** tdurakov has quit IRC17:38
*** tdurakov has joined #openstack-nova17:39
*** lucasagomes is now known as lucas-dinner17:39
*** pratikmallya has quit IRC17:41
*** sacharya has joined #openstack-nova17:43
*** devananda has quit IRC17:44
*** devananda has joined #openstack-nova17:45
*** mylu has quit IRC17:46
*** mylu has joined #openstack-nova17:46
*** paul-carlton has quit IRC17:46
*** Piet has joined #openstack-nova17:47
*** stackdump has joined #openstack-nova17:47
*** garyk1 has quit IRC17:50
*** mylu has quit IRC17:51
*** rotbeard has quit IRC17:51
*** zhangjn has quit IRC17:51
*** yamahata has quit IRC17:52
*** tdurakov has quit IRC17:52
*** lykinsbd has quit IRC17:53
*** matrohon has quit IRC17:55
*** RichardRaseley has joined #openstack-nova17:56
*** lykinsbd has joined #openstack-nova17:57
*** ericksonsantos has quit IRC17:58
*** penick has joined #openstack-nova17:58
*** suro-patz has quit IRC17:58
*** josecastroleon has quit IRC17:59
*** mylu has joined #openstack-nova18:00
*** mylu has quit IRC18:01
*** jistr has quit IRC18:01
*** achanda has quit IRC18:01
*** mylu has joined #openstack-nova18:03
*** unicell has joined #openstack-nova18:04
*** daemontool has quit IRC18:05
*** dims has joined #openstack-nova18:05
*** suro-patz has joined #openstack-nova18:06
*** dims_ has quit IRC18:06
*** apoorvad has joined #openstack-nova18:06
*** daemontool has joined #openstack-nova18:07
*** smatzek has quit IRC18:07
*** fawadkhaliq has quit IRC18:07
*** mylu has quit IRC18:09
*** pratikmallya has joined #openstack-nova18:09
*** mylu has joined #openstack-nova18:09
*** aix has quit IRC18:10
openstackgerritZoltan Arnold Nagy proposed openstack/nova-specs: Encryption support for rbd-backed volumes  https://review.openstack.org/23979818:10
superdanman, I'm so stupid18:10
superdanI should never have signed up to do this migration data refactor18:10
*** e0ne has joined #openstack-nova18:11
openstackgerritDan Smith proposed openstack/nova: Add xenapi support for XenapiLiveMigrateData objects  https://review.openstack.org/24785318:11
openstackgerritDan Smith proposed openstack/nova: Make libvirt driver return migrate data objects for source and dest checks  https://review.openstack.org/24772018:11
openstackgerritDan Smith proposed openstack/nova: Add transitional support for migrate data objects to compute manager  https://review.openstack.org/24771918:11
openstackgerritDan Smith proposed openstack/nova: Actually pass the migration data object down to the virt drivers  https://review.openstack.org/24821118:11
*** mylu has quit IRC18:11
*** mylu has joined #openstack-nova18:12
danpbsuperdan: oooh, you da man !  i was wondering if anyone would ever dare tackle that dragon18:13
*** paul-carlton has joined #openstack-nova18:13
superdandanpb: it's going to be the death of me, unfortunately18:13
*** w_verdugo has quit IRC18:13
*** mriedem has quit IRC18:13
*** tdurakov has joined #openstack-nova18:14
*** mylu has quit IRC18:14
*** vilobhmm has joined #openstack-nova18:14
*** mylu has joined #openstack-nova18:15
*** vilobhmm has quit IRC18:15
*** vilobhmm has joined #openstack-nova18:15
*** pratikma_ has joined #openstack-nova18:15
*** klkumar has quit IRC18:15
*** mylu_ has joined #openstack-nova18:17
*** mriedem has joined #openstack-nova18:18
*** mylu has quit IRC18:18
*** pratikmallya has quit IRC18:19
mriedemsuperdan: this shouldn't be true in liberty anymore right? https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L75318:21
mriedemi tried doing this: https://gist.github.com/mriedem/fdf0edfa19632f151f6d18:22
mriedemand got this: https://gist.github.com/mriedem/38a602f0d6bc7d38d6e618:22
mriedemsince the instance context is nulled out18:22
*** e0ne has quit IRC18:22
*** markmc has quit IRC18:22
*** w_verdugo has joined #openstack-nova18:23
*** otter768 has joined #openstack-nova18:23
superdanmriedem: is it reading a deleted instance?18:24
superdanmriedem: we never migrated deleted instances' flavor information18:24
*** markus_z has quit IRC18:24
superdanso if it's deleted I think you'll need to just look up the flavor by id and call it good18:24
mriedemit is reading a deleted instance, yes18:25
*** paul-carlton has quit IRC18:25
mriedemthis is a new devstack, so not an upgrade from kilo18:25
superdanso you hit that if you don't have flavor on the resulting instance, which is intentional to avoid a loop18:25
superdanso you're not getting a flavor on that deleted instance18:26
*** achanda has joined #openstack-nova18:26
superdanI don't remember all the details of what we do, so look and see what its extra record looks like18:26
*** danpb has quit IRC18:27
*** edtubill has quit IRC18:27
*** otter768 has quit IRC18:28
jrollmriedem: that spec review you did for me was useful, no need to apologize. though you could have just said "gimme the details yo"18:28
jrollhard to write specs when you have all the context, end up leaving things out18:29
*** thorst_ has joined #openstack-nova18:29
*** moshele has joined #openstack-nova18:31
*** tdurakov has quit IRC18:32
*** tdurakov has joined #openstack-nova18:33
*** thorst has quit IRC18:33
*** tdurakov has quit IRC18:33
*** vilobhmm has quit IRC18:33
*** e0ne has joined #openstack-nova18:34
*** zhipeng has joined #openstack-nova18:35
*** mgoddard_ has quit IRC18:35
*** mylu_ has quit IRC18:39
*** mylu has joined #openstack-nova18:39
*** edmondsw has joined #openstack-nova18:39
*** vilobhmm has joined #openstack-nova18:41
*** nickchase has joined #openstack-nova18:42
mriedemsuperdan: heh18:42
mriedemmysql> select instance_uuid,flavor,deleted from nova.instance_extra;18:42
mriedemEmpty set (0.00 sec)18:42
superdanI wanna say we delete the extra when we delete the instance18:42
superdanlike actually delete it for reals18:43
mriedemi also ran archive on this before doing this18:43
superdanah18:43
mriedemso that could have removed extra18:43
mriedembut b/c of the fkey issues, the instances are still there18:43
mriedemwill try to recreate w/o archive18:43
superdandude, don't you know? fkeys kill cloud kittens18:43
mriedemwell,18:43
mriedemthey do if you (1) aren't consistent about using them and (2) consistent about soft deleting all things in the fkey chain18:44
mriedemwhich we aren't18:44
superdanthat's not the story I heard18:44
*** jbernard has quit IRC18:44
*** pixelbeat has quit IRC18:45
*** stevemar_ has joined #openstack-nova18:46
*** moshele has quit IRC18:47
*** sbezverk has quit IRC18:47
*** gjayavelu has joined #openstack-nova18:48
*** stevemar_ has quit IRC18:48
*** stevemar_ has joined #openstack-nova18:48
ccarmackmriedem: does removing py26 compat code from python-novaclient also mean removing things like the tox py26 env?18:50
mriedemccarmack: i think so18:51
superdansdague: so I thought the existing multinode job did one live migration test? I don't see it in here: http://logs.openstack.org/20/247720/2/check/gate-grenade-dsvm-multinode/004d380/logs/testr_results.html.gz18:51
ccarmackok18:51
superdanoh wait18:51
superdanmaybe multinode-full?18:51
*** aginwala has joined #openstack-nova18:51
superdanyep, there we go18:52
*** salv-orl_ has joined #openstack-nova18:54
*** e0ne has quit IRC18:57
*** salv-orlando has quit IRC18:57
*** ijw has joined #openstack-nova19:00
zhipenghey do we still have spec review today19:00
mriedemis it just me, or is it dumb that you have to be an admin to list your tenant's deleted instances?19:04
*** ijw has quit IRC19:04
mriedemi understand why all-tenants is admin-only19:04
*** ijw has joined #openstack-nova19:04
mriedembut nova list --deleted should work for non-admins i'd think19:04
*** lpetrut has quit IRC19:06
*** rk4n has quit IRC19:07
*** aginwala has quit IRC19:09
melwittmriedem: all should be policy controllable, in my opinion. and I can't immediately think why a tenant shouldn't be able to see their own deleted instances19:10
mriedemyeah, i guess that's another spec for another time19:11
*** stevemar_ has quit IRC19:13
*** aginwala has joined #openstack-nova19:13
openstackgerritRyan Rossiter proposed openstack/nova: Use ContainerFormat instead of strings  https://review.openstack.org/24583519:13
openstackgerritRyan Rossiter proposed openstack/nova: Add ContainerFormat field  https://review.openstack.org/24583419:13
*** mc_nair has quit IRC19:13
*** mylu has quit IRC19:13
doffmsdague: Is there any way I can help with the live-migration work or is it all under control?19:13
*** pumaranikar has quit IRC19:15
*** stevemar_ has joined #openstack-nova19:16
*** aginwala has quit IRC19:16
*** baoli has quit IRC19:17
*** smatzek has joined #openstack-nova19:18
*** sudipto has quit IRC19:18
*** mylu has joined #openstack-nova19:21
*** jdurgin has quit IRC19:22
*** eglynn has quit IRC19:22
*** aginwala has joined #openstack-nova19:24
*** jdurgin has joined #openstack-nova19:25
*** rlrossit has left #openstack-nova19:28
*** zhipeng has quit IRC19:30
*** liusheng has quit IRC19:30
mriedemi'm not even sure where non-admin is filtered out for nova list --deleted19:30
mriedemthe db api doesn't seem to care19:30
*** gjayavelu has quit IRC19:31
*** liusheng has joined #openstack-nova19:32
melwittmriedem: I think it might be remove_invalid_options in servers.py that strips out the search_opt if context isn't admin19:33
mriedemnope19:33
mriedemfor key in ('sort_key', 'sort_dir', 'limit', 'marker'):19:33
*** sacharya has quit IRC19:34
*** achanda has quit IRC19:34
melwitthm19:35
*** rook0- has quit IRC19:35
mriedemi see it now19:35
mriedemhttps://github.com/openstack/nova/blob/12.0.0/nova/api/openstack/compute/servers.py#L335-L34019:36
mriedemwait, nvm19:37
mriedemthat's only if you're searching on vm_state == 'deleted'19:37
mriedemwhich i'm not19:37
*** lykinsbd has quit IRC19:40
*** yamahata has joined #openstack-nova19:41
*** jdurgin has quit IRC19:41
sdaguesuperdan: grenade does not19:41
sdaguegrenade only runs the smoke target19:41
sdaguewhich is pretty stripped down19:42
mtreinishsdague: we could add an experimental job that does a full tempest run, but I'm not sure it provides much more19:44
*** mc_nair has joined #openstack-nova19:44
sdaguewe have a different full run19:45
*** pumaranikar has joined #openstack-nova19:45
sdagueit's just not passing regularly19:45
mtreinishoh, is the desire just for multinode full I didn't read the backscroll19:45
*** mylu has quit IRC19:46
mtreinishyeah that job exists and doesnt work19:46
mtreinishbecause of the shelve thing right?19:46
*** mylu has joined #openstack-nova19:46
*** zenoway has joined #openstack-nova19:46
*** lykinsbd has joined #openstack-nova19:46
openstackgerritBob Ball proposed openstack/nova: XenAPI: Cope with more Cinder backends  https://review.openstack.org/24478919:47
*** achanda has joined #openstack-nova19:48
superdansdague: oh, I see I was looking at grenade.. unintentionally19:48
superdansdague: the full job shows that I didn't break live migration for that config at least19:49
*** ociuhandu has quit IRC19:49
sdaguesuperdan: \o/19:49
sdagueheh, we landed the liberty backport of the ebtables hack in devstack19:51
*** lykinsbd has quit IRC19:51
*** mylu has quit IRC19:51
sdaguenow we just see kilo fails19:51
*** sacharya has joined #openstack-nova19:51
*** liusheng has quit IRC19:52
*** liusheng has joined #openstack-nova19:52
openstackgerritBob Ball proposed openstack/nova: XenAPI: Workaround for 6.5 iSCSI bug  https://review.openstack.org/23110319:53
superdanxen's live migration path is not very well unit tested, so I'm fairly sure I'm going to break it19:53
superdanbut I have no way to test it, so..19:53
*** lykinsbd has joined #openstack-nova19:55
*** eharney has quit IRC19:57
*** mylu has joined #openstack-nova19:57
*** aginwala has quit IRC19:58
figleafmriedem: it's here: https://github.com/openstack/nova/blob/12.0.0/nova/api/openstack/compute/servers.py#L1114-L112119:58
mriedemfigleaf: yeah, but what does that have to do with 'deleted'?19:58
*** aginwala has joined #openstack-nova19:58
mriedemfigleaf: oh you mean b/c it's NOT in that list19:58
figleafmriedem: yup19:59
mriedemgot it19:59
figleafmriedem: from the log: Removing options 'deleted' from query from (pid=28732) remove_invalid_options /opt/stack/nova/nova/api/openstack/compute/servers.py:117619:59
figleafmriedem: that's when I run 'nova list --deleted' as a regular user20:00
mriedemyup20:00
mriedemeasy fix20:00
mriedemwith a microversion20:00
mriedemi already have a bp filed https://blueprints.launchpad.net/nova/+spec/non-admin-list-deleted-instances20:00
mriedemjust need to find the time to write a spec20:00
*** ctrath has quit IRC20:00
figleafmriedem: I can do it20:00
superdanwe want to further the use of deleted things?20:00
figleafsuperdan: no, but it's already there in the API20:00
superdanI thought we specifically wanted to cut down on and maybe remove it eventually20:01
figleafjust making it work as advertised20:01
superdanfigleaf: yeah, aware20:01
superdanfigleaf: that doesn't mean we have to add a microversion to enable more of it20:01
figleafsuperdan: so maybe a microversion to remove it altogether?20:01
mriedemi've sort of lost track of what are the million hoops we have to jump through to drop soft deleted20:01
mriedembut yeah, removing access to deleted things in the API is a first step20:02
superdanmriedem: it mostly hinges on the api telling the users they can do it20:02
superdanso adding more surface that allows it seems like a bad idea to me20:02
*** mylu has quit IRC20:02
mriedemheh, you won't like this either then https://blueprints.launchpad.net/nova/+spec/os-instance-actions-read-deleted-instances20:02
*** mylu has joined #openstack-nova20:02
*** mylu has joined #openstack-nova20:02
superdanleaving the actions for a longer period than the instance makes sense to me20:03
superdani.e. instance is deleted but the actions are not yet deleted, that's fine20:03
mriedemwell, ^ is for allowing os-instance-actions to read deleted instances20:04
mriedemsince that seems useful20:04
*** signed8bit is now known as signed8bit_ZZZzz20:04
superdanwell, I'm not sure why we need to read deleted instances to read deleted actions20:04
superdanmaybe an implementation detail/requirement20:04
superdananyway20:04
mriedemthese aren't deleted actions20:05
mriedemb/c we don't soft delete actions20:05
superdanI know20:05
mriedemso this is postmortem on the deleted instance20:05
superdansorry, I meant actions for deleted instances, not deleted actions themselves20:05
superdanright20:05
*** mylu has quit IRC20:05
*** mylu has joined #openstack-nova20:07
mriedemso you disagree with that bp?20:07
superdanI think that bp is saying we need to read (soft) deleted instances in order to show actions for them right?20:07
mriedemyes20:08
*** burgerk has quit IRC20:08
superdanand I'm saying I don't see why that is, unless there is some mechanical reason that is hard to get rid of20:08
superdani.e. if I have the instance uuid, we should be able to look up actions for that uuid,20:08
melwittit's a bit silly, the api does an instance lookup by uuid, passes the instance object to the actions api where the actions api passes only the uuid. the instance object isn't actually needed and doesn't need to be looked up20:08
superdanor if I want to see changes-since actions for my tenant, we should be able to do that20:08
mriedemsuperdan: os-instance-actions takes the instance uuid20:09
superdanmelwitt: right, my point20:09
mriedemto look up the actions20:09
*** ctrath has joined #openstack-nova20:09
superdanmriedem: uuid is fine, but we shouldn't need to actually have to locate the whole instance, I think20:09
mriedemyeah, i see where you're going now20:10
mriedemjust do the db query20:10
superdanyar20:10
superdannow, we might have to store something else like project_id with the action or something,20:10
superdanbut I'd rather make the BP about that than reading more deleted instance data20:10
*** smurke has joined #openstack-nova20:11
superdanwe'll also have the instance map table in the api,20:11
superdanwhich could give us our security check,20:11
superdanbut I don't know what the plans are for purging that on instance delte20:11
superdaner, delete20:11
superdanso maybe it's better to just store project with the actions, I dunno20:11
mriedemi think that's already stored20:11
superdanwell then it should be "easy"20:12
superdanSMOP20:12
mriedemhttps://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L124820:12
*** signed8bit_ZZZzz is now known as signed8bit20:12
superdanperfect20:12
superdanI'm going to go get lunch now20:14
superdanjust thought everyone should know that20:15
*** smurke_ has joined #openstack-nova20:15
melwittI was thinking some more about why not let non-admin list deleted instances and if they're "using the cloud" and creating/deleting a lot, every user could have potentially 100+ deleted instances and listing them could get unwieldy on the api load20:15
mriedemmelwitt: you could using paging, but yeah..20:17
mriedemi think i'm giving up on that one20:17
mriedemgiven the gauntlet that was thrown down in YVR20:17
mriedemi guess we should put that in our devref somewhere that says, as a policy, we don't want more API changes to read deleted resources20:17
*** ctrath has quit IRC20:18
figleafmriedem: if you're going to do that, it seems that it should be coupled with a policy that says deleted stuff hanging around is going to go away20:19
mriedemfigleaf: but we don't really have consensus on what that's going to be20:19
*** thumpba has quit IRC20:20
*** apoorvad has quit IRC20:21
figleafmriedem: is there such consensus on not fixing broken APIs if they deal with deleted instances?20:21
*** vilobhmm has quit IRC20:21
*** vilobhmm has joined #openstack-nova20:22
BobBallsuperdan: I can test the live migration for xen :) This for the XenapiLiveMigrateData change?20:22
*** thumpba has joined #openstack-nova20:22
*** dims has quit IRC20:23
*** otter768 has joined #openstack-nova20:24
*** thangp has quit IRC20:26
mriedemfigleaf: not sure i'm following, but before we could get rid of soft delete we'd have to disable reading deleted instances in the db20:26
mriedembut i'm not sure how we can really do that with just a microversion20:26
mriedemsince if we drop the deleted column in the db, the api microversion don't get a rat's ass20:27
mriedems/get/give/20:27
figleafmriedem: I meant fixing 'nova list --deleted'20:27
mriedemfigleaf: i guess it's a won't fix20:28
figleafmriedem: and yeah, removing the deleted column means that at the very least, --deleted will be toast20:28
figleafmriedem: ok. I was just asking if there already was consensus on doing this20:28
*** otter768 has quit IRC20:28
mriedemwhich i guess gets us back to i don't know how we drop the deleted column20:29
mriedemsince that would seem to be a backward incompatible change that affects the API20:29
mriedemregardless of microversion20:29
mtreinishmriedem: you could add a config opt and have it write all the deleted instances to a new table. So if you want to preserve the old api20:30
mtreinishnot sure that really helps though20:30
*** thumpba_ has joined #openstack-nova20:31
mriedemthat wouldn't really be 'def coreable'20:31
mriedembad UX20:31
mtreinishdo you want it to be def coreable?20:31
mtreinishlike you don't need to include a test that lists deleted instances20:32
mtreinishand if you microversion against adding the option newer versions dont even acknowlege it as a thing20:32
*** rpodolyaka1 has joined #openstack-nova20:32
*** thumpba has quit IRC20:33
mriedemyeah20:33
mriedemso it's not great20:33
mriedemanyway, have to run out for awhile20:33
mriedembbl20:33
mriedemwhat i want is for my 2016 health care elections website to work20:33
*** mriedem has quit IRC20:33
*** eharney has joined #openstack-nova20:36
*** tdurakov has joined #openstack-nova20:37
*** artom has quit IRC20:38
*** aginwala has quit IRC20:40
*** yassine__ has quit IRC20:42
openstackgerritSamuel Matzek proposed openstack/nova: Reschedule boot when attach volume fails  https://review.openstack.org/24650520:46
*** aginwala has joined #openstack-nova20:47
*** dane-fichter has quit IRC20:49
*** thumpba_ has quit IRC20:50
*** jdurgin has joined #openstack-nova20:52
*** achanda has quit IRC20:53
*** achanda has joined #openstack-nova20:56
superdanBobBall: yes and cool :)20:58
superdanBobBall: not worth doing it just yet though20:58
superdanstill working through those20:58
*** openstackstatus has quit IRC21:02
*** openstack has joined #openstack-nova21:04
*** pratikm__ has joined #openstack-nova21:05
*** pratikma_ has quit IRC21:05
*** ijw has joined #openstack-nova21:06
*** rpodolyaka1 has quit IRC21:06
openstackgerritBrian Rosmaita proposed openstack/nova-specs: Consistent Instance Actions  https://review.openstack.org/24824821:07
*** tdurakov has quit IRC21:07
*** mylu has quit IRC21:07
*** mylu has joined #openstack-nova21:07
*** pratikmallya has quit IRC21:08
*** jianghuaw has joined #openstack-nova21:09
*** tdurakov has joined #openstack-nova21:10
bauwseralaski: around?21:11
bauwseralaski: trying to see why http://logs.openstack.org/53/211753/35/check/gate-nova-tox-functional/2fddd1f/console.html#_2015-11-20_17_28_37_751 doesn't work21:11
*** mylu has quit IRC21:11
*** jianghuaw has quit IRC21:14
*** marcusvrn_ has quit IRC21:15
tpeoplesmelwitt: do you want me to respin for your comment on https://review.openstack.org/#/c/220634/ ?21:16
*** sfinucan has joined #openstack-nova21:17
*** daemontool has quit IRC21:19
*** daemontool has joined #openstack-nova21:19
openstackgerritBrian Rosmaita proposed openstack/nova-specs: Consistent Instance Actions  https://review.openstack.org/24824821:20
*** ociuhandu has joined #openstack-nova21:20
*** apoorvad has joined #openstack-nova21:21
*** mylu has joined #openstack-nova21:25
*** apoorvad has quit IRC21:27
*** gszasz has quit IRC21:30
*** jbernard has joined #openstack-nova21:31
*** stevemar_ has quit IRC21:31
*** thorst_ has quit IRC21:31
*** smatzek has quit IRC21:31
*** mylu has quit IRC21:31
*** mylu has joined #openstack-nova21:32
*** mylu_ has joined #openstack-nova21:33
*** mylu has quit IRC21:33
*** vladikr has quit IRC21:33
*** vilobhmm has quit IRC21:40
*** vilobhmm has joined #openstack-nova21:41
*** RichardRaseley has quit IRC21:41
*** ijw has quit IRC21:42
*** mriedem has joined #openstack-nova21:46
openstackgerritStephen Finucane proposed openstack/nova-specs: Rework policies for virt-driver CPU thread pinning  https://review.openstack.org/24419821:49
*** rcernin has quit IRC21:50
mriedemdid everyone get everything figured out in the last hour?21:52
mriedemre: deleting things and reading them?21:52
*** lykinsbd has quit IRC21:52
melwitttpeoples: no need to respin IMO, I just mentioned it since I noticed it21:53
*** penick has quit IRC21:56
sfinucanHappy Friday. Is there anyone I can poke to get another +2 on Nikola's bugfixes? https://bugs.launchpad.net/nova/+bug/1250066 They're blocking my rework :(21:58
openstackLaunchpad bug 1250066 in OpenStack Compute (nova) "Need change instance's property updated_at when attach/detach volume" [Low,In progress] - Assigned to Pushkar Umaranikar (pushkar-umaranikar)21:58
openstackgerritEd Leafe proposed openstack/nova: WIP: Add better help text to scheduler options  https://review.openstack.org/24718121:59
openstackgerritEd Leafe proposed openstack/nova: Config options: centralize section "scheduler"  https://review.openstack.org/24589121:59
*** pradk has quit IRC22:02
*** dave-mccowan has quit IRC22:03
*** mylu_ has quit IRC22:05
*** mylu has joined #openstack-nova22:05
*** tdurakov has quit IRC22:06
*** ZZelle_ has joined #openstack-nova22:07
*** mylu_ has joined #openstack-nova22:07
*** mylu has quit IRC22:07
*** richm has left #openstack-nova22:11
mriedemsuperdan: on that instance actions API change, it does look up the instance to use that for policy auth, i'm not sure what removing that does22:11
mriedemwe'd just be authorizing by the context i think22:11
*** ijw has joined #openstack-nova22:12
openstackgerritBrian Rosmaita proposed openstack/nova-specs: Lightweight Nova Service Profiling  https://review.openstack.org/24761622:12
*** pumaranikar has quit IRC22:13
openstackgerritStephen Finucane proposed openstack/nova: Add 'hw_cpu_threads_policy' to ImageMetaProps  https://review.openstack.org/20264722:13
openstackgerritStephen Finucane proposed openstack/nova: Add 'cpu_policy' and 'cpu_threads_policy' fields  https://review.openstack.org/20264822:13
openstackgerritStephen Finucane proposed openstack/nova: Add 'hw:cpu_threads_policy=avoid' filtering  https://review.openstack.org/20264922:13
openstackgerritStephen Finucane proposed openstack/nova: trivial: Add some logs to 'numa_topology_filter'  https://review.openstack.org/20265022:13
openstackgerritStephen Finucane proposed openstack/nova: Add 'hw:cpu_threads_policy=require' scheduling  https://review.openstack.org/20265122:13
*** aginwala has quit IRC22:14
*** vilobhmm has quit IRC22:15
*** vilobhmm has joined #openstack-nova22:15
*** aginwala has joined #openstack-nova22:16
*** smurke has quit IRC22:17
*** bauwser is now known as bauzas22:17
*** smurke_ has quit IRC22:18
*** edtubill has joined #openstack-nova22:18
*** yamahata has quit IRC22:18
melwittmriedem: hm, it might be trying to make sure you're an instance owner or admin in order to authorize22:19
mriedemyeah i have to assume that's what it's doing, i'm having a hard time tracing down how the instance target is used in the policy rules enforcement22:20
openstackgerritStephen Finucane proposed openstack/nova: test_fields: Remove all 'Enum' subclass tests  https://review.openstack.org/24437222:20
mriedemso the default policy is: "os_compute_api:os-instance-actions": "",22:21
mriedemwhich i guess defaults to rule:admin_or_owner ?22:22
melwittI think so22:22
bauzasno, anyone22:23
bauzasoh sec22:23
bauzasno22:23
bauzashttps://github.com/openstack/nova/blob/master/etc/nova/policy.json#L422:23
mriedemso if user A in project A knows about an instance uuid for user B project B, if we remove that policy check then user A could get the instance actions for the instance in project B ?22:23
mriedemreferring to this https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/instance_actions.py#L5722:24
mriedembut,22:24
bauzasit does the lookup here https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L322:24
mriedemif we just change that code to lookup the instance action by instance uuid and the project_id from the context, that would handle it, right?22:25
*** otter768 has joined #openstack-nova22:25
*** doug-fish has quit IRC22:25
mriedemif we do ^,22:25
bauzasmriedem: sec22:26
mriedemthen if project A is looking up project B's instance uuid, it wouldn't find it22:26
mriedemand we return 40422:26
bauzasI have to remember the oslo.policy code22:26
melwittyeah, I'm confused about who the "owner" of a set of instance actions is, from an instance actions records perspective22:27
melwittthe current code is checking ownership of the instance itself (we assume)22:27
*** stackdump has quit IRC22:29
*** ijw has quit IRC22:29
*** otter768 has quit IRC22:30
melwittmriedem: if you do the lookup that way you would miss actions that were initiated by admin (or some other tenant), I think22:30
bauzasso yeah the target is where we verify against the project_id22:31
*** RichardRaseley has joined #openstack-nova22:31
mriedemmelwitt: so like a tenant user looking up instance actions performed on their instance but done by the admin?22:31
melwittmriedem: yeah, I'm thinking the way it currently is, it policy auths that you're the owner or an admin, and then you get to see all actions on that instance, no matter what tenant did them22:32
mriedembauzas: yeah so in the case of target=instance thta's the project_id on the instance22:32
*** yamahata has joined #openstack-nova22:32
bauzascorrect, that's what I verified in oslo.policy22:32
melwittif for example admin rebooted your instance at some point, you would see that22:32
mriedemyeah22:33
mriedemso....22:33
mriedemwe have to do the instance lookup22:33
melwittyeah. there's a reason it does that :(22:33
bauzasindeed22:33
mriedemalright, well, that still makes for an even easier spec22:33
bauzasmriedem: I answered to that thread by saying that looking up at an known uuid is already a good thing22:34
*** thorst has joined #openstack-nova22:34
mriedemyup saw that22:34
mriedemi was just looking into this policy auth thing before starting on the spec22:35
bauzaswe could tho imagine a separate policy for getting any action22:35
bauzasbut it would be an admin one22:35
mriedemso if context.is_admin(): bypass looking up the instance for auth and just get all actions for that instance uuid22:36
mriedem?22:36
melwittI was trying to think if there's a way we could effectively pass read_deleted for just the instance_actions lookup call22:37
bauzasmriedem: if we use https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L92 then it only checks the context, yes22:38
*** thorst has quit IRC22:39
bauzasmriedem: and we could leave an empty target IIRC22:39
bauzassec, verifying22:39
mriedemmelwitt: i was just thinking this https://gist.github.com/mriedem/891cc00c528e7ba2d99b22:39
mriedemcrap, well, around the instance_get actually22:40
melwittmriedem: I didn't think you could need it there, the instance_actions aren't the thing that's deleted. right?22:40
mriedemright22:40
mriedemmutate around common.get_instance22:40
melwittyeah, that's a lot simpler than I was thinking it would be22:41
mriedemso https://gist.github.com/mriedem/ab9cdde3d7e3f091111222:41
bauzasmriedem: so, confirmed, if we have an admin policy, we can just authorize(context)22:42
melwittmriedem: yeah, I thought that would be an easy way to solve it. not expose read deleted everywhere, but only for these instance_actions auth22:43
*** thorst has joined #openstack-nova22:43
*** jwcroppe has quit IRC22:44
melwittbeing that I think the instance owner policy enforcement here does make sense now that we've talked about it22:44
bauzasmriedem: lol, I missed your consensus with sdague, so I don't want again to say YUUUUUP22:44
bauzasI mean in the ML22:45
bauzasbut ack22:45
mriedemmelwitt: yeah22:46
bauzasheh sec22:47
bauzasmriedem: melwitt: https://github.com/openstack/nova/blob/master/nova/api/openstack/extensions.py#L347-L34922:47
bauzasI remember now22:48
bauzasby default we take the project_id from the user context22:48
*** thorst has quit IRC22:48
*** junjie has quit IRC22:48
*** betherly has quit IRC22:49
*** kgalanov has quit IRC22:49
*** tpeoples has quit IRC22:49
mriedemyup22:49
mriedemwhich is pretty much how we auth everywhere22:49
mriedemthere are very few authorize(context, target=foo) APIs22:50
melwittyeah. this thing actually setting the target was something I hadn't seen before22:50
*** auggy has quit IRC22:50
bauzasIIUC, that only makes sure that we have a project_id in the context22:51
*** josh6627 is now known as jhesketh22:51
*** sneti has quit IRC22:51
*** mc_nair has quit IRC22:52
*** krtaylor has quit IRC22:55
*** aginwala has quit IRC22:56
*** signed8bit is now known as signed8bit_ZZZzz22:57
*** mdrabe has quit IRC22:58
*** ijuwang has quit IRC22:58
*** burt has quit IRC22:59
bauzasmriedem: melwitt: yeah, correct, it's for checking %(project_id)s % target == project_id22:59
bauzashttps://github.com/openstack/oslo.policy/blob/master/oslo_policy/_checks.py#L33223:00
* bauzas goes in weekend23:02
*** stevemar has joined #openstack-nova23:02
*** xyang1 has quit IRC23:03
*** stevemar_ has joined #openstack-nova23:04
*** stevemar_ has quit IRC23:04
*** stackdump has joined #openstack-nova23:05
openstackgerritStephen Finucane proposed openstack/nova: Rework 'limited' and 'get_limit_and_marker'  https://review.openstack.org/24136123:07
*** krtaylor has joined #openstack-nova23:08
*** stackdump has quit IRC23:09
*** aginwala has joined #openstack-nova23:09
*** mrkz has quit IRC23:10
*** pratikmallya has joined #openstack-nova23:11
*** jhesketh has quit IRC23:13
*** pratikm__ has quit IRC23:14
*** betherly has joined #openstack-nova23:14
*** jwcroppe has joined #openstack-nova23:14
*** jhesketh has joined #openstack-nova23:15
*** rk4n has joined #openstack-nova23:15
*** pratikmallya has quit IRC23:19
*** edtubill has quit IRC23:19
*** vilobhmm has quit IRC23:22
*** vilobhmm has joined #openstack-nova23:22
*** changbl has quit IRC23:23
*** jwcroppe has quit IRC23:23
*** aginwala has quit IRC23:24
*** changbl has joined #openstack-nova23:27
*** kgalanov has joined #openstack-nova23:28
*** liusheng has quit IRC23:28
*** liusheng has joined #openstack-nova23:29
*** alejandrito has quit IRC23:29
*** vilobhmm has quit IRC23:31
*** vilobhmm has joined #openstack-nova23:31
*** changbl has quit IRC23:33
openstackgerritMatt Riedemann proposed openstack/nova-specs: Make os-instance-actions read deleted instances  https://review.openstack.org/24828823:34
*** markvoelker has quit IRC23:34
openstackgerritStephen Finucane proposed openstack/nova: Add 'hw_cpu_threads_policy' to ImageMetaProps  https://review.openstack.org/20264723:38
openstackgerritStephen Finucane proposed openstack/nova: Add 'cpu_policy' and 'cpu_threads_policy' fields  https://review.openstack.org/20264823:38
openstackgerritStephen Finucane proposed openstack/nova: Add 'hw:cpu_threads_policy=avoid' filtering  https://review.openstack.org/20264923:38
openstackgerritStephen Finucane proposed openstack/nova: trivial: Add some logs to 'numa_topology_filter'  https://review.openstack.org/20265023:38
openstackgerritStephen Finucane proposed openstack/nova: Add 'hw:cpu_threads_policy=require' scheduling  https://review.openstack.org/20265123:38
*** jwcroppe has joined #openstack-nova23:39
*** pixelbeat has joined #openstack-nova23:40
*** mylu_ has quit IRC23:43
openstackgerritLianhao Lu proposed openstack/nova-specs: Need a way to list compute node metric names  https://review.openstack.org/18004923:44
*** sfinucan has quit IRC23:44
*** vilobhmm has quit IRC23:46
*** vilobhmm has joined #openstack-nova23:46
*** aginwala has joined #openstack-nova23:49
*** ZZelle_ has quit IRC23:50
*** liusheng has quit IRC23:50
*** liusheng has joined #openstack-nova23:51
*** rk4n has quit IRC23:53
openstackgerritLianhao Lu proposed openstack/nova-specs: Need a way to list compute node metric names  https://review.openstack.org/18004923:56

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