Re: [openstack-dev] [tricircle] your proposal for the name of networking and gateway sub-projects

Hello, After the discussion in the #openstack-tricircle channel and mail-list, 4 candidates available now, please vote the name for the new sub-project for api-gateway functionality: 1. Triangel, 2 votes The Triangel are dolls that bring luck. Found some meaning may not all people like it,

Re: [openstack-dev] [tripleo] collaboration request with vendors

Thanks Emilien. Response inline: > Since Plumgrid is a proprietary software I'm not sure now how we could > test it to be honest but you might have some idea to do it. > If that's something we can download from the internet and install > during a tripleo deployment, then we could use our current

[openstack-dev] 转发: A mail from BJUT student

As a rookie of Openstack and i want to ask you guys a few questions about your project Steth so that I can understand more clearly. 1.What's the function limitation of the current version of Steth ? 2.According to the Steth introduction files,Steth just applying to ML2, I can not understand

Re: [openstack-dev] [tricircle]

Hello, Ronghui, Saw your mail. Best Regards Chaoyi Huang(joehuang) From: crh [cr_...@126.com] Sent: 06 September 2016 15:44 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [tricircle] hello -- Best regards,

Re: [openstack-dev] [networking-sfc] SFC flows issue

Hi Ravi , Could you share tcpdump on P3 as well ( sudo tcpdump -n -e -i "P3 tab-interface" ) IMO , the possible reasons would be [1] port-security on SF port may block the packet , since it destined to different ip address. [2] The SF program may alter the IP Header (Destination field )

[openstack-dev] [tricircle]

hello -- Best regards, Ronghui Cao, Ph.D. Candidate College of Information Science and Engineering Hunan University, Changsha 410082, Hunan, China__ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [nova] using the qemu memory overhead in memory resource tracking or scheduling

Hi, In our cloud we use 1G huge pages for the instance memory. We started notice that qemu has a relevant memory overhead per domain (something like 300MB per domain). As we use huge pages for the instance memory nova scheduler makes placement decision based on the available huge pages. However

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

+1 to Lukasz. -1 to the proposal, we had it this way for a quite some time, and it was not good for the project (as Lukasz pointed out), why should a person who merges the code to the library have an access to merge the code to Nailgun/Astute without proper expertise. Those are different areas

Re: [openstack-dev] [Glare][Heat][Murano][Tosca] Review of artifact structure for specific projects in Glare

Sorry, I posted the wrong line for TOSCA guys. The correct link to TOSCA artifact here: https://review.openstack.org/# /c/365631/. Best regards, Kairat Kushaev On Mon, Sep 5, 2016 at 4:18 PM, Kairat Kushaev wrote: > TL;DR: Heat,

Re: [openstack-dev] [tricircle]

Hello, Jiawei, Now your mail has been sent to the openstack-dev list successfully Best Regards Chaoyi Huang(joehuang) From: hejiawei [h452577...@126.com] Sent: 06 September 2016 14:51 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [tricircle]

[openstack-dev] [tricircle]

test__ 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] [Fuel] Common fuel-core group for all Fuel projects

On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov wrote: > +1 > This is a good proposal, I also think we should have single fuel-core group > for all repos. In real life core reviewers won't set +2 or merge to repos > with which they are not familiar with. Actually one of

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

+1, I think it is good idea. Regards, Bulat Gaifullin Mirantis Inc. > On 05 Sep 2016, at 20:17, Maksim Malchuk wrote: > > I want to clarify my previous reply > +1 > but the new fuel-core would be a small group of the cores who are fully > involved in the whole Fuel

Re: [openstack-dev] [neutron][taas] On TaaS not capturing some packets between two VMs on the same host

hi, On Sat, Sep 3, 2016 at 7:32 AM, Anil Rao wrote: > Hello, > > Here is an update on the issue of not being able to capture packets flowing > between two VMs on the same host. it it about bug 1529595 ? https://bugs.launchpad.net/tap-as-a-service/+bug/1529595 > >

<    1   2