Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

[Harm Weites]

Hi guys,

As Steven noted, activity from my side has dropped significantly, and with +2 
comes a certain responsibility of at the very least keeping track of the 
codebase. Various reasons keep me from even doing that so this seems the 
logical outcome.

Thanks for your support, it’s been a great ride :)

see you in #kolla!

> Op 15 jan. 2016, om 20:10 heeft Steven Dake (stdake) <std...@cisco.com> het 
> volgende geschreven:
> 
> I counted 6 votes in favor of removal.  We have 10 people on our core team.  
> A majority has been met and I have removed Harm from the core reviewer team.
> 
> Harm,
> 
> Thanks again for your helpful reviews and remember, your always welcome back 
> in the future if your availability changes.
> 
> For the record, the core reviewers that voted for removal were:
> Steven Dake
> Jeff Peeler
> Paul Bourke
> Michal Jastrzebski
> Ryan Hallisey
> Michal Rostecki
> 
> Regards,
> -steve
> 
> 
> From: Steven Dake <std...@cisco.com <mailto:std...@cisco.com>>
> Reply-To: openstack-dev <openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org>>
> Date: Thursday, January 14, 2016 at 5:12 PM
> To: openstack-dev <openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org>>
> Subject: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from 
> the core reviewer team
> 
> Hi fellow core reviewers,
> 
> Harm joined Kolla early on with great enthusiasm and did a bang-up job for 
> several months working on Kolla.  We voted unanimously to add him to the core 
> team.  Over the last 6 months Harm hasn't really made much contribution to 
> Kolla.  I have spoken to him about it in the past, and he indicated his work 
> and other activities keep him from being able to execute the full job of a 
> core reviewer and nothing environmental is changing in the near term that 
> would improve things.
> 
> I faced a similar work/life balance problem when working on Magnum as a core 
> reviewer and also serving as PTL for Kolla.  My answer there was to step down 
> from the Magnum core reviewer team [1] because Kolla needed a PTL more then 
> Magnum needed a core reviewer.  I would strongly prefer if folks don't have 
> the time available to serve as a Kolla core reviewer, to step down as was 
> done in the above example.  Folks that follow this path will always be 
> welcome back as a core reviewer in the future once they become familiar with 
> the code base, people, and the project.
> 
> The other alternative to stepping down is for the core reviewer team to vote 
> to remove an individual from the core review team if that is deemed 
> necessary.  For future reference, if you as a core reviewer have concerns 
> about a fellow core reviewer's performance, please contact the current PTL 
> who will discuss the issue with you.
> 
> I propose removing Harm from the core review team.  Please vote:
> 
> +1 = remove Harm from the core review team
> -1 = don't remove Harm from the core review team
> 
> Note folks that are voted off the core review team are always welcome to 
> rejoin the core team in the future once they become familiar with the code 
> base, people, and the project.  Harm is a great guy, and I hope in the future 
> he has more time available to rejoin the Kolla core review team assuming this 
> vote passes with simple majority.
> 
> It is important to explain why, for some folks that may be new to a core 
> reviewer role (which many of our core reviewers are), why a core reviewer 
> should have their +2/-2 voting rights removed when they become inactive or 
> their activity drops below an acceptable threshold for extended or permanent 
> periods.  This hasn't happened in Harm's case, but it is possible that a core 
> reviewer could approve a patch that is incorrect because they lack sufficient 
> context with the code base.  Our core reviewers are the most important part 
> of ensuring quality software.  If the individual has lost context with the 
> code base, their voting may be suspect, and more importantly the other core 
> reviewers may not trust the individual's votes.  Trust is the cornerstone of 
> a software review process, so we need to maximize trust on a technical level 
> between our core team members.  That is why maintaining context with the code 
> base is critical and why I am proposing a vote to remove Harm from the core 
> reviewer team.
> 
> On a final note, folks should always know, joining the core review team is 
> never "permanent".  Folks are free to move on if their interests take them 
> into other areas or their availability becomes limited.  Core Reviewers can 
> also be removed by majority vote.  If ther

