Earlier  
Posted Nick Remark
#openstack-nova - 2019-07-26
11:44:08 efried yeah, it certainly is.
11:44:17 efried and per the design, max_unit=1 is also correct.
11:44:21 efried as you said
11:48:06 efried alex_xu: yt?
11:50:04 efried sean-k-mooney, aspiers: Who among cores do y'all think would be appropriate reviewers for https://review.opendev.org/670189 (harden get_domain_capabilities)?
11:52:32 sean-k-mooney good question. am most of the redhat folk are familar with libvirt, matt knows all but is also always over subsribed, maybe alex_xu on the intel side
11:53:16 sean-k-mooney to be honest we added a tone of comments so most core should be able to review at this point
11:54:36 sean-k-mooney short list would proably be dansmith bauzas alex_xu or mriedem
12:00:19 sean-k-mooney stephenfin is on pto today and maybe monday hence why he is not on the list
12:04:19 sean-k-mooney johnthetubaguy: by the way regarding https://review.opendev.org/#/c/669190/
12:05:29 sean-k-mooney one i assume you still want to merge ^ but second i assume you are not against either reverting the feature entrily or making it work properly
12:24:39 openstackgerrit Merged openstack/os-vif master: Blacklist sphinx 2.1.0 (autodoc bug) https://review.opendev.org/672856
12:57:37 aspiers efried: re. core reviewers, I can't add anything to sean-k-mooney's answer
12:57:52 aspiers I just found an issue with some of the SEV tests
12:58:11 aspiers turns out you can't use decorators on classes after all :-( or at least in some circumstances. digging more now
13:06:25 openstack Launchpad bug 1837995 in OpenStack Compute (nova) ""Unexpected API Error" when use "openstack usage show" command" [Undecided,New]
13:06:25 mriedem if anyone has a stein env handy could you see if you can recreate this? https://bugs.launchpad.net/nova/+bug/1837995
13:06:33 mriedem i don't see why it would happen but if it is it should be fairly obvious
13:53:38 sean-k-mooney mriedem: i can unstack and restack an env but i dont have one to hand
14:09:45 aspiers stupid question #734: what's a "remote security group" as returned by "openstack security group rule list" ?
14:10:29 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Where have all the global_request_id gone? https://review.opendev.org/672986
14:10:43 aspiers and what's the effect of rules where the IP protocol / range are both None?
14:11:02 aspiers I would assume it just allows everything, but I'm not seeing that behaviour
14:13:11 efried aspiers: This sounds like a question for #openstack-keystone
14:13:32 aspiers oh really? I thought secgroups were part of nova
14:13:45 aspiers I guess my knowledge in this area is 5 years out of date or something
14:15:32 mriedem you're both wrong
14:15:34 mriedem neutron
14:15:39 aspiers haha
14:15:45 aspiers that would have been my second guess
14:16:01 aspiers actually I don't know why it wasn't my first
14:16:16 aspiers since I know full well that neutron manages the network namespaces and the rules within them
14:18:12 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:18:42 aspiers slaweq: isn't the default is to reject?
14:19:05 aspiers if there's no corresponding iptables rule, I don't see what could match
14:19:08 slaweq aspiers: with rules You are defining what should be accepted
14:19:15 aspiers exactly that's what I mean
14:19:21 slaweq everything else, what will not match rules will be rejected
14:19:37 aspiers right but before you said "all will be matched"
14:19:44 slaweq so e.g. if You have rule with only "--direction ingress" than everything with ingress direction will be accepted
14:20:07 slaweq as such rule will be inserted into iptables (or openflow rules, depends on fw driver)
14:20:22 aspiers are you still talking about when you have a rule with proto/range None?
14:20:31 slaweq if You will do e.g. rule "--direction ingress --protocol tcp" than such rule will be in iptables and will be accepted
14:20:40 aspiers yes I know that, but I'm asking about proto/range None
14:21:02 aspiers because above you said if it's proto/range None then it's not inserted into iptables, in which case I don't see how any iptables rule can match
14:21:11 aspiers therefore it should use the default which is REJECT
14:21:17 aspiers (or maybe DROP I dunno)
14:21:35 slaweq aspiers: yes, if You not specify protocol, it's None
14:21:44 aspiers I don't even know why devstack created rules with proto/range None
14:21:48 aspiers that makes no sense to me
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?

Earlier   Later