| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-26 | |||
| 14:21:59 | aspiers | unless None means "match ANY proto/range" | |
| 14:22:05 | aspiers | but that doesn't align with what you said above | |
| 14:22:17 | aspiers | because it can't match if there is no iptables rule for it | |
| 14:22:40 | slaweq | technically it's not None but null :) | |
| 14:22:45 | openstackgerrit | Merged openstack/os-traits master: CPU: add a trait for AVX512-VNNI support https://review.opendev.org/672888 | |
| 14:22:58 | aspiers | openstack CLI says "None" | |
| 14:23:13 | aspiers | but I guess you mean null in the db | |
| 14:23:20 | aspiers | None in Python | |
| 14:23:28 | aspiers | maybe a SQLAlchemy translation? | |
| 14:23:59 | slaweq | aspiers: ok, so lets say I'm creating rule like http://paste.openstack.org/show/754898/ | |
| 14:24:15 | slaweq | this will be visible in iptables like: | |
| 14:24:42 | aspiers | ohhhh I see the confusion now | |
| 14:24:54 | aspiers | <slaweq> aspiers: if both IP protocol and range are None than it's not inserted into iptables rule to match, so all will be matched | |
| 14:25:04 | aspiers | I thought you were saying that _no_rule_ would be inserted into iptables | |
| 14:25:12 | aspiers | but you meant just the protocol/range elements of the rule | |
| 14:25:37 | aspiers | so there will be a rule, but it won't care what protocol/range, so it will match anything | |
| 14:26:14 | slaweq | this will be visible in iptables like: -A neutron-openvswi-i425cf5a4-1 -j RETURN | |
| 14:27:03 | aspiers | right | |
| 14:27:11 | aspiers | so it will accept | |
| 14:27:19 | slaweq | aspiers: but if You will e.g. specify "--protocol tcp" in this rule in neutron, rule in iptables will be like: | |
| 14:27:53 | slaweq | -A neutron-openvswi-i425cf5a4-1 -p tcp -j RETURN | |
| 14:28:01 | slaweq | so it will accept "only" tcp traffic | |
| 14:28:22 | slaweq | if You will add some port or port range in neutron, it will be added to match conditions in iptables | |
| 14:28:30 | slaweq | is it more clear now? | |
| 14:28:33 | aspiers | yeah I get what you were saying now. that all makes sense in theory, but it doesn't match the behaviour I'm seeing | |
| 14:29:56 | aspiers | slaweq: look at this sec group: http://paste.openstack.org/show/754899/ | |
| 14:30:09 | aspiers | I can't ping my cirros VM in that group until I add another rule for icmp | |
| 14:30:29 | slaweq | from "outside"? | |
| 14:30:31 | slaweq | it's normal | |
| 14:30:38 | aspiers | from the qrouter netns | |
| 14:30:48 | aspiers | the private address | |
| 14:30:51 | slaweq | You have only rules to allow all egress traffic from instance | |
| 14:31:00 | aspiers | huh? | |
| 14:31:06 | aspiers | there are two ingress rules | |
| 14:31:10 | slaweq | and 2 rules which accepts traffic from other instances which are using same security group | |
| 14:31:30 | slaweq | router port is not using same SG so from router it will not be allowed | |
| 14:31:39 | aspiers | ohhhh OK | |
| 14:31:46 | slaweq | if You will have second vm which will use same SG than it will work for You | |
| 14:32:00 | aspiers | so effectively you are explaining what "remote security group" means? | |
| 14:32:05 | sean-k-mooney | aspiers: i generally have better look in the dhcp namespaces | |
| 14:32:08 | slaweq | yes :) | |
| 14:32:19 | aspiers | slaweq: is that documented anywhere? | |
| 14:32:46 | sean-k-mooney | aspiers: why would the router ever be in the the same securtiy group | |
| 14:32:55 | sean-k-mooney | the security group is typically on the port | |
| 14:33:16 | sean-k-mooney | not the network unlike qos | |
| 14:33:17 | slaweq | aspiers: tbh I'm not sure, let me look | |
| 14:34:07 | aspiers | also interesting to note that security groups are documented in nova not neutron https://docs.openstack.org/nova/latest/admin/security-groups.html | |
| 14:34:27 | aspiers | well, in both | |
| 14:34:28 | sean-k-mooney | aspiers: thats because fo nova networks | |
| 14:34:40 | sean-k-mooney | which we have now deleted? | |
| 14:34:52 | aspiers | sean-k-mooney: yeah I remember the history from 2012 :) | |
| 14:35:41 | sean-k-mooney | aspiers: well stpehn is activly deleteing the remainder of the code this cycle | |
| 14:35:47 | aspiers | finally \o/ | |
| 14:35:54 | sean-k-mooney | i think he has done cellsv1 | |
| 14:36:07 | sean-k-mooney | and some of the xen only console stuff | |
| 14:36:16 | sean-k-mooney | nova networks is next on his list | |
| 14:36:46 | sean-k-mooney | after he finishes the cpu pinning via placement stuff | |
| 14:39:39 | slaweq | aspiers: from what I'm now looking into Neutron documentation, I think this remote_group_id isn't really explained there | |
| 14:39:42 | slaweq | :( | |
| 14:39:55 | aspiers | slaweq: thanks for checking! | |
| 14:40:00 | aspiers | that sounds like a doc bug | |
| 14:40:09 | slaweq | aspiers: yes, indeed | |
| 14:40:16 | slaweq | aspiers: but I hope it's clear for You now :) | |
| 14:40:21 | aspiers | I think so | |
| 14:40:45 | aspiers | is it also possible to have an egress rule with remote secgroup set? | |
| 14:41:07 | aspiers | so that the rule only matches outgoing traffic to another (or maybe the same) secgroup? | |
| 14:41:18 | slaweq | aspiers: yes | |
| 14:41:26 | aspiers | cool | |
| 14:41:41 | slaweq | technically it creates ipset with IP addresses which belongs to other ports with same SG | |
| 14:41:54 | slaweq | and use this ipset in match conditions for rule | |
| 14:42:10 | aspiers | makes sense | |
| 14:42:13 | slaweq | but if You want to do so, please remember to remove default rule which allows all egress traffic | |
| 14:42:29 | slaweq | otherwise it will match first and still all will work fine | |
| 14:42:51 | slaweq | s/work fine/be allowed | |
| 14:42:52 | slaweq | :) | |
| 14:42:59 | aspiers | got it | |
| 14:43:12 | aspiers | OK think I understand much better now, thanks a lot! | |
| 14:48:58 | slaweq | aspiers: yw :) | |
| 14:56:40 | sean-k-mooney | aspiers: you can use cidr notation with egreess rules | |
| 14:56:55 | sean-k-mooney | you do not need to use remote sec groups at all | |
| 15:09:43 | melwitt | dansmith: hey, appreciate the review on the last context manager patch. I'm investigating into the our test setup code to be able to reply about some things. thanks again for looking | |
| 15:10:16 | dansmith | melwitt: okay, you haven't rebased the archive patch yet right? | |
| 15:10:45 | melwitt | dansmith: not yet no, wanted to get a run with the post test hook change before shuffling things around | |
| 15:11:11 | melwitt | which I got last evening, just need to rebase from the last context manager patch now | |
| 15:11:23 | melwitt | *away from | |
| 15:12:07 | melwitt | should do that right now actually, I got distracted | |
| 15:13:17 | openstackgerrit | melanie witt proposed openstack/nova master: nova-manage db archive_deleted_rows is not multi-cell aware https://review.opendev.org/507486 | |
| 15:13:18 | openstackgerrit | melanie witt proposed openstack/nova master: Verify archive_deleted_rows --all-cells in post test hook https://review.opendev.org/672840 | |
| 15:14:16 | melwitt | still have mriedem's +2 on the top patch, yusss | |
| 15:14:42 | sean-k-mooney | mriedem: could you take a second look at https://review.opendev.org/#/c/669738/2 i added the functional tests and its pretttry trivial otherwise so it would be nice to land that | |
| 15:27:42 | efried | https://review.opendev.org/#/c/672800/ | |
| 15:27:42 | efried | https://review.opendev.org/#/c/672805/ | |
| 15:27:42 | efried | mriedem: Got $NOVA_CPU_CONF working | |
| 15:30:24 | sean-k-mooney | efried: are you finally fixing the fact that we override the /etc/nova/nova-cpu.conf | |
| 15:30:34 | efried | yes, see above. | |
| 15:31:25 | sean-k-mooney | cool i have been setting things for both nova.conf and nova-cpu.conf in my local.conf for years at this point to work around it | |
| 16:32:35 | mriedem | sean-k-mooney: i've been busy with some stuff most of the morning and i'm going to lunch soon but i have that in a tab for later | |
| 16:33:04 | mriedem | efried: same for you | |
| 16:34:15 | mriedem | melwitt: i would have expected https://review.opendev.org/#/c/507486/65 to be smaller after you rebased it away from https://review.opendev.org/#/c/672604/1 ? | |
| 16:35:45 | melwitt | mriedem: oh, so I wasn't sure whether I should toss out the func test or if it still has any value | |