Re: [openstack-dev] [neutron] out-of-tree l3 service providers

[Takashi Yamamoto]

hi,

On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  wrote:
> If I understand the main issue with using regular callbacks, it's mainly
> just that the flavor assignment itself is in a callback, right?

yes.

>
> If so, couldn't we solve the problem by just moving flavor assignment to an
> explicit call before emitting the callbacks? Or would that still result in
> other ordering issues?

it would solve the problem for CREATE.
for UPDATE and DELETE, i'm not sure.
UPDATE can change the flavor but it's supposed to be a special case
only for dvr/ha, right?
AFTER_DELETE might be tricky as we probably need to provide flavor
info to subscribers.

>
> On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto 
> wrote:
>>
>> hi,
>>
>> today i managed to play with l3 flavors.
>> i wrote a crude patch to implement midonet flavor. [1]
>>
>> [1] https://review.openstack.org/#/c/483174/
>>
>> a good news is it's somehow working.
>>
>> a bad news is it has a lot of issues, as you can see in TODO comments
>> in the patch.
>> given these issues, now i tend to think it's cleaner to introduce
>> ml2-like precommit/postcommit driver api (or its equivalent via
>> callbacks) rather than using these existing notifications.
>>
>> how do you think?
>
>

__
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] [tripleo] not running PTL during Queens

[Jason E. Rist]

On 07/30/2017 10:52 PM, Emilien Macchi wrote:
> Hi,
>
> After 3 cycles of Puppet OpenStack PTL and 2 cycles of TripleO PTL, I
> decided to do a little break on this role and give the opportunity to
> let other people taking it.
> A few months ago, I wrote a blog post about my personal thoughts on
> what leadership means to me and what I've learnt by being PTL:
> http://my1.fr/blog/my-journey-as-an-openstack-ptl/
>
> My hope is to see new leaders in our project and maintain the
> OpenStack values as strong as we've tried to push over the last years.
> I'll still be around but hopefully stepping down will allow me to
> focus on some other things (still TripleO of course), including my
> position at the Technical Committee.
>
> Thanks all for your trust, your patience, your tolerance and more than
> anything else: your hard work.
> I'm looking forward to continuing this adventure :-)
>
Thank you for your help and your leadership during Ocata and Pike!

-J

__
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] [tripleo] not running PTL during Queens

[Emilien Macchi]

Hi,

After 3 cycles of Puppet OpenStack PTL and 2 cycles of TripleO PTL, I
decided to do a little break on this role and give the opportunity to
let other people taking it.
A few months ago, I wrote a blog post about my personal thoughts on
what leadership means to me and what I've learnt by being PTL:
http://my1.fr/blog/my-journey-as-an-openstack-ptl/

My hope is to see new leaders in our project and maintain the
OpenStack values as strong as we've tried to push over the last years.
I'll still be around but hopefully stepping down will allow me to
focus on some other things (still TripleO of course), including my
position at the Technical Committee.

Thanks all for your trust, your patience, your tolerance and more than
anything else: your hard work.
I'm looking forward to continuing this adventure :-)
-- 
Emilien Macchi

__
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] [srv-apl-arch:7386] Re: [nova] Discussions for ivshmem support in OpenStack Nova

[TETSURO NAKAMURA]

On 2017/07/27 20:53, Mooney, Sean K wrote:




-Original Message-
From: TETSURO NAKAMURA [mailto:nakamura.tets...@lab.ntt.co.jp]
Sent: Thursday, July 27, 2017 2:13 AM
To: Daniel P. Berrange ; Mooney, Sean K

Cc: Jay Pipes ; OpenStack Development Mailing List
(not for usage questions) ;
sfinu...@redhat.com; mriede...@gmail.com; 【社内】【ML】srv-apl-arch 
Subject: Re: [srv-apl-arch:7353] Re: [openstack-dev] [nova] Discussions
for ivshmem support in OpenStack Nova

On 2017/07/27 0:58, Daniel P. Berrange wrote:

On Wed, Jul 26, 2017 at 11:53:06AM -0400, Jay Pipes wrote:

On 07/26/2017 09:57 AM, Daniel P. Berrange wrote:

On Wed, Jul 26, 2017 at 09:50:23AM -0400, Jay Pipes wrote:

On 07/26/2017 03:06 AM, TETSURO NAKAMURA wrote:

Hi Nova team,

It has been quite a long time since the last discussion, but let
me make sure one thing about the thread below.

IIUC, Nova is not welcome ivshmem support because it is no longer
supported by DPDK+QEMU.

But how would you say if it is supported out of DPDK-tree and can
be used from the newest qemu version ?

We are now developing SPP, a DPDK-based vswitch, and thinking
about trying to implement ivshmem support under our SPP code tree
if nova (or at first libvirt community) is acceptable for ivshmem

configuration.


Your advice will be very helpful for our decision-making in our

project.


I think this is a question that the libvirt community would first
need to weigh in on since Nova is downstream from libvirt -- at
least in the sense of low-level hypervisor support.


Libvirt already supports ivshmem device config

 http://libvirt.org/formatdomain.html#elementsShmem


Sorry, I suppose I should have said QEMU, not libvirt. Daniel, you
were the one that specifically discouraged doing anything on ivshmem

to Tetsuro:


http://lists.openstack.org/pipermail/openstack-dev/2017-

July/120136.h

tml


'ivshmem' was the original device in QEMU and that is indeed still
deprecated.

There are now two replacements 'ivshmem-plain' and 'ivshmem-doorbell'
which can be used instead, which are considered supported by QEMU,
though most people will still recommend using 'vhostuser' instead if
the use of ivshmem is at all network related.

Regards,
Daniel



Thank you very much for the information about current status of ivshmem
in QEMU.
I now understand that 'ivshmem', 'ivshmem-plain' and 'ivshmem-doorbell'
are different solutions, and libvirt already supports the latter two.

+ Mr. Sean Mooney
Did you mean that you caution against building new solutions ontop of
'ivshmem' or ontop of 'ivshmem-plain' and 'ivshmem-doorbell' too?

[Mooney, Sean K] I would caution against building any networking based uscases 
ontop of ivshmem.
The move to using a memdev instead of directly specifying shm args to qemu for 
ivshmem-plain/doorbell
Should allow hugepage memory to be used instead of posix sheared mem which 
would be needed for spp.

That said just because you can use ivshmem-plain/doorbell with hugepages via a 
memdev form the qemu commandline
does not mean it is supported by Libvirt 
https://libvirt.org/formatdomain.html#elementsShmem or that it is the best 
approach,
upstream development has shifted to virtio and vhost-user.
0 copy tx from a vm is already supported with vhost-user and ovs-dpdk.
0 copy rx Is under development which is the main delta in performance between 
ivshmem and vhost-user that remains.
Both of these features could be ported to the spp.

Vhost-user does have some inherent overhead such as the descriptor rings etc 
required to support virtio
Must be created which is required to support the virtio spec which give you 
portability and performance when
Coupled with multi queue and the dpdk vhost pmd in the guest.

If vhost-user is really not sufficient for your usecase I would first suggest 
extending Libvirt to allow
Passing a memdev name as a parameter to the shmem element.
At that point we could discuss how to request openstack to use those new 
element to create the shmem device.

The best approach using what openstack support today for a generic shmem dev 
would be via a Libvirt option in the image metatdata the same
Way that serial ports allocation or vGPU memory is configured. If this device 
was to be used as a nic however
A different approach of creating a new vnic_type of ivsheme_plain and 
ivshmem_doorbell would be more approiate with the
Port binding profile used to transport the memory mapping info similar to how 
we expose info for sriov devices.

The issue with ivshsmem interfaces in a neutron context is its just a pci 
device where bar2 points to a shared memory region
There is no way to pass info such as a mac address to a hypervisor for it to 
enforce so the use of ivshmem deveices as
Nic means that you are enabling a adressless port that can transmit and recive 
any  packet unless you explicitly implement
Port security (mac/arp anti spoof) in the 

