[openstack-dev] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting on the coming Wednesday, Dec 27th, is canceled.

Thanks,
Ifat

__
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] Bug deputy report

[Takashi Yamamoto]

hi,

thank you.
do you have anything to hand off to the next bug deputy (me) ?

On Mon, Dec 25, 2017 at 3:31 PM, Luo, Lujin  wrote:
> Hello everyone,
>
> I was on bug deputy between 2017.12.18 and 2017.12.25. I am sending a short 
> summary of the bugs reported during this period.
>
> https://bugs.launchpad.net/neutron/+bug/1739798 - Medium. networking-ovn 
> driver expects network postcommit methods to be called with no open sessions 
> to the database. Some changes of how we handle segments deletion inside 
> network deletion are required. It is not assigned yet, so if anyone is 
> interested, it is yours.
>
> https://bugs.launchpad.net/neutron/+bug/1739411 - Low. QoS DSCP mark 
> disappear stable/ocata. Two possible fixes have been proposed and one is used 
> in Pike and current master. It looks to me like a low-hanging fruit. Anyone 
> interested, please take it over.
>
> https://bugs.launchpad.net/neutron/+bug/1739227 - One test case does not obey 
> when the parent network is vlan. Jakub is handling it. Thanks :)
>
> https://bugs.launchpad.net/neutron/+bug/1739219 - Medium. stable/Pike. 
> Removal of DHCP agent does not cascade to the removal of the corresponding 
> port (with device_onwer as "network:dhcp"). It is not assigned yet, so if 
> anyone is interested, it is yours.
>
> https://bugs.launchpad.net/neutron/+bug/1739078 and 
> https://bugs.launchpad.net/neutron/+bug/1739075 - RFE of full stack test 
> proposed by Jakub.
>
> https://bugs.launchpad.net/neutron/+bug/1739071 and 
> https://bugs.launchpad.net/neutron/+bug/1738983 - garyk has started working 
> on them.
>
> https://bugs.launchpad.net/neutron/+bug/1738768 - Critial. Regression of 
> dataplane downtime when L3 agents running in containers are shutdown. It is 
> also marked as high in TripleO. Currently no one is assigned. I have asked 
> Miguel to take a look at it. But anyone else who is familiar with containers 
> and L3, please take a look too.
>
> https://bugs.launchpad.net/neutron/+bug/1738738 - RFE poposed by Reedip.
>
>
> Happy holidays!
>
> Best regards,
> Lujin
>
> ∽---
> Lujin Luo
> Email: luo.lu...@jp.fujitsu.com
> Tel: (81) 044-754-2027
> Linux Development Division
> Platform Software Business Unit
> Fujitsu Ltd.
> --∽
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [neutron] Bug deputy report

[Luo, Lujin]

Hello everyone,

I was on bug deputy between 2017.12.18 and 2017.12.25. I am sending a short 
summary of the bugs reported during this period.

https://bugs.launchpad.net/neutron/+bug/1739798 - Medium. networking-ovn driver 
expects network postcommit methods to be called with no open sessions to the 
database. Some changes of how we handle segments deletion inside network 
deletion are required. It is not assigned yet, so if anyone is interested, it 
is yours.

https://bugs.launchpad.net/neutron/+bug/1739411 - Low. QoS DSCP mark disappear 
stable/ocata. Two possible fixes have been proposed and one is used in Pike and 
current master. It looks to me like a low-hanging fruit. Anyone interested, 
please take it over.

https://bugs.launchpad.net/neutron/+bug/1739227 - One test case does not obey 
when the parent network is vlan. Jakub is handling it. Thanks :)

https://bugs.launchpad.net/neutron/+bug/1739219 - Medium. stable/Pike. Removal 
of DHCP agent does not cascade to the removal of the corresponding port (with 
device_onwer as "network:dhcp"). It is not assigned yet, so if anyone is 
interested, it is yours.

https://bugs.launchpad.net/neutron/+bug/1739078 and 
https://bugs.launchpad.net/neutron/+bug/1739075 - RFE of full stack test 
proposed by Jakub.

https://bugs.launchpad.net/neutron/+bug/1739071 and 
https://bugs.launchpad.net/neutron/+bug/1738983 - garyk has started working on 
them. 

https://bugs.launchpad.net/neutron/+bug/1738768 - Critial. Regression of 
dataplane downtime when L3 agents running in containers are shutdown. It is 
also marked as high in TripleO. Currently no one is assigned. I have asked 
Miguel to take a look at it. But anyone else who is familiar with containers 
and L3, please take a look too. 