Re: [openstack-dev] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Harm Weites]

+1 :)

Jeff Peeler schreef op 2015-11-13 19:51:

On 12/11/15 08:41, Steven Dake (stdake) wrote:

Hey folks,

Its been awhile since we have had a core reviewer nomination, but I
really feel like Michal has the right stuff. If you look at the 30 day
stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits 
in

a 30 day period. He is beating 2/3rds of our core reviewer team on all
stats. I think his reviews, while could use a little more depth, are
solid and well considered. That said he participates on the mailing
list more then others and has been very active in IRC. He has come up
to speed on the code base in quick order and I expect if he keeps 
pace,
the top reviewers in Kolla will be challenged to maintain their spots 
:)

Consider this proposal as a +1 vote from me.

As a reminder, our core review process requires 3 core reviewer +1
votes, with no core reviewer –1 (veto) votes within a 1 week period. 
If

your on the fence, best to abstain :) I'll close voting November 20th,
or sooner if there I a veto vote or a unanimous vote.

Regards
-steve

http://stackalytics.com/report/contribution/kolla-group/30


+1!

 
 
 
___

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Harm Weites]

+1 this sort of stuff makes live a lot better :)

Swapnil Kulkarni schreef op 2015-10-23 07:08:

On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake)
 wrote:


Hello Folks,

Oracle has developed a CLI tool for managing OpenStack Kolla
clusters.  Several months ago at our midcycle, the topic was
brought up an I suggested to go ahead and get started on the work. 
We clearly didn't spend enough time discussing how it should be
integrated into the code base or developed or even what its features
should be, and that is my error.

What ended up happening is sort of a code dump, which is not ideal,
but I can only work so many 20 hour days ;)  I didn't believe our
community had the bandwidth to deal with integrating a CLI directly
into the tree while we were focused on our major objective of
implementing Ansible deployment of OpenStack in Docker containers. 
Possibly the wrong call, but it is what it is and it is my error,
not Oracles.


I think user experience will of the one of the major milestones for
Kolla in Mitaka, e.g. user facing documentation, operator integration
etc. a CLI would be helpful in that.


The code can be cloned from:

git clone git://oss.oracle.com/git/openstack-kollacli.git [1]

The code as is is very high quality but will likely need to go
through alot of refactoring to ReST-ify it.  There are two major
authors of the code, Borne Mace and Steve Noyes.

I'd like a majority vote from the core team as to whether we should
add this repository to our list of governed repositories in the
OpenStack Kolla governance repository here:














hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509

[2]

Consider this email a +1 vote from me.


+1 from me 


A completely separate email thread and decision will be made by the
community about core team membership changes to handle maintenance
of the code.  Assuming this code is voted into Kolla's governance,
I plan to propose Borne as a core reviewer, which will be open to
core team vote as a separate act with our 3 +1 votes no vetos within
1 week period.  We will address that assuming a majority vote of
the code merge wins.  Steve can follow the normal processes for
joining the core team if he wishes (reviewing patches) - clearly his
code contributions are there.  Borne already does some reviews, and
although he isn't a top reviewer, he does have some contribution in
this area making it into the top 10 for the Liberty cycle.

 



Kolla CLI Features:

* dynamic ansible inventory manipulation via the host, group and
service commands
* ssh key push via the host setup command
* ssh key validation via the host check command
* ansible deployment via the deploy command
* property viewing and modification with the property list, set and
clear commands
* cleanup of docker containers on a single, multiple or all hosts
via the host destroy command
* debug data collection via the dump command
* configuration of openstack passwords via the password command
* Lines of python = 2700
* Lines of  test case code =  1800
* ~ 200 commits


 
 
 
___

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [3]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[4]




Links:
--
[1] http://oss.oracle.com/git/openstack-kollacli.git
[2]











hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509
[3] 
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 
___

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] proposing Michal Jastrzebski (inc0) for core reviewer

[Harm Weites]

Looks like he passed 3 already, but here's another +1 :)

Steven Dake (stdake) schreef op 2015-09-30 00:20:

Hi folks,

I am proposing Michal for core reviewer. Consider my proposal as a +1
vote. Michal has done a fantastic job with rsyslog, has done a nice
job overall contributing to the project for the last cycle, and has
really improved his review quality and participation over the last
several months.

Our process requires 3 +1 votes, with no veto (-1) votes. If your
uncertain, it is best to abstain :) I will leave the voting open for 1
week until Tuesday October 6th or until there is a unanimous decision
or a veto.

Regards
-steve
 
 
 
___

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

[Harm Weites]

great! +1 :)

Op 14-08-15 om 15:38 schreef Paul Bourke:
+1, Swapnil has made a ton of useful contributions and continues to do 
so :)


On 14/08/15 14:29, Steven Dake (stdake) wrote:

Hi folks,

Swapnil has done a bunch of great technical work, participates 
heavily in IRC, and has contributed enormously to the implementation 
of Kolla.  I’d like to see more reviews from Swapnil, but he has 
committed to doing more reviews and already has gone from something 
like 0 reviews to 90 reviews in about a month.  Count this proposal 
as a +1 from me.


His 90 day stats are:
http://stackalytics.com/report/contribution/kolla-group/90

The process we go to select new core reviewers is that we require a 
minimum of 3 +1 votes within a 1 week voting window. A vote of –1 is 
a veto.  It is fine to abstain as well without any response to this 
email.  If the vote is unanimous or there is a veto vote prior to the 
end of the voting window, I’ll close voting then.


The voting is open until Friday August 21st.

Thanks!
-steve



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][magnum] Removal of Daneyon Hansen from the Core Reviewer team for Kolla

[Harm Weites]

Agreed, everyone should do what they love - so I wish you the best of 
luck with the Magnum crew Daneyon!


Op 22-07-15 om 22:47 schreef Steven Dake (stdake):

Fellow Kolla developers,

Daneyon has been instrumental in getting Kolla rolling and keeping our 
project alive.  He even found me a new job that would pay my mortgage 
and Panamera payment so I could continue performing as PTL for Kolla 
and get Magnum off the ground.  But Daneyon has conferred with me that 
he has a personal objective of getting highly involved in the Magnum 
project and leading the container networking initiative coming out of 
Magnum.  For a sample of his new personal mission:


https://review.openstack.org/#/c/204686/

I’m a bit sad to lose Daneyon to Magnum, but life is short and not 
sweet enough.  I personally feel people should do what makes them 
satisfied and happy professionally.  Daneyon will still be present at 
the Kolla midcycle and contribute to our talk (if selected by the 
community) in Tokyo.  I expect Daneyon will make a big impact in 
Magnum, just as he has with Kolla.


In the future if Daneyon decides he wishes to re-engage with the Kolla 
project, we will welcome him with open arms because Daneyon rocks and 
does super high quality work.


NB Typically we would vote on removal of a core reviewer, unless they 
wish to be removed to focus on on other projects.  Since that is the 
case here, there is no vote necessary.


Please wish Daneyon well in his adventures in Magnum territory and 
prey he comes back when he finishes the job on Magnum networking :)


Regards
-steve




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Harm Weites]

no-brainer: +1

Op 14-07-15 om 13:19 schreef Ryan Hallisey:

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: Steven Dake (stdake) std...@cisco.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team. He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation. His statistics are fantastic including both code and 
reviews. His reviews are not only voluminous, but consistently good. Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for 
the candidate, so if you are on the fence, best to abstain :) We require 3 core 
reviewer votes to approve a candidate. I will leave the voting open until July 
20th  UTC. If the vote is unanimous prior to that time or a veto vote is 
received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Proposal for new core-reviewer Harm Waites

[Harm Weites]

