Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-17
13:42:52 smcginnis Correct.
13:43:21 gibi stephenfin, smcginnis: I got your comments on the fix, I will respin that patch quickly
13:43:58 openstackgerrit Takashi NATSUME proposed openstack/nova stable/pike: Fix unit of hw_rng:rate_period https://review.opendev.org/689158
13:46:33 efried okay, I'm going to be late to the meeting, but hopefully not more than a few minutes
13:46:49 efried poor planning (from like months ago)
13:50:31 mriedem i'll start the meeting
14:00:17 mriedem nova meeting starting now in -meeting
14:03:24 openstackgerrit Balazs Gibizer proposed openstack/nova master: Make sure tox install requirements.txt with upper-constraints https://review.opendev.org/689152
14:03:58 gibi mriedem, stephenfin, smcginnis ^^
14:05:33 openstackgerrit Dan Smith proposed openstack/nova stable/train: Update compute rpc version alias for train https://review.opendev.org/689164
14:06:40 sean-k-mooney oh for the docs job. there was a reson we did not isntall requriement and test requireemnt in the docs job before
14:07:30 sean-k-mooney the way we build docs useign auto generation its kind of required but there was pushback to doing htis in the past.
14:08:56 openstackgerrit Huachang Wang proposed openstack/nova master: [WIP] metadata: export the vCPU IDs that are pinning on the host CPUs https://review.opendev.org/688936
14:15:51 stephenfin sean-k-mooney: We're installing requirements.txt by default already. Unless you have skipsdist=False configured, tox will build your package for you
14:16:05 stephenfin which obviously requires all dependencies in requirements.txt at a minimum
14:16:06 sean-k-mooney ya i know
14:16:47 sean-k-mooney because of the way our docs work you need /requirements.txt. and /docs/requirements.txt
14:17:09 sean-k-mooney you should not need test-requirements.txt but it wont break anything if its installed
14:36:08 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Change order of two classes https://review.opendev.org/689178
14:36:09 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Make '_wait_for_state_change' behave consistently https://review.opendev.org/689180
14:36:09 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Rework '_delete_server' https://review.opendev.org/689179
14:36:10 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Make 'ServerTestBase' subclass 'InstanceHelperMixin' https://review.opendev.org/689182
14:36:10 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Unify '_wait_until_deleted' implementations https://review.opendev.org/689181
14:40:12 stephenfin mdbooth, sean-k-mooney: ^
14:40:39 stephenfin the juicy one in the middle is failing for reasons I haven't yet grokked, but that's where I'm going with it
14:44:46 openstackgerrit Matthew Booth proposed openstack/nova master: Add new functional test base for libvirt tests https://review.opendev.org/689186
14:45:18 mdbooth stephenfin sean-k-mooney: ^^^
14:46:12 mdbooth sean-k-mooney: I ripped out a few things you added for your test because I'm not using them in mine, so you'll almost certainly want to add some of them back in
14:46:42 mdbooth sean-k-mooney: But I think that's ok. i.e. Extend functionality as the use case arises.
14:46:54 sean-k-mooney sure
14:47:47 mdbooth However, with ^^^, a functional libvirt test is: inherit IntegratedTestBase; self._start_compute('compute1'); server = self._create_active_server()
14:47:53 mdbooth And I like that simplicity
14:48:27 sean-k-mooney ya that seam like a good way forward
14:54:39 melwitt dansmith: from the meeting, any opinion on whether this is better off as a bp or a wishlist bug that is backportable? https://blueprints.launchpad.net/nova/+spec/nova-manage-db-purge-task-log
14:54:53 melwitt task_log records pile up and there's no way to clean them up
14:55:44 melwitt gibi, stephenfin, bauzas: ^ any opinion
14:55:47 melwitt ?
14:57:14 gibi melwitt: I will have to dig a bit
14:57:26 gibi melwitt: give me 15 minutes as there is a paralle meeting
14:57:32 mriedem mdbooth: new functional tests shouldn't be using IntegratedTestBase
14:57:43 melwitt mriedem: he's afk!
14:57:51 mriedem it's got all sorts of warts from api samples tests, like CastAsCall fixture and stuff
14:58:13 melwitt efried_afk: can you give your opinion on bp vs wishlist bug while you're driving pls ^
14:59:27 dansmith melwitt: I'd probably say it's a feature like db purge was, but I understand the desire to make it backportable (for real value), so I don't feel that strongly
14:59:57 melwitt ack
15:00:32 bauzas melwitt: /me looks
15:01:09 bauzas honestly, I have the same thoughts about the audit command
15:01:42 bauzas once we merge it (and honestly, it still needs some time from me), I think we *could* honestly backport it to help operators
15:01:50 bauzas I said we *could*
15:01:58 bauzas but we need some consensus
15:01:58 mriedem like, honestly?
15:02:25 bauzas if someone doesn't want about backporting any feature or a wishlist bug, I understand it
15:02:34 bauzas because I could tell this
15:02:49 melwitt yeah, I mean, the usual is we backport downstream only in the feature cases. example: I'm in the middle of backporting db purge, archive_deleted_rows --before and --all-cells
15:03:20 bauzas yeah, honestly, backporting the audit command only downstream wouldn't be a problem for me
15:03:28 melwitt if people are ok with backporting purge_task_log upstream, then bug it up I guess
15:03:33 bauzas but I think operators not using OSP would also love it, even for Train
15:03:40 melwitt yeah
15:03:48 bauzas and I think for purge, it's the same
15:03:57 melwitt I dunno, I would have thought the same for purge, --before and --all-cells
15:04:02 melwitt though
15:04:29 bauzas so, yeah, I agree with you, maybe just provide a backport change in stable/train and then we could discuss about it there
15:05:04 mriedem imo backporting standalone new commands (like heal_allocations in my case) is less of an issue because if they are busted then whatever, no one is using them on stable already anyway,
15:05:18 mriedem but backporting big changes to existing CLIs that people are using, like the all cells stuff for archive, is much riskier
15:05:33 bauzas actually, good point
15:05:48 melwitt yeah, I could see that. risk aspect
15:05:49 bauzas if we're adding some argument, I don't see the problem
15:06:02 bauzas but if we're changing some arg, then yes it's at risk
15:06:06 mriedem depends on how invasive it is
15:06:18 melwitt heh yeah.
15:06:27 bauzas right, hence us should be discussing on the stable change
15:06:56 bauzas I mean, anyone can provide any change to the stable branches
15:06:56 openstack Launchpad bug 1847367 in OpenStack Compute (nova) "Images with hw:vif_multiqueue_enabled can be limited to 8 queues even if more are supported" [Undecided,Confirmed] - Assigned to sean mooney (sean-k-mooney)
15:06:56 mriedem diconico07: i've commented in https://bugs.launchpad.net/nova/+bug/1847367 from the results of the meeting
15:07:10 bauzas it's just the stable cores that either accept or disagree with it
15:07:33 sean-k-mooney mriedem: cool i have something typed up as well
15:07:48 melwitt bauzas: the master change isn't written yet :P but really the discussion here is whether to do it as a bp or a wishlist bug with backports in the mind
15:08:22 melwitt I think the process has been, if it's a bp then it's totally nacked on stable
15:08:26 bauzas melwitt: mriedem: but honestly, the stable rules don't say 'please don't backport any feature'
15:08:28 bauzas https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
15:09:03 bauzas apart of https://docs.openstack.org/project-team-guide/stable-branches.html#active-maintenance rule #1
15:09:19 openstack bugzilla.redhat.com bug 1714075 in openstack-nova "[OSP13][NFV] 8 queues limit is applicable for tap device not for vhostuser port in kernel version 3." [Medium,Assigned] - Assigned to smooney
15:09:19 sean-k-mooney mriedem: this was the downstream bug that i was going to fix https://bugzilla.redhat.com/show_bug.cgi?id=1714075 but to be honest i have known about this bevhaior for years and its bugged me so ill be happy to fix it
15:09:27 bauzas but in https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines we say " Proposed backports breaking any of the above guidelines can be discussed as exception requests on the openstack-discuss list (prefix with [stable]) where the stable maintenance core team will have the final say. "
15:09:48 bauzas melwitt: so, see, even with stable, you can still have exceptions
15:09:56 sean-k-mooney mriedem: i was pretty sure i had already filed a bug for vhost-user but i cnat find it in launchpad so ill file a new one as you said
15:10:20 bauzas melwitt: so I don't see a problem with you asking for an exception once you're done with master
15:11:11 mriedem "the backport guidelines don't say anything about new features...oh except this part where it says backports for new features are completely forbidden"
15:11:20 mriedem :/
15:11:43 mriedem melwitt: just do a wishlist bug, drop the bp, write the patch and we can slit each others throats on backport policy in 3 months?
15:11:43 melwitt bauzas: I don't think that's likely to fly with the stable team :P just mho
15:11:58 melwitt mriedem: lol, sounds great
15:12:10 bauzas mriedem: it tells about some possible exceptions :p
15:12:40 mriedem how about someone familiar with the new blueprint process tell me the decoder ring for what i can set for the Direction and Definition fields when approving a specless blueprint?
15:12:44 dansmith If we couldn't backport a tiny feature to mitigate spectre, I can't imagine we're going to get permission to backport something like this
15:12:45 mriedem can i mark both as "approved"?
15:13:38 melwitt I think there's an ML mail about that. /me looks
15:13:57 sean-k-mooney mriedem: i think the intent was to mark the direct as appoved after review around m2
15:14:35 sean-k-mooney but this is a small thing that i expect mel will have ready pretty quickly so i hope its merged well before that point
15:14:48 sean-k-mooney so ya you proably could mark both as approved

Earlier   Later