Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-02-04
07:09:57 sean-k-mooney[m] security groups can match on ports/adreees adn on ingress vs egress
07:11:00 sean-k-mooney[m] but if you want to enforce that policy regradless of how the vms are booted on the dmz you cant reallly do that at the network level in neutron out of the box
07:16:27 sean-k-mooney[m] you could try https://docs.openstack.org/neutron/latest/admin/fwaas.html but as i said im not sure if that is even maintaiend anymore you shouold talk to the neutron team about it first because the project was being discontinued at one point
09:53:40 opendevreview melanie witt proposed openstack/nova master: Reproducer for bug 2003991 unshelving offloaded instance https://review.opendev.org/c/openstack/nova/+/872470
09:53:40 opendevreview melanie witt proposed openstack/nova master: Enforce quota usage from placement when unshelving https://review.opendev.org/c/openstack/nova/+/872471
12:06:10 EugenMayer4 sean-k-mooney[m] thank you for clarifying. The scope of security groups is hard to grasp. I tried secgroups on the VM, but i cannot limit the ingress to the intranet lan while opening the egress for internet via 0.0.0.0/0
12:06:53 EugenMayer4 also, i assume that port (router port) based SG with OVS are entirely broken
12:07:25 sean-k-mooney[m] not broken security groups were only ever intended for vm ports
12:07:54 sean-k-mooney[m] the firewall as a service api was for router based firewalling.
12:07:59 EugenMayer4 i understand that (know) after digging int things. But that is not how they are exposed, described and "advertised"
12:08:15 sean-k-mooney[m] with that said you have differnt behavior with iptables and openflow in some cases
12:09:08 sean-k-mooney[m] the openflow firewall is more permissive interms fo what packets are allowed
12:09:09 EugenMayer4 yes, the iptables vs openflow stuff is entirely on me. We use OVS and i'am actually only okish with iptables in general, understand the concepts and know how to debug and isolate. Openflow is rather blowing my mind up
12:09:47 EugenMayer4 So that one is very much on me. I seem to struggle a lot of netns/openflow and all the tools one needs (and a lot of more complex concepts)
12:10:34 sean-k-mooney[m] i learnd openflow and ovs at the same time i was learning linux networking so i gnereally unserdstand the ovs side better
12:11:16 sean-k-mooney[m] if you were using the iptables firewalll driver you might be able to open egrees to the world and limit ingress
12:11:45 sean-k-mooney[m] the way the connection tracker stuff works is different between the two
12:12:24 EugenMayer4 well yes, i could limit the other side, but that seems overkill closing down the ingress on all the other targets. But surely doable somewhat
12:13:21 sean-k-mooney[m] https://docs.openstack.org/neutron/latest/admin/config-ovsfwdriver.html#differences-between-ovs-and-iptables-firewall-drivers
12:13:51 EugenMayer4 I'am used to limit what networks can do, since that really helps reducing the extra cost. I mean networks in openstack, beside the segmentation, has no real usage otherwise, if you cannot really control the flow, right. I mean you could also opt in for a huge 16 network or whatever and then use ingress for limitations (somewhat)
12:14:52 sean-k-mooney[m] neutron model is all based aroudn the ports not the networks
12:15:02 sean-k-mooney[m] and doign qos/firewallign on the ports
12:15:26 EugenMayer4 interesting, reading the OVS part it would mean, if i have an egress 0.0.0.0/0 and on 10.10.5.5/32 and i want to talk to 10.10.5/32 it might block it (but it does not make sense)
12:15:40 sean-k-mooney[m] partly because form most of its life it only had contol at the endpoints
12:15:42 EugenMayer4 yes, maybe i have to adopt that more. I usually tend to do more with networks
12:15:44 sean-k-mooney[m] i.e. linux bridge and ovs really could not influcance the core network at all
12:16:26 EugenMayer4 So you would, potentially, instead of controlling the egress of my DMZ network, rather control the ingress of the VMS in the the intranet network
12:16:45 sean-k-mooney[m] so there were those that wanted to do that and they created the firewall as a service and service function chaning projects to try and do that
12:16:46 EugenMayer4 that would be more the neutron way, right?
12:16:54 sean-k-mooney[m] the problem is they didnt keep maintianing them
12:17:16 sean-k-mooney[m] contolling ingress to the vms is the normally way yes
12:17:28 sean-k-mooney[m] security groups by defaull block all trafffic
12:17:45 sean-k-mooney[m] and you are expected to only open the port to the clinets that need acess
12:17:53 EugenMayer4 Yeah, i think the openstack hype was 2018 and has fallen quiet a bit. Also looked for some literature recently. People basically stopped publishing in 2018
12:18:33 sean-k-mooney[m] i tought the hype died before that but ok :)
12:19:01 EugenMayer4 Well i'am not the one to define that, i came in here very much after that. I think we run openstack since jan 2021
12:19:04 sean-k-mooney[m] the problem escpailly on the neutron side si none of the network vendors wanted to work and maintian the core
12:19:20 sean-k-mooney[m] they wanted to integrate there network stack so they could sell you that
12:19:52 EugenMayer4 well i think, the "vendors" wanted to make a difference in their services they offer, and to have that, they stopped sharing to be "different and better" then the competitor vendor
12:20:22 EugenMayer4 looking at what is really missing in openstack, and looking who is using openstack big scale, i see that most of the things i miss, have been solved on-platform by that vendor
12:20:43 sean-k-mooney[m] right but since neutron allows vendor extentions in the api cisco or juniper would just add a vendor exteion instead of implement a common shared api
12:20:59 EugenMayer4 yeah, i see that.
12:21:27 sean-k-mooney[m] there is less of a porblem for that in cinder
12:21:52 sean-k-mooney[m] they do not allow arbitray api extentions and use microverions like nova and keystone
12:22:01 sean-k-mooney[m] so there is driver to driver variance
12:22:11 sean-k-mooney[m] but the api is much more uniform
12:23:20 EugenMayer4 I would also say that in terms of API, openstack seems like designed by sysops people opting on microservices, while forgetting / not caring about all the dowsides and complications. There are so much lose ends, nobody is responsible for a task. Creating a backup with glance of a machine in nova ends up to be a task nobody has control over. One
12:23:20 EugenMayer4 starts it, the other "does something but has no clue who and what it belongs to" .. and that funny thing then, if anything errors, does not know how and what to recover or where to report the error to even
12:24:58 EugenMayer4 I think the hypversor/network/encapsulation part of Openstack is really solid, that's where a lot of the sysops people could do a lot of the good stuff. But the API and Software stack, the architecture, seems to have been neglected and as an "end user" that really bothers me
12:29:00 EugenMayer4 A war story, from time to time, no specific pattern, on of our VMs is just shutdown. In the VM audit log i see an anon user (so it will be something systemic) telling the VM to shutdown (cleanly). That's it. No trails no nothing .So something told something to do something somewhere - and i cannot even track the "next layer". Or i have a
12:29:00 EugenMayer4 hard-anti-affinity of a server-group. 3 VMS, 3 computes. first deployment, happy time, they land on 1 compute each. From time to time, openstack decides to reschedule them, and on VM lands on the same compute, so one compute has none. This happened about 3 times now and finally i will basically do the stupid thing and tie each of them to one
12:29:00 EugenMayer4 specific compute. What is responsible for the re-scheduling, IDK.
12:29:19 EugenMayer4 Enough of the ranting (if it was any). Thank you a lot for your insight (as always!)
13:19:03 opendevreview melanie witt proposed openstack/nova master: Reproducer for bug 2003991 unshelving offloaded instance https://review.opendev.org/c/openstack/nova/+/872470
13:19:04 opendevreview melanie witt proposed openstack/nova master: Enforce quota usage from placement when unshelving https://review.opendev.org/c/openstack/nova/+/872471
#openstack-nova - 2023-02-05
16:54:19 prometheanfire working on an updated constraints patchset, so far it's just nova and tempest that are still failing, anyone around to help figure out which lib update is causing the fail?
16:54:23 prometheanfire https://zuul.opendev.org/t/openstack/build/4ba64ca08116467daca31551ce8a9753
22:32:37 opendevreview Takashi Natsume proposed openstack/placement master: Fix a wrong assertion method https://review.opendev.org/c/openstack/placement/+/861489
#openstack-nova - 2023-02-06
03:22:23 opendevreview yzp proposed openstack/nova master: Fix bug after executing cinder retype https://review.opendev.org/c/openstack/nova/+/872726
06:20:19 opendevreview yzp proposed openstack/nova master: fix the bug of volume_id is not correct about existed instance https://review.opendev.org/c/openstack/nova/+/872728
08:59:09 ralonsoh sean-k-mooney, good morning! do you think we should reduce the concurrency in the os-vif tempest tests?
08:59:12 ralonsoh https://review.opendev.org/c/openstack/os-vif/+/872655
08:59:50 ralonsoh increasing the swap size reduce the occurrence of oom but kills the performance
10:27:42 opendevreview yzp proposed openstack/nova master: fix the bug of volume_id is not correct about existed instance https://review.opendev.org/c/openstack/nova/+/872728
10:50:00 opendevreview yzp proposed openstack/nova master: fix the bug of volume_id is not correct about existed instance https://review.opendev.org/c/openstack/nova/+/872728
10:54:34 opendevreview Sylvain Bauza proposed openstack/nova master: Enable cpus when an instance is spawning https://review.opendev.org/c/openstack/nova/+/868237
11:41:11 opendevreview Merged openstack/nova stable/xena: Improving logging at '_allocate_mdevs'. https://review.opendev.org/c/openstack/nova/+/871415
13:05:40 auniyal_ O/,
13:05:41 auniyal_ hyper_v.limit_cpu_features configuration parameter
13:05:41 auniyal_ https://opendev.org/openstack/nova/src/commit/72370a188c0755bc9c864b5a5e4a972077cb8dd6/nova/conf/hyperv.py#L72
13:05:41 auniyal_ "live migration to hosts with different CPU features, ..... limit the CPU features used by the instance (while creation)"
13:05:41 auniyal_ what is it mean to limit? and to be true of false ?
13:16:25 opendevreview Merged openstack/os-vif master: Increase the swap size to 8GB in tempest jobs https://review.opendev.org/c/openstack/os-vif/+/872655
13:25:42 opendevreview Sahid Orentino Ferdjaoui proposed openstack/nova master: fup: support evacuate target state https://review.opendev.org/c/openstack/nova/+/872413
14:22:02 opendevreview Merged openstack/nova stable/wallaby: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864691
14:28:17 dvo-plv Hello, Sean. I would like to continue our coversation, which we had at friday
14:29:28 dvo-plv We talked about packed_ring option
14:33:07 dvo-plv I would like to discuss the situation when use did not ask about COMPUTE_NET_VIRTIO_PACKED trait, but we need to handle migration in some way. I found that scheduler has ALL_REQUEST_FILTERS array with different filters. My eye falls on the accelerators_filter. I suggest implement packed_ring filtering in the same way as in this method
14:40:45 bauzas dvo-plv: sean-k-mooney is on PTO today
14:57:22 dvo-plv Thank you
15:07:57 bauzas by default, now my disk is getting a lot of shit from dstat and other dbtracing
15:08:04 bauzas so, huge logs size
15:10:34 bauzas man, I just miss the old g'days of screen-based services :)
15:41:46 prometheanfire working on an updated constraints patchset, so far it's just nova and tempest that are still failing, anyone around to help figure out which lib update is causing the fail? https://zuul.opendev.org/t/openstack/build/4ba64ca08116467daca31551ce8a9753
15:59:35 bauzas gmann: I lost a bit of scope for tempest wallaby, what's up ?
15:59:45 bauzas can we recheck wallaby changes ?
16:58:54 gibi bauzas: I guess it might make sense now to start an etherpad about CI failures on master and try to get the grouped and maybe tracking how is looking at which failure
16:59:01 gibi we can talk about this tomorrow ^^
16:59:16 bauzas gibi: looks a need, indeed
16:59:44 bauzas gibi: wants to start it, or do you want me to pull things I found first ?
17:09:15 gibi bauzas: please start it. I won't have time to look at it today, but maybe tomorrow I can take a look them
17:09:41 bauzas gibi: ok, I'll try to gather my findings tomorrow morning
17:09:55 bauzas and we can improve it as a team
17:10:40 gibi cool, thanks
18:32:46 opendevreview Merged openstack/os-vif master: Implement "BaseCommand" result property https://review.opendev.org/c/openstack/os-vif/+/872391
18:58:37 gmann bauzas: gibi, yes, after tempest, sdks broke it and with this it fixed and green https://review.opendev.org/c/openstack/nova/+/871798
18:58:55 gmann it is good to recheck now
21:24:42 tobias-urdin found a little nasty spelling mistake in compute rpc api aliasing introduced here https://review.opendev.org/c/openstack/nova/+/858383/30/nova/compute/rpcapi.py#428
21:24:49 tobias-urdin unless there is a patch pending for it
21:25:03 tobias-urdin alias for 6.2 rpc version says antilope and not antelope

Earlier   Later