*** prithiv has joined #openstack-astara | 00:06 | |
*** jordantardif has quit IRC | 00:07 | |
*** prithiv has quit IRC | 00:56 | |
*** prithiv has joined #openstack-astara | 00:57 | |
*** prithiv has quit IRC | 00:57 | |
openstackgerrit | Merged openstack/astara: devstack: Bump alive_timeout https://review.openstack.org/298949 | 01:54 |
---|---|---|
openstackgerrit | Adam Gandelman proposed openstack/astara-neutron: Remove UNRELEASED tag from Mitaka release notes https://review.openstack.org/299094 | 02:52 |
openstackgerrit | Adam Gandelman proposed openstack/astara: Remove UNRELEASED tag from Mitaka release notes https://review.openstack.org/299095 | 02:52 |
*** jordant has joined #openstack-astara | 02:56 | |
*** jordant has quit IRC | 02:56 | |
adam_g | the gate seems to be stabilized thanks to a combo of https://review.openstack.org/299004 + https://review.openstack.org/298496 | 03:11 |
adam_g | markmcclain, ^ | 03:11 |
adam_g | markmcclain, rods https://review.openstack.org/#/c/298854/ is the bug fix we want backported to the stable/mitaka branch so we can cut the RC2 tag from there. ive self-approved the gate fixers but would appreciate it if you guys could approve that one just to be kosher | 03:12 |
adam_g | should be good to tag the final RCs on Thurs provided the gate doesnt continue to blow up | 03:12 |
adam_g | tty then | 03:12 |
openstackgerrit | Merged openstack/astara-neutron: Remove UNRELEASED tag from Mitaka release notes https://review.openstack.org/299094 | 04:11 |
openstackgerrit | Merged openstack/astara: Remove UNRELEASED tag from Mitaka release notes https://review.openstack.org/299095 | 04:11 |
*** jordant has joined #openstack-astara | 04:11 | |
*** ronis has joined #openstack-astara | 07:25 | |
*** elo has quit IRC | 07:38 | |
*** elo has joined #openstack-astara | 07:38 | |
*** prithiv has joined #openstack-astara | 08:51 | |
*** prithiv has quit IRC | 09:30 | |
*** prithiv has joined #openstack-astara | 10:02 | |
*** prithiv has quit IRC | 11:19 | |
*** cleverdevil has quit IRC | 11:40 | |
*** cleverdevil has joined #openstack-astara | 11:47 | |
*** openstackgerrit has quit IRC | 11:47 | |
*** openstackgerrit has joined #openstack-astara | 11:48 | |
*** openstackgerrit has quit IRC | 12:33 | |
*** openstackgerrit has joined #openstack-astara | 12:33 | |
*** openstackgerrit has quit IRC | 13:18 | |
*** openstackgerrit has joined #openstack-astara | 13:18 | |
*** xiayu1 has quit IRC | 13:19 | |
*** xiayu has joined #openstack-astara | 13:19 | |
*** ronis has quit IRC | 14:26 | |
*** jordantardif has joined #openstack-astara | 16:06 | |
*** openstack has joined #openstack-astara | 17:05 | |
*** ronis has joined #openstack-astara | 17:20 | |
stupidnic | Could somebody explain to me where security groups are implemented in Astara? Are they stored as iptables rules in the router? If so where would they be? Are they namespaced? | 18:07 |
*** davidlenwell has quit IRC | 18:27 | |
stupidnic | nevermind... I now understand that they are implemented in the hypervisor. I was trying to understand how Astara would work with the DHCP and why our configuration still requires implicit DHCP rules in all security groups | 18:34 |
*** davidlenwell has joined #openstack-astara | 18:34 | |
markmcclain | stupidnic: that was addressed here: https://review.openstack.org/#/c/266586/ | 19:53 |
markmcclain | should be in stable/(liberty|mitaka) and master | 19:53 |
stupidnic | markmcclain: yeah, I actually have that code, but it still doesn't work without the security group rules, and that is what I was trying to determine | 19:56 |
markmcclain | really? | 19:56 |
stupidnic | This could be an instance of version mismatch | 19:56 |
markmcclain | we've tested with default sec group rules for some time | 19:57 |
stupidnic | If you recall I am running Liberty but I am running astara master | 19:57 |
markmcclain | right... so the change was backported to astara-neutron stable/liberty branch | 19:57 |
markmcclain | make sure the astara-neutron package is the latest from stable | 19:57 |
markmcclain | the backport was merged 2/1 (https://review.openstack.org/#/c/272269/) | 19:58 |
stupidnic | Yeah, I mean I am running master astara code with a Liberty install | 20:00 |
stupidnic | Liberty should still reference akanda, but my code references astara | 20:00 |
stupidnic | Although looking at the code they appear to be the same | 20:01 |
*** ronis has quit IRC | 20:06 | |
markmcclain | hmmmm | 20:09 |
stupidnic | markmcclain: can you explain exactly what this is supposed to be doing? From what I gather there is some MAC address filtering on the routers that is supposed block non-recognized MAC addresses from instances, is that correct? | 20:20 |
stupidnic | Or is that on the hypervisor? | 20:21 |
markmcclain | the mac filtering is on the hypervisor | 20:21 |
markmcclain | this code adds rules to allow DHCP since by default it is blocked to prevent DHCP spoofing | 20:21 |
markmcclain | s/spoofing/rogue severs/ | 20:21 |
stupidnic | Right. Okay. | 20:22 |
stupidnic | So should this be in the incoming, outgoing, or source filtering? | 20:22 |
markmcclain | should see 2 rules | 20:23 |
stupidnic | in which chain? | 20:23 |
markmcclain | one for 68 > 67 accepting traffic from VM and the other for 67 > 68 dropping if originates from VM | 20:24 |
markmcclain | stupidnic: does the router instance have security group rules? | 20:25 |
markmcclain | by default nova should not be installing any rules for it | 20:25 |
markmcclain | wondering if that's the problem | 20:25 |
stupidnic | markmcclain: I am not sure. How would I check that? | 20:25 |
stupidnic | I placed my router instances in the service project | 20:26 |
markmcclain | on the hypervisor where a router is running | 20:26 |
stupidnic | (since that made sense to me) | 20:26 |
markmcclain | dump the iptables via iptables-save | 20:26 |
markmcclain | right the routers are owned by service tenant | 20:26 |
stupidnic | Okay... so looking at the outgoing chain... I can see that there is a rule for sport 68 to 67 with a drop on sport 67 to 68 | 20:47 |
stupidnic | and looking at the incoming chain there is a rule with source of the router's IP sport 67 to 68 | 20:47 |
stupidnic | so the rules are there | 20:47 |
*** openstackgerrit has quit IRC | 20:48 | |
*** openstackgerrit has joined #openstack-astara | 20:48 | |
stupidnic | Okay. Well I just fired up an instance and didn't have any issues with getting an IP address with a limited security group (basically only 22 inbound) | 20:54 |
stupidnic | So I am not sure why some of my clients require it | 20:54 |
stupidnic | perhaps it is an issue with the router version I have running? My project (admin) has a newer version that supports LBaaSv2 where as other clients have older versions | 20:55 |
stupidnic | Yeah, I just confirmed that it doesn't work with another client's project (the one that was complaining), same instance image (Ubuntu). | 21:08 |
stupidnic | I will do a router refresh on this client once I clean up the new router image | 21:08 |
*** prithiv has joined #openstack-astara | 21:11 | |
*** phil_h has quit IRC | 21:20 | |
*** phil_h has joined #openstack-astara | 21:36 | |
*** shashank_hegde has joined #openstack-astara | 21:37 | |
*** davidlenwell has quit IRC | 21:48 | |
*** davidlenwell has joined #openstack-astara | 21:55 | |
*** shashank_hegde has quit IRC | 22:07 | |
*** shashank_hegde has joined #openstack-astara | 22:16 | |
markmcclain | stupidnic: it might actually be related to the age of the instance | 22:18 |
stupidnic | The router instance? | 22:18 |
markmcclain | any instances started prior to updating astara-neutron with that change would not have the proper DHCP rules | 22:18 |
stupidnic | Okay. That's most likely the culprit then | 22:18 |
stupidnic | I just finished tweaking the new image and updating astara's config to point to it | 22:19 |
stupidnic | I just rebooted the admin router instance and it works as planned, so I am guessing that is probably the case. I will sneak in a reboot on the other instances to get them on the new router instances | 22:20 |
markmcclain | ok cool | 22:20 |
stupidnic | markmcclain: confirmed. The client that was having the issue previously no longer has the same issue. Updating the router image did the trick. | 22:44 |
markmcclain | awesome | 22:51 |
*** prithiv1 has joined #openstack-astara | 23:00 | |
*** prithiv has quit IRC | 23:00 | |
*** prithiv has joined #openstack-astara | 23:07 | |
*** prithiv1 has quit IRC | 23:08 | |
*** fzylogic has joined #openstack-astara | 23:10 | |
*** shashank_hegde has quit IRC | 23:13 | |
*** shashank_hegde has joined #openstack-astara | 23:17 | |
*** prithiv has quit IRC | 23:26 | |
*** prithiv has joined #openstack-astara | 23:33 | |
*** prithiv has quit IRC | 23:33 | |
*** shashank_hegde has quit IRC | 23:47 | |
*** shashank_hegde has joined #openstack-astara | 23:54 | |
openstackgerrit | mark mcclain proposed openstack/astara-appliance: Ensure VPN settings are more prescriptive. https://review.openstack.org/299680 | 23:54 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!