Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-13
14:14:18 mriedem lyarwood: you see me doing that on yours right?
14:14:30 lyarwood mriedem: right, just checking.
14:14:45 mriedem i think it's ok for clean backports on clear bug fixes
14:15:15 lyarwood yeah agreed, I still feel slightly uneasy about it sometimes but this example is simple etc.
14:15:24 mriedem if it's something like stephen's series here https://review.openstack.org/#/c/588570/ then that's a different story
14:15:58 lyarwood stephenfin: ^ I was going to ask if you wanted to drop this btw
14:16:16 mriedem with extended maintenance it's less bad if we screw up on stable b/c we have time to fix it,
14:16:16 stephenfin lyarwood: Oh, yeah. I'll abandon that now
14:16:29 lyarwood stephenfin: thanks
14:16:31 mriedem plus we just have fewer people reviewing stable and i hate to let fixes sit for months
14:16:48 lyarwood yup indeed, cool that's clear now thanks.
14:26:14 stephenfin sean-k-mooney: Thoughts on this? https://review.openstack.org/#/c/625011/ Could be a more programmatic solution to https://review.openstack.org/#/c/624445/
14:33:10 cdent mnaser, coreycb, anyone else: I'll spin up an etherpad on the "path internal to nova to happy placement extraction" topic and invite you to help refine it. Won't be today, but soon
14:37:26 openstackgerrit Stephen Finucane proposed openstack/nova master: Summarize output of sample configuration generator https://review.openstack.org/625014
14:37:46 gibi mriedem: when you have a minute, can you check back to https://review.openstack.org/#/c/624740/
14:37:49 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842
14:38:42 frickler coreycb: did you make progress with building pike with stestr? otherwise we should maybe also consider reverting https://review.openstack.org/580492 before the next stable/pike release
14:39:49 frickler mriedem: melwitt: ^^ not sure whether you had seen that some weeks ago. stestr isn't in the original set of pike reqs, so building the latest release there was broken on ubuntu
14:40:31 frickler also sorry that I didn't remember to mention that for the meeting
14:41:48 frickler oh, there's https://bugs.launchpad.net/nova/+bug/1806079 for that already
14:41:48 openstack Launchpad bug 1806079 in OpenStack Compute (nova) "revert use of stestr in stable/pike" [Wishlist,In progress] - Assigned to Corey Bryant (corey.bryant)
14:42:40 mriedem gibi: looking
14:43:04 gibi adrianc: hi! we talked about sriov after the bandwidth demo in Berlin. I think I see the way forward how to influence which VF nova-compute chooses for a neutron port https://review.openstack.org/#/c/623543
14:43:23 mriedem frickler: yes i specifically requested that from mtreinish for reasons stated in the patch/bug
14:43:40 mriedem https://review.openstack.org/#/c/621227/2//COMMIT_MSG@12
14:43:41 gibi adrianc: the patch is still WIP but the the logic is already visible
14:44:13 frickler mriedem: yeah, I was just reading that. if it reverts cleanly, I guess it should be fine to carry the revert on the ubuntu branch
14:44:26 mriedem frickler: as coreycb said, they can carry it as a patch for them on pike
14:44:26 mriedem yeah
14:45:03 gibi mriedem: futurist added to the nova lower-constraints when the global lower constraints was moved from the global requirement to per project
14:45:14 adrianc gibi: Hi, ill put this in my review list
14:45:25 gibi adrianc: cool
14:45:38 mriedem gibi: and that was done blindly via automation,
14:45:46 gibi mriedem: I guess so
14:45:47 mriedem before your change, nova didn't use futurist, so this is the first usage of it,
14:45:52 gibi mriedem: true
14:45:53 mriedem which means, we should use what we gate against,
14:45:58 mriedem so use the version from u-c
14:46:24 gibi mriedem: when u-c changes then our lower constraints can diverge from u-c is that OK?
14:46:31 mriedem yeah
14:46:36 mriedem we have a lower-constraints unit test job for that,
14:46:46 mriedem but upper-constraints is used in both unit/functional/tempest integration testing
14:46:59 mriedem lower-constraints is kind of a 'cover your bare ass' job
14:47:05 cdent mriedem: its broken until https://review.openstack.org/#/c/622972/
14:47:56 gibi mriedem: OK, then I will fix up the patch by bumping the lower constraints of futurist to 1.8.0
14:50:29 mnaser cdent: cool thanks
14:50:32 adrianc gibi: is there also code that deals with the migration use-case ? (cold and live-migration)
14:50:47 openstackgerrit Merged openstack/os-vif master: Create iproute.IPRoute() inside a context https://review.openstack.org/624831
14:51:32 gibi adrianc: not yet. that patch series only works with boot, delete, re-schedule. I'm working on the instance move cases
14:52:37 gibi cdent: I can try my patch with your lower constraint fix to see if everything works after both
14:52:40 adrianc gibi: ack :)
14:53:00 gibi adrianc: ohh one more thing, interface detach works as well :)
14:54:24 adrianc gibi: good to know! sean-k-mooney ^ hopefully the direct support will go smoothly
15:03:26 sean-k-mooney gibi: well i intend to detach the interface at the hypervior level but i wont actully be detaching the interface form a neutron point of view
15:03:49 sean-k-mooney adrianc: ^
15:04:35 sean-k-mooney from a nova and neutron point of view the interfce need to remain attached to the instance as it does in the macvtap case for schduling to work
15:05:06 sean-k-mooney so i plan on only detaching at the libvirt level
15:05:19 gibi sean-k-mooney: a think we are thinking about two different use case. you are working on live-migrate and I work on detaching a port that has bandwidth allocation in placement
15:05:35 sean-k-mooney gibi: yep
15:06:26 sean-k-mooney gibi: but if you have live migration working with bandwidth allocation on ovs for example i think it shoudl work with sriov too once we are done
15:07:19 sean-k-mooney from a neutorn perspective and mostly from a nova one the detach/attach i plan to do will be hiden in the driver level
15:09:16 gibi sean-k-mooney: there is one difference between ovs and sriov. for sriov there is VF resource handled by nova today and now there will be bandwidth resource handled by placement
15:10:10 gibi sean-k-mooney: the leads to a situation described in the patch https://review.openstack.org/#/c/623543/
15:11:20 gibi sean-k-mooney: and we discussed a bit about this in Berlin with adrianc
15:13:22 sean-k-mooney gibi: ill be leaveing soon but ill take a look tomorow. i can try and test it next week.
15:13:54 gibi sean-k-mooney: no rush, that patch is still WIP
15:14:28 gibi sean-k-mooney: it is more like that the problem statement might be relevant for your live migration work
15:19:09 openstackgerrit Jose Castro Leon proposed openstack/nova master: Fix destination_type attribute in the bdm_v2 documentation https://review.openstack.org/625020
15:36:08 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add DownCellFixture https://review.openstack.org/614810
15:36:09 openstackgerrit Surya Seetharaman proposed openstack/nova master: API microversion 2.68: Handles Down Cells https://review.openstack.org/591657
15:41:09 openstackgerrit Balazs Gibizer proposed openstack/nova master: Replace ThreadPoolExecutor with GreenThreadPoolExecutor https://review.openstack.org/624740
15:41:50 mriedem d'oh
15:42:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Replace ThreadPoolExecutor with GreenThreadPoolExecutor https://review.openstack.org/624740
15:42:34 openstackgerrit Matt Riedemann proposed openstack/nova master: Add python 3.7 unit and functional tox jobs https://review.openstack.org/624055
15:42:34 openstackgerrit Matt Riedemann proposed openstack/nova master: Add py36/py37 functional jobs to the experimental queue https://review.openstack.org/624826
15:42:45 mriedem gibi: i was rebasing and fixing that at the same time
15:43:00 gibi mriedem: no problemo
15:44:17 gibi stephenfin: could you look at it? ^^
15:45:34 gibi stephenfin: mriedem and I agreed on the solution
15:59:55 mriedem ooo goody http://logs.openstack.org/82/624982/1/check/nova-next/4d4ec67/logs/screen-n-cpu.txt.gz
16:00:51 dansmith looks fine
16:03:38 mriedem dansmith: that's the backport of your multi-cell n-api rpc version check
16:03:44 mriedem the n-cpu failures there have to be unrelated
16:04:23 mriedem i thought we collected mysql logs but maybe not anymore
16:04:29 dansmith hmm, it shouldn't check all cells if the api connection isn't set
16:04:38 mriedem this is n-cpu failing to start
16:05:06 mriedem File "/opt/stack/new/nova/nova/objects/cell_mapping.py", line 257, in get_all\n
16:05:06 mriedem wtf
16:05:27 mriedem oooo
16:05:42 mriedem http://logs.openstack.org/82/624982/1/check/nova-next/4d4ec67/logs/etc/nova/nova-cpu.conf.txt.gz
16:05:51 mriedem we still have the api db conf set in rocky devstack
16:06:04 dansmith but.. then it shouldn't fail right?
16:06:23 mriedem unless it's starting n-cpu before the api db is up?
16:06:33 mriedem but i thought n-cpu went last
16:06:40 dansmith the error says no connection parameter, right?
16:06:59 dansmith oh, this is a RemoteError btw
16:07:24 dansmith so the cell conductor doesn't have it,
16:07:31 dansmith but cpu does, so it tried a remotable all_cells call maybe?
16:07:39 dansmith no, that doesn't make sense
16:08:00 mriedem right nova_cell1.conf (conductor) doesn't have api_database http://logs.openstack.org/82/624982/1/check/nova-next/4d4ec67/logs/etc/nova/nova_cell1.conf.txt.gz

Earlier   Later