Thanks guys, both for all the nice words and the acceptance!

harmw

Op 16-06-15 om 16:32 schreef Steven Dake (stdake):

Its unanimous!  Welcome to the core reviewer team Harm!

Regards
-steve


From: Steven Dake std...@cisco.com mailto:std...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage 
questions) openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org

Date: Sunday, June 14, 2015 at 10:48 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] Proposal for new core-reviewer Harm 
Waites


Hey folks,

I am proposing Harm Waites for the Kolla core team.  He did a
fantastic job implementing Designate in a container[1] which I’m
sure was incredibly difficult and never gave up even though there
were 13 separate patch reviews :)  Beyond Harm’s code
contributions, he is responsible for 32% of the “independent”
reviews[1] where independents compose 20% of our total reviewer
output.  I think we should judge core reviewers on more then
output, and I knew Harm was core reviewer material with his
fantastic review of the cinder container where he picked out 26
specific things that could be broken that other core reviewers may
have missed ;) [3].  His other reviews are also as thorough as
this particular review was.  Harm is active in IRC and in our
meetings for which his TZ fits.  Finally Harm has agreed to
contribute to the ansible-multi implementation that we will finish
in the liberty-2 cycle.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote
is a veto for the candidate, so if you are on the fence, best to
abstain :)  Since our core team has grown a bit, I’d like 3 core
reviewer +1 votes this time around (vs Sam’s 2 core reviewer
votes).  I will leave the voting open until June 21  UTC.  If
the vote is unanimous prior to that time or a veto vote is
received, I’ll close voting and make appropriate adjustments to
the gerrit groups.

Regards
-steve

[1] https://review.openstack.org/#/c/182799/
[2]

http://stackalytics.com/?project_type=allmodule=kollacompany=%2aindependent
[3] https://review.openstack.org/#/c/170965/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

[Harm Weites]

I'm ok with moving to 16:30 UTC instead of staying at 16:00.

I actually prefer it in my evening schedule :) Moving to 16:30 would 
already be a great improvement to the current schedule and should at 
least allow me to not miss everything.


- harmw

Op 12-06-15 om 15:44 schreef Steven Dake (stdake):

Even though 7am is not ideal for the west coast, I¹d be willing to go back
that far.  That would put the meeting at the morning school rush for the
west coast folks though (although we are in summer break in the US and we
could renegotiate a time in 3 months when school starts up again if its a
problem) - so creating different set of problems for different set of
people :)

This would be a 1400 UTC meeting.

While I wake up prior to 7am, (usually around 5:30) I am not going to put
people through the torture of a 6am meeting in any timezone if I can help
it so 1400 is the earliest we can go :)

Regards
-steve


On 6/12/15, 4:37 AM, Paul Bourke paul.bou...@oracle.com wrote:


I'm fairly easy on this but, if the issue is that the meeting is running
into people's evening schedules (in EMEA), would it not make sense to
push it back an hour or two into office hours, rather than forward?

On 10/06/15 18:20, Ryan Hallisey wrote:

After some upstream discussion, moving the meeting from 1600 to 1700
UTC does not seem very popular.
It was brought up that changing the time to 16:30 UTC could accommodate
more people.

For the people that attend the 1600 UTC meeting time slot can you post
further feedback to address this?

Thanks,
Ryan

- Original Message -
From: Jeff Peeler jpee...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Tuesday, June 9, 2015 2:19:00 PM
Subject: Re: [openstack-dev] [kolla] Proposal for changing 1600UTC
meeting to 1700 UTC

On Mon, Jun 08, 2015 at 05:15:54PM +, Steven Dake (stdake) wrote:

Folks,

Several people have messaged me from EMEA timezones that 1600UTC fits
right into the middle of their family life (ferrying kids from school
and what-not) and 1700UTC while not perfect, would be a better fit
time-wise.

For all people that intend to attend the 1600 UTC, could I get your
feedback on this thread if a change of the 1600UTC timeslot to 1700UTC
would be acceptable?  If it wouldn¹t be acceptable, please chime in as
well.

