Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-08
14:57:16 mriedem libpcre3-dev [platform:dpkg]
14:57:19 mriedem i think that's all you need
14:58:03 mriedem looks like it's pcre-devel on fedora/centos
14:58:06 mriedem https://rpmfind.net/linux/rpm2html/search.php?query=pkgconfig(libpcre)
14:58:13 ameeda mriedem: you are talking about current opened bug of ubuntu . what do you think about the Centos one ?
14:58:30 mriedem ameeda: it's a nova bug that the entries are missing from nova's bindep,
14:58:38 mriedem just add the entries for deb and rpm
14:58:43 mriedem which i've given above
14:59:01 ameeda to this file bindep.txt right ?
14:59:07 mriedem yes
14:59:14 mriedem see the existing entries in there as an example
14:59:17 ameeda cool, thanks
14:59:59 mriedem same for opensuse https://software.opensuse.org/package/pcre-devel
15:00:21 mriedem looks like we don't have specific entries for suse
15:00:53 sean-k-mooney stephenfin: since the intel nfv ci has been offline we dont test int 300 times a day and i have only been using it on ubuntu lately but i fixed the centos support a few months ago when centos decided qemu-kvm should nolonger install qemu..
15:01:01 sean-k-mooney stephenfin: if you have issue let me know
15:01:08 Roamer` mriedem, pcre-devel should cover all RPM-based distributions
15:01:09 mriedem ameeda: btw, you can see the same thing done in devstack https://github.com/openstack-dev/devstack/commits/master/files
15:01:22 stephenfin sean-k-mooney: I'm using CentOS, so I sure will
15:01:31 mriedem devstack changes aren't bindep, but that shows you which packages for which distro
15:01:39 Roamer` mriedem, there's a bit less divergence in RPM-based distributions than there is between Debian and Ubuntu sometimes, at least WRT libraries and development packages, not the system startup stuff :)
15:02:29 ameeda mriedem: now I am using Centos, and the bug for Ubuntu , so the fix needs to be on ubuntu or don't care ?
15:02:35 Roamer` (and I say this a bit sadly, with all my love for Debian and respect for Ubuntu and, well, reluctance when it comes to working on RPM-based distributions)
15:02:57 mriedem ameeda: i'm not sure how to answer that
15:03:11 mriedem ameeda: you can update nova and push the fix from a gentoo system, it doesn't matter,
15:03:18 mriedem just add the packages to nova's bindep file
15:03:22 Roamer` ameeda, try to figure out what the bug actually is, what libpcre3-dev is and why it needs to be added
15:03:36 mriedem Roamer`: it's a transitive dependency,
15:03:42 Roamer` mriedem, I know, I fixed it for our CI
15:03:43 mriedem because of the new dep on the whereto package
15:03:51 mriedem whereto requires pcre
15:03:59 cdent bauzas: thanks for that. I read through and I wonder to what extent claims in the scheduler are now making a difference to the concerns?
15:04:02 ameeda thanks all for help, I have to go now, I will back soon.
15:06:11 bauzas cdent: I feel we solved the main blocker
15:06:13 gibi mriedem: I think it is not a big deal but we have some inconsistency here https://review.openstack.org/#/c/541008/9/nova/tests/unit/image/test_glance.py@1629
15:06:22 bauzas cdent: because I was wrong in the past
15:06:35 bauzas cdent: the fact that we have workers doesn't mean greenlets
15:06:53 bauzas hence separate processes, exactly like having multiple n-sch services
15:07:21 bauzas so, what we solved with scheduler claims is also a valid argument for saying we can have workers
15:10:57 cdent I've made reference to the code and the email thread in the notes I'm writing up, so we'll have that to refer back to later if needed
15:11:12 mriedem gibi: i think it's probably fine, the only place we append anything to that url is in "generate_image_url" and we append /images/{id} to it
15:11:23 mriedem for the createImage response location header
15:11:43 mriedem and some notification during rebuild
15:13:17 edleafe bauzas: I do remember that the argument was made for claiming in the scheduler that it would allow for multiple scheduler processes
15:13:33 mriedem the pike release notes also say you can now run multiple schedulers b/c we do claims in the scheduler
15:13:44 mriedem which is why i wanted to add that test wrinkle to the nova-next job
15:13:54 mriedem since we have had 409 issues since pike with claims in the scheduler
15:13:57 stephenfin sean-k-mooney: So etcd failed to start. Lovely :)
15:14:25 bauzas mriedem: sure, but we don't support yet multiple workers, hence the discussion
15:14:41 bauzas it's just a very simple patch
15:14:48 bauzas but someone has to write it
15:15:04 mriedem bauzas: you mean this patch? https://review.openstack.org/#/c/159382/
15:15:28 bauzas and again, I think I wonder what is the opportunity of having a separate process for filtering
15:15:45 bauzas in particular now we have cells v2 and superconductor/conductors
15:16:41 bauzas mriedem: yup
15:17:00 bauzas anyway, something to merge in Rocky :)
15:17:14 openstackgerrit Merged openstack/nova master: Fix 500 in test_resize_server_negative_invalid_state https://review.openstack.org/531117
15:21:14 openstackgerrit Jianghua Wang proposed openstack/nova master: VGPU: Modify the example of vgpu white_list set https://review.openstack.org/539183
15:23:16 openstackgerrit Merged openstack/nova master: Add index(instance_uuid, updated_at) on instance_actions table https://review.openstack.org/530429
15:23:41 openstackgerrit Matt Riedemann proposed openstack/nova master: VGPU: Modify the example of vgpu white_list set https://review.openstack.org/539183
15:24:53 gibi mriedem: OK, then I'm +2
15:26:25 jianghuaw mriedem, thanks.
15:28:47 sean-k-mooney stephenfin: that is unrelated i normally trun it off as it is not need at all for a default devstack install
15:29:27 sean-k-mooney stephenfin: i have found the etcd installation in devstack to be kindo of flaky
15:29:34 efried lajoskatona: I'm going to rebase the series upon which you have https://review.openstack.org/#/c/527728/9 stacked. I'll go ahead and pull yours into the rebase unless you have objections?
15:30:10 stephenfin sean-k-mooney: So I had HOST_IP configured to the IP of the IF I was binding DPDK to. Think I had that wrong, tbhg
15:30:40 sean-k-mooney stephenfin: haha ya that could cause issues allright
15:31:16 dansmith mriedem: in case it's not clear I think this patch from tssurya is closer to being ready than takashi's https://review.openstack.org/#/c/541246/
15:33:26 sean-k-mooney stephenfin: are you deploying on a phyicla server or a vm
15:33:35 stephenfin sean-k-mooney: The latter
15:33:36 mriedem dansmith: i think it is too
15:33:38 stephenfin Sorry - former
15:33:44 stephenfin Got a machine sat here beside me
15:36:08 sean-k-mooney ok this let me see if i have the vm i was doing the centos fixes on still and i can see if i can grab the local.conf. that said if you have issue with the getting started guide it would be nice to fix them too
15:37:08 stephenfin sean-k-mooney: Well, let's see. It's proceeding quite nicely so far
15:37:12 stephenfin since I fixed the HOST_IP issue
15:43:02 lajoskatona efried: from my side it is ok for rebasing. I just tried to put my patch for tests on top of yours to see how it goes on latest nested patches
15:43:29 efried lajoskatona: Okay. Should be coming up in the next 10-15 minutes.
15:44:58 mriedem dansmith: one of the proxy methods in https://review.openstack.org/#/c/541005/ is broken
15:45:03 mriedem otherwise just some questions
15:45:50 dansmith mriedem: ack thanks /cc stephenfin
15:49:49 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix wrong link for "Manage Flavors" in CPU topologies doc https://review.openstack.org/542270
15:50:19 stephenfin mriedem, dansmith: Alrighty then, dumb question time 🎉 How are we able to drop the v4 proxy in the above change so early? Surely that means all our clients would have to talk 5.0 as soon as we do that?
15:50:44 dansmith stephenfin: we merge the 5.0 server and client in queens,
15:50:53 dansmith then in rocky we can drop the 4.x server proxy
15:51:02 dansmith stephenfin: we send 5.0 by default after that second change
15:51:21 dansmith which means queens supports 5.0 client side, and since we only support one gap, we can drop 4.x in rocky
15:51:40 dansmith stephenfin: you saw the second change in that stack right?
15:53:45 stephenfin dansmith: Riiight, so once people start deploying from master (future Rocky), the expectation is that _everything_ in the deployment will be on stable/queens code or newer
15:53:50 stephenfin Yup, I did indeed
15:54:48 dansmith stephenfin: them's the rules yeah
15:54:49 stephenfin sean-k-mooney: Success! (I think) Now to actually test it and recreate NUMA issues :)
15:55:08 stephenfin dansmith: Gotcha. And the 6 month rule we have for conf options doesn't apply to this?
15:55:14 dansmith stephenfin: no
15:55:20 dansmith stephenfin: (no it does not)
15:55:43 stephenfin 👍
15:56:38 dansmith I'm assuming you mean the 6-mo deprecation warning period.. this is per release, and nothing is being deprecated.. we only support one version back technically anyway, so this is just us officially dropping stuff that has technically been deprecated for a long time
15:56:46 dansmith (and this is the pattern we do every time we bump)
15:58:29 stephenfin dansmith: Yup, that's the one. Thanks for the context
15:58:55 stephenfin dansmith: and a last one: this is a different RPC API with it's own unique version, right? https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L51

Earlier   Later