[openstack-dev] [neutron][networking-vpp]networking-vpp 17.07.1 for VPP 17.07 is available

[Ian Wells]

In conjunction with the release of VPP 17.07, I'd like to invite you all to
try out networking-vpp 17.07.1 for VPP 17.07.  VPP is a fast userspace
forwarder based on the DPDK toolkit, and uses vector packet processing
algorithms to minimise the CPU time spent on each packet and maximise
throughput.  networking-vpp is a ML2 mechanism driver that controls VPP on
your control and compute hosts to provide fast L2 forwarding under Neutron.

This version has a few additional enhancements, along with supporting the
VPP 17.07 API:
- remote security group IDs are now supported
- VXLAN GPE support now includes proxy ARP at the local forwarder

Along with this, there have been the usual bug fixes, code and test
improvements.

The README [1] explains how you can try out VPP using devstack: the
devstack plugin will deploy etcd, the mechanism driver and VPP itself and
should give you a working system with a minimum of hassle.

We will continuing development between now and VPP's 17.10 release in
October.  There are several features we're planning to work on (you'll find
a list in our RFE bugs at [2]), and we welcome anyone who would like to
come help us.

Everyone is welcome to join our biweekly IRC meetings, every other Monday
(the next one is due in a week), 0900 PDT = 1600 GMT.
-- 
Ian.

[1]https://github.com/openstack/networking-vpp/blob/master/README.rst
[2]http://goo.gl/i3TzAt
__
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] [tripleo] Deriving Parameters from Introspection Data

[Don maillist]

On Mon, Jul 17, 2017 at 1:13 AM, Saravanan KR  wrote:

> On Sun, Jul 16, 2017 at 6:10 AM, Don maillist 
> wrote:
> > Looks interesting. Wish I had this or something like it now for Newton
> and
> > OVS 2.6.1 which just dropped. Wondering why you don't include the grub
> > command line?
> KernelArgs parameter which will have iommu and huge page args are
> derived as part of this workflow, which will be applied to grub. Are
> you looking for any specific parameter?
>
>
Yes, # of huge pages.


> >
> > Do you have a stand alone utility?
> Not as of now. But we are looking in to the possibility of developing
> a utility tool for using it for Newton. I will post it when we have
> it.
>
> Wonderful!!


> Regards,
> Saravanan KR
>
> >
> > Best Regards,
> > Don
>
>
>
Best Regards,
Don
__
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] [release] nominating Sean McGinnis for releases-core

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-07-27 11:14:51 -0400:
> Sean has been increasingly active with the release team this cycle, and
> wants to contribute. I think we should go ahead and add him to the
> releases-core group.
> 
> Please respond +1/-1.
> 
> Doug
> 

As all of the feedback has been positive, I went ahead and added Sean
to the releases-core group in gerrit today.

Doug

__
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] Announcing Gertty 1.5.0

[James E. Blair]

Announcing Gertty 1.5.0
===

Gertty is a console-based interface to the Gerrit Code Review system.

Gertty is designed to support a workflow similar to reading network
news or mail.  It syncs information from Gerrit to local storage to
support disconnected operation and easy manipulation of local git
repos.  It is fast and efficient at dealing with large numbers of
changes and projects.

The full README may be found here:

  https://git.openstack.org/cgit/openstack/gertty/tree/README.rst

Changes since 1.4.0:


* Added support for sorting dashboards and change lists by multiple
  columns

* Added a Unicode graphic indication of the size of changes in the
  change list

* Added the number of changes to the status bar in the change list

* Added a trailing whitespace indication (which can be customized or
  ignored in a custom palette)

* Several bug fixes related to:
  * Negative topic search results
  * Crashes on loading changes with long review messages
  * Avoiding spurious sync failures on conflict queries
  * Errors after encounting a deleted project
  * Better detection of some offline errors
  * Fetching missing refs
  * Gerrit projects created since Gertty started
  * Re-syncing individual changes after a sync failure

Thanks to the following people whose changes are included in this
release:

  Jim Rollenhagen
  Kevin Benton
  Masayuki Igawa
  Matthew Thode

__
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