Both 1600 and 1700 UTC are fine for me.

Jeff


_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] ipv6 and ipv4 dual stack for floating IP

[Harm Weites]

I'm seeing the same error when trying to setup a whole new network
through Horizon with external gateway and an ipv4 and ipv6 subnet. Eg,
without floating ip.

l3_agent.py is trying this: prefixlen =
netaddr.IPNetwork(port['subnet']['cidr']).prefixlen

Looking inside port[] lists the following items:

2014-10-30 10:26:05.834 21765 ERROR neutron.agent.l3_agent [-] Ignoring
multiple IPs on router port b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.836 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[status] = DOWN
2014-10-30 10:26:05.837 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:host_id] = myhostname
2014-10-30 10:26:05.839 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[name] =
2014-10-30 10:26:05.840 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[allowed_address_pairs] = []
2014-10-30 10:26:05.841 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[admin_state_up] = True
2014-10-30 10:26:05.843 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[network_id] = 00539791-0b2f-4628-9599-622fa00993b5
2014-10-30 10:26:05.844 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[tenant_id] =
2014-10-30 10:26:05.846 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[extra_dhcp_opts] = []
2014-10-30 10:26:05.847 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_details] = {}
2014-10-30 10:26:05.848 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_type] = binding_failed
2014-10-30 10:26:05.849 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_owner] = network:router_gateway
2014-10-30 10:26:05.851 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[mac_address] = fa:16:3e:53:89:8d
2014-10-30 10:26:05.853 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:profile] = {}
2014-10-30 10:26:05.854 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vnic_type] = normal
2014-10-30 10:26:05.856 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[fixed_ips] = [{u'subnet_id':
u'faaf9c91-19ce-4c14-8f86-c81949cdbac5', u'ip_address':
u'192.168.64.30'}, {u'subnet_id':
u'381d0c54-1a4e-4a27-9858-a81202e81487', u'ip_address':
u'2001:470::64::'}]
2014-10-30 10:26:05.857 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[id] = b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.858 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[security_groups] = []
2014-10-30 10:26:05.860 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_id] = d3bbec5a-2075-4229-ba88-698f27cd0943

_set_subnet_info() is set to log an ERROR when it encounters multiple
addresses and then happily continues doing something:

 prefixlen = netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
 port['ip_cidr'] = %s/%s % (ips[0]['ip_address'], prefixlen)

Operations with just 1 (ipv6) ip go without any issues, the adress is
added to a namespace and pongs just fine. Adding 2 subnets to this
external net and creating a gateway to it on the l3 router causes a problem.

Do we need to wait for K before we can fully go dual-stack?

- Harm

op 29-10-14 15:29, Jerry Xinyu Zhao schreef:
 Hi
 I want to use both ipv4 and ipv6 for floating ip at the same time.
 However, I have the following issue when setting router gateway or
 associate floating ip to an instance.
 Is it supported in the first place? What should I do to make it work?
 Thanks!

 neutron router-list
 +--++---+-+---+
 | id   | name   |
 external_gateway_info
  
  
 |
 distributed | ha|
 +--++---+-+---+
 | b243c786-4648-4d69-b749-ee5fad02069b | default-router |
 {network_id: 02eca54a-420d-4d52-b045-1207e17994e5, enable_snat:
 true, external_fixed_ips: [{subnet_id:
 a188333f-77c3-40d9-9048-e733c4da30b1, ip_address: 162.3.123.51},
 {subnet_id: 14d9dd91-b315-43bc-818d-ab21f62c1ebb, ip_address:
 2001:470:1f0f:cb4::7}]} | False   | False |
 

Re: [openstack-dev] Status of Neutron IPv6 dual stack

[Harm Weites]

Hi Dane,

Just wondering if you've made some progression on the matter :)

Regards,
Harm

