On Tue, Sep 1, 2015 at 3:15 AM, Carl Baldwin wrote:
> On Mon, Aug 31, 2015 at 11:02 AM, Armando M. wrote:
>> On 31 August 2015 at 09:53, Jeremy Stanley wrote:
>>> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote:
>>> > I was under the impression that we had a plan to stop allowing these
On Mon, Aug 31, 2015 at 11:02 AM, Armando M. wrote:
>
>
> On 31 August 2015 at 09:53, Jeremy Stanley wrote:
>>
>> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote:
>> > I was under the impression that we had a plan to stop allowing these
>> > external updates break our gate jobs.
>> [...]
On Mon, Aug 31, 2015 at 10:50 AM, Armando M. wrote:
> You missed 'weekends' :)
I did miss weekends! While I went about my life last night blissfully
unaware of the problems that were brewing, you were on top of things
and came to our rescue. I thank you for your efforts and time, truly.
> Not
On 31 August 2015 at 09:53, Jeremy Stanley wrote:
> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote:
> > I was under the impression that we had a plan to stop allowing these
> > external updates break our gate jobs.
> [...]
>
> We do, and it succeeded in protecting master branch integrat
On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote:
> I was under the impression that we had a plan to stop allowing these
> external updates break our gate jobs.
[...]
We do, and it succeeded in protecting master branch integration test
jobs from this new netaddr release:
https://revie
On 31 August 2015 at 09:33, Carl Baldwin wrote:
> I was under the impression that we had a plan to stop allowing these
> external updates break our gate jobs. It seems extremely unwise to
> allow these forces outside of our control to disrupt us so much
> especially in such a large project as Ne
I was under the impression that we had a plan to stop allowing these
external updates break our gate jobs. It seems extremely unwise to
allow these forces outside of our control to disrupt us so much
especially in such a large project as Neutron. We lose a lot of
valuable time to these. I though
> On 31 Aug 2015, at 08:19, Kevin Benton wrote:
>
> Even if this version is fixed for valid_mac, it appears the netaddr authors
> made the decision to make a backwards incompatible change WRT to the
> 'broadcast' attribute on IPNetwork objects that have CIDRs of /31 and /32.
> This means that
Even if this version is fixed for valid_mac, it appears the netaddr authors
made the decision to make a backwards incompatible change WRT to the
'broadcast' attribute on IPNetwork objects that have CIDRs of /31 and /32.
This means that all future versions of netaddr will be incompatible with
the cu
Yeah,
The latest netaddr seems broken.
The behavior is changed like
* PREVIOUS: netaddr-0.7.15
>>> import netaddr
>>>
>>> mac = 'fa:16:3e:4e:a1:0a'
>>> netaddr.valid_mac(mac)
True
>>>
* LATEST: netaddr-0.7.16
>>> import netaddr
>>> mac = 'fa:16:3e:4e:a1:0a'
>>> netaddr.valid_mac(mac)
False
>>>
Looks like a legitimate bug in netaddr for mac address validation. The
'valid_mac' function gets setup twice at the top level.
https://github.com/drkjam/netaddr/blob/b2b83f5d69f7b38f31330624ec9eb292b1cc880d/netaddr/__init__.py#L42-L46
On Sun, Aug 30, 2015 at 8:54 PM, Armando M. wrote:
> Hi,
>
>
Hi,
If you wonder why hell broke loose, [1] will have the answer to your
questions.
Armando
[1] https://bugs.launchpad.net/neutron/+bug/1490380
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
12 matches
Mail list logo
