Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-17
13:34:20 smcginnis Then the other jobs that need different deps, like the lower-constraints job, override "deps" to set the requirements it needs.
13:34:46 stephenfin smcginnis: Cool. I didn't know this would happen so I need to go make sure we haven't broken other projects
13:35:03 smcginnis As long as the -c isn't hard coded in the install_command, settings "deps" should be flexible enough to use different requirements for different jobs.
13:35:09 openstackgerrit Takashi NATSUME proposed openstack/nova stable/queens: Fix unit of hw_rng:rate_period https://review.opendev.org/689155
13:36:10 smcginnis One tricky bit I've seen is that it's not always obvious that putting a deps line in a tox environment overrides rather than appends to the deps that are used. So there have been some cases where teams have meant to use an additional file but have ended up excluding some common ones.
13:36:31 smcginnis So just make sure wherever used deps you always include things like test-requirements (where appropriate of course).
13:36:40 stephenfin gibi: comments left
13:37:52 stephenfin smcginnis: Yeah, we're good there. We use the '{testenv[blah]}deps' syntax everywhere that matters
13:37:59 mriedem stephenfin: replied to you in there
13:38:47 smcginnis stephenfin: ++
13:38:48 stephenfin mriedem: yup, both valid
13:39:42 stephenfin gibi, efried, mriedem, alex_xu: Also, I'm on PTO from tomorrow until the summit. Just FYI
13:40:20 efried holy crap, that's in like two and a half weeks, I didn't realize how close it was.
13:40:39 sean-k-mooney yep
13:40:43 stephenfin you're telling me
13:41:18 efried gdi, I have to take my kid to the dentist this morning during meeting time
13:41:31 gibi stephenfin: I've just confirmed that haveing the constraint in the install_command also works
13:41:59 stephenfin gibi: yeah, I think we don't want to do that because people forget to override install_command for the lower-constraints target
13:42:31 stephenfin at least that's what I took away from smcginnis' comments above and elsewhere
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

Earlier   Later