op 19-08-14 19:08, Dane Leblanc (leblancd) schreef:

 Hi Harm:

  

 Unfortunately I haven't had time to complete the changes yet. Even
 if/when these changes are completed, it's unlikely that this blueprint
 will get approved for Juno, but I'll see what I can do.

  

 Thanks,

 Dane

  

  

 *From:*Harm Weites [mailto:h...@weites.com]
 *Sent:* Tuesday, August 19, 2014 12:53 PM
 *To:* openstack-dev@lists.openstack.org
 *Subject:* Re: [openstack-dev] Status of Neutron IPv6 dual stack

  

 Thiago,

 My old setup was dual-stacked, simply using a flat linuxbridge. It's
 just that I now realy would like to separate multiple tenants using L3
 routers, which should be easy (dual stacked) to achieve once Dane's
 work is completed.

 Did you find the time to commit those required changes for that yet Dane?

 Regards,
 Harm

 op 16-08-14 23:33, Martinx - ? schreef:

 Guys,

  

 Just for the record, I'm using IceHouse in a Dual-Stacked
 environment (with security groups working) but, Instance's IPv6
 address are static (no upstream SLAAC, arrived in Juno-2, I think)
 and the topology is `VLAN Provider Networks`, no Neutron L3
 Router. Where each VLAN have v4/v6 addrs, same upstream router
 (also dual-stacked - still no radvd enabled).

  

 Looking forward to start testing L3 + IPv6 in K...

  

 Best,

 Thiago

  

 On 16 August 2014 16:21, Harm Weites h...@weites.com
 mailto:h...@weites.com wrote:

 Hi Dane,

 Thanks, that looks promising. Once support for multiple v6
 addresses on
 gateway ports is added I'll be happy to give this a go. Should it work
 just fine with an otherwise Icehouse based deployment?

 Regards,
 Harm

 op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:

  Hi Harm:
 
  Can you take a look at the following, which should address this:

  https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes
 
  There are some diffs out for review for this blueprint:
 https://review.openstack.org/#/c/113339/
  but the change to support 1 V4 + multiple V6 addresses on a
 gateway port hasn't been added yet. I should be adding this soon.
 
  There was a request for a Juno feature freeze exception for this
 blueprint, but there's been no response, so this may not get
 approved until K release.
 
  -Dane
 
  -Original Message-
  From: Harm Weites [mailto:h...@weites.com mailto:h...@weites.com]
  Sent: Saturday, August 16, 2014 2:22 PM
  To: openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
  Subject: [openstack-dev] Status of Neutron IPv6 dual stack
 
  Hi,
 
  Given the work on [1] has been abandoned, I'm wondering what the
 current status of going dual stack is. Of course, given Neutron
 got something like that on it's roadmap.
 
  The initial BP [2] aimed for Havana and Icehouse, and I'm
 unaware of something similar to achieve a dual stack network. What
 are the options, if any? To my knowledge it all comes down to
 supporting multiple exterior interfaces (networks) on a l3-agent,
 which is currently limited to just 1: either IP4 or IP6.
 
  [1] https://review.openstack.org/#/c/77471/
  [2]
 
 
 https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
 
  Regards,
  Harm
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

  




 ___

 OpenStack-dev mailing list

 OpenStack-dev@lists.openstack.org 
 mailto:OpenStack-dev@lists.openstack.org

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

  



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Status of Neutron IPv6 dual stack

[Harm Weites]

Thiago,

My old setup was dual-stacked, simply using a flat linuxbridge. It's
just that I now realy would like to separate multiple tenants using L3
routers, which should be easy (dual stacked) to achieve once Dane's work
is completed.

Did you find the time to commit those required changes for that yet Dane?

Regards,
Harm

