Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-12-11
15:23:20 sean-k-mooney yep also the server the drives cost more then the server i would have been over 3500 for the same capasity in dirves
15:24:11 gibi sean-k-mooney: you passthrough a physical GPU for the windows gaming VM?
15:24:28 sean-k-mooney that is my plan yes
15:24:37 sean-k-mooney i did before but its currenly in my desktop
15:24:48 gibi interesting
15:24:55 sean-k-mooney jsut using pci passthoough in the flavor not the vgpu support
15:25:28 sean-k-mooney gpus that support vGPU are still $$$$
15:26:29 gibi yeah, and I guess you don't need multiple gpus in your openstack cluster
15:26:46 sean-k-mooney it might be nice but ya i dont
15:27:21 sean-k-mooney if amd or intel add it to a consume gpu that would be a huge add value to me
15:27:40 sean-k-mooney but im not spendign 3000 on a nvida gpu + lisciening
15:28:19 gibi yeah
15:34:37 openstackgerrit Balazs Gibizer proposed openstack/nova stable/victoria: Disable qos resize tempest test for nova-multi-cell job https://review.opendev.org/c/openstack/nova/+/766474
15:36:04 gibi lyarwood: I've backorted ^^ so we can even chose to redo https://review.opendev.org/c/openstack/nova/+/765749 by squashing ^^ into it and remove making nova-multi-cell non-votin
15:36:23 gibi but I'm OK keeping it as is
15:36:58 lyarwood gibi: it's just in the check queue at the moment so feel free to if you have time
15:37:14 gibi lyarwood: OK, the I will respin it quikly
15:37:28 melwitt gibi: np, just checked it (master change) finally merged, geesh
15:37:41 gibi melwitt: yeah, we are making progress.. :)
15:38:55 gibi melwitt: I will drop an update to the ML thread about where we are before I leave for today
15:39:04 melwitt ++
15:40:27 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Wallaby https://review.opendev.org/c/openstack/nova-specs/+/759731
15:40:30 kashyap gibi: Fixed the nit
15:41:00 gibi kashyap: re-applied my badge
15:41:14 kashyap Thanks! :)
15:41:20 gibi I thank you
15:47:49 openstackgerrit Balazs Gibizer proposed openstack/nova stable/victoria: lower-constraints: Bump packaging to 20.4 https://review.opendev.org/c/openstack/nova/+/765749
15:47:54 gibi lyarwood: ^^
15:48:16 lyarwood gibi: awesome thanks
15:48:47 gibi melwitt: could you babysitt ^^ during your day if needed?
15:49:06 melwitt gibi: yep
15:49:20 gibi thanks
15:49:29 sean-k-mooney gibi: fungi raised an interesting point regarding the usefullness of lower constriants. personlly i only found it use full to detect when we use a new feature that is not in the version used by lower constraits
15:49:48 sean-k-mooney it has some other uses but do we want to discuss if we ant to keep supporting it
15:50:48 gibi sean-k-mooney: I don't have to much past knowledge about why we added lower constraints in the first place
15:51:04 sean-k-mooney in principal i do like the idea of tracking you min requirements and testing it but on the other hand i dont know if distos actully use this
15:51:23 sean-k-mooney gibi: it was mainly for distos to tell them what the min version they could use was
15:51:33 openstackgerrit Balazs Gibizer proposed openstack/nova stable/victoria: lower-constraints: Bump packaging to 20.4 https://review.opendev.org/c/openstack/nova/+/765749
15:51:45 gibi OK, then we need to see if distros are depending on this information or not
15:52:00 gmann sean-k-mooney: gibi yeah that is very open thing to discuss on how we should test it and whether we should test it or not
15:52:29 gmann one place it is helpful is while upgrade
15:52:55 sean-k-mooney only partly
15:52:58 melwitt gibi: were you meaning to write more on this line or is it just a typo? "and bug" at the end https://review.opendev.org/c/openstack/nova/+/765749/7//COMMIT_MSG#15
15:53:07 sean-k-mooney knowing that there is an overlap is useful yes
15:53:21 gibi melwitt: typo, I've pushed a new ps
15:53:26 sean-k-mooney but in a none conatienrised env it get complicated bwtween multipel serivces
15:53:46 gibi melwitt: my editor moved the #<bugnumber> ot the beginning of the next line and git ignored that line as a comment :)
15:54:15 melwitt gibi: that was nice of it :)
15:54:18 sean-k-mooney :) hehe helpful editors strike again
15:54:47 gibi I'm not even mad, it is soo friday and soo many fires
15:57:06 sean-k-mooney ya if that is the most pressing problem on a friday its not bad. hopefully the rest wont take you too long or can wait till monday
15:59:20 gibi sean-k-mooney: master is unblocked and the stable/v unblocking patch is going forward again. So yeah I will sleep well tonight
16:03:03 melwitt bauzas: could you take a look at https://review.opendev.org/c/openstack/nova/+/765749 ? gate unblock patch for stable/victoria has gotten a new patch squashed into it
16:03:13 bauzas melwitt: sure
16:04:11 melwitt thanks
16:04:31 bauzas melwitt: when squashing, should we add the cherry-picked SHA1s for all the squashed backports ?
16:04:33 bauzas gibi: ^
16:04:56 bauzas fortunately, we have the gerrit IDs within the commit msg, so it's more a procedural question
16:05:04 gibi bauzas: I can do that
16:05:14 gibi give me 5
16:05:16 bauzas it's an open question, I dunno
16:05:39 melwitt good question, I can't remember if we normally do. will do a quick gerrit search
16:05:41 bauzas we very rarely squash commits when backporting
16:06:55 bauzas eyes at https://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes
16:08:04 gibi it says cherry-pick with -x
16:08:12 gibi and that does include that hash
16:08:14 melwitt yeah. I find examples of both in the gerrit search
16:08:42 gibi bauzas: if you feel that the commit hash is helpful then I can add that no problme
16:09:00 bauzas I'm not *that* opiniated
16:09:12 bauzas gibi: but if you feel OK with it, please do
16:09:14 bauzas it doesn't harm
16:09:25 bauzas the more the better in this case
16:12:18 gibi oops, we need to merge
16:12:19 gibi
16:12:23 gibi https://review.opendev.org/c/openstack/nova/+/766720
16:12:26 gibi to master first
16:12:57 gibi as now it is part of the squashy commit on stable/v
16:13:15 openstackgerrit Balazs Gibizer proposed openstack/nova stable/victoria: lower-constraints: Bump packaging to 20.4 https://review.opendev.org/c/openstack/nova/+/765749
16:13:23 gibi bauzas: could you look at https://review.opendev.org/c/openstack/nova/+/766720 please?
16:13:27 bauzas done
16:13:40 gibi thanks
16:32:00 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit to 1.6.2 and raise hacking to 1.1.0 in LC https://review.opendev.org/c/openstack/nova/+/766171
16:33:56 lyarwood okaas~.
16:34:42 lyarwood gah sorry ssh died
16:45:19 openstackgerrit Lee Yarwood proposed openstack/nova stable/ussuri: [stable-only] lower-contraints: Bump hacking to 3.0.1 and amqp to 2.5.2 https://review.opendev.org/c/openstack/nova/+/766738
16:45:37 lyarwood ^ so I can't actually build these lower-constraint venvs locally thanks to virtualenv pulling in weird versions of setuptools
16:46:03 lyarwood I'm going to go afk for a few hours to deal with some childcare stuff and then attack this again later, with beer.
16:47:51 sean-k-mooney lyarwood: you can contol the version fo setup tools with a flag
16:50:27 fungi sean-k-mooney: i did not mean to suggest that jobs testing lower-bounds of our (transitive) dependency sets wouldn't be useful, simply that we don't have (and haven't ever had) them. when they were originally proposed i pointed out the problem is intractable without implementing it in pip or duplicating a large portion of pip's routines, but folks decided to just punt because the (in this case
16:50:29 fungi especially incorrect) version selections pip failed to particularly enforce were considered "good enough"
16:52:57 sean-k-mooney fungi: sure but i konw at least form a redhat downstream point of view lower constratis and upper constraits are not really used
16:53:48 sean-k-mooney they are useful but due to downstream backports and other issues outside of a pip based install they are not directly translateable to distro versions
16:56:24 fungi the global upper-constraints.txt wasn't introduced for the benefit of distributors. in was actually introduced to allow us to freeze the exact versions we're testing with so that they don't change in stable branches, but the supposition was that pip would be able to obey that list. it holds true for our normal jobs, but lower-constraints.txt files in projects aren't calculated from a known consistent
16:56:26 fungi set
16:56:59 sean-k-mooney fungi: oh i know upper-constraits is not for distos
16:57:02 fungi we rely on pip to calculate our upper-constraints.txt file, and we can do that because we want new packages and pip prefers the latest version of any dependency which can satisfy everyone's requirements
16:57:53 fungi the lower-constraints.txt files in projects are cobbled together by hand, are incomplete, and clearly inconsistent (i always suspected, but the dep solver in pip 2.3 has proven that now)
16:57:56 sean-k-mooney fungi: im just observing that i have seend requirement lower the lower constirant and higher then uppeor in our product
16:58:12 sean-k-mooney due to backprots and other reasons
16:58:22 sean-k-mooney e.g. rhel shiping only one verion of a dep

Earlier   Later