Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Baohua Yang]

Like the policy-group naming.

The policy-target is better than policy-point, but still feel there's some
little confusing, as the target is usually meaning what it's for, but not
what it's on.

Hence, the policy-endpoint might be more exact.


On Fri, Aug 8, 2014 at 11:43 PM, Jay Pipes  wrote:

> On 08/07/2014 01:17 PM, Ronak Shah wrote:
>
>> Hi,
>> Following a very interesting and vocal thread on GBP for last couple of
>> days and the GBP meeting today, GBP sub-team proposes following name
>> changes to the resource.
>>
>>
>> policy-point for endpoint
>> policy-group for endpointgroup (epg)
>>
>> Please reply if you feel that it is not ok with reason and suggestion.
>>
>
> Thanks Ronak and Sumit for sharing. I, too, wasn't able to attend the
> meeting (was in other meetings yesterday and today).
>
> I'm very happy with the change from endpoint-group -> policy-group.
>
> policy-point is better than endpoint, for sure. The only other suggestion
> I might have would be to use "policy-target" instead of "policy-point",
> since the former clearly delineates what the object is used for (a target
> for a policy).
>
> But... I won't raise a stink about this. Sorry for sparking long and
> tangential discussions on GBP topics earlier this week. And thanks to the
> folks who persevered and didn't take too much offense to my questioning.
>
> Best,
> -jay
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron]Performance of security group

[Baohua Yang]

Great！
We met similar problems.
The current mechanisms produce too many iptables rules, and it's hard to
debug.
Really look forward to seeing a more efficient security group design.


On Thu, Jul 10, 2014 at 11:44 PM, Kyle Mestery 
wrote:

> On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang 
> wrote:
> >
> > With the deployment 'nova + neutron + openvswitch', when we bulk create
> > about 500 VM with a default security group, the CPU usage of
> neutron-server
> > and openvswitch agent is very high, especially the CPU usage of
> openvswitch
> > agent will be 100%, this will cause creating VMs failed.
> >
> > With the method discussed in mailist:
> >
> > 1) ipset optimization   (https://review.openstack.org/#/c/100761/)
> >
> > 3) sg rpc optimization (with fanout)
> > (https://review.openstack.org/#/c/104522/)
> >
> > I have implement  these two scheme in my deployment,  when we again bulk
> > create about 500 VM with a default security group, the CPU usage of
> > openvswitch agent will reduce to 10%, even lower than 10%, so I think the
> > iprovement of these two options are very efficient.
> >
> > Who can help us to review our spec?
> >
> This is great work! These are on my list of things to review in detail
> soon, but given the Neutron sprint this week, I haven't had time yet.
> I'll try to remedy that by the weekend.
>
> Thanks!
> Kyle
>
> >Best regards,
> > shihanzhang
> >
> >
> >
> >
> >
> > At 2014-07-03 10:08:21, "Ihar Hrachyshka"  wrote:
> >>-BEGIN PGP SIGNED MESSAGE-
> >>Hash: SHA512
> >>
> >>Oh, so you have the enhancement implemented? Great! Any numbers that
> >>shows how much we gain from that?
> >>
> >>/Ihar
> >>
> >>On 03/07/14 02:49, shihanzhang wrote:
> >>> Hi, Miguel Angel Ajo! Yes, the ipset implementation is ready, today
> >>> I will modify my spec, when the spec is approved, I will commit the
> >>> codes as soon as possilbe!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> At 2014-07-02 10:12:34, "Miguel Angel Ajo" 
> >>> wrote:
> 
>  Nice Shihanzhang,
> 
>  Do you mean the ipset implementation is ready, or just the
>  spec?.
> 
> 
>  For the SG group refactor, I don't worry about who does it, or
>  who takes the credit, but I believe it's important we address
>  this bottleneck during Juno trying to match nova's scalability.
> 
>  Best regards, Miguel Ángel.
> 
> 
>  On 07/02/2014 02:50 PM, shihanzhang wrote:
> > hi Miguel Ángel and Ihar Hrachyshka, I agree with you that
> > split  the work in several specs, I have finished the work (
> > ipset optimization), you can do 'sg rpc optimization (without
> > fanout)'. as the third part(sg rpc optimization (with fanout)),
> > I think we need talk about it, because just using ipset to
> > optimize security group agent codes does not bring the best
> > results!
> >
> > Best regards, shihanzhang.
> >
> >
> >
> >
> >
> >
> >
> >
> > At 2014-07-02 04:43:24, "Ihar Hrachyshka" 
> > wrote:
> >>> On 02/07/14 10:12, Miguel Angel Ajo wrote:
> >>>
>  Shihazhang,
> >>>
>  I really believe we need the RPC refactor done for this cycle,
>  and given the close deadlines we have (July 10 for spec
>  submission and July 20 for spec approval).
> >>>
>  Don't you think it's going to be better to split the work in
>  several specs?
> >>>
>  1) ipset optimization   (you) 2) sg rpc optimization (without
>  fanout) (me) 3) sg rpc optimization (with fanout) (edouard, you
>  , me)
> >>>
> >>>
>  This way we increase the chances of having part of this for the
>  Juno cycle. If we go for something too complicated is going to
>  take more time for approval.
> >>>
> >>>
> >>> I agree. And it not only increases chances to get at least some of
> >>> those highly demanded performance enhancements to get into Juno,
> >>> it's also "the right thing to do" (c). It's counterproductive to
> >>> put multiple vaguely related enhancements in single spec. This
> >>> would dim review focus and put us into position of getting
> >>> 'all-or-nothing'. We can't afford that.
> >>>
> >>> Let's leave one spec per enhancement. @Shihazhang, what do you
> >>> think?
> >>>
> >>>
>  Also, I proposed the details of "2", trying to bring awareness
>  on the topic, as I have been working with the scale lab in Red
>  Hat to find and understand those issues, I have a very good
>  knowledge of the problem and I believe I could make a very fast
>  advance on the issue at the RPC level.
> >>>
>  Given that, I'd like to work on this specific part, whether or
>  not we split the specs, as it's something we believe critical
>  for neutron scalability and thus, *nova parity*.
> >>>
>  I will start a separate spec for "2", later on, if you find it
>  ok, we keep them as separate ones, if you believe having just 1
>  spec (for 1 & 2) is going be safer for juno-* approval, then we
>  can in

Re: [openstack-dev] Thought on service plugin architecture (was [Neutron][QoS] Request to be considered for neutron-incubator)

[Baohua Yang]

+1
The agent number should be limited restrictly.


On Thu, Aug 21, 2014 at 8:56 AM, loy wolfe  wrote:

>
>
>
> On Wed, Aug 20, 2014 at 7:03 PM, Salvatore Orlando 
> wrote:
>
>> As the original thread had a completely different subject, I'm starting a
>> new one here.
>>
>> More specifically the aim of this thread is about:
>> 1) Define when a service is best implemented with a service plugin or
>> with a ML2 driver
>> 2) Discuss how bindings between a "core" resource and the one provided by
>> the service plugin should be exposed at the management plane, implemented
>> at the control plane, and if necessary also at the data plane.
>>
>> Some more comments inline.
>>
>> Salvatore
>>
>>
>>> When a port is created, and it has Qos enforcement thanks to the service
>>> plugin,
>>> let's assume that a ML2 Qos Mech Driver can fetch Qos info and send
>>> them back to the L2 agent.
>>> We would probably need a Qos Agent which communicates with the plugin
>>> through a dedicated topic.
>>>
>>
>> A distinct agent has pro and cons. I think however that we should try and
>> limit the number of agents on the hosts to a minimum. And this minimum in
>> my opinion should be 1! There is already a proposal around a modular agent
>> which should be able of loading modules for handling distinct services. I
>> think that's the best way forward.
>>
>>
>
> +1
> consolidated modular agent can greatly reduce rpc communication with
> plugin, and redundant code . If we can't merge it to a single "Neutron
> agent" now, we can at least merge into two agents: modular L2 agent, and
> modular L3+ agent
>
>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Neutron][DevStack] How to increase developer usage of Neutron

[Baohua Yang]

Through my experience, RDO should be the most reliable way to do the
deployment.
Also, there're some more detailed installation scripts, like
https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst
.

Still, I think, as a developer, it would be nice to have a deeper
understanding of the underlay implementation.


On Thu, Aug 14, 2014 at 9:25 PM, Mike Spreitzer  wrote:

> I'll bet I am not the only developer who is not highly competent with
> bridges and tunnels, Open VSwitch, Neutron configuration, and how DevStack
> transmutes all those.  My bet is that you would have more developers using
> Neutron if there were an easy-to-find and easy-to-follow recipe to use, to
> create a developer install of OpenStack with Neutron.  One that's a pretty
> basic and easy case.  Let's say a developer gets a recent image of Ubuntu
> 14.04 from Canonical, and creates an instance in some undercloud, and that
> instance has just one NIC, at 10.9.8.7/16.  If there were a recipe for
> such a developer to follow from that point on, it would be great.
>
> Regards,
> Mike
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Neutron] Author tags

[Baohua Yang]

+1.


On Wed, Aug 27, 2014 at 10:25 PM, Kyle Mestery  wrote:

> On Wed, Aug 27, 2014 at 8:24 AM, Gary Kotton  wrote:
> > Hi,
> > A few cycles ago the Nova group decided to remove @author from copyright
> > statements. This is due to the fact that this information is stored in
> git.
> > After adding a similar hacking rule to Neutron it has stirred up some
> > debate.
> > Does anyone have any reason to for us not to go ahead with
> > https://review.openstack.org/#/c/112329/.
> > Thanks
> > Gary
> >
> My main concern is around landing a change like this during feature
> freeze week, I think at best this should land at the start of Kilo.
>
> > ___
> > 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
>



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

Re: [openstack-dev] [neutron] New meeting rotation starting next week

[Baohua Yang]

+1.
This would be better!
Maybe we can send a google calendar invitation.


On Thu, Sep 4, 2014 at 7:45 AM, Sukhdev Kapur 
wrote:

> +1
>
> It will be very useful to have neutron specific meetings on iCal -
> considering that they will be moving around...
>
> -Sukhdev
>
>
>
> On Mon, Sep 1, 2014 at 6:58 PM, Kevin Benton  wrote:
>
>> Unfortunately the master ICAL has so many meetings that it's not useful
>> to have displaying as part of a normal calendar.
>> I was hoping for a Neutron-specific one similar to Tripleo's.
>>
>>
>> On Mon, Sep 1, 2014 at 6:52 PM, Anne Gentle  wrote:
>>
>>> Look on https://wiki.openstack.org/wiki/Meetings for a link to an iCal
>>> feed of all OpenStack meetings.
>>>
>>>
>>> https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Sep 1, 2014 at 8:26 PM, Kevin Benton  wrote:
>>>
 Is it possible to put an iCal on the wiki so we can automatically see
 when meetings are updated/cancelled/moved?
  On Sep 1, 2014 6:23 PM, "Kyle Mestery"  wrote:

> Per discussion again today in the Neutron meeting, next week we'll
> start rotating the meeting. This will mean next week we'll meet on
> Tuesday (9-9-2014) at 1400 UTC in #openstack-meeting-alt.
>
> I've updated the Neutron meeting page [1] as well as the meeting wiki
> page [2] with the new details on the meeting page.
>
> Please add any agenda items to the page.
>
> Looking forward to seeing some new faces who can't normally join us at
> the 2100UTC slot!
>
> Thanks,
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Network/Meetings
> [2] https://wiki.openstack.org/wiki/Meetings#Neutron_team_meeting
>
> ___
> 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
>>>
>>>
>>
>>
>> --
>> Kevin Benton
>>
>> ___
>> 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
>
>


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

