| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-30 | |||
| 06:30:15 | hariii2503 | nova.servers.list() | |
| 06:30:28 | hariii2503 | Please help me in this | |
| 06:30:37 | hariii2503 | openstack version is stein | |
| 07:45:47 | openstackgerrit | Victor Coutellier proposed openstack/nova-specs master: Non-admin user can filter their instances by AZs https://review.opendev.org/701763 | |
| 08:04:22 | openstackgerrit | Victor Coutellier proposed openstack/nova-specs master: Non-admin user can filter their instances by AZs https://review.opendev.org/701763 | |
| 09:54:50 | openstackgerrit | Victor Coutellier proposed openstack/nova-specs master: Non-Admin user can filter their instances by more filters https://review.opendev.org/701763 | |
| 10:05:11 | stephenfin | bauzas: Could you hit https://review.opendev.org/#/c/695380/ ? | |
| 10:05:47 | stephenfin | Appears to be the only remaining issue we have for the py3 goal | |
| 10:51:24 | jawad_axd | Hi all ! Question is, from instances, download/upload speed is around 10MB/s while from underlying host is 80MB/s. How can I increase/tune bandwidth parameters? I am using Stein,linux bridge,vxlans setup.Any pointers? | |
| 11:22:04 | donnyd | @jawad_axd you need to look for your bottleneck. Download speeds can depend on a lot of different things | |
| 11:22:56 | donnyd | maybe start with some simple iperf testing in and out of the tenant space. | |
| 11:23:29 | donnyd | What are you using for a storage backend on your instances - that is the second place i would look | |
| 11:24:44 | donnyd | maybe also try some fio disk benchmarking to ensure your instances can write to disk at faster than 10MB/s | |
| 11:29:32 | jawad_axd | @donnyd I am using ceph as storage backend. | |
| 11:30:01 | donnyd | I would start with a disk benchmark then | |
| 11:30:46 | jawad_axd | Okay..thats good pointer. I will look into it. Thanks | |
| 11:30:59 | donnyd | also maybe reachout to #openstack-operators | |
| 11:31:19 | jawad_axd | Sure. | |
| 11:31:49 | donnyd | that is where all the operators hang out and you may get to an end a little sooner there | |
| 11:32:12 | donnyd | np @jawad_axd | |
| 11:57:57 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: Fix volume attachment rollback https://review.opendev.org/704847 | |
| 12:09:56 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Re-propose the flavor extra spec validation spec https://review.opendev.org/682655 | |
| 12:19:52 | openstackgerrit | sean mooney proposed openstack/os-vif master: [OVS] VLAN tag should be set in the Port register https://review.opendev.org/703373 | |
| 12:32:46 | gibi | stephenfin: there are two additional places that uses USE_PYTHON3 in our tree. Can we get rid of those as well now? https://review.opendev.org/#/c/695380 | |
| 12:35:03 | sean-k-mooney | gibi: you mean in the legacy jobs | |
| 12:35:53 | sean-k-mooney | gibi: we could remove them there at this point too however i htink we might need to keep it for grenade | |
| 12:36:35 | gibi | sean-k-mooney: do we have grenade job where the from state is py27 and the dest state is py36? | |
| 12:36:45 | sean-k-mooney | no | |
| 12:36:51 | sean-k-mooney | at least not intentionally | |
| 12:37:05 | sean-k-mooney | we are having issue related to that however | |
| 12:37:32 | sean-k-mooney | specificly because on train devstack install under py2 and py3 on train when you enable py3 | |
| 12:37:52 | gibi | I see. | |
| 12:38:07 | gibi | my knowledge is limited here so I follow your lead | |
| 12:38:10 | sean-k-mooney | and that causees issues with osc and other console script still being the python 2 version in the py3 only ussuri | |
| 12:38:52 | sean-k-mooney | gibi: i belive its still one of the issue tosky is trying to fix in the new zuul v3 native grenade job to get plugins to work | |
| 12:39:11 | gibi | sean-k-mooney: OK, thanks | |
| 12:39:19 | gibi | stephenfin: +A-d https://review.opendev.org/#/c/695380/ | |
| 12:40:00 | sean-k-mooney | gibi: did you have a chance to review the numa proposal following the conversation efried and i had yesterday | |
| 12:40:28 | stephenfin | gibi: Thanks. Looks like sean-k-mooney addressed your earlier question :) | |
| 12:40:53 | sean-k-mooney | stephenfin: acully ^ goes for you and bauzas | |
| 12:42:11 | stephenfin | I saw the etherpad, yup. LGTM | |
| 12:42:22 | sean-k-mooney | stephenfin: bauzas gibi https://review.opendev.org/#/c/552924/15/specs/ussuri/approved/numa-topology-with-rps.rst@126 is the main comment. | |
| 12:43:30 | sean-k-mooney | stephenfin: cool | |
| 12:43:35 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Re-propose the flavor extra spec validation spec https://review.opendev.org/682655 | |
| 12:43:48 | sean-k-mooney | hehe i was just reviewing that | |
| 12:43:57 | sean-k-mooney | although its small so ill start again | |
| 12:45:52 | gibi | sean-k-mooney: I read the scrollback but did not read the etherpad and the review yet. stay tuned | |
| 12:46:08 | sean-k-mooney | will do | |
| 12:46:31 | sean-k-mooney | the etherpad has a diagram which hopefully makes the design clear | |
| 12:46:54 | sean-k-mooney | when it comes to placement pictures help a lot | |
| 12:47:36 | gibi | totally agree ^^ | |
| 12:55:45 | sean-k-mooney | stephenfin: im happy with the latest version of the extra spec validation | |
| 12:58:52 | gibi | stephenfin: I have one, hopefully the last question in https://review.opendev.org/#/c/682655/5/specs/ussuri/approved/flavor-extra-spec-validators.rst@152 | |
| 13:02:30 | openstackgerrit | Merged openstack/nova-specs master: Non-Admin user can filter their instances by more filters https://review.opendev.org/701763 | |
| 13:03:02 | stephenfin | gibi: replied | |
| 13:06:31 | sean-k-mooney | stephenfin: if you are storing the validator in a dict you could use set_defautl to get the right behavior | |
| 13:06:42 | sean-k-mooney | depending on how you are doing the lookup | |
| 13:06:52 | stephenfin | set_default? | |
| 13:07:10 | sean-k-mooney | on a dict set default only sets the value if the key is not already present | |
| 13:07:44 | stephenfin | oh, I was going to hard fail if it was there | |
| 13:07:54 | sean-k-mooney | so if you regeister all the intree ones first by namespace and then the out of tree ones the intree would win | |
| 13:07:54 | stephenfin | rather than ignore it | |
| 13:08:18 | sean-k-mooney | ya thats an option | |
| 13:08:36 | sean-k-mooney | but i have found that if you try to block peole doing things they will find a way to work around it | |
| 13:08:44 | sean-k-mooney | like with os-vif | |
| 13:09:16 | sean-k-mooney | we blocked people form importing our internal module by requireing the plugins to start with os_vif to only support intree plugins | |
| 13:09:41 | sean-k-mooney | so a vendor that will go unnamed renamed there plugin to be able to import them | |
| 13:10:02 | stephenfin | \o/ | |
| 13:12:24 | kashyap | Stable folks, am I correct in assuming that this is a "feature" and not a likely backport candidate for Train? -- https://opendev.org/openstack/nova/commit/de512f2c02 | |
| 13:12:29 | gibi | stephenfin: thank. I'm +2 on the extra spec validation again | |
| 13:12:37 | kashyap | It's a small, non-invasive change, though | |
| 13:13:11 | sean-k-mooney | kashyap changing default ya i think that is not a backport candiate | |
| 13:13:13 | stephenfin | kashyap: not stable-core, but the change in behaviour of the extra spec suggests to me it's not backportable, no | |
| 13:13:19 | stephenfin | jinx | |
| 13:13:24 | sean-k-mooney | :) | |
| 13:13:36 | stephenfin | gimme my coke, damn it | |
| 13:13:42 | lyarwood | yup, I wouldn't describe it as non-invasive tbh | |
| 13:13:52 | kashyap | stephenfin: sean-k-mooney: Yeah, guessed as much | |
| 13:13:55 | sean-k-mooney | kashyap: also i missed that merging congrats its nice to have that done | |
| 13:14:08 | sean-k-mooney | kashyap: i also would not really like to backport that downstream | |
| 13:14:09 | kashyap | lyarwood: Yeah, I was a "broad" def of "non-invasive" (db changes, etc) | |
| 13:14:24 | kashyap | sean-k-mooney: I won't. Just wondering, in case people come knocking | |
| 13:14:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643 | |
| 13:14:37 | sean-k-mooney | kashyap: we could maybe add it to 16 since that is not released yet | |
| 13:14:58 | sean-k-mooney | but ya i think that will have to wait to 17 | |
| 13:15:18 | stephenfin | don't bother reviewing that ^ I've still a lot to do | |
| 13:15:54 | sean-k-mooney | stephenfin: by the way you dont need to my "we shoudl really move this" comments | |
| 13:16:06 | stephenfin | eh, it's good to note for the future | |
| 13:16:22 | sean-k-mooney | we shoudl totally rename/move them at somepoint but ya not related to your work | |
| 13:17:36 | stephenfin | efried: When you're about, if you'd care to provide docs for these (or point me to someone that could) I'd be most grateful https://review.opendev.org/#/c/704643/3/nova/api/validation/extra_specs/powervm.py | |
| 13:18:42 | tosky | sean-k-mooney, gibi: we don't have jobs which starts from py27 and ends with py3*; the patch which backports the "don't install python2 library packages" has been backported to train a few hours ago, so grenade jobs should be fine for a final review (and merge) now | |
| 13:18:51 | gibi | sean-k-mooney, efried: I like the numa modeling proposal. thanks for crafting it | |
| 13:19:09 | gibi | tosky: ack, thanks | |
| 13:20:29 | tosky | gibi: afaik (gmann can provide a better answer), we don't support at all that py2->py3 scenario; if you want to test the train->master migration, just deploy train with py3 | |
| 13:20:30 | sean-k-mooney | tosky: awsome | |
| 13:21:00 | sean-k-mooney | tosky: that more because we dont have a good way of cleaning the packages | |
| 13:21:27 | gmann | yeah and do not have someone to do that | |
| 13:22:42 | sean-k-mooney | well we are also not sure if there could in be a difference in the rpc traffic somehow | |
| 13:23:11 | sean-k-mooney | we dont think there will be but that was one of the worries. e.g. the ovo we send over amqp could some how be incompatiable | |
| 13:23:27 | sean-k-mooney | i dont think that is the case but i know it was raised in the past | |