https://bugs.launchpad.net/neutron/+bug/1738738 - RFE poposed by Reedip. 


Happy holidays!

Best regards,
Lujin

∽---
Lujin Luo
Email: luo.lu...@jp.fujitsu.com
Tel: (81) 044-754-2027
Linux Development Division
Platform Software Business Unit
Fujitsu Ltd.
--∽



__
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] [nova] seeking your kind support and assistance regarding securing hypervisor and virtual machines against security attacks or threats

[Darshan Tank]

Hi,

I'm working on security aspects in cloud computing. I focused on
virtualization specific vulnerabilities in cloud computing environment. I
selected OpenStack as my cloud computing software platform. In general,
there are two primary threats vectors in OpenStack.

1.  Hypervisor threats
2.  Virtual Machine (multi-tenant) threats

In OpenStack, "nova" is responsible for the management of virtual machines.

How to recognize and prevent a hypervisor and virtual machine attacks to
protect data in OpenStack?

How to secure hypervisor and virtual machine against security threats in
OpenStack? What are the methods, techniques or algorithms, OpenStack
community/developers followed to make openstack as secure cloud environment?

How one can contribute in securing OpenStack hypervisor and virtual
machines?

I'm looking forward to hearing from you.

Thanks in advance for your support.

With Warm Regards,
*Darshan Tank *

[image: Please consider the environment before printing]
__
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] Stepping down from core

[reedip banerjee]

Hi Armando,
Its not easy to hear this news.
But all the best of luck to you Armando for your future endeavors.

Best Regards,
Reedip


On Sat, Dec 23, 2017 at 1:38 AM, German Eichberger <
german.eichber...@rackspace.com> wrote:

> Hi,
>
>
>
> Thanks for all the help and support over the years. Both LBaaS (Octavia)
>  and FWaaS wouldn’t be what they are today without your leadership and
> advice –
>
>
>
> All the best + good luck,
>
> German
>
>
>
> *From: *"Armando M." 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, December 15, 2017 at 8:04 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [neutron] Stepping down from core
>
>
>
> Hi neutrinos,
>
>
>
> To some of you this email may not come as a surprise.
>
>
>
> During the past few months my upstream community engagements have been
> more and more sporadic. While I tried hard to stay committed and fulfill my
> core responsibilities I feel like I failed to retain the level of quality
> and consistency that I would have liked ever since I stepped down from
> being the Neutron PTL back at the end of Ocata.
>
>
>
> I stated many times when talking to other core developers that being core
> is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
>
>
>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing
> with the neutron quirks for which I might be (git) blamed :)
>
>
>
> Cheers,
>
> Armando
>
>
>
> __
> 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
>
>


-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
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] Regarding inter-VM inter process communication in OpenStack

[Jay Pipes]

On 12/24/2017 12:56 AM, Darshan Tank wrote:

Hi,

I have been working on inter-virtual machine inter process communication 
(IPC) methods.


I would like to know whether current OpenStack framework supports 
inter-VM shared memory concept or not ?


No. OpenStack (or at least, the components you are referring to here -- 
Nova, Neutron, Cinder, Glance and Keystone) is a virtual machine and 
baremetal server *management* platform. These components do not get 
involved in the workloads running within the virtual or baremetal machines.


If not, then what are the mechanisms for inter-VM inter process 
communication in OpenStack?


There is no specific IPC mechanism used in OpenStack because OpenStack 
isn't at that level of the stack.


If you are looking for true IPC (on a single host between multiple 
*operating system* processes, you probably want to look at doing 
something with Linux containers which can share IPC Linux namespaces.


If you are looking for VMWare DRS-like functionality, you should look at 
a VMWare-specific solution. But AFAIK, that really isn't IPC in the 
sense of sharing operating system process memory. I think DRS is more 
about duplicating writes (to disk/memory) so that (potentially hot) 
standby virtual machines can take over if a failure occurs on another.


VMWare experts should correct me if I'm wrong here.

A more traditional way of doing "IPC" in the virtual machine (and 
multiple host) world is to just set up a communication tunnel over some 
transport mechanism (TCP/UDP/whatever) and send two-way communication 
over this tunnel to keep the two sides' state in sync.


Best,
-jay


I'm looking forward to hearing from you.

Thanks in advance for your support.

With Warm Regards,

*Darshan Tank *
*
*
Please consider the environment before printing*
*


__
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