Re: [openstack-dev] [all] Alpha release of Congress

[Baohua Yang]

Congrats!
Will appear in J or K?
And will there's an interface in horizon?
Thanks!


On Thu, Sep 4, 2014 at 5:41 AM, Tim Hinrichs  wrote:

> Hi all,
>
> The alpha release of Congress is now available!  We'd love any and all
> feedback.
>
> Components and Features
> - Support for policy monitoring
> - Policy engine implementation
> - Message-passing architecture
> - Drivers for Nova and Neutron
> - Devstack integration
> - Documentation
> - REST API
>
> README (with install instructions):
> https://github.com/stackforge/congress/blob/master/README.rst
>
> Tutorial:
>
> https://github.com/stackforge/congress/blob/master/doc/source/tutorial-tenant-sharing.rst
>
> Troubleshooting:
>
> https://github.com/stackforge/congress/blob/master/doc/source/troubleshooting.rst
>
> Contributors (IRC, Reviews, Code):
> Sergio Cazzolato (sjcazzol)
> Peter Balland (pballand)
> Mohammad Banikazemi (banix)
> Rajdeep Dua (rajdeep)
> Conner Ferguson (Radu)
> Tim Hinrichs (thinrichs)
> Gokul Kandiraju (gokul)
> Harrison Kelly (harrisonkelly)
> Prabhakar Kudva (kudva)
> Susanta Nanda (skn)
> Sean Roberts (sarob)
> Iben Rodriguez (iben)
> Aaron Rosen (arosen)
> Derick Winkworth (cloudtoad)
> Alex Yip (alexsyip)
>
>
> Sincerely,
> The Congress team
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] China blocking access to OpenStack git review push

[Baohua Yang]

There're several ways to overcome the problem.
Other than https,  using the socks proxy is also possible.
$ sudo aptitude install connect-proxy ##for windows, just install the git
$ cat ~/.ssh/config
Host review.openstack.org
ProxyCommand connect -S *PROXY_IP*:*PORT* %h %p
IdentityFile ~/.ssh/id_rsa
TCPKeepAlive yes
IdentitiesOnly yes
PreferredAuthentications publickey



On Tue, Sep 9, 2014 at 9:37 AM, Huang Zhiteng  wrote:

> I am a China Telecom user and have been blocked by the same issue for
> days.  I actually reported this to China Telecom customer service.  I
> don't expect these ISPs have the authority to unblock this, all I
> wanted is they file something to GFW so that those guys would be aware
> that one innocent site got blocked.  Well, until then I'll go with
> Clark's suggestion with https.
>
> On Mon, Sep 8, 2014 at 12:20 PM, Thomas Goirand  wrote:
> > Am I dreaming, or is the Chinese government is trying to push for the
> > cloud, they said. However, today, bad surprise:
> >
> > # nmap -p 29418 23.253.232.87
> >
> > Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST
> > Nmap scan report for review.openstack.org (23.253.232.87)
> > Host is up (0.21s latency).
> > PORT  STATESERVICE
> > 29418/tcp filtered unknown
> >
> > Oh dear ... not fun!
> >
> > FYI, this is from China Unicom (eg: CNC Group)
> >
> > I'm guessing that this is the Great Firewall of China awesome automated
> > ban script which detected too many ssh connection to a weird port. It
> > has blocked a few of my servers recently too, as it became a way too
> > aggressive. I very much prefer to use my laptop to use git review than
> > having to bounce around servers. :(
> >
> > Are their alternative IPs that I could use for review.openstack.org?
> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> > P.S: If a Chinese official read this, an easy way to unlist (legitimate)
> > servers access would be the first action any reasonable Chinese
> > government people must do.
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Regards
> Huang Zhiteng
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

[Baohua Yang]

Agree.
It's necessary for neutron to have GBP, and we can certainly utilize
stackforge to help improve it.


On Fri, Sep 5, 2014 at 11:08 PM, Mohammad Banikazemi  wrote:

> I can only see the use of a separate project for Group Policy as a
> tactical and temporary solution. In my opinion, it does not make sense to
> have the Group Policy as a separate project outside Neutron (unless the new
> project is aiming to replace Neutron and I do not think anybody is
> suggesting that). In this regard, Group Policy is not similar to Advanced
> Services such as FW and LB.
>
> So, using StackForge to get things moving again is fine but let us keep in
> mind (and see if we can agree on) that we want to have the Group Policy
> abstractions as part of OpenStack Networking (when/if it proves to be a
> valuable extension to what we currently have). I do not want to see our
> decision to make things moving quickly right now prevent us from achieving
> that goal. That is why I think the other two approaches (from the little I
> know about the incubator option, and even littler I know about the feature
> branch option) may be better options in the long run.
>
> If I understand it correctly some members of the community are actively
> working on these options (that is, the incubator and the Neutron feature
> branch options) . In order to make a better judgement as to how to proceed,
> it would be very helpful if we get a bit more information on these two
> options and their status here on this mailing list.
>
> Mohammad
>
>
>
> [image: Inactive hide details for Kevin Benton ---09/05/2014 04:31:05
> AM---Tl;dr - Neutron incubator is only a wiki page with many unce]Kevin
> Benton ---09/05/2014 04:31:05 AM---Tl;dr - Neutron incubator is only a wiki
> page with many uncertainties. Use StackForge to make progre
>
> From: Kevin Benton 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 09/05/2014 04:31 AM
> Subject: Re: [openstack-dev] [neutron][policy] Group-based Policy next
> steps
> --
>
>
>
> Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use
> StackForge to make progress and re-evaluate when the incubator exists.
>
>
> I also agree that starting out in StackForge as a separate repo is a
> better first step. In addition to the uncertainty around packaging and
> other processes brought up by Mandeep, I really doubt the Neutron incubator
> is going to have the review velocity desired by the group policy
> contributors. I believe this will be the case based on the Neutron
> incubator patch approval policy in conjunction with the nature of the
> projects it will attract.
>
> Due to the requirement for two core +2's in the Neutron incubator, moving
> group policy there is hardly going to do anything to reduce the load on the
> Neutron cores who are in a similar overloaded position as the Nova
> cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron
> incubator receive even less core attention than the main repo simply
> because their location outside of openstack/neutron will be a good reason
> to treat them with a lower priority.
>
> If you combine that with the fact that the incubator is designed to house
> all of the proposed experimental features to Neutron, there will be a very
> high volume of patches constantly being proposed to add new features, make
> changes to features, and maybe even fix bugs in those features. This new
> demand for reviewers will not be met by the existing core reviewers because
> they will be busy with refactoring, fixing, and enhancing the core Neutron
> code.
>
> Even ignoring the review velocity issues, I see very little benefit to GBP
> starting inside of the Neutron incubator. It doesn't guarantee any
> packaging with Neutron and Neutron code cannot reference any incubator
> code. It's effectively a separate repo without the advantage of being able
> to commit code quickly.
>
> There is one potential downside to not immediately using the Neutron
> incubator. If the Neutron cores decide that all features must live in the
> incubator for at least 2 cycles regardless of quality or usage in
> deployments, starting outside in a StackForge project would delay the start
> of the timer until GBP makes it into the incubator. However, this can be
> considered once the incubator actually exists and starts accepting
> submissions.
>
> In summary, I think GBP should move to a StackForge project as soon as
> possible so development can progress. A transition to the Neutron incubator
> can be evaluated once it actually becomes something more than a wiki page.
>
>
> 1.
> *http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html*
> 
>
> --
> Kevin Benton
>
>
> On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami <*dh...@noironetworks.com*
> > wrote:
>
>
>I agree. Also, as this does n

Re: [openstack-dev] [nova][neutron] default allow security group

[Baohua Yang]

Not arguing if it's suitable to implement this with security-group commands.

To solve the problem, I guess no 20 rules are necessary at all.

You can just add one rules like the following to allow all traffic going
out of the vm.

iptables -I neutron-openvswi-o9LETTERID -j RETURN
Where the id part is the first 9 letters of the vm attached port id.
This rule will bypass all security filtering for the outgoing traffic.

On Fri, Sep 5, 2014 at 11:27 PM, Monty Taylor  wrote:

> Hi!
>
> I've decided that as I have problems with OpenStack while using it in the
> service of Infra, I'm going to just start spamming the list.
>
> Please make something like this:
>
> neutron security-group-create default --allow-every-damn-thing
>
> Right now, to make security groups get the hell out of our way because
> they do not provide us any value because we manage our own iptables, it
> takes adding something like 20 rules.
>
> 15:24:05  clarkb | one each for ingress and egress udp tcp over
> ipv4 then ipv6 and finaly icmp
>
> That may be great for someone using my-first-server-pony, but for me, I
> know how the internet works, and when I ask for a server, I want it to just
> work.
>
> Now, I know, I know - the DEPLOYER can make decisions blah blah blah.
>
> BS
>
> If OpenStack is going to let my deployer make the absolutely assinine
> decision that all of my network traffic should be blocked by default, it
> should give me, the USER, a get out of jail free card.
>
> kthxbai
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Baohua Yang]

The similar problem has been discussed before.
There is no definitive answer, and currently seems we cannot simply disable
it since G version.
However, we can add some ALLOW rules to bypass the rules inside the
iptables chains.
Hope there be more flexibility to controller the security groups in the
future release.


On Tue, Sep 16, 2014 at 4:00 PM, Fawad Khaliq  wrote:

> Folks,
>
> I have had discussions with some folks individually about this but I would
> like bring this to a broader audience.
>
> I have been playing with security groups and I see the notion of 'default'
> security group seems to create some nuisance/issues.
>
> There are list of things I have noticed so far:
>
>- Tenant for OpenStack services (normally named service/services) also
>ends up having default security group.
>- Port create operation ends up ensuring default security groups for
>all the tenants as this completely seems out of the context of the tenant
>the port operation takes place. (bug?)
>- Race conditions where if system is stressed and Neutron tries to
>ensure the first default security group and in parallel another call comes,
>Neutron ends up trying to create multiple default security groups as the
>checks for duplicate groups are invalidated as soon as the call make past a
>certain point in code.
>- API performance where orchestration chooses to spawn 1000 tenants
>and we see unnecessary overhead.
>- For plugins that use RESTful proxy backends require the backend
>systems to be up at the time neutron starts. [Minor, but affects some
>packaging solutions]
>
>
> To summarize, is there a way to disable default security groups? Expected
> answer is no; can we introduce a way to disable it? If that does not make
> sense, should we go ahead and fix the issues around it?
>
> I am sure some of you must have seen some of these issues and solved them
> already. Please do share how do tackle these issues?
>
> Thanks,
> Fawad Khaliq
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] Heat dependency visualisation

[Baohua Yang]

Nice work.
We discussed similar work weeks ago.
And the idea is to generate the dot file from a heat template, and then
draw figures from the dot file.

Even in the reversed direction, we can generate a heat template from a dot
based file.

Seems the community are eager to seem some heat template visualization tool.

On Mon, Sep 15, 2014 at 11:24 PM, Alexis Lee  wrote:

> For your amusement,
>
> https://github.com/lxsli/heat-viz
>
> This produces HTML which shows which StructuredDeployments (boxes)
> depends_on each other (bold arrows). It also shows the
> StructuredDeployments which StructuredConfigs (ovals) feed into (normal
> arrows).
>
> Both CFN + HOT format files should be supported. Thanks to Steve Baker
> for the code I nicked, ahem, reused from merge.py.
>
>
> Alexis
> --
> Nova Engineer, HP Cloud.  AKA lealexis, lxsli.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Baohua Yang]

Hi fawad
Yes, you're right.
I mentioned that not to answer the exact question, but think to drop some
line around it.
I do hope we can provide the capacity in the API layer, and let the
security group become more intuitive for users.