op 16-08-14 23:33, Martinx - ? schreef:
 Guys,

 Just for the record, I'm using IceHouse in a Dual-Stacked environment
 (with security groups working) but, Instance's IPv6 address are static
 (no upstream SLAAC, arrived in Juno-2, I think) and the topology is
 `VLAN Provider Networks`, no Neutron L3 Router. Where each VLAN have
 v4/v6 addrs, same upstream router (also dual-stacked - still no radvd
 enabled).

 Looking forward to start testing L3 + IPv6 in K...

 Best,
 Thiago


 On 16 August 2014 16:21, Harm Weites h...@weites.com
 mailto:h...@weites.com wrote:

 Hi Dane,

 Thanks, that looks promising. Once support for multiple v6
 addresses on
 gateway ports is added I'll be happy to give this a go. Should it work
 just fine with an otherwise Icehouse based deployment?

 Regards,
 Harm

 op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:
  Hi Harm:
 
  Can you take a look at the following, which should address this:

  https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes
 
  There are some diffs out for review for this blueprint:
 https://review.openstack.org/#/c/113339/
  but the change to support 1 V4 + multiple V6 addresses on a
 gateway port hasn't been added yet. I should be adding this soon.
 
  There was a request for a Juno feature freeze exception for this
 blueprint, but there's been no response, so this may not get
 approved until K release.
 
  -Dane
 
  -Original Message-
  From: Harm Weites [mailto:h...@weites.com mailto:h...@weites.com]
  Sent: Saturday, August 16, 2014 2:22 PM
  To: openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
  Subject: [openstack-dev] Status of Neutron IPv6 dual stack
 
  Hi,
 
  Given the work on [1] has been abandoned, I'm wondering what the
 current status of going dual stack is. Of course, given Neutron
 got something like that on it's roadmap.
 
  The initial BP [2] aimed for Havana and Icehouse, and I'm
 unaware of something similar to achieve a dual stack network. What
 are the options, if any? To my knowledge it all comes down to
 supporting multiple exterior interfaces (networks) on a l3-agent,
 which is currently limited to just 1: either IP4 or IP6.
 
  [1] https://review.openstack.org/#/c/77471/
  [2]
 
 
 https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
 
  Regards,
  Harm
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Status of Neutron IPv6 dual stack

[Harm Weites]

Hi,

Given the work on [1] has been abandoned, I'm wondering what the current
status of going dual stack is. Of course, given Neutron got something
like that on it's roadmap.

The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of
something similar to achieve a dual stack network. What are the options,
if any? To my knowledge it all comes down to supporting multiple
exterior interfaces (networks) on a l3-agent, which is currently limited
to just 1: either IP4 or IP6.

[1] https://review.openstack.org/#/c/77471/
[2]
https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port

Regards,
Harm

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Status of Neutron IPv6 dual stack

[Harm Weites]

Hi Dane,

Thanks, that looks promising. Once support for multiple v6 addresses on
gateway ports is added I'll be happy to give this a go. Should it work
just fine with an otherwise Icehouse based deployment?

Regards,
Harm

op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:
 Hi Harm:

 Can you take a look at the following, which should address this:
 https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes

 There are some diffs out for review for this blueprint:
https://review.openstack.org/#/c/113339/
 but the change to support 1 V4 + multiple V6 addresses on a gateway port 
 hasn't been added yet. I should be adding this soon.

 There was a request for a Juno feature freeze exception for this blueprint, 
 but there's been no response, so this may not get approved until K release.

 -Dane 

 -Original Message-
 From: Harm Weites [mailto:h...@weites.com] 
 Sent: Saturday, August 16, 2014 2:22 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] Status of Neutron IPv6 dual stack

 Hi,

 Given the work on [1] has been abandoned, I'm wondering what the current 
 status of going dual stack is. Of course, given Neutron got something like 
 that on it's roadmap.

 The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of 
 something similar to achieve a dual stack network. What are the options, if 
 any? To my knowledge it all comes down to supporting multiple exterior 
 interfaces (networks) on a l3-agent, which is currently limited to just 1: 
 either IP4 or IP6.

 [1] https://review.openstack.org/#/c/77471/
 [2]
 https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port

 Regards,
 Harm

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev