[openstack-dev] [Neutron] VLAN trunking network for NFV

2015-03-25 Thread Darragh O'Reilly
> *From:* Ian Wells [mailto:ijw.ubuntu at cack.org.uk] > *Sent:* Wednesday, March 25, 2015 2:18 AM > > That spec ensures that you can tell what the plugin is doing. You can ask > for a VLAN transparent network, but the cloud may tell you it can't make > one. > > If you want to use a VLAN trunk usi

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

2014-03-31 Thread Darragh O'Reilly
ok, good to hear you are making progress. From the variable names in the script - ifname=$IFNAME_ETH2,vlan=2 - it sounds like this is a Neutron provider network. If so, then it should be possible to bridge the VM to the link with with a simple Linux bridge, without the need for a Neutron port

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

2014-03-31 Thread Darragh O'Reilly
com >IRC ……..… pcm_ (irc.freenode.com) >TW ………... @pmichali >GPG Key … 4525ECC253E31A83 >Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 > > > > >On Mar 31, 2014, at 4:20 AM, Darragh O'Reilly >wrote: > >Hi Paul, >> >>the OVSInterfaceD

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

2014-03-31 Thread Darragh O'Reilly
Hi Paul, the OVSInterfaceDriver creates interfaces with type internal so agents like DHCP/L3 etc can put IP addresses on them. But I don't think type internal will work for instances. You could try subclassing and overriding so it does not do this:   https://github.com/openstack/neutron/blob/2

Re: [openstack-dev] [qa][neutron] neutron version in openstack/nova neutron tests

2014-03-14 Thread Darragh O'Reilly
ah - forget it - it was stable/havana of course https://review.openstack.org/#/c/75825/ On Friday, 14 March 2014, 20:29, Darragh O'Reilly wrote: I'm looking at errors in the dhcp-agent using logstash and I see openstack/nova Jenkins jobs running today [1] that have an outdate

[openstack-dev] [qa][neutron] neutron version in openstack/nova neutron tests

2014-03-14 Thread Darragh O'Reilly
I'm looking at errors in the dhcp-agent using logstash and I see openstack/nova Jenkins jobs running today [1] that have an outdated neutron/openstack/common/lockutils.py. The message format used to be 1 line per lock/unlock eg: Got semaphore "dhcp-agent" for method "subnet_delete_end"... But

Re: [openstack-dev] [Neutron] Selectively disabling certain built in iptables rules

2014-01-21 Thread Darragh O'Reilly
> >Darragh O'Reilly wrote: > >>Neutron does not know about flavors or images. But it has ports which have a >>name attribute that can be set to an arbitrary string, e.g. 'anti_spoof_off'. >>The >>name does not need to be unique within the tenan

Re: [openstack-dev] [Neutron] Selectively disabling certain built in iptables rules

2014-01-21 Thread Darragh O'Reilly
I think there is a blueprint for that. Anyway, see idea for current releases below: >Feel free to tell me this is a bad idea and scold me for even asking, but >please >help me figure out how to do it anyway. This is for a specific tenant in a >specific lab that was built specifically for that

Re: [openstack-dev] [Neutron] Apparently weird timeout issue

2014-01-20 Thread Darragh O'Reilly
hcpc command line parameters are baked into the image. It's part of BusyBox, and I'm not even sure if it's configurable from a script/text file. > >Best, > -jay > > > > >On Mon, Jan 20, 2014 at 10:23 AM, Darragh O'Reilly > wrote: > > >>I did a

Re: [openstack-dev] [Neutron] Apparently weird timeout issue

2014-01-20 Thread Darragh O'Reilly
ent another dhcp discover now if it had been let live I think it would be worth trying to change that test to poll for 120 seconds instead of 60. On Monday, 20 January 2014, 11:23, Darragh O'Reilly wrote: Hi Salvatore, > > >I presume it's this one?  >http://logs.opens

Re: [openstack-dev] [Neutron] Apparently weird timeout issue

2014-01-20 Thread Darragh O'Reilly
Hi Salvatore, I presume it's this one?  http://logs.openstack.org/38/65838/4/check/check-tempest-dsvm-neutron-isolated/d108e4a/logs/tempest.txt.gz?#_2014-01-19_20_50_14_604 Is it true that the cirros image just fires off a few dhcp discovers and then gives up? If so, then maybe it did so before