On Tue, Sep 16, 2014 at 10:45 PM, Fawad Khaliq  wrote:

> Hi Boahua,
>
> Thanks for sharing your thoughts. The issues seen are not related to
> "access", they are all related to API layer, so having ALLOW all etc does
> not fix/workaround the problems I mentioned.
>
> Please do share if you have something more to add.
>
> Fawad Khaliq
>
> On Tue, Sep 16, 2014 at 7:28 PM, Baohua Yang  wrote:
>
>> The similar problem has been discussed before.
>> There is no definitive answer, and currently seems we cannot simply
>> disable it since G version.
>> However, we can add some ALLOW rules to bypass the rules inside the
>> iptables chains.
>> Hope there be more flexibility to controller the security groups in the
>> future release.
>>
>>
>> On Tue, Sep 16, 2014 at 4:00 PM, Fawad Khaliq  wrote:
>>
>>> Folks,
>>>
>>> I have had discussions with some folks individually about this but I
>>> would like bring this to a broader audience.
>>>
>>> I have been playing with security groups and I see the notion of
>>> 'default' security group seems to create some nuisance/issues.
>>>
>>> There are list of things I have noticed so far:
>>>
>>>- Tenant for OpenStack services (normally named service/services)
>>>also ends up having default security group.
>>>- Port create operation ends up ensuring default security groups for
>>>all the tenants as this completely seems out of the context of the tenant
>>>the port operation takes place. (bug?)
>>>- Race conditions where if system is stressed and Neutron tries to
>>>ensure the first default security group and in parallel another call 
>>> comes,
>>>Neutron ends up trying to create multiple default security groups as the
>>>checks for duplicate groups are invalidated as soon as the call make 
>>> past a
>>>certain point in code.
>>>- API performance where orchestration chooses to spawn 1000 tenants
>>>and we see unnecessary overhead.
>>>- For plugins that use RESTful proxy backends require the backend
>>>systems to be up at the time neutron starts. [Minor, but affects some
>>>packaging solutions]
>>>
>>>
>>> To summarize, is there a way to disable default security groups?
>>> Expected answer is no; can we introduce a way to disable it? If that does
>>> not make sense, should we go ahead and fix the issues around it?
>>>
>>> I am sure some of you must have seen some of these issues and solved
>>> them already. Please do share how do tackle these issues?
>>>
>>> Thanks,
>>> Fawad Khaliq
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best wishes!
>> Baohua
>>
>> ___
>> 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
>
>


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

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Baohua Yang]

Agree!
+1

On Thu, Sep 18, 2014 at 1:47 PM, Lingxian Kong  wrote:

> Hi, shihanzhang:
>
> Thanks for bringing this up, again.
>
> As I said before, this blueprint will solve the problems that the
> 'hard-coded' rules related to the default security group we are
> suffering from, which I do think will give Fawad an anser. So, I
> really hope that we can particapate all together to make this happen
> in Kilo.
>
> 2014-09-17 10:11 GMT+08:00 shihanzhang :
> > As I know there is no a way to disable default security groups, but I
> think
> > this BP can solve this problem:
> >
> https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group
> >
> >
> > 在 2014-09-17 07:44:42，"Aaron Rosen"  写道：
> >
> > Hi,
> >
> > Inline:
> >
> > On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq 
> wrote:
> >>
> >> Folks,
> >>
> >> I have had discussions with some folks individually about this but I
> would
> >> like bring this to a broader audience.
> >>
> >> I have been playing with security groups and I see the notion of
> 'default'
> >> security group seems to create some nuisance/issues.
> >>
> >> There are list of things I have noticed so far:
> >>
> >> Tenant for OpenStack services (normally named service/services) also
> ends
> >> up having default security group.
> >> Port create operation ends up ensuring default security groups for all
> the
> >> tenants as this completely seems out of the context of the tenant the
> port
> >> operation takes place. (bug?)
> >> Race conditions where if system is stressed and Neutron tries to ensure
> >> the first default security group and in parallel another call comes,
> Neutron
> >> ends up trying to create multiple default security groups as the checks
> for
> >> duplicate groups are invalidated as soon as the call make past a certain
> >> point in code.
> >
> > Right this is a bug. We should catch this foreign key constraint
> exception
> > here and pass as the default security group was already created. We do
> > something similar here when ports are created as there is a similar race
> for
> > ip_allocation.
> >>
> >>
> >> API performance where orchestration chooses to spawn 1000 tenants and we
> >> see unnecessary overhead
> >>
> >> For plugins that use RESTful proxy backends require the backend systems
> to
> >> be up at the time neutron starts. [Minor, but affects some packaging
> >> solutions]
> >
> >
> > This is probably always a requirement for neutron to work so I don't
> think
> > it's related.
> >>
> >>
> >> To summarize, is there a way to disable default security groups?
> Expected
> >> answer is no; can we introduce a way to disable it? If that does not
> make
> >> sense, should we go ahead and fix the issues around it?
> >
> >
> > I think we should fix these bugs you pointed out.
> >>
> >>
> >> I am sure some of you must have seen some of these issues and solved
> them
> >> already. Please do share how do tackle these issues?
> >>
> >> Thanks,
> >> Fawad Khaliq
> >>
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> Regards!
> ---
> Lingxian Kong
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Heat] About the DEFAULT_PAGE_SIZE

[Baohua Yang]

Hi, all
 Just notice there're several DEFAULT_PAGE_SIZE=20 lines inside the
latest python-heatclient package, e.g.,

$ grep DEFAULT_PAGE_SIZE . -r
./heatclient/v1/actions.py:DEFAULT_PAGE_SIZE = 20
./heatclient/v1/events.py:DEFAULT_PAGE_SIZE = 20
./heatclient/v1/resources.py:DEFAULT_PAGE_SIZE = 20

  What is that for? I checked the source code, but no where utilizes
that.
  From google, it seems some Java things?

  Thanks!

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

Re: [openstack-dev] [Heat] About the DEFAULT_PAGE_SIZE

[Baohua Yang]

Thanks qiming!


On Fri, Nov 28, 2014 at 12:14 AM, Qiming Teng 
wrote:

> It looks like some constants not yet used in pagination.
>
> (refer to: heatclient/v1/stacks.py: StackManager.list())
>
> Regards,
>   Qiming
>
> On Thu, Nov 27, 2014 at 03:56:07PM +0800, Baohua Yang wrote:
> > Hi, all
> >  Just notice there're several DEFAULT_PAGE_SIZE=20 lines inside the
> > latest python-heatclient package, e.g.,
> >
> > $ grep DEFAULT_PAGE_SIZE . -r
> > ./heatclient/v1/actions.py:DEFAULT_PAGE_SIZE = 20
> > ./heatclient/v1/events.py:DEFAULT_PAGE_SIZE = 20
> > ./heatclient/v1/resources.py:DEFAULT_PAGE_SIZE = 20
> >
> >   What is that for? I checked the source code, but no where utilizes
> > that.
> >   From google, it seems some Java things?
> >
> >   Thanks!
> >
> > --
> > Best wishes!
> > Baohua
>
> > ___
> > 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
>



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

Re: [openstack-dev] [kolla] on Dockerfile patterns

[Baohua Yang]

And here is the best practice for using Dockerfile.
https://docs.docker.com/articles/dockerfile_best-practices/

On Tue, Oct 14, 2014 at 11:51 AM, Angus Lees  wrote:

> I've been reading a bunch of the existing Dockerfiles, and I have two
> humble
> requests:
>
>
> 1. It would be good if the "interesting" code came from python sdist/bdists
> rather than rpms.
>
> This will make it possible to rebuild the containers using code from a
> private
> branch or even unsubmitted code, without having to go through a redhat/rpm
> release process first.
>
> I care much less about where the python dependencies come from. Pulling
> them
> from rpms rather than pip/pypi seems like a very good idea, given the
> relative
> difficulty of caching pypi content and we also pull in the required C, etc
> libraries for free.
>
>
> With this in place, I think I could drop my own containers and switch to
> reusing kolla's for building virtual testing environments.  This would
> make me
> happy.
>
>
> 2. I think we should separate out "run the server" from "do once-off
> setup".
>
> Currently the containers run a start.sh that typically sets up the
> database,
> runs the servers, creates keystone users and sets up the keystone
> catalog.  In
> something like k8s, the container will almost certainly be run multiple
> times
> in parallel and restarted numerous times, so all those other steps go
> against
> the service-oriented k8s ideal and are at-best wasted.
>
> I suggest making the container contain the deployed code and offer a few
> thin
> scripts/commands for entrypoints.  The main replicationController/pod
> _just_
> starts the server, and then we have separate pods (or perhaps even non-k8s
> container invocations) that do initial database setup/migrate, and post-
> install keystone setup.
>
> I'm open to whether we want to make these as lightweight/independent as
> possible (every daemon in an individual container), or limit it to one per
> project (eg: run nova-api, nova-conductor, nova-scheduler, etc all in one
> container).   I think the differences are run-time scalability and
> resource-
> attribution vs upfront coding effort and are not hugely significant either
> way.
>
> Post-install catalog setup we can combine into one cross-service setup like
> tripleO does[1].  Although k8s doesn't have explicit support for batch
> tasks
> currently, I'm doing the pre-install setup in restartPolicy: onFailure pods
> currently and it seems to work quite well[2].
>
> (I'm saying "post install catalog setup", but really keystone catalog can
> happen at any point pre/post aiui.)
>
> [1]
> https://github.com/openstack/tripleo-incubator/blob/master/scripts/setup-endpoints
> [2]
> https://github.com/anguslees/kube-openstack/blob/master/kubernetes-in/nova-db-sync-pod.yaml
>
> --
>  - Gus
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron] what is the different between ovs-ofctl and iptalbes? Can we use ovs-ofctl to nat floating ip into fixed ip if we use openvswitch agent?

[Baohua Yang]

As I remember, ovs does not support binding-on veth rules.
Hence now we might need tools like iptables.
However, this might change in future.

As to the l3 part, should be handled in more efficient way, e.g., NFV.


On Tue, Nov 4, 2014 at 2:29 PM, loy wolfe  wrote:

> maybe two reasons: performance caused by flow miss; feature parity
>
> L3+ flow table destroy the megaflow aggregation, so if your app has
> many concurrent sessions like web server, flow miss upcall would make
> vswitchd corrupted.
>
> iptable is already there, migrating it to ovs flow table needs a lot
> of extra development, not to say that some advanced features is lost
> (for example, stateful firewall). However ovs is considering to add
> some hook to iptable, but in the very early stage yet. Even with that,
> it is not implemented by ovs datapath flowtable, but by iptable.
>
> On Tue, Nov 4, 2014 at 1:07 PM, Li Tianqing  wrote:
> > ovs is implemented open flow, in ovs, it can see the l3, why do not use
> ovs?
> >
> > --
> > Best
> > Li Tianqing
> >
> > At 2014-11-04 11:55:46, "Damon Wang"  wrote:
> >
> > Hi,
> >
> > OVS mainly focus on l2 which iptables mainly focus on l3 or higher.
> >
> > Damon Wang
> >
> > 2014-11-04 11:12 GMT+08:00 Li Tianqing :
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Best
> >> Li Tianqing
> >>
> >>
> >>
> >> ___
> >> 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
>



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

Re: [openstack-dev] [nova][neutron] Networks without subnets

[Baohua Yang]

IMHO, the non-subnet port can be created in the technique.
This is quite useful especially when there is some special appliance, e.g.,
some firewall appliance without any IP necessarily.


On Tue, Jul 15, 2014 at 1:18 AM, Ian Wells  wrote:

