Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-30
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 stephenfin rather than ignore it
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: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 sean-k-mooney kashyap: we could maybe add it to 16 since that is not released yet
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: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
13:24:33 sean-k-mooney no one has reported upgrade issues at least so its untested in the gate but appears to work in reality
13:26:14 gmann yeah, other integration py2 job on train or older release along with py3 jobs can tell both py version works well and should not be issue on upgrade with py2 version too. but yes it is not tested on gate.

Earlier   Later