> Funnily enough, when I first reported this bug I was actually trying to
> run Openstack in VMs on Openstack.  This works better now (not well; just
> better) in that there's L3 networking options, but the basic L2-VLAN
> networking option has never worked (fascinating we can't eat our own
> dogfood on this).
>
> Brent, to answer your point: networks with subnets don't work, and the
> reason they don't work is ports with 0 addresses don't work.  I've been
> thinking about this a long time, and there's two things here:
>
> - we want ports without addresses (specifically: without antispoof;
> actually, it makes reasonable sense to leave security groups on) to work
> - when people set up a network with no subnet, 99.99% of the time they do
> it it's an accident - and booting a machine on that network with no address
> and no firewalling is almost certainly not a helpful thing to be doing.
>
> In summary, I think we need a way to make no-subnet cases work (and, for
> what it's worth, the unaddressed interface blueprint in there changed tack,
> it's more about firewalling now for almost exactly that reason), I think
> it's reasonable to put one hurdle between the advanced user and their
> intent to avoid shooting the common user in the foot.  I would suggest that
> we want port-no-address cases to work when someone has explicitly disabled
> the antispoof on the port - and not otherwise.  This works with
> portsecurity right now.
>
> My beef with the portsecurity BP is that it targets OVS - this is no use
> for NFV people, because OVS plugins don't work with VLAN tags) and it
> assumes that security groups and antispoof are related when they aren't,
> which is a fundamental issue of portsecurity and makes it annoying to use.
> It's also annoying when you get portsecurity errors when it's not even
> enabled, but I think we got past that point ;)
> --
> Ian.
>
>
> On 11 July 2014 15:36, Ben Nemec  wrote:
>
>> FWIW, I believe TripleO will need this if we're going to be able to do
>> https://blueprints.launchpad.net/tripleo/+spec/tripleo-on-openstack
>>
>> Being able to have instances without IPs assigned is basically required
>> for that.
>>
>> -Ben
>>
>> On 07/11/2014 04:41 PM, Brent Eagles wrote:
>> > Hi,
>> >
>> > A bug titled "Creating quantum L2 networks (without subnets) doesn't
>> > work as expected" (https://bugs.launchpad.net/nova/+bug/1039665) was
>> > reported quite some time ago. Beyond the discussion in the bug report,
>> > there have been related bugs reported a few times.
>> >
>> > * https://bugs.launchpad.net/nova/+bug/1304409
>> > * https://bugs.launchpad.net/nova/+bug/1252410
>> > * https://bugs.launchpad.net/nova/+bug/1237711
>> > * https://bugs.launchpad.net/nova/+bug/1311731
>> > * https://bugs.launchpad.net/nova/+bug/1043827
>> >
>> > BZs on this subject seem to have a hard time surviving. The get marked
>> > as incomplete or invalid, or in the related issues, the problem NOT
>> > related to the feature is addressed and the bug closed. We seem to dance
>> > around actually getting around to implementing this. The multiple
>> > reports show there *is* interest in this functionality but at the moment
>> > we are without an actual implementation.
>> >
>> > At the moment there are multiple related blueprints:
>> >
>> > * https://review.openstack.org/#/c/99873/ ML2 OVS: portsecurity
>> >   extension support
>> > * https://review.openstack.org/#/c/106222/ Add Port Security
>> >   Implementation in ML2 Plugin
>> > * https://review.openstack.org/#/c/97715 NFV unaddressed interfaces
>> >
>> > The first two blueprints, besides appearing to be very similar, propose
>> > implementing the "port security" extension currently employed by one of
>> > the neutron plugins. It is related to this issue as it allows a port to
>> > be configured indicating it does not want security groups to apply. This
>> > is relevant because without an address, a security group cannot be
>> > applied and this is treated as an error. Being able to specify
>> > "skipping" the security group criteria gets us a port on the network
>> > without an address, which is what happens when there is no subnet.
>> >
>> > The third approach is, on the face of it, related in that it proposes an
>> > interface without an address. However, on review it seems that the
>> > intent is not necessarily inline with the some of the BZs mentioned
>> > above. Indeed there is text that seems to pretty clearly state that it
>> > is not intended to cover the port-without-an-IP situation. As an aside,
>> > the title in the commit message in the review could use revising.
>> >
>> > In order to implement something that finally implements the
>> > functionality alluded to in the above BZs in Juno, we need to settle on
>> > a

Re: [openstack-dev] [specs] how to continue spec discussion

[Baohua Yang]

Agreed.
And we should keep records for each release.


On Wed, Jul 16, 2014 at 7:57 PM, Tim Bell  wrote:

>  As we approach Juno-3, a number of specs have been correctly marked as
> abandoned since they are not expected to be ready in time for the release.
>
>
>
> Is there a mechanism to keep these specs open for discussion even though
> there is no expectation that they will be ready for Juno and ‘defer’ them
> to ‘K’ ?
>
>
>
> It seems a pity to archive the comments and reviewer lists along with
> losing a place to continue the discussions even if we are not expecting to
> see code in Juno.
>
>
>
> Tim
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Neutron] port-forwarding for router

[Baohua Yang]

Hi, ma li,
And, do you target a flexible port-forwarding (like [1], which does
mirroring) or something like DNAT (as in the [2])?
If the latter, suggest you contact the bp owner to see if can work together.

[1] https://review.openstack.org/#/c/96149/6
[2] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding


On Fri, Jul 18, 2014 at 2:57 PM, Li Ma  wrote:

> Hi folks,
>
> I'd like to implement port-forwarding for router in l3-agent node, and
> meanwhile I noticed the related blueprint[1] has been there for long.
> Unfortunately, the code review[2] has been abandoned. Is there any latest
> news about this blueprint? AFAIK, this functionality is very important for
> operators and end-users.
>
> [1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
> [2] https://review.openstack.org/#/c/60512/
>
> Thanks,
> Li Ma
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [Neutron] minimal device driver for VPN

[Baohua Yang]

Hi julio
There are not many documents currently. The only one on neutron I can
find is http://docs.openstack.org/developer/neutron/devref/index.html.
From what you described, I suggest you have a look of the neutron.
services.vpn code as an example.
And from my experience, those classes inherited from rpc.RpcProxy are
usually the handlers of rpc call, and those from rpc.RpcCallback will call
targeting methods.



On Fri, Jul 18, 2014 at 2:30 PM, Julio Carlos Barrera Juez <
juliocarlos.barr...@i2cat.net> wrote:

> Is there any documentation about these RPC messages? Or de we need to use
> examples as guide?
>
> Once again, thank you Paul.
>
>     
> Julio C. Barrera Juez  [image: View my profile on LinkedIn]
> 
> Office phone: (+34) 93 357 99 27 (ext. 527)
> Office mobile phone: (+34) 625 66 77 26
> Distributed Applications and Networks Area (DANA)
> i2CAT Foundation, Barcelona
>
>
> On 17 July 2014 20:37, Paul Michali (pcm)  wrote:
>
>> So you have your driver loading… great!
>>
>> The service driver will log in screen-q-*svc*.log, provided you have the
>> service driver called out in neutron.conf (as the only one for VPN).
>>
>> Later, you’ll need the supporting RPC classes to send messages from
>> service driver to device driver…
>>
>>
>> Regards,
>>
>>
>> PCM (Paul Michali)
>>
>> MAIL …..…. p...@cisco.com
>> IRC ……..… pcm_ (irc.freenode.com)
>> TW ………... @pmichali
>> GPG Key … 4525ECC253E31A83
>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>>
>>
>>
>> On Jul 17, 2014, at 2:18 PM, Julio Carlos Barrera Juez <
>> juliocarlos.barr...@i2cat.net> wrote:
>>
>> We have followed your advices:
>>
>> - We created our fake device driver located in the same level as other
>> device drivers
>> (/opt/stack/neutron/neutron/services/vpn//device_drivers/fake_device_driver.py):
>>
>> import abc
>> import six
>>
>> from neutron.openstack.common import log
>> from neutron.services.vpn import device_drivers
>>
>>
>> LOG = log.getLogger(__name__)
>>
>> @six.add_metaclass(abc.ABCMeta)
>> class FakeDeviceDriver(device_drivers.DeviceDriver):
>> '''
>> classdocs
>> '''
>>
>> def __init__(self, agent, host):
>> pass
>>
>> def sync(self, context, processes):
>> pass
>>
>> def create_router(self, process_id):
>> pass
>>
>> def destroy_router(self, process_id):
>> pass
>>
>>
>> - Our service driver located in
>> /opt/stack/neutron/neutron/services/vpn/service_drivers/fake_service_driver.py:
>>
>> from neutron.openstack.common import log
>>
>> LOG = log.getLogger(__name__)
>>
>> class FakeServiceDriver():
>> '''
>> classdocs
>> '''
>>
>> def get_vpnservices(self, context, filters=None, fields=None):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def get_vpnservice(self, context, vpnservice_id, fields=None):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def create_vpnservice(self, context, vpnservice):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def update_vpnservice(self, context, vpnservice_id, vpnservice):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def delete_vpnservice(self, context, vpnservice_id):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def get_ipsec_site_connections(self, context, filters=None,
>> fields=None):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def get_ipsec_site_connection(self, context,
>> ipsecsite_conn_id, fields=None):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def get_ikepolicy(self, context, ikepolicy_id, fields=None):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def get_ikepolicies(self, context, filters=None, fields=None):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def create_ikepolicy(self, context, ikepolicy):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def update_ikepolicy(self, context, ikepolicy_id, ikepolicy):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def delete_ikepolicy(self, context, ikepolicy_id):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def get_ipsecpolicies(self, context, filters=None, fields=None):
>>  LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def get_ipsecpolicy(self, context, ipsecpolicy_id, fields=None):
>> LOG.info('XX Calling method: ' + __name__)
>> pass
>>
>> def create_ipsecpolicy(self, context, ipsecpolicy):
>> LOG.info('XX

Re: [openstack-dev] [neutron] Specs repository update and the way forward

[Baohua Yang]

Great!
And, not sure if it's right, but cannot find place to compare two commits
through the website, e.g., the latest version and the last one.
Guess this would be easier to find what changes in the new patch.


On Mon, Jul 21, 2014 at 9:47 PM, Kyle Mestery  wrote:

> On Mon, Jul 21, 2014 at 8:33 AM, Carlos Gonçalves 
> wrote:
> > On 12 Jun 2014, at 15:00, Carlos Gonçalves  wrote:
> >
> > Is there any web page where all approved blueprints are being published
> to?
> > Jenkins builds such pages I’m looking for but they are linked to each
> > patchset individually (e.g.,
> >
> http://docs-draft.openstack.org/77/92477/6/check/gate-neutron-specs-docs/f05cc1d/doc/build/html/
> ).
> > In addition, listing BPs currently under reviewing and linking to its
> > review.o.o page could potentially draw more attention/awareness to what’s
> > being proposed to Neutron (and other OpenStack projects).
> >
> >
> > Kyle? :-)
> >
> I don't know of a published page, but you can always look at the git
> repository [1].
>
> [1] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno
>
> > Thanks,
> > Carlos Goncalves
> >
> > ___
> > 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
>



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

Re: [openstack-dev] [tc][rally] Application for a new OpenStack Program: Performance and Scalability

[Baohua Yang]

It's interesting and practical!
There're some early efforts to make openstack more robust and efficient,
however, we're still lacking one such framework.

Just a little question.
On the wiki, it says to consider the scalability problem.
How can we measure the performance at large scale? By real deployment or
just simulating the input?
Through the descriptions, seems the method is to try testing every single
component.

Also, suggest adding necessary perf checks into the test/integration jobs,
too.
Thanks!



On Tue, Jul 22, 2014 at 5:53 AM, Boris Pavlovic  wrote:

> Hi Stackers and TC,
>
> The Rally contributor team would like to propose a new OpenStack program
> with a mission to provide scalability and performance benchmarking, and
> code profiling tools for OpenStack components.
>
> We feel we've achieved a critical mass in the Rally project, with an
> active, diverse contributor team. The Rally project will be the initial
> project in a new proposed "Performance and Scalability" program.
>
> Below, the details on our proposed new program.
>
> Thanks for your consideration,
> Boris
>
>
>
> [1] https://review.openstack.org/#/c/108502/
>
>
> Official Name
> =
>
> Performance and Scalability
>
> Codename
> 
>
> Rally
>
> Scope
> =
>
> Scalability benchmarking, performance analysis, and profiling of
> OpenStack components and workloads
>
> Mission
> ===
>
> To increase the scalability and performance of OpenStack clouds by:
>
> * defining standard benchmarks
> * sharing performance data between operators and developers
> * providing transparency of code paths through profiling tools
>
> Maturity
> 
>
> * Meeting logs http://eavesdrop.openstack.org/meetings/rally/2014/
> * IRC channel: #openstack-rally
> * Rally performance jobs are in (Cinder, Glance, Keystone & Neutron)
> check pipelines.
> * > 950 commits over last 10 months
> * Large, diverse contributor community
>  *
> http://stackalytics.com/?release=juno&metric=commits&project_type=All&module=rally
>  * http://stackalytics.com/report/contribution/rally/180
>
> * Non official lead of project is Boris Pavlovic
>  * Official election In progress.
>
> Deliverables
> 
>
> Critical deliverables in the Juno cycle are:
>
> * extending Rally Benchmark framework to cover all use cases that are
> required by all OpenStack projects
> * integrating OSprofiler in all core projects
> * increasing functional & unit testing coverage of Rally.
>
> Discussion
> ==
>
> One of the major goals of Rally is to make it simple to share results of
> standardized benchmarks and experiments between operators and
> developers. When an operator needs to verify certain performance
> indicators meet some service level agreement, he will be able to run
> benchmarks (from Rally) and share with the developer community the
> results along with his OpenStack configuration. These benchmark results
> will assist developers in diagnosing particular performance and
> scalability problems experienced with the operator's configuration.
>
> Another interesting area is Rally & the OpenStack CI process. Currently,
> working on performance issues upstream tends to be a more social than
> technical process. We can use Rally in the upstream gates to identify
> performance regressions and measure improvement in scalability over
> time. The use of Rally in the upstream gates will allow a more rigorous,
> scientific approach to performance analysis. In the case of an
> integrated OSprofiler, it will be possible to get detailed information
> about API call flows (e.g. duration of API calls in different services).
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

[Baohua Yang]

Hi, all
 The current oslo.cfg module provides an easy way to load name known
options/groups from he configuration files.
  I am wondering if there's a possible solution to dynamically load
them?

  For example, I do not know the group names (section name in the
configuration file), but we read the configuration file and detect the
definitions inside it.

#Configuration file:
[group1]
key1 = value1
key2 = value2

   Then I want to automatically load the group1. key1 and group2. key2,
without knowing the name of group1 first.

Thanks a lot!

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

Re: [openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

[Baohua Yang]

Dear all
Thanks for all the responses!
First, I threw the question actually wanting to hear other voices of
the similar requirements of dynamic parsing.
Glad to get all supports and also questions.
The scenario is that sometime we might define some groups in the config
file with changing names. One not appropriated example is that we add a
network element with properties as
[xxx_box]
property1=aaa
property2=bbb

In this case, the parser should automatically read in the xxx_box and
parses its properties, which would extend the power of the current config
lib.
Although we can utilize explicit definitions of groups names in our
code to ignore uninterested groups in the configuration file, I think it
would be more flexible to keep the functionality to read in those undefined
groups.
Now I am sure it's impossible to do so with existing olso.config lib.
Thanks for all the feedbacks, and would like to get more comments on
whether we should implement this!









On Fri, Jul 25, 2014 at 1:58 AM, Yuriy Taraday  wrote:

>
>
>
> On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann 
> wrote:
>
>>
>> On Jul 23, 2014, at 11:10 PM, Baohua Yang  wrote:
>>
>> Hi, all
>>  The current oslo.cfg module provides an easy way to load name known
>> options/groups from he configuration files.
>>   I am wondering if there's a possible solution to dynamically load
>> them?
>>
>>   For example, I do not know the group names (section name in the
>> configuration file), but we read the configuration file and detect the
>> definitions inside it.
>>
>> #Configuration file:
>> [group1]
>> key1 = value1
>> key2 = value2
>>
>>Then I want to automatically load the group1. key1 and group2.
>> key2, without knowing the name of group1 first.
>>
>>
>> If you don’t know the group name, how would you know where to look in the
>> parsed configuration for the resulting options?
>>
>
> I can imagine something like this:
> 1. iterate over undefined groups in config;
> 2. select groups of interest (e.g. by prefix or some regular expression);
> 3. register options in them;
> 4. use those options.
>
> Registered group can be passed to a plugin/library that would register its
> options in it.
>
> So the only thing that oslo.config lacks in its interface here is some way
> to allow the first step. The rest can be overcomed with some sugar.
>
> --
>
> Kind regards, Yuriy.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

[Baohua Yang]

Woo~
Really nice work!


On Thu, Aug 7, 2014 at 7:09 AM, Sukhdev Kapur 
wrote:

> Folks,
>
> Just wanted to share with you that Arista CI has been up and running 24x7
> since the beginning of this year with no down time.
>
> This morning it posted a vote on 10,000th Neutron patch
>
> cheers..
> -Sukhdev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

[Baohua Yang]

+1.
And the review process should be more efficient!



On Thu, Aug 7, 2014 at 3:07 AM, Stefano Maffulli 
wrote:

> On 08/06/2014 11:19 AM, Edgar Magana wrote:
> > That is the beauty of the open source projects, there is always a
> smartest
> > reviewer catching out the facts that you don¹t.
>
> And yet, the specification clearly talks about 'endpoints' and nobody
> caught it where it supposed to be caught so I fear that something failed
> badly here:
>
> https://review.openstack.org/#/c/89469/10
>
> What failed and how we make sure this doesn't happen again? This to me
> is the most important question to answer.  If I remember correctly we
> introduced the concept of Specs exactly to discuss on the ideas *before*
> the implementation starts. We wanted things like architecture, naming
> conventions and other important decisions to be socialized and agreed
> upon *before* code was proposed. We wanted to avoid developers to spend
> time implementing features in ways that are incompatible and likely to
> be rejected at code review time. And yet, here we are.
>
> Something failed and I would ask for all core reviewers to sit down and
> do an exercise to identify the root cause. If you want we can start from
> this specific case, do some simple root cause analysis together and take
> GBP as an example. Thoughts?
>
> /stef
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] Well-tested guides for OpenStack Icehouse installation and Instance creation with Neutron

[Baohua Yang]

Nice work.
Suggest add some watch points/problem solution/diagnosis in the
installations.
Btw, recently we find both the RDO and devstack are very unstable for
installation, wish there will be more test and improvements soon.


On Wed, Aug 6, 2014 at 3:27 AM, chayma ghribi  wrote:

>
> Hi all,
>
>
> I want to share with you our well tested OpenStack Icehouse Installation
> Guide for Ubuntu 14.04.
>
>
> https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst
>
> If you want to create your first instance with Neutron, follow the
> instructions in our VM creation guide available here:
>
>
> https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/Create-your-first-instance-with-Neutron.rst
>
> Hope this will be helpful !
> Your questions and suggestions are welcome :)
>
>
> Regards,
>
> Chaima Ghribi
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [HEAT] Is there any line length limitation in paste deploy configuration file?

[Baohua Yang]

Hi,
Recently I have noticed the api-paste. ini file in heat has some very
long lines (over the popular 80c).
Wondering if there's recommended length limitation on it?
Sometime, users have to read the file and change the configuration
value, so I think it should be kept readable.
 Thanks!

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

Re: [openstack-dev] [magnum][kolla] Stepping down as a Magnum core reviewer

[Baohua Yang]

Really a pity!

We need more resources on the container part in OpenStack indeed, as so
many new projects are just initiated.

Community is not only about putting technologies together, but also putting
technical guys together.

Happy to see so many guys in the Tokyo Summit this afternoon.

Let's take care of the opportunities to make good communications with each
other.

On Mon, Oct 26, 2015 at 8:17 AM, Steven Dake (stdake) 
wrote:

> Hey folks,
>
> It is with sadness that I find myself under the situation to have to write
> this message.  I have the privilege of being involved in two of the most
> successful and growing projects (Magnum, Kolla) in OpenStack.  I chose
> getting involved in two major initiatives on purpose, to see if I could do
> the job; to see if  I could deliver two major initiatives at the same
> time.  I also wanted it to be a length of time that was significant – 1+
> year.  I found indeed I was able to deliver both Magnum and Kolla, however,
> the impact on my personal life has not been ideal.
>
> The Magnum engineering team is truly a world class example of how an Open
> Source project should be constructed and organized.  I hope some young
> academic writes a case study on it some day but until then, my gratitude to
> the Magnum core reviewer team is warranted by the level of  their sheer
> commitment.
>
> I am officially focusing all of my energy on Kolla going forward.  The
> Kolla core team elected me as PTL (or more accurately didn’t elect anyone
> else;) and I really want to be effective for them, especially in what I
> feel is Kolla’s most critical phase of growth.
>
> I will continue to fight  for engineering resources for Magnum internally
> in Cisco.  Some of these have born fruit already including the Heat
> resources, the Horizon plugin, and of course the Networking plugin system.
> I will also continue to support Magnum from a resources POV where I can do
> so (like the fedora image storage for example).  What I won’t be doing is
> reviewing Magnum code (serving as a gate), or likely making much technical
> contribution to Magnum in the future.  On the plus side I’ve replaced
> myself with many many more engineers from Cisco who should be much more
> productive combined then I could have been alone ;)
>
> Just to be clear, I am not abandoning Magnum because I dislike the people
> or the technology.  I think the people are fantastic! And the technology –
> well I helped design the entire architecture!  I am letting Magnum grow up
> without me as I have other children that need more direct attention.  I
> think this viewpoint shows trust in the core reviewer team, but feel free
> to make your own judgements ;)
>
> Finally I want to thank Perry Myers for influencing me to excel at
> multiple disciplines at once.  Without Perry as a role model, Magnum may
> have never happened (or would certainly be much different then it is
> today). Being a solid hybrid engineer has a long ramp up time and is really
> difficult, but also very rewarding.  The community has Perry to blame for
> that ;)
>
> 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
>
>


-- 
Best wishes!
Baohua
__
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] [Neutron][Kuryr] - Design Summit etherpad

[Baohua Yang]

Thanks, and nice meeting everyone!

On Mon, Nov 2, 2015 at 2:06 PM, Gal Sagie  wrote:

> Hello All,
>
> It was great meeting everyone in the summit, it ended too fast..
> We had a free design talk on Friday about Kuryr. (Thanks to everyone that
> participated)
>
> We have created this etherpad with all the related tasks:
>
> https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track-kuryr
>
> If there is something you would like to work on, please let us know, we
> have some
> challenging and interesting tasks ahead of us.
>
> Since everyone are still recovering from the summit, we will not have an
> IRC Meeting
> today.
>
> Thanks
> Gal.
>
>
>
>
> __
> 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
>
>


-- 
Best wishes!
Baohua
__
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] [kuryr] competing implementations

[Baohua Yang]

+1, Antoni!
btw, is our weekly meeting still on meeting-4 channel?
Not found it there yesterday.

On Wed, Nov 4, 2015 at 9:27 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

> Hi Kuryrs,
>
> Last Friday, as part of the contributors meetup, we discussed also code
> contribution etiquette. Like other OpenStack project (Magnum comes to
> mind), the etiquette for what to do when there is disagreement in the way
> to code a blueprint of fix a bug is as follows:
>
> 1.- Try to reach out so that the original implementation gets closer to a
> compromise by having the discussion in gerrit (and Mailing list if it
> requires a wider range of arguments).
> 2.- If a compromise can't be reached, feel free to make a separate
> implementation arguing well its difference, virtues and comparative
> disadvantages. We trust the whole community of reviewers to be able to
> judge which is the best implementation and I expect that often the
> reviewers will steer both submissions closer than they originally were.
> 3.- If both competing implementations get the necessary support, the core
> reviewers will take a specific decision on which to take based on technical
> merit. Important factor are:
> * conciseness,
> * simplicity,
> * loose coupling,
> * logging and error reporting,
> * test coverage,
> * extensibility (when an immediate pending and blueprinted feature can
> better be built on top of it).
> * documentation,
> * performance.
>
> It is important to remember that technical disagreement is a healthy thing
> and should be tackled with civility. If we follow the rules above, it will
> lead to a healthier project and a more friendly community in which
> everybody can propose their vision with equal standing. Of course,
> sometimes there may be a feeling of duplicity, but even in the case where
> one's solution it is not selected (and I can assure you I've been there and
> know how it can feel awkward) it usually still enriches the discussion and
> constitutes a contribution that improves the project.
>
> Regards,
>
> Toni
>
> __
> 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
>
>


-- 
Best wishes!
Baohua
__
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] [kuryr] competing implementations

[Baohua Yang]

Sure, thanks!
And suggest add the time and channel information at the kuryr wiki page.


On Wed, Nov 4, 2015 at 9:45 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

>
>
> On Wed, Nov 4, 2015 at 2:38 PM, Baohua Yang  wrote:
>
>> +1, Antoni!
>> btw, is our weekly meeting still on meeting-4 channel?
>> Not found it there yesterday.
>>
>
> Yes, it is still on openstack-meeting-4, but this week we skipped it,
> since some of us were
> traveling and we already held the meeting on Friday. Next Monday it will
> be held as usual
> and the following week we start alternating (we have yet to get a room for
> that one).
>
>>
>> On Wed, Nov 4, 2015 at 9:27 PM, Antoni Segura Puimedon <
>> toni+openstac...@midokura.com> wrote:
>>
>>> Hi Kuryrs,
>>>
>>> Last Friday, as part of the contributors meetup, we discussed also code
>>> contribution etiquette. Like other OpenStack project (Magnum comes to
>>> mind), the etiquette for what to do when there is disagreement in the way
>>> to code a blueprint of fix a bug is as follows:
>>>
>>> 1.- Try to reach out so that the original implementation gets closer to
>>> a compromise by having the discussion in gerrit (and Mailing list if it
>>> requires a wider range of arguments).
>>> 2.- If a compromise can't be reached, feel free to make a separate
>>> implementation arguing well its difference, virtues and comparative
>>> disadvantages. We trust the whole community of reviewers to be able to
>>> judge which is the best implementation and I expect that often the
>>> reviewers will steer both submissions closer than they originally were.
>>> 3.- If both competing implementations get the necessary support, the
>>> core reviewers will take a specific decision on which to take based on
>>> technical merit. Important factor are:
>>> * conciseness,
>>> * simplicity,
>>> * loose coupling,
>>> * logging and error reporting,
>>> * test coverage,
>>> * extensibility (when an immediate pending and blueprinted feature
>>> can better be built on top of it).
>>> * documentation,
>>> * performance.
>>>
>>> It is important to remember that technical disagreement is a healthy
>>> thing and should be tackled with civility. If we follow the rules above, it
>>> will lead to a healthier project and a more friendly community in which
>>> everybody can propose their vision with equal standing. Of course,
>>> sometimes there may be a feeling of duplicity, but even in the case where
>>> one's solution it is not selected (and I can assure you I've been there and
>>> know how it can feel awkward) it usually still enriches the discussion and
>>> constitutes a contribution that improves the project.
>>>
>>> Regards,
>>>
>>> Toni
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Best wishes!
>> Baohua
>>
>> __
>> 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
>
>


-- 
Best wishes!
Baohua
__
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] [kuryr] mutihost networking with nova vm as docker host

[Baohua Yang]

It does cause confusing by calling container-inside-vm as nested container.

The "nested" term in container area usually means
container-inside-container.

we may refer this (container-inside-vm) explicitly as vm-holding container.

On Fri, Nov 6, 2015 at 12:13 PM, Vikas Choudhary  wrote:

> @Gal, I was asking about "container in nova vm" case.
> Not sure if you were referring to this case as nested containers case. I
> guess nested containers case would be "containers inside containers" and
> this could be hosted on nova vm and nova bm node. Is my understanding
> correct?
>
> Thanks Gal and Toni, for now i got answer to my query related to
> "container in vm" case.
>
> -Vikas
>
> On Thu, Nov 5, 2015 at 6:00 PM, Gal Sagie  wrote:
>
>> The current OVS binding proposals are not for nested containers.
>> I am not sure if you are asking about that case or about the nested
>> containers inside a VM case.
>>
>> For the nested containers, we will use Neutron solutions that support
>> this kind of configuration, for example
>> if you look at OVN you can define "parent" and "sub" ports, so OVN knows
>> to perform the logical pipeline in the compute host
>> and only perform VLAN tagging inside the VM (as Toni mentioned)
>>
>> If you need more clarification you can catch me on IRC as well and we can
>> talk.
>>
>> On Thu, Nov 5, 2015 at 8:03 AM, Vikas Choudhary <
>> choudharyvika...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I would appreciate inputs on following queries:
>>> 1. Are we assuming nova bm nodes to be docker host for now?
>>>
>>> If Not:
>>>  - Assuming nova vm as docker host and ovs as networking plugin:
>>> This line is from the etherpad[1], "Eachdriver would have
>>> an executable that receives the name of the veth pair that has to be bound
>>> to the overlay" .
>>> Query 1:  As per current ovs binding proposals by Feisky[2]
>>> and Diga[3], vif seems to be binding with br-int on vm. I am unable to
>>> understand how overlay will work. AFAICT , neutron will configure br-tun of
>>> compute machines ovs only. How overlay(br-tun) configuration will happen
>>> inside vm ?
>>>
>>>  Query 2: Are we having double encapsulation(both at vm and
>>> compute)? Is not it possible to bind vif into compute host br-int?
>>>
>>>  Query3: I did not see subnet tags for network plugin being
>>> passed in any of the binding patches[2][3][4]. Dont we need that?
>>>
>>>
>>> [1]  https://etherpad.openstack.org/p/Kuryr_vif_binding_unbinding
>>> [2]  https://review.openstack.org/#/c/241558/
>>> [3]  https://review.openstack.org/#/c/232948/1
>>> [4]  https://review.openstack.org/#/c/227972/
>>>
>>>
>>> -Vikas Choudhary
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>> __
>> 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
>
>


-- 
Best wishes!
Baohua
__
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-dev] [kuryr] Current status of docker python lib supports for libnetwork

[Baohua Yang]

Hi, kuryr guys
I may not attend tmr's IRC meeting, hence make a quick sync here.
One task is to investigate the docker python lib support to libnetwork.
I checked the code here at https://github.com/docker/docker-py.
They do have the network api support in code (in api/network.py), as
 1. create_network
 2. remove_network
 3. inspect_network
 4. connect_container_to_network
 5. disconnect_container_from_network
 Those apis are implemented by calling the rest api directly.
 But those apis are not mentioned in doc yet.
 Thanks!

-- 
Best wishes!
Baohua
__
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-dev] [kuryr] gerrit/git review problem error code 10061

[Baohua Yang]

Hi,
   Anyone recently meet such problem after cloning the latest code from
kuryr?
   Try proxy also, but not solved.

$ git review -s
Problem running 'git remote update gerrit'
Fetching gerrit
FATAL: Unable to connect to relay host, errno=10061
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch gerrit
Traceback (most recent call last):
  File "d:\Python27\lib\runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "d:\Python27\lib\runpy.py", line 72, in _run_code
exec code in run_globals
  File "d:\Python27\Scripts\git-review.exe\__main__.py", line 9, in 
  File "d:\Python27\lib\site-packages\git_review\cmd.py", line 1202, in main
set_hooks_commit_msg(remote, hook_file)
  File "d:\Python27\lib\site-packages\git_review\cmd.py", line 283, in
set_hooks_commit_msg
run_command_exc(CannotInstallHook, *cmd)
  File "d:\Python27\lib\site-packages\git_review\cmd.py", line 152, in
run_command_exc
raise klazz(rc, output, argv, env)
git_review.cmd.CannotInstallHook: Problems encountered installing
commit-msg hook
The following command failed with exit code 1
"scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg
.git\hooks\commit-msg"
---
FATAL: Unable to connect to relay host, errno=10061
ssh_exchange_identification: Connection closed by remote host


$ git remote show origin
* remote origin
  Fetch URL: git://git.openstack.org/openstack/kuryr
  Push  URL: git://git.openstack.org/openstack/kuryr
  HEAD branch: master
  Remote branch:
master tracked
  Local branch configured for 'git pull':
master merges with remote master
  Local ref configured for 'git push':
master pushes to master (local out of date)


   Thanks!

-- 
Best wishes!
Baohua
__
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] [kuryr] gerrit/git review problem error code 10061

[Baohua Yang]

Thanks to all!
It seems network connectivity problem. How sad again!  :(
i will try other ways.

On Tue, Nov 10, 2015 at 12:52 AM, Jeremy Stanley  wrote:

> On 2015-11-09 10:13:33 +0800 (+0800), Baohua Yang wrote:
> > Anyone recently meet such problem after cloning the latest code
> > from kuryr? Try proxy also, but not solved.
> [...]
> > The following command failed with exit code 1
> > "scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg
> > .git\hooks\commit-msg"
> > ---
> > FATAL: Unable to connect to relay host, errno=10061
> > ssh_exchange_identification: Connection closed by remote host
> [...]
>
> I've checked our Gerrit SSH API authentication logs from the past 30
> days and find no record of any yangbaohua authenticating. Chances
> are this is a broken local proxy or some sort of intercepting
> firewall which is preventing your 29418/tcp connection from even
> reaching review.openstack.org.
>
> If you use Telnet or NetCat to connect to port 29418 on
> review.openstack.org directly, do you see an SSH banner starting
> with a string like "SSH-2.0-GerritCodeReview_2.8.4-19-g4548330
> (SSHD-CORE-0.9.0.201311081)" or something else?
> --
> Jeremy Stanley
>
> __
> 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
>
>


-- 
Best wishes!
Baohua
__
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] [Kuryr] Testing, Rally and Wiki

[Baohua Yang]

Great!
Would try to offer a hand on the wiki and testing.

On Thu, Dec 10, 2015 at 10:11 PM, Gal Sagie  wrote:

> Hello everyone,
>
> As some of you have already noticed one of the top priorities for Kuryr
> this cycle is to get
> our CI and gate testing done.
>
> I have been working on creating the base for adding integration tests that
> will run
> in the gate in addition to our unit tests and functional testing.
>
> If you would like to join and help this effort, please stop by
> #openstack-kuryr or email
> me back.
>
> We are also working on combining Rally testing with Kuryr and for that we
> are going to
> introduce Docker context plugin and client and other parts that are
> probably needed by other projects (like Magnum)
> I think it would be great if we can combine forces on this.
>
> I have also created Kuryr Wiki:
> https://wiki.openstack.org/wiki/Kuryr
>
> Feel free to edit and add needed information.
>
>
> Thanks all
> Gal.
>
>
>
> __
> 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
>
>


-- 
Best wishes!
Baohua
__
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] [kuryr] Failed to create network with kuryr driver type

[Baohua Yang]

Hi mars
Which code are u using?

I repeated your steps with latest master branch.

And the error from kuryr is

127.0.0.1 - - [20/Jan/2016 17:23:50] "POST
/IpamDriver.GetDefaultAddressSpaces HTTP/1.1" 200 -

ERROR in controllers [/opt/stack/kuryr/kuryr/controllers.py:872]:
Default neutron pools not found

Default neutron pools not found
127.0.0.1 - - [20/Jan/2016 17:23:50] "POST /IpamDriver.RequestPool
HTTP/1.1" 200 -



On Wed, Jan 20, 2016 at 5:09 PM, Mars Ma  wrote:

> Hi Vikas,
>
> I added your fix , and also have problem, but different :
>
> $ neutron subnetpool-list
>
> +--+---+---+---+--+
> | id   | name  | prefixes  |
> default_prefixlen | address_scope_id |
>
> +--+---+---+---+--+
> | 360765af-fd5d-432c-990f-f787600c30ab | kuryr | [u'10.10.1.0/24'] | 24
>  |  |
>
> +--+---+---+---+--+
> ubuntu@kuryr1:~$ sudo docker network create -d kuryr --ipam-driver=kuryr
> kuryr
> Error response from daemon: Plugin Error: NetworkDriver.CreateNetwork, {
>   "Err": "u'Gateway' is a required property\n\nFailed validating
> u'required' in schema[u'properties'][u'IPv4Data'][u'items']:\n
>  {u'description': u'IPv4 data',\n u'example': {u'AddressSpace':
> u'foo',\n  u'AuxAddresses': {u'db': u'192.168.42.3',\n
>u'web': u'192.168.42.2'},\n
>  u'Gateway': u'192.168.42.1/24',\n  u'Pool': u'
> 192.168.42.0/24'},\n u'properties': {u'AddressSpace':
> {u'description': u'The name of the address space.',\n
> u'example': u'foo',\n
> u'type': u'string'},\n u'AuxAddresses':
> {u'description': u'A list of pre-allocated ip-addresses with an associated
> identifier as provided by the user to assist network driver if it requires
> specific ip-addresses for its operation.',\n
> u'patternProperties': {u'.+': {u'$ref':
> u'#/definitions/commons/definitions/ipv4',\n
>u'description': u'key-vavule pair of
> the ID and the IP address'}},\n
> u'type': u'object'},\n u'Gateway': {u'$ref':
> u'#/definitions/commons/definitions/cidr',\n
>u'description': u'Optionally, the IPAM driver may provide a Gateway for
> the subnet represented by the Pool.'},\n u'Pool':
> {u'$ref': u'#/definitions/commons/definitions/cidr',\n
>   u'description': u'A range of IP Addresses represted in CIDR
> format address/mask.'}},\n u'required': [u'AddressSpace', u'Pool',
> u'Gateway'],\n u'type': u'object'}\n\nOn instance[u'IPv4Data'][0]:\n
>  {u'AddressSpace': u'', u'Pool': u'10.10.1.0/24'}"
> }
> ubuntu@kuryr1:~$ neutron subnetpool-list
>
> ubuntu@kuryr1:~$
>
> Thank you & Best regards !
> Mars Ma
> -
>
> On Wed, Jan 20, 2016 at 2:48 PM, Vikas Choudhary <
> choudharyvika...@gmail.com> wrote:
>
>> Hi Mars,
>>
>> Your code seems to be missing missing this fix:
>> https://review.openstack.org/#/c/265732/
>>
>> Please try with this and let us know if any issues further.
>>
>> Thanks
>> -Vikas
>>
>>
>> On Wed, Jan 20, 2016 at 11:41 AM, Mars Ma  wrote:
>>
>>> hi Vikas,
>>>
>>> Thanks for your reply, I tried your method, looks like that the previous
>>> problem disappear,
>>> but a new problem came out:
>>>
>>> $ sudo docker network create -d kuryr --ipam-driver=kuryr kuryr
>>> Error response from daemon: failed to allocate gateway (): invalid CIDR
>>> address: /24
>>>
>>> $ neutron subnetpool-list
>>>
>>> +--+---+---+---+--+
>>> | id   | name  | prefixes  |
>>> default_prefixlen | address_scope_id |
>>>
>>> +--+---+---+---+--+
>>> | 3c52c9dd-579e-4648-8ea7-e2af059d2914 | kuryr | [u'10.10.1.0/24'] | 24
>>>|  |
>>>
>>> +--+---+---+---+--+
>>>
>>> it got invalid gateway CIDR address:  /24 , I don't know why
>>>
>>> Thanks you & Best regards !
>>> Mars Ma
>>> -
>>>
>>> On Wed, Jan 20, 2016 at 11:53 AM, Vikas Choudhary <
>>> choudharyvika...@gmail.com> wrote:
>>>
 Hi Mars,

 Please use "--ipam-driver=kuryr" also. Kuryr has its own ipam driver.

 Please refer this also:
 https://github.com/openstack/kuryr/blob/master/doc/source/devref/libnetwork_remote_driver_des

Re: [openstack-dev] [Kuryr] IRC Meeting - Tuesday (1/26) 0300 UTC (#openstack-meeting-4)

[Baohua Yang]

Seems we missed the last meeting (01-18) agenda part at the wikipage.
Thanks!

On Mon, Jan 25, 2016 at 7:51 PM, Gal Sagie  wrote:

> Hello All,
>
> We are going to have an IRC meeting tomorrow.
>
> I have updated the agenda for the upcoming meeting [1]
> Please review and add any additional topics you might want to cover.
>
> Last meeting action items can be seen here [2]
>
> Thanks and see you there!
>
> [1] https://wiki.openstack.org/wiki/Meetings/Kuryr
> [2] 
> *http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-18-15.02.html
> *
>
> __
> 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
>
>


-- 
Best wishes!
Baohua
__
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-dev] [Kuryr] Starting Kuryr service requires root privilege

[Baohua Yang]

Hi toni

Recently we found some issue when starting kuryr service without root
privilege [1].

Tfukushima mentioned that you have some suggestion on using capacity to
solve this?

We currently make a temp workaround by suggesting using sudo to start the
service [2].

Any advice?

Thanks!

[1] https://bugs.launchpad.net/kuryr/+bug/1516539.
[2] https://review.openstack.org/#/c/272370

-- 
Best wishes!
Baohua
__
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] [Kuryr] Starting Kuryr service requires root privilege

[Baohua Yang]

Hi hua
Thanks for the suggestion!
Yes, root wrap is also a good candidate.
We will compare to choose the proper solution.
Thanks!

On Tue, Jan 26, 2016 at 1:59 PM, 王华  wrote:

> Hi Baohua,
>
> I think https://wiki.openstack.org/wiki/Rootwrap can solve this problem.
> It is used in other OpenStack projects like Nova, Neutron.
>
> Regards,
> Wanghua
>
> On Tue, Jan 26, 2016 at 1:07 PM, Baohua Yang  wrote:
>
>> Hi toni
>>
>> Recently we found some issue when starting kuryr service without root
>> privilege [1].
>>
>> Tfukushima mentioned that you have some suggestion on using capacity to
>> solve this?
>>
>> We currently make a temp workaround by suggesting using sudo to start the
>> service [2].
>>
>> Any advice?
>>
>> Thanks!
>>
>> [1] https://bugs.launchpad.net/kuryr/+bug/1516539.
>> [2] https://review.openstack.org/#/c/272370
>>
>> --
>> Best wishes!
>> Baohua
>>
>> __
>> 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
>
>


-- 
Best wishes!
Baohua
__
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] [Kuryr] Starting Kuryr service requires root privilege

[Baohua Yang]

Thanks toni.
Could u help add those instructions into doc?
And we might need provide some tool to enable those CAP_NET_ADMIN cap in
the startup scripts.

On Tue, Jan 26, 2016 at 4:29 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

> On Tue, Jan 26, 2016 at 8:13 AM, Baohua Yang  wrote:
> > Hi hua
> > Thanks for the suggestion!
> > Yes, root wrap is also a good candidate.
> > We will compare to choose the proper solution.
> > Thanks!
> >
> > On Tue, Jan 26, 2016 at 1:59 PM, 王华  wrote:
> >>
> >> Hi Baohua,
> >>
> >> I think https://wiki.openstack.org/wiki/Rootwrap can solve this
> problem.
> >> It is used in other OpenStack projects like Nova, Neutron.
> >>
> >> Regards,
> >> Wanghua
> >>
> >> On Tue, Jan 26, 2016 at 1:07 PM, Baohua Yang 
> wrote:
> >>>
> >>> Hi toni
> >>>
> >>> Recently we found some issue when starting kuryr service without root
> >>> privilege [1].
> >>>
> >>> Tfukushima mentioned that you have some suggestion on using capacity to
> >>> solve this?
>
> I do. I have a C launcher that allows Kuryr to run with CAP_NET_ADMIN so
> that
> any user can run it. My idea was to put it in contrib and then let the
> distros decide
> if they want to run kuryr as root or use the launcher in their packaging
> systemd
> service files.
>
> >>>
> >>> We currently make a temp workaround by suggesting using sudo to start
> the
> >>> service [2].
> >>>
> >>> Any advice?
> >>>
> >>> Thanks!
> >>>
> >>> [1] https://bugs.launchpad.net/kuryr/+bug/1516539.
> >>> [2] https://review.openstack.org/#/c/272370
> >>>
> >>> --
> >>> Best wishes!
> >>> Baohua
> >>>
> >>>
> >>>
> __
> >>> 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
> >>
> >
> >
> >
> > --
> > Best wishes!
> > Baohua
> >
> >
> __
> > 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
>



-- 
Best wishes!
Baohua
__
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-dev] [Neutron] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

[Baohua Yang]

Hi , all

When using neutron (especially with DVR), I find it difficult to debug
problems with lots of ovs rules, complicated iptables rules, network
namespaces, routing tables, ...

So I create 
easyOVS ,
in summary, it can


   - Format the output and use color to make it clear and easy to compare.
   - Associate the OpenStack information (e.g., vm ip) on the virtual port
   or rule
   - Query openvswitch,iptables,namespace information in smart way.
   - Check if the DVR configuration is correct.
   - Smart command completion, try tab everywhere.
   - Support runing local system commands.

In latest 0.5 version, it supports checking your dvr configuration and
running states, e.g., on a compute node, I run 'dvr check' command, then it
will automatically check the configuration files, bridges, ports, network
spaces, iptables rules,... like

 No type given, guessing...compute node
=== Checking DVR on compute node ===
>>> Checking config files...
# Checking file = /etc/sysctl.conf...
# Checking file = /etc/neutron/neutron.conf...
# Checking file = /etc/neutron/plugins/ml2/ml2_conf.ini...
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has [agent]
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has l2_population = True
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has
enable_distributed_routing = True
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has arp_responder = True
# Checking file = /etc/neutron/l3_agent.ini...
<<< Checking config files has warnings

>>> Checking bridges...
# Existing bridges are br-tun, br-int, br-eno1, br-ex
# Vlan bridge is at br-tun, br-int, br-eno1, br-ex
<<< Checking bridges passed

>>> Checking vports ...
## Checking router port = qr-b0142af2-12
### Checking rfp port rfp-f046c591-7
Found associated floating ips : 172.29.161.127/32, 172.29.161.126/32
### Checking associated fpr port fpr-f046c591-7
### Check related fip_ns=fip-9e1c850d-e424-4379-8ebd-278ae995d5c3
Bridging in the same subnet
fg port is attached to br-ex
floating ip 172.29.161.127 match fg subnet
floating ip 172.29.161.126 match fg subnet
Checking chain rule number: neutron-postrouting-bottom...Passed
Checking chain rule number: OUTPUT...Passed
Checking chain rule number: neutron-l3-agent-snat...Passed
Checking chain rules: neutron-postrouting-bottom...Passed
Checking chain rules: PREROUTING...Passed
Checking chain rules: OUTPUT...Passed
Checking chain rules: POSTROUTING...Passed
Checking chain rules: POSTROUTING...Passed
Checking chain rules: neutron-l3-agent-POSTROUTING...Passed
Checking chain rules: neutron-l3-agent-PREROUTING...Passed
Checking chain rules: neutron-l3-agent-OUTPUT...Passed
DNAT for incoming: 172.29.161.127 --> 10.0.0.3 passed
Checking chain rules: neutron-l3-agent-float-snat...Passed
SNAT for outgoing: 10.0.0.3 --> 172.29.161.127 passed
Checking chain rules: neutron-l3-agent-OUTPUT...Passed
DNAT for incoming: 172.29.161.126 --> 10.0.0.216 passed
Checking chain rules: neutron-l3-agent-float-snat...Passed
SNAT for outgoing: 10.0.0.216 --> 172.29.161.126 passed
## Checking router port = qr-8c41bfc7-56
Checking passed already
<<< Checking vports passed


Welcome for any feedback, and welcome for any contribution!

I am trying to put this project into stackforge to let more people can use
and improve it, any thoughts if it is suitable?

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

Thanks for any help or suggestion!


-- 
Best wishes!
Baohua
__
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] New Pycharm License

[Baohua Yang]

Hi andrew
Would greatly appreciate a PyCharm license key!
Thanks a lot!

On Thu, Sep 26, 2013 at 11:41 PM, Andrew Melton  wrote:

> Hey Devs,
>
>
>
> It's almost been a year since I sent out the first email and I've been
> getting a few emails lately about alerts that the current license is about
> to expire. Well, I've got a hold of our new license, good for another year.
> This'll give you access to the new Pro edition of Pycharm and any updates
> for a year.
>
>
>
> As this list is public, I can't email the license out to everyone, so
> please reply to this email and I'll get you the license.
>
>
>
> Also, please note that if your current license expires, Pycharm will
> continue to work. You will just stop receiving updates until you've entered
> this new license.
>
>
>
> Thanks,
>
> Andrew Melton
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best wishes!
Baohua
__
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-dev] [Magnum] Magnum installation problem with devstack kilo

[Baohua Yang]

Hi, all
   I am following
http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst
to
install magnum with openstack kilo version.

   At the end, there are error messages like

python update.py /opt/stack/magnum
...
 Syncing /opt/stack/magnum/requirements.txt
2015-05-29 12:50:28.075 | 'oslo.versionedobjects' is not in
global-requirements.txt
2015-05-29 12:50:28.083 | + exit_trap
2015-05-29 12:50:28.083 | + local r=1
2015-05-29 12:50:28.084 | ++ jobs -p
2015-05-29 12:50:28.085 | + jobs=
2015-05-29 12:50:28.085 | + [[ -n '' ]]
2015-05-29 12:50:28.085 | + kill_spinner
2015-05-29 12:50:28.085 | + '[' '!' -z '' ']'
2015-05-29 12:50:28.085 | + [[ 1 -ne 0 ]]
2015-05-29 12:50:28.085 | + echo 'Error on exit'
2015-05-29 12:50:28.085 | Error on exit
2015-05-29 12:50:28.085 | + [[ -z /opt/stack/logs ]]
2015-05-29 12:50:28.085 | + /opt/stack/devstack/tools/worlddump.py -d
/opt/stack/logs
2015-05-29 12:50:28.122 | df: '/run/user/1000/gvfs': Permission denied
2015-05-29 12:50:28.165 | + exit 1


This repeats several times, does any one know the reason?

Thanks!

-- 
Best wishes!
Baohua
__
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] [Magnum] Magnum installation problem with devstack kilo

[Baohua Yang]

Thanks!
Reported the bug here at https://bugs.launchpad.net/magnum/+bug/1460574.

On Mon, Jun 1, 2015 at 4:37 PM, Kai Qiang Wu  wrote:

> Hi BaoHua,
>
> For kilo you test, I am not sure what's the steps you did, as the
> dev-guide is for master branch development.
>
>
> If you have any questions, you can ask in #openstack-containers IRC
> channel or file bug in launchpad.
>
>
>
> Thanks
>
> Best Wishes,
>
> 
> Kai Qiang Wu (吴开强  Kennan）
> IBM China System and Technology Lab, Beijing
>
> E-mail: wk...@cn.ibm.com
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
> 100193
>
> 
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for "Steven Dake (stdake)" ---06/01/2015
> 01:37:32 PM---I have this same problem with devstack master. I]"Steven
> Dake (stdake)" ---06/01/2015 01:37:32 PM---I have this same problem with
> devstack master.  I’m not sure what it is other then it involves the r
>
> From: "Steven Dake (stdake)" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 06/01/2015 01:37 PM
> Subject: Re: [openstack-dev] [Magnum] Magnum installation problem with
> devstack kilo
> --
>
>
>
> I have this same problem with devstack master.  I’m not sure what it is
> other then it involves the requirements repo possibly not containing
> oslo.versionedobjects on my system.  Dims has a suggestion to do something
> about it, but I didn’t get back to it.  Try joining channel
> #openstack-containers and hunting down dims.
>
> Regards
> -steve
>
> *From: *Baohua Yang <*yangbao...@gmail.com* >
> * Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <*openstack-dev@lists.openstack.org*
> >
> * Date: *Sunday, May 31, 2015 at 10:08 PM
> * To: *OpenStack Development Mailing List <
> *openstack-dev@lists.openstack.org* >
> * Subject: *[openstack-dev] [Magnum] Magnum installation problem with
> devstack kilo
>
>Hi, all
>   I am following
>
> *http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst*
>
> <http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst>
>  to
>install magnum with openstack kilo version.
>
>   At the end, there are error messages like
>
>python update.py /opt/stack/magnum
>...
> Syncing /opt/stack/magnum/requirements.txt
>2015-05-29 12:50:28.075 | 'oslo.versionedobjects' is not in
>global-requirements.txt
>2015-05-29 12:50:28.083 | + exit_trap
>2015-05-29 12:50:28.083 | + local r=1
>2015-05-29 12:50:28.084 | ++ jobs -p
>2015-05-29 12:50:28.085 | + jobs=
>2015-05-29 12:50:28.085 | + [[ -n '' ]]
>2015-05-29 12:50:28.085 | + kill_spinner
>2015-05-29 12:50:28.085 | + '[' '!' -z '' ']'
>2015-05-29 12:50:28.085 | + [[ 1 -ne 0 ]]
>2015-05-29 12:50:28.085 | + echo 'Error on exit'
>2015-05-29 12:50:28.085 | Error on exit
>2015-05-29 12:50:28.085 | + [[ -z /opt/stack/logs ]]
>2015-05-29 12:50:28.085 | + /opt/stack/devstack/tools/worlddump.py -d
>/opt/stack/logs
>2015-05-29 12:50:28.122 | df: '/run/user/1000/gvfs': Permission denied
>2015-05-29 12:50:28.165 | + exit 1
>
>
>This repeats several times, does any one know the reason?
>
>Thanks!
>
>--
>Best wishes!
>Baohua
>__
>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
>
>


-- 
Best wishes!
Baohua
__
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] [Magnum] Docker Native Networking

[Baohua Yang]

Just put here for more comments, thanks!

IMHO, there are three different options, worth discussion before the
designing:
#Opt 1: Magnum as the API. The entire driver layer still leverages the
third-party solutions like swarm or kubernetes, then we have to keep
compatible with their limitation in networking. This will be quick to
implement, but inflexible in networking capacities. This is the traditional
way, easy for now, but hard for the future.
#Opt 2: Magnum as the Engine. We only leverage third-party drivers to
manage the lifestyle of containers, but utilize the OpenStack mechanism
(i.e., Neutron) to handle the networking. This need investigation into the
possibility of combination in different environments. This can target to
combine the best of Docker and OpenStack.
#Opt 3: Magnum as the Solution. Besides the third-party drivers, we design
our own container provision mechanism (Not Nova-Docker), then it will be
more fluent to integrate with Neutron. However, this need to design new
naive driver layer (Docker+Flannel is a good reference, as the design idea
is similar and simpler with Neutron). This is the most clean option.

Finally, after investigating most existing open source container networking
mechanisms, overlay is the common idea, where Neutron seems a good
candidate.

On Sat, Jun 13, 2015 at 2:22 AM, Adrian Otto 
wrote:

>  Team,
>
>  OpenStack Networking support for Magnum Bays was an important topic for
> us in Vancouver at the design summit. Here is one blueprint that requires
> discussion that’s beyond the scope of what we can easily fit in the BP
> whiteboard:
>
>  https://blueprints.launchpad.net/magnum/+spec/native-docker-network
>
>  Before we dive into implementation planning, I'll offer these as
> guardrails to use as a starting point:
>
>  1) Users of the Swarm bay type have the ability to create containers.
> Those containers may reside on different hosts (Nova instances). We want
> those containers to be able to communicate with each other over a network
> similar to the way that they can over the Flannel network used with
> Kubernetes.
>
>  2) We should leverage community work as much as possible, combining the
> best of Docker and OpenStack to produce an integrated solution that is easy
> to use, and exhibits performance that's suitable for common use cases.
>
>  3) Recognize that our Docker community is working on libnetwork [1]
> which will allow for the creation of logical "networks" similar to "links"
> that allow containers to communicate with each other across host
> boundaries. The implementation is pluggable, and we decided in Vancouver
> that working on a Neutron plugin for libnetwork could potentially make the
> user experience  consistent whether you are using Docker within Magnum or
> not.
>
>  4) We would like to plug in Neutron to Flannel as a modular option for
> Kubernetes Bays, so both solutions leverage OpenStack networking, and users
> can use familiar, native tools.
>
>  References:
> [1] https://github.com/docker/libnetwork
>
>  Please let me know what you think of this approach. I’d like to re-state
> the Blueprint description, clear the whiteboard, and put up a spec that
> will accommodate in-line comments so we can work on the implementation
> specifics better in context.
>
>  Adrian
>
> __
> 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
>
>


-- 
Best wishes!
Baohua
__
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] [Kuryr] Now part of OpenStack big-tent

[Baohua Yang]

Great and congrats!

On Wed, Feb 24, 2016 at 11:51 PM, Gal Sagie  wrote:

> Hello Everyone,
>
> Just wanted to update you that Kuryr [1] was officially accepted yesterday
> as a
> big tent project.
>
> We are currently facing some interesting challenges and times and if you
> are running containers in OpenStack in mixed environments you most
> certainly
> want to look and examine Kuryr.
>
> We are holding a weekly IRC meeting [2] which is alternating between time
> zones
> so you have no excuse :) everyone are welcome!
>
> We want to help and solve more challenges in the realm of containers
> networking
> deployments in OpenStack and if you are deploying this either in
> development or
> in production we would love to hear your experience and the problems you
> are facing
> and try to help you manage this better, feel free to share!
>
> [1] https://wiki.openstack.org/wiki/Kuryr
> [2] https://wiki.openstack.org/wiki/Meetings/Kuryr
>
> __
> 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
>
>


-- 
Best wishes!
Baohua
__
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