Re: [openstack-dev] [Fuel][puppet] CI gate for regressions detection in deployment data

[bdobrelia]

> Why do you use [puppet] tag?
> Is there anything related to Puppet OpenStack modules we should take
> care of?


There are several deployment automation tools leveraging the puppet-openstack 
modules.
Those are under the Big Tent and each has its own composition layer and 
deployment patterns with specific data flows. That is why I opened this 
discussion public and put the puppet tag as well. I believe the idea of 
automated checks of the data layer applies to them as well and I’d like to have 
opinions on that from a broad audience.
What is the correct tag for deploymnent automation with a Puppet?

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando__
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] IPAM drivers for BlueCat networks and Alcatel-Lucent VitalQIP

[John Belamaric]

Hi Maruti,

Yes, it is still ongoing, without a first release yet. We expect to release a 
1.0 driver very soon that will support a single network view shared by all 
tenants. 

A later version will include the ability to map tenants and/or specific subnets 
to various network views at runtime. 

John

> On Oct 30, 2015, at 12:51 PM, Kamat, Maruti Haridas  
> wrote:
> 
> Hi Pavel,
> 
> Thanks for the information.
> 
> I was also looking at Infoblox driver at 
> https://github.com/openstack/networking-infoblox
> 
> Is implementation of Infoblox driver still going on? 
> 
> Thanks,
> Maruti
> 
> 
> -Original Message-
> From: Pavel Bondar [mailto:pbon...@infoblox.com] 
> Sent: Friday, October 30, 2015 6:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and 
> Alcatel-Lucent VitalQIP
> 
> Hi Maruti,
> 
> For now only Pluggable IPAM interface with reference IPAM driver were 
> released, and I am working on implementing IPAM driver for Infoblox.
> 
> But I am not aware about existense of IPAM drivers from BlueCat or Alcatel.
> If you want to investigate with pluggable IPAM more you can start with IPAM 
> Interface and reference IPAM driver. They can be found under [1].
> 
> [1] https://github.com/openstack/neutron/tree/master/neutron/ipam
> 
> Thanks,
> Pavel
> 
> From: Kamat, Maruti Haridas 
> Sent: Thursday, October 29, 2015 8:24 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and 
> Alcatel-Lucent VitalQIP
>   
> 
> Hi
>  
> I am exploring IPAM feature in OpenStack Neutron. In particular, I wanted to 
> look at the IPAM drivers for BlueCat Networks' (Proteus) and Alcatel-Lucent's 
> VitalQIP.
>  
> If someone can provide me with pointers, it would be of great help.
>  
> Thanks,
> Maruti
>  
>  
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Multi-ip use cases

[Aihua Li]

I have attempted to use the fixed_ip for our internal use. 

I found too many issues with the existing feature, and would propose to rewrite 
it as new feature. 

The problem I experienced are:
1. ) I have to repeatedly enter the option --fixed_ip for as many IPs as I need 
to apply. This will not scale if I wanted many IPs.2). The operation does not 
guarantee you get your original IP assigned, the VM instance become 
non-reachable.3). I can not requested seperate MAC addresses to go with the IP 
address.4.)  The command acces privilage is controlled by policy.  It would be 
more appropriate to use quota to control how many IPs a user can request 
instead of granting a privilage to the user.
To use the mulitple IP,you can use OVS, mac-vlan etc. But that requires 
seperate MAC address to go with IPs. 

 == Aihua Edward Li == 


 On Friday, October 30, 2015 12:00 PM, Shraddha Pandhe 
 wrote:
   

 Hi folks,
James Penick from Yahoo! presented a talk on Thursday about how Yahoo uses 
Neutron for Ironic. I would like to follow up on one particular use case that 
was discussed: Multi-IP support.
Here's our use-case for Multi-ip:
For Ironic, we want user to specify the number of IPs on boot. Now, we want 
scheduler to find a network with sufficient IPs and then pick a host in that 
subnet (Note: static IPs for baremetal). Now, when allocating network, we want 
to assign all requested IPs from the same subnet as the host's static IP. Also, 
we don't want to configure those IPs on the host. We only want to display them 
on "nova show".
So basically we will only create one port for the host, and append all 
fixed_ips in the ports fixed_ip list field.
Questions:1. Hows do most people use the fixed_ips field in the port? What are 
different ways you can populate multiple IPs in fixed_ips? One way I know is, 
using neutron-client to create port, you can specify --fixed-ip as many times 
as you want, and that will append fixed_ips to the port. Any other way?
2. Is anybody else using multi-ip?


__
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] [nova] vif unplugging when deleting instance while resizing

[Chris Friesen]

Hi,

I do have a situation where an instance was deleted while resizing, and there 
are vswitch ports remaining in use when they shouldn't be.


I suspect that it's related to bug 1392527. 
(https://bugs.launchpad.net/nova/+bug/1392527)  That bug was involved a scenario 
where we trigger a resize or cold migration, and while it's in progress we 
delete the instance.


In the fix an audit was added to clean up the instance files, but I'm wondering 
if we forgot to clean up the networking.


From what I can tell, in stable/kilo with neutron when doing a resize we will 
only unplug the vifs on the source side when confirming the resize.  The code 
path looks like:


compute.manager.ComputeManager.confirm_resize()
compute.manager.ComputeManager._confirm_resize()
virt.libvirt.driver.LibvirtDriver.confirm_migration()
virt.libvirt.driver.LibvirtDriver._cleanup_resize()
virt.libvirt.driver.LibvirtDriver.unplug_vifs()

I'm concerned that if we delete the instance before the vm_state hits RESIZED, 
then we will not ever confirm the resize on the host.  (I think this could 
happen since the instance host is set to the destination in 
compute.manager.ComputeManager.resize_instance(), but the vm_state isn't set to 
RESIZED until compute.manager.ComputeManager._finish_resize().


Then the audit from bug 1392527 runs and cleans up the instance files left on 
the host, but we're left with the vswitch port still in use because nobody 
unplugged it.


Can anyone poke holes in the description above?

The above is all supposition, I haven't reproduced it or gone through it in 
enough detail to be certain that this is what's happening.  That's the next step.


Chris

__
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] [app-catalog] [glance] [murano] Data Assets API for App Catalog

[Alexander Tivelkov]

Hi folks,

Thanks for the fruitful discussion on the summit: seems like we are in
agreement and have a good plan to proceed.

Here is the video recording of the PoC I've made to serve the current
AppCatalog's data using Glance Artifacts. As the demo was recorded before
the summit, it's called Glance V3 everywhere. Now we've agreed that this
will be a Glance Artifacts Repository (aka Glare) API v1 - but everything
else about its functionality is still valid :)

https://youtu.be/5IxKqJiD2xw

Please feel free to ask any questions you may have on the demo and Glare
functionality in general.

Thanks again


On Wed, Oct 28, 2015 at 11:38 AM Flavio Percoco  wrote:

> On 23/10/15 19:25 +, Fox, Kevin M wrote:
> >The "Glance: Artefacts API" session was scheduled right on top of the
> "Nova:
> >Cross Service Issues: Service Lock Server, Service Tokens, Instance Users
> (TBC)
> >" session. The latter having been really hard to schedule since it
> involves so
> >many different projects and something I must attend. So I won't be able to
> >attend the glance session.
> >
> >The Murano folks have kindly offered to use one of their sessions:
> >Murano contributors meetup (9:00am-12:30pm)
> >
> http://mitakadesignsummit.sched.org/event/5e244fb7f342854dc5c112e76e77c930
> >to discuss Glance Artefacts/Murano integration/Community App Catalog
> needs.
> >
> >Can folks from the glance team that are interested in the discussion
> please
> >attend?
>
> Kevin, thanks for the heads up! I'll help spreading the word in case
> some folks missed this email.
>
> Flavio
>
> >
> >Thanks,
> >Kevin
> >
>
> >━━━
> >From: Alexander Tivelkov [ativel...@mirantis.com]
> >Sent: Thursday, October 15, 2015 3:04 AM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: [openstack-dev] [app-catalog] [glance] [murano] Data Assets API
> for
> >App Catalog
> >
> >Hi folks,
> >
> >I’ve noticed that the Community Application Catalog has begun to
> implement its
> >own API, and it seems to me that we are going to have some significant
> >duplication of efforts with the code which has already been implemented in
> >Glance as Artifact Repository initiative (also known as Glance V3).
> >From the very beginning of the App Catalog project (and I’ve been
> involved in
> >it since February) I’ve been proposing to use Glance as its backend,
> because
> >from my point of view it covers like 90% of the needed functionality. But
> it
> >looks like we have some kind of miscommunication here, as I am getting
> some
> >confusing questions and assumptions, like the vision of Glance V3 being
> >dedicated backend for Murano (which is definitely incorrect).
> >So, I am writing the email to clarify my vision of what Glance V3 is and
> how
> >its features may be used to provide the REST API for Community App
> Catalog.
> >
> >1.  Versioned schema
> >First of all, Glance V3 operates on entities called “artifacts”, and
> these ones
> >perfectly map to the Data Assets of community app catalog. The artifacts
> are
> >strongly typed: there are artifact types for murano packages, glance
> images,
> >heat templates - and there may be (and will be) more. Each artifact type
> is
> >represented by a plugin, defining the schema of objects’ data and
> metadata and
> >- optionally - custom logic. So, this thing is extensible: when a new
> type of
> >asset needs to be added to a catalog it can be done really quickly by just
> >defining the schema and putting that schema into a plugin. Also, these
> plugins
> >are versioned, so the possible changes in the schema are handled properly.
> >
> >2. Generic properties
> >Next, all the artifact types in Glance V3 have some generic metadata
> properties
> >(i.e. part of the schema which is common for all the types), including the
> >name, the version, description, authorship information and so on. This
> also
> >corresponds to the data schema of community app catalog. The mapping is
> not
> >1:1, but we can work together on this to make sure that these generic
> >properties match the expectations of the catalog.
> >
> >3. Versioning
> >Versions are very important for catalogs of objects, so Glance V3 was
> initially
> >designed keeping versioning questions in mind: each artifact has a
> semver-based
> >version assigned, so the artifacts having the same name but different
> versions
> >are grouped into the proper sequences. API is able to query artifacts
> based on
> >their version spec, e.g. it is possible to fetch the latest artifact with
> the
> >name “foo” having the version greater than 2.1 and less than 3.5.7 - or
> any
> >other version spec, similar to pip or any other similar tool. As far as I
> know,
> >community app catalog does not have such capabilities right now - and I
> >strongly believe that it is really a must have feature for a catalog to be
> >successful. At least it is absolutely mandatory for Murano 

Re: [openstack-dev] [nova] vif unplugging when deleting instance while resizing

[Chris Friesen]

On 10/30/2015 03:11 PM, Chris Friesen wrote:


 From what I can tell, in stable/kilo with neutron when doing a resize we will
only unplug the vifs on the source side when confirming the resize.  The code
path looks like:

compute.manager.ComputeManager.confirm_resize()
 compute.manager.ComputeManager._confirm_resize()
 virt.libvirt.driver.LibvirtDriver.confirm_migration()
 virt.libvirt.driver.LibvirtDriver._cleanup_resize()
 virt.libvirt.driver.LibvirtDriver.unplug_vifs()

I'm concerned that if we delete the instance before the vm_state hits RESIZED,
then we will not ever confirm the resize on the host.  (I think this could
happen since the instance host is set to the destination in
compute.manager.ComputeManager.resize_instance(), but the vm_state isn't set to
RESIZED until compute.manager.ComputeManager._finish_resize().

Then the audit from bug 1392527 runs and cleans up the instance files left on
the host, but we're left with the vswitch port still in use because nobody
unplugged it.

Can anyone poke holes in the description above?

The above is all supposition, I haven't reproduced it or gone through it in
enough detail to be certain that this is what's happening.  That's the next 
step.


Some evidence to support the above theory...

I put a "pdb.set_trace()" in _finish_resize() right before the line with

instance.vm_state = vm_states.RESIZED

I then triggered a cold migration, and when it hit the debug statement I ran 
"nova delete " from the CLI and then let the nova-compute process 
continue.


This results in the instance being deleted, but a vswitch port is left open on 
the source host.


Chris

__
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] [Policy][Group-based-policy] SFC Use Case

[NareshA kumar]

Hi,
I have tried GBP in Kilo. Now I want to try GBP+SFC integration in Kilo.
Regarding which i have few questions,


   1. Is GBP+SFC supported now in Kilo?
   2. If yes, please suggest me some links to follow.
   3. For creating SFC in kilo where can I find heat templates?

Regards,

Naresh.
__
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] Fwd: [cloud-devel] Summit Report - Dirk

[Andreas Jaeger]

Maybe interesting for some of you as well,

Andreas


 Forwarded Message 
Subject: [cloud-devel] Summit Report - Dirk
Date: Fri, 30 Oct 2015 17:46:06 +0900
From: Dirk Müller 
To: cloud-devel list 

Hi,

For the last week I’ve been at the OpenStack Summit in Tokyo. If there 
is one major topic then it probably is Docker, Kubernetes and the 
related projects on the OpenStack side.
For the first time Neutron was the most popular project rather than 
Nova, and those sessions were generally the most crowded ones. NFV, SDN 
are therefore also strong themes.


General impression is that given this happened in multiple hotels spread 
across a campus it was much less crowded than the summits before, and 
usually sessions were not so full that one couldn’t get in. That said of 
course there were session where it was just impossible to get in. I 
don’t know the overall attendee number but it was probably not lower 
than Vancouver. Surprisingly when they asked in the keynote about first 
time attendees vs first time japan visitors, there were many more hands 
raised for first time japan visitors (like the majority of the room).


Basically it was very hard to walk around without stumbling over a Red 
Hat employee. I was told over 250 employees attended this summit, which 
felt higher than IBM. My impression was that attendance from HP was 
lower than the years before. The HP cloud announcement probably was 
causing that to some extend, as well as Rackspace raising their 
attendance level quite a bit. Maybe it was also because RH employees got 
asked to wear either RDO or Red Hat corporate branding shirts or hats 
all the time. I did not have any SUSE branding with me since I had to 
save the shirts from last year’s susecon for the susecon attendance next 
week.


City and people are absolutely amazing, I think this got the 2nd spot on 
the ranking of openstack summit locations just after vancouver.


I“ve had a couple of meetings related to Ruler of the Stack challenge. 
The talk was reasonably well attended for a small room (maybe 50 - 60 
people). Funny side stories are that Canonical seemed to have spent some 
man weeks on preparing for the challenge but then only realized two days 
beforehand that the competition will not happen this time. Similarly 
there was a private attendee from Netherlands attending the Summit just 
in order to „kick my butt“. He booked the flights and took holidays just 
in order to win the challenge on his private expenses, and he bought 8 
expensive Extremespeed USB drives preloaded with an image that he built 
by himself (own bootloader, own OS, own package installer and so on, 
based on RHEL7). From what he told me, he would probably have won 
assuming he would have been able to comply to the rules since in a test 
run on his own hardware he managed to install in 8 minutes or so.


We also had a long session with Michael from intel on defining the 
future rules for the competition and got a lot of good ideas out of that 
session.


I’ve not been attending many of the general track sessions since they’re 
all recorded anyway. There was one about the release process changes for 
OpenStack Mitaka that is probably a good time spent if you don’t know 
about it already (done by TTX and dh).


There were a couple of good design sessions. In general my impression it 
is that the decision less crazy than it was before, which is a good 
thing. Particularly worth mentioning was the session about Live Upgrade 
which was eye-opening to me. it looks like we’ll have plenty of fun to 
do that when we’re skipping a release since nova’s implementation is 
depending on customer to upgrade from N to N+1 to N+2. skipping a 
release is unsupported. Tom and I discussed probably a few hours about 
that during the summit already.


Another interesting one was about keystone. There were btw several 
keystone in big deployments/multi site talks that are very worth 
watching. Major upcoming change is deprecation of v2 (which was 
expected) and deprecation of PKI, since it has an unfixable severe 
security bug. We should probably go switching to other backends 
immediately, even for older products. It looks like they might move off 
eventlet removal for another cycle although there is ongoing work to 
integrate with nginx/wsgi, which seems to be a slightly saner choice 
than apache2 as wsgi container. The reason on why they’re not removing 
it is because eventlet is the easiest server to use for dockerized 
openstack services.


Besides that I spent a lot of time on the „OpenStack RPM Packaging“ 
group that I’m currently PTLing. We’ve met with Haikel and Igor as well 
as a couple of people from TripleO and Red Hat. Today I spent most of 
the day helping Mirantis to fix their packaging so that they would be 
able to switch to our common packaging. Luckily we got our first spec 
file merged (after months of little to no progress) and started on 
gating 

Re: [openstack-dev] [Fuel] network_checker code freeze

[Vladimir Kozhukalov]

Dear colleagues,

I'm glad to announce that network-checker is a separate project now. All
related patches have been merged. Thanks everyone for your efforts to make
this happen.

Vladimir Kozhukalov

On Thu, Oct 29, 2015 at 6:42 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> We still can not say that network-checker is a separate project now. I'm
> still working on related issues. Current status is
>
> Network-checker
>
>- Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506896
>- project-config patch https://review.openstack.org/235822 (DONE)
>- pypi (DONE)
>- run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
>- rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
>- fuel-ci verification jobs https://review.fuel-infra.org/12923 (DONE)
>- label jenkins slaves for verification (DONE)
>- directory freeze (DONE)
>- prepare upstream (DONE)
>- wait for project-config patch to be merged (DONE)
>- .gitreview https://review.openstack.org/#/c/238500/ (DONE)
>- .gitignore https://review.openstack.org/#/c/238519/ (ON REVIEW)
>- custom jobs parameters https://review.fuel-infra.org/13272 (DONE)
>- fix core group (DONE)
>- fuel-main
>   - fuel-main: use network-checker repository
>   https://review.openstack.org/238992 (ON REVIEW)
>   - fuel-menu: rename nailgun-net-check -> network-checker
>   https://review.openstack.org/#/c/240225 (ON REVIEW)
>   - network-checker: fix package spec
>   https://review.openstack.org/#/c/240191/ (ON REVIEW)
>- packaging-ci  https://review.fuel-infra.org/13181 (DONE)
>- deprecate network_checker directory
>https://review.openstack.org/23 (ON REVIEW) (once fuel-main patch
>is merged)
>- fix unit tests https://review.openstack.org/#/c/239425/ (DONE)
>- libpcap-dev package and fix tests (patches have been merged but not
>deployed yet)
>   - https://review.openstack.org/#/c/239421/ openstack-ci libpcap-dev
>   package (DONE)
>   - https://review.openstack.org/239463 openstack-ci libpcap-dev
>   package for puppet (DONE)
>   - https://review.fuel-infra.org/13173 fuel-ci libpcap-dev package
>   (DONE)
>- remove old nailgun-net-check package (TODO)
>
> Network-checker tests are still red because libpcap-dev package is not
> installed both on Openstack CI and on Fuel CI.
>
> If you can help to review those patches which are (ON REVIEW), please help.
>
>
>
> Vladimir Kozhukalov
>
> On Tue, Oct 20, 2015 at 6:45 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> As you might know I'm working on splitting multiproject fuel-web
>> repository into several sub-projects. network_checker is one of directories
>> that are to be moved to a separate git project.
>>
>> Checklist for this to happen is as follows:
>>
>>
>>- Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506896
>>- project-config patch https://review.openstack.org/235822 (ON REVIEW)
>>- pypi
>>https://pypi.python.org/pypi?%3Aaction=pkg_edit=Network-checker
>>(DONE)
>>- run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
>>- rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
>>- fuel-ci verification jobs https://review.fuel-infra.org/12923 (ON
>>REVIEW)
>>- label jenkins slaves for verification jobs (ci team)
>>- directory freeze (WE ARE HERE)
>>- prepare upstream (TODO)
>>- project-config (ON REVIEW)
>>- fuel-main patch (TODO)
>>- packaging-ci patch (TODO)
>>- deprecate network_checker directory (TODO)
>>
>>
>> Now we are at the point where we need to freeze fuel-web/network_checker
>> directory. So, I'd like to announce code freeze for this directory and all
>> patches that make changes in the directory and are currently on review will
>> need to be backported to the new git repository.
>>
>>
>>
>> Vladimir Kozhukalov
>>
>
>
__
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] [release] is the new bandit release for mitaka?

[Matthew Thode]

Didn't see a message on the announce list for that.

-- 
Matthew Thode (prometheanfire)

__
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] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

[Davanum Srinivas]

Matt,

0.6.0 and 0.7.0 were released for Mitaka! not Liberty. Though yes, because
of not having pins any library we release for Mitaka will end up being used
with Liberty as well.
http://lists.openstack.org/pipermail/openstack-announce/2015-October/000701.html

No, we are not reverting. Here's my current thought as a review:
https://review.openstack.org/#/c/240371

-- Dims

On Sat, Oct 31, 2015 at 12:06 AM, Matt Riedemann  wrote:

>
>
> On 10/29/2015 5:22 PM, Sean Dague wrote:
>
>> Right, the crux of the problem is the move by the library from SIGUSR1
>> -> SIGUSR2 with no overlap and deprecation period breaks the ability to
>> have any tooling use this without atomically updating that tooling, and
>> this library, in all environments, all at the same time.
>>
>> We need the SIGUSR1 handler added back in, deprecated, and not removed
>> for a couple cycles.
>>
>> -Sean
>>
>>
>> On 10/30/2015 06:46 AM, Davanum Srinivas wrote:
>>
>>> Matt,
>>>
>>> Yes, Sean already opened a critical bug
>>> - https://bugs.launchpad.net/oslo.reports/+bug/1510740
>>>
>>> Please note that this change was added to oslo.reports *after* the
>>> liberty release in support of Mitaka. So i am not sure why we need to
>>> add it to liberty release notes. Also this is a consequence of NOT
>>> having version caps which was a decision a while ago as well.
>>>
>>> -- DIms
>>>
>>> On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann
>>> > wrote:
>>>
>>>
>>>
>>>  On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:
>>>
>>>  Background
>>>  --
>>>
>>>  Oslo Guru Meditation (error) Reports (GMR)[*] are a useful
>>> debugging
>>>  mechanism that allows one to capture the current state of a Nova
>>>  process/executable (e.g. `nova-compute`, `nova-api`, etc).
>>>
>>>  The way to generate the error report is to supply the
>>> 'User-defined
>>>  signal', SIGUSR1, when killing a Nova process.  E.g.
>>>
>>>   $ kill -USR1 `pgrep nova-compute`
>>>
>>>  which results in GMR being printed to your standard error
>>> ('stderr')
>>>  stream, wherever it ends up being redirected to (e.g. to a
>>>  corresponding
>>>  Nova process-specific log file, otherwise, on systemd-enabled
>>>  systems,
>>>  to its journal).
>>>
>>>
>>>  Change in Mitaka (and above)
>>>  
>>>
>>>   From the upcoming Mitaka release onwards, the default expected
>>> UNIX
>>>  signal to generate GMR has been changed[1] from USR1 to USR2
>>>  (another
>>>  User-defined singal), because the USR1 is reserved by Apache
>>>  'mod_wsgi'
>>>  for its own purpose.
>>>
>>>  So, to generate GMR, from Mitaka release:
>>>
>>>   $ kill -USR2 `pgrep nova-compute`
>>>
>>>  A corresponding Nova documentation change[2] has been submitted
>>> to
>>>  reflect this new reality.
>>>
>>>
>>>  [1] https://review.openstack.org/#/c/223133/ --
>>>  guru_meditation_report:
>>>   Use SIGUSR2 instead of SIGUSR1
>>>  [2] https://review.openstack.org/#/c/227779/ -- doc: gmr:
>>> Update
>>>   instructions to generate GMR error reports
>>>
>>>
>>>  [*] References
>>>  --
>>>
>>>  Related reading:
>>>
>>>  - http://docs.openstack.org/developer/nova/gmr.html
>>>  - http://docs.openstack.org/developer/oslo.reports/usage.html
>>>  - https://wiki.openstack.org/wiki/GuruMeditationReport
>>>  -
>>>
>>> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
>>>
>>>
>>>  Looks like this broke some tooling in the gate job runs where gmr's
>>>  are created at the end of the service logs when the services exit.
>>>  Here is a mitaka change with grenade on the liberty side with the
>>>  gmr at the end:
>>>
>>>
>>> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz
>>>
>>>  And on the new side it's gone:
>>>
>>>
>>> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz
>>>
>>>  So obviously an upgrade impact, I'm hoping we get this into the
>>>  liberty release notes as something to change when people move up to
>>>  oslo.reports 1.6.0.
>>>
>>>  We should also get the gate tooling fixed around this, I'm not sure
>>>  where that was configured/triggered though, sdague probably knows.
>>>
>>>  --
>>>
>>>  Thanks,
>>>
>>>  Matt Riedemann
>>>
>>>
>>>
>>>
>>>  __
>>>  OpenStack Development Mailing List (not for usage questions)
>>>  Unsubscribe:
>>>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> 

Re: [openstack-dev] Fwd: [cloud-devel] Summit Report - Dirk

[Dirk Müller]

Hi,

> Ha, I'm surprised you forwarded this. But thanks. :)

Yeah, I guess I need to be more explicit on where my mails should be
forwarded to without even asking me next time..
I apologize wholeheartedly.

> Also, this is the first time Neutron has been more popular/buzzworthy than
> Nova?

Oh, it was definitely the most buzzworthy project already in YVR, but
this time it had only positive words attached to it as well. Very well
done, Neutron team!

>  The Nova sessions are usually populated by Nova people and we just
> stare at each other. :)

Thats not true.. At some point we might need a separate Nova/Neutron
summit though.

> I believe the best compliment I heard at the YVR
> nova/ops session was an operator saying 'nova is the least bad project in my
> deployment.'

Oh come on, we all love Nova anyway :-)

Greetings,
Dirk

__
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] status of the live upgrade session

[Gareth]

Hey guys,

In this summary
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads, there
is a live upgrade session. But the linked the etherpad is empty:
https://etherpad.openstack.org/p/mitaka-crossproject-upgrades .

So what's the status or conclusion of this session?

-- 
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ￥1 to an open organization you specify.

__
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] [Infra][Nova][Neutron] 6WIND Networking CI - approval for posting comments

[Armando M.]

On 30 October 2015 at 18:41, Francesco Santoro 
wrote:

>
> Hi Armando,
> thanks for you answer.
>
> We actually just want approval for posting non voting comments to neutron.
> As you said we don't have a significant history on Gerrit because, after
> some successful tests, we stopped posting comments on neutron (and nova)
> waiting for core maintainers approval.
> Our current CI activity is obviously not long enough to request voting
> rights.
>
> We are still commenting back to Gerrit on ci-devstack but there is no big
> activity on this project.
> Since our idea (for future) is to obtain voting rights we need to post
> comments to have a stronger Gerrit activity and to let you evaluate the
> stability of our CI.
>
> Do you suggest to keep posting on ci-devstack or can we enable comments to
> neutron as well?
>

I would be ok to have this voting for now.

Having said that, Mike (cc-ed here) will be working closely with the
Neutron team to re-align/improve Neutron 3rd party CI support, so stay
tuned for progresses on this front.

Cheers,
Armando


>
> Regards,
> Francesco
> On Fri, Oct 30, 2015 at 1:17 AM, Armando M.  wrote:
>
>>
>>
>> On 30 October 2015 at 02:49, Matt Riedemann 
>> wrote:
>>
>>>
>>>
>>> On 10/29/2015 12:13 PM, Francesco Santoro wrote:
>>>
 Dear Infra team,

 According to the requirements specified in [1] posting comments on
 patches needs approval from core maintainers of projects.

 Here at 6WIND we deployed and successfully tested [2] (using ci-sandbox
 project) our third party CI system [4] following all the steps defined
 in [1].
 We also run our CI on nova (and neutron) patches without posting
 comments just to test a bigger jobs load.
 Example artifacts are available at [3]

 For this reason we would like to get your official approval for posting
 non voting comments to both nova and neutron.

>>>
>> The CI hasn't been doing this long enough [1] to really see how reliable
>> it is, but it's been promising so far.
>>
>
>> [1]
>> https://review.openstack.org/#/q/reviewer:%226WIND+Networking+CI+%253Copenstack-networking-ci%25406wind.com%253E%22+project:openstack/neutron,n,z
>>
>>
>>>
 Kind regards,
 Francesco

 [1]

 http://docs.openstack.org/infra/system-config/third_party.html#requirements
 [2] https://review.openstack.org/#/c/238139/ or
 https://review.openstack.org/#/c/226956/
 [3] http://openstack-ci.6wind.com/networking-6wind-ci/230537 or
 http://openstack-ci.6wind.com/networking-6wind-ci/202098
 [4]
 https://wiki.openstack.org/wiki/ThirdPartySystems/6WIND_Networking_CI



 __
 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


>>> Do you have any code in nova that's specific to your configuration?
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and Alcatel-Lucent VitalQIP

[Pavel Bondar]

Hi Maruti,

For now only Pluggable IPAM interface with reference IPAM driver were released,
and I am working on implementing IPAM driver for Infoblox.

But I am not aware about existense of IPAM drivers from BlueCat or Alcatel.
If you want to investigate with pluggable IPAM more you can start with IPAM 
Interface
and reference IPAM driver. They can be found under [1].

[1] https://github.com/openstack/neutron/tree/master/neutron/ipam

Thanks,
Pavel

From: Kamat, Maruti Haridas 
Sent: Thursday, October 29, 2015 8:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and 
Alcatel-Lucent VitalQIP
  

Hi
 
I am exploring IPAM feature in OpenStack Neutron. In particular, I wanted to 
look at the IPAM drivers for BlueCat Networks’ (Proteus) and Alcatel-Lucent’s 
VitalQIP.
 
If someone can provide me with pointers, it would be of great help.
 
Thanks,
Maruti
 
 
 
__
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] [nova] Checking dates for the Mitaka Nova Midcycle

[Matt Riedemann]

On 10/19/2015 11:35 AM, John Garbutt wrote:

Hi,

We have a few offers for midcycle dates.

If you would like to attend, please let me know if:
* the proposed date works for you
* one of the proposed venues is a no go (budget or otherwise)

http://doodle.com/poll/88sbzgcv28rww2n3

Thanks,
johnthetubaguy

PS
If doodle doesn't work for you, let me know and I can add your vote in.

__
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



I heard that it was decided to go with Bristol, are the dates firm?

--

Thanks,

Matt Riedemann


__
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] [nova] Checking dates for the Mitaka Nova Midcycle

[Matt Riedemann]

On 10/30/2015 9:08 AM, Matt Riedemann wrote:



On 10/19/2015 11:35 AM, John Garbutt wrote:

Hi,

We have a few offers for midcycle dates.

If you would like to attend, please let me know if:
* the proposed date works for you
* one of the proposed venues is a no go (budget or otherwise)

http://doodle.com/poll/88sbzgcv28rww2n3

Thanks,
johnthetubaguy

PS
If doodle doesn't work for you, let me know and I can add your vote in.

__

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



I heard that it was decided to go with Bristol, are the dates firm?



Nevermind, I just saw mikal's post.

--

Thanks,

Matt Riedemann


__
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] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

[Matt Riedemann]

On 10/29/2015 4:46 PM, Davanum Srinivas wrote:

Matt,

Yes, Sean already opened a critical bug -
https://bugs.launchpad.net/oslo.reports/+bug/1510740

Please note that this change was added to oslo.reports *after* the
liberty release in support of Mitaka. So i am not sure why we need to
add it to liberty release notes. Also this is a consequence of NOT
having version caps which was a decision a while ago as well.

-- DIms

On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann
> wrote:



On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:

Background
--

Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
mechanism that allows one to capture the current state of a Nova
process/executable (e.g. `nova-compute`, `nova-api`, etc).

The way to generate the error report is to supply the 'User-defined
signal', SIGUSR1, when killing a Nova process.  E.g.

  $ kill -USR1 `pgrep nova-compute`

which results in GMR being printed to your standard error ('stderr')
stream, wherever it ends up being redirected to (e.g. to a
corresponding
Nova process-specific log file, otherwise, on systemd-enabled
systems,
to its journal).


Change in Mitaka (and above)


  From the upcoming Mitaka release onwards, the default expected
UNIX
signal to generate GMR has been changed[1] from USR1 to USR2
(another
User-defined singal), because the USR1 is reserved by Apache
'mod_wsgi'
for its own purpose.

So, to generate GMR, from Mitaka release:

  $ kill -USR2 `pgrep nova-compute`

A corresponding Nova documentation change[2] has been submitted to
reflect this new reality.


[1] https://review.openstack.org/#/c/223133/ --
guru_meditation_report:
  Use SIGUSR2 instead of SIGUSR1
[2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
  instructions to generate GMR error reports


[*] References
--

Related reading:

- http://docs.openstack.org/developer/nova/gmr.html
- http://docs.openstack.org/developer/oslo.reports/usage.html
- https://wiki.openstack.org/wiki/GuruMeditationReport
-

https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/


Looks like this broke some tooling in the gate job runs where gmr's
are created at the end of the service logs when the services exit.
Here is a mitaka change with grenade on the liberty side with the
gmr at the end:


http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz

And on the new side it's gone:


http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz

So obviously an upgrade impact, I'm hoping we get this into the
liberty release notes as something to change when people move up to
oslo.reports 1.6.0.

We should also get the gate tooling fixed around this, I'm not sure
where that was configured/triggered though, sdague probably knows.

--

Thanks,

Matt Riedemann



__
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




--
Davanum Srinivas :: https://twitter.com/dims


__
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



I guess upper-constraints in stable/liberty is 0.5.0 for oslo.reports 
[1] so people shouldn't be using anything newer than than with liberty 
deployments. So nothing needed in the release notes there I suppose.


But I agree we should probably have a deprecation cycle on this.

[1] 
https://github.com/openstack/requirements/blob/stable/liberty/upper-constraints.txt#L197


--

Thanks,

Matt Riedemann


__
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] Fwd: [cloud-devel] Summit Report - Dirk

[Matt Riedemann]

On 10/30/2015 4:29 AM, Andreas Jaeger wrote:

Maybe interesting for some of you as well,

Andreas


 Forwarded Message 
Subject: [cloud-devel] Summit Report - Dirk
Date: Fri, 30 Oct 2015 17:46:06 +0900
From: Dirk Müller 
To: cloud-devel list 

Hi,

For the last week I’ve been at the OpenStack Summit in Tokyo. If there
is one major topic then it probably is Docker, Kubernetes and the
related projects on the OpenStack side.
For the first time Neutron was the most popular project rather than
Nova, and those sessions were generally the most crowded ones. NFV, SDN
are therefore also strong themes.

General impression is that given this happened in multiple hotels spread
across a campus it was much less crowded than the summits before, and
usually sessions were not so full that one couldn’t get in. That said of
course there were session where it was just impossible to get in. I
don’t know the overall attendee number but it was probably not lower
than Vancouver. Surprisingly when they asked in the keynote about first
time attendees vs first time japan visitors, there were many more hands
raised for first time japan visitors (like the majority of the room).

Basically it was very hard to walk around without stumbling over a Red
Hat employee. I was told over 250 employees attended this summit, which
felt higher than IBM. My impression was that attendance from HP was
lower than the years before. The HP cloud announcement probably was
causing that to some extend, as well as Rackspace raising their
attendance level quite a bit. Maybe it was also because RH employees got
asked to wear either RDO or Red Hat corporate branding shirts or hats
all the time. I did not have any SUSE branding with me since I had to
save the shirts from last year’s susecon for the susecon attendance next
week.

City and people are absolutely amazing, I think this got the 2nd spot on
the ranking of openstack summit locations just after vancouver.

I“ve had a couple of meetings related to Ruler of the Stack challenge.
The talk was reasonably well attended for a small room (maybe 50 - 60
people). Funny side stories are that Canonical seemed to have spent some
man weeks on preparing for the challenge but then only realized two days
beforehand that the competition will not happen this time. Similarly
there was a private attendee from Netherlands attending the Summit just
in order to „kick my butt“. He booked the flights and took holidays just
in order to win the challenge on his private expenses, and he bought 8
expensive Extremespeed USB drives preloaded with an image that he built
by himself (own bootloader, own OS, own package installer and so on,
based on RHEL7). From what he told me, he would probably have won
assuming he would have been able to comply to the rules since in a test
run on his own hardware he managed to install in 8 minutes or so.

We also had a long session with Michael from intel on defining the
future rules for the competition and got a lot of good ideas out of that
session.

I’ve not been attending many of the general track sessions since they’re
all recorded anyway. There was one about the release process changes for
OpenStack Mitaka that is probably a good time spent if you don’t know
about it already (done by TTX and dh).

There were a couple of good design sessions. In general my impression it
is that the decision less crazy than it was before, which is a good
thing. Particularly worth mentioning was the session about Live Upgrade
which was eye-opening to me. it looks like we’ll have plenty of fun to
do that when we’re skipping a release since nova’s implementation is
depending on customer to upgrade from N to N+1 to N+2. skipping a
release is unsupported. Tom and I discussed probably a few hours about
that during the summit already.

Another interesting one was about keystone. There were btw several
keystone in big deployments/multi site talks that are very worth
watching. Major upcoming change is deprecation of v2 (which was
expected) and deprecation of PKI, since it has an unfixable severe
security bug. We should probably go switching to other backends
immediately, even for older products. It looks like they might move off
eventlet removal for another cycle although there is ongoing work to
integrate with nginx/wsgi, which seems to be a slightly saner choice
than apache2 as wsgi container. The reason on why they’re not removing
it is because eventlet is the easiest server to use for dockerized
openstack services.

Besides that I spent a lot of time on the „OpenStack RPM Packaging“
group that I’m currently PTLing. We’ve met with Haikel and Igor as well
as a couple of people from TripleO and Red Hat. Today I spent most of
the day helping Mirantis to fix their packaging so that they would be
able to switch to our common packaging. Luckily we got our first spec
file merged (after months of little to no progress) and started on
gating implementations.

The 

Re: [openstack-dev] [Infra][Nova][Neutron] 6WIND Networking CI - approval for posting comments

[Matt Riedemann]

On 10/30/2015 7:41 AM, Armando M. wrote:



On 30 October 2015 at 18:41, Francesco Santoro
> wrote:


Hi Armando,
thanks for you answer.

We actually just want approval for posting non voting comments to
neutron.
As you said we don't have a significant history on Gerrit because,
after some successful tests, we stopped posting comments on neutron
(and nova) waiting for core maintainers approval.
Our current CI activity is obviously not long enough to request
voting rights.

We are still commenting back to Gerrit on ci-devstack but there is
no big activity on this project.
Since our idea (for future) is to obtain voting rights we need to
post comments to have a stronger Gerrit activity and to let you
evaluate the stability of our CI.

Do you suggest to keep posting on ci-devstack or can we enable
comments to neutron as well?


I would be ok to have this voting for now.

Having said that, Mike (cc-ed here) will be working closely with the
Neutron team to re-align/improve Neutron 3rd party CI support, so stay
tuned for progresses on this front.

Cheers,
Armando


Regards,
Francesco
On Fri, Oct 30, 2015 at 1:17 AM, Armando M. > wrote:



On 30 October 2015 at 02:49, Matt Riedemann
>
wrote:



On 10/29/2015 12:13 PM, Francesco Santoro wrote:

Dear Infra team,

According to the requirements specified in [1] posting
comments on
patches needs approval from core maintainers of projects.

Here at 6WIND we deployed and successfully tested [2]
(using ci-sandbox
project) our third party CI system [4] following all the
steps defined
in [1].
We also run our CI on nova (and neutron) patches without
posting
comments just to test a bigger jobs load.
Example artifacts are available at [3]

For this reason we would like to get your official
approval for posting
non voting comments to both nova and neutron.


The CI hasn't been doing this long enough [1] to really see how
reliable it is, but it's been promising so far.


[1]

https://review.openstack.org/#/q/reviewer:%226WIND+Networking+CI+%253Copenstack-networking-ci%25406wind.com%253E%22+project:openstack/neutron,n,z



Kind regards,
Francesco

[1]

http://docs.openstack.org/infra/system-config/third_party.html#requirements
[2] https://review.openstack.org/#/c/238139/ or
https://review.openstack.org/#/c/226956/
[3]
http://openstack-ci.6wind.com/networking-6wind-ci/230537 or
http://openstack-ci.6wind.com/networking-6wind-ci/202098
[4]

https://wiki.openstack.org/wiki/ThirdPartySystems/6WIND_Networking_CI



__
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


Do you have any code in nova that's specific to your
configuration?

--

Thanks,

Matt Riedemann



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

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




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

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



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

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

[Matt Riedemann]

On 10/29/2015 5:22 PM, Sean Dague wrote:

Right, the crux of the problem is the move by the library from SIGUSR1
-> SIGUSR2 with no overlap and deprecation period breaks the ability to
have any tooling use this without atomically updating that tooling, and
this library, in all environments, all at the same time.

We need the SIGUSR1 handler added back in, deprecated, and not removed
for a couple cycles.

-Sean

On 10/30/2015 06:46 AM, Davanum Srinivas wrote:

Matt,

Yes, Sean already opened a critical bug
- https://bugs.launchpad.net/oslo.reports/+bug/1510740

Please note that this change was added to oslo.reports *after* the
liberty release in support of Mitaka. So i am not sure why we need to
add it to liberty release notes. Also this is a consequence of NOT
having version caps which was a decision a while ago as well.

-- DIms

On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann
> wrote:



 On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:

 Background
 --

 Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
 mechanism that allows one to capture the current state of a Nova
 process/executable (e.g. `nova-compute`, `nova-api`, etc).

 The way to generate the error report is to supply the 'User-defined
 signal', SIGUSR1, when killing a Nova process.  E.g.

  $ kill -USR1 `pgrep nova-compute`

 which results in GMR being printed to your standard error ('stderr')
 stream, wherever it ends up being redirected to (e.g. to a
 corresponding
 Nova process-specific log file, otherwise, on systemd-enabled
 systems,
 to its journal).


 Change in Mitaka (and above)
 

  From the upcoming Mitaka release onwards, the default expected UNIX
 signal to generate GMR has been changed[1] from USR1 to USR2
 (another
 User-defined singal), because the USR1 is reserved by Apache
 'mod_wsgi'
 for its own purpose.

 So, to generate GMR, from Mitaka release:

  $ kill -USR2 `pgrep nova-compute`

 A corresponding Nova documentation change[2] has been submitted to
 reflect this new reality.


 [1] https://review.openstack.org/#/c/223133/ --
 guru_meditation_report:
  Use SIGUSR2 instead of SIGUSR1
 [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
  instructions to generate GMR error reports


 [*] References
 --

 Related reading:

 - http://docs.openstack.org/developer/nova/gmr.html
 - http://docs.openstack.org/developer/oslo.reports/usage.html
 - https://wiki.openstack.org/wiki/GuruMeditationReport
 -
 
https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/


 Looks like this broke some tooling in the gate job runs where gmr's
 are created at the end of the service logs when the services exit.
 Here is a mitaka change with grenade on the liberty side with the
 gmr at the end:

 
http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz

 And on the new side it's gone:

 
http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz

 So obviously an upgrade impact, I'm hoping we get this into the
 liberty release notes as something to change when people move up to
 oslo.reports 1.6.0.

 We should also get the gate tooling fixed around this, I'm not sure
 where that was configured/triggered though, sdague probably knows.

 --

 Thanks,

 Matt Riedemann



 __
 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




--
Davanum Srinivas :: https://twitter.com/dims


__
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



Is there going to be a revert of 
https://review.openstack.org/#/c/223133/ ?  This has already baked into 
a couple of oslo.reports releases:

Re: [openstack-dev] Fwd: [cloud-devel] Summit Report - Dirk

[Matt Riedemann]

On 10/30/2015 4:29 AM, Andreas Jaeger wrote:

Maybe interesting for some of you as well,

Andreas


 Forwarded Message 
Subject: [cloud-devel] Summit Report - Dirk
Date: Fri, 30 Oct 2015 17:46:06 +0900
From: Dirk Müller 
To: cloud-devel list 

Hi,

For the last week I’ve been at the OpenStack Summit in Tokyo. If there
is one major topic then it probably is Docker, Kubernetes and the
related projects on the OpenStack side.
For the first time Neutron was the most popular project rather than
Nova, and those sessions were generally the most crowded ones. NFV, SDN
are therefore also strong themes.

General impression is that given this happened in multiple hotels spread
across a campus it was much less crowded than the summits before, and
usually sessions were not so full that one couldn’t get in. That said of
course there were session where it was just impossible to get in. I
don’t know the overall attendee number but it was probably not lower
than Vancouver. Surprisingly when they asked in the keynote about first
time attendees vs first time japan visitors, there were many more hands
raised for first time japan visitors (like the majority of the room).

Basically it was very hard to walk around without stumbling over a Red
Hat employee. I was told over 250 employees attended this summit, which
felt higher than IBM. My impression was that attendance from HP was
lower than the years before. The HP cloud announcement probably was
causing that to some extend, as well as Rackspace raising their
attendance level quite a bit. Maybe it was also because RH employees got
asked to wear either RDO or Red Hat corporate branding shirts or hats
all the time. I did not have any SUSE branding with me since I had to
save the shirts from last year’s susecon for the susecon attendance next
week.

City and people are absolutely amazing, I think this got the 2nd spot on
the ranking of openstack summit locations just after vancouver.

I“ve had a couple of meetings related to Ruler of the Stack challenge.
The talk was reasonably well attended for a small room (maybe 50 - 60
people). Funny side stories are that Canonical seemed to have spent some
man weeks on preparing for the challenge but then only realized two days
beforehand that the competition will not happen this time. Similarly
there was a private attendee from Netherlands attending the Summit just
in order to „kick my butt“. He booked the flights and took holidays just
in order to win the challenge on his private expenses, and he bought 8
expensive Extremespeed USB drives preloaded with an image that he built
by himself (own bootloader, own OS, own package installer and so on,
based on RHEL7). From what he told me, he would probably have won
assuming he would have been able to comply to the rules since in a test
run on his own hardware he managed to install in 8 minutes or so.

We also had a long session with Michael from intel on defining the
future rules for the competition and got a lot of good ideas out of that
session.

I’ve not been attending many of the general track sessions since they’re
all recorded anyway. There was one about the release process changes for
OpenStack Mitaka that is probably a good time spent if you don’t know
about it already (done by TTX and dh).

There were a couple of good design sessions. In general my impression it
is that the decision less crazy than it was before, which is a good
thing. Particularly worth mentioning was the session about Live Upgrade
which was eye-opening to me. it looks like we’ll have plenty of fun to
do that when we’re skipping a release since nova’s implementation is
depending on customer to upgrade from N to N+1 to N+2. skipping a
release is unsupported. Tom and I discussed probably a few hours about
that during the summit already.


This is due to online data migrations which are a key part of live 
upgrade. Dan Smith has an excellent series of blog posts on that 
starting here [1].




Another interesting one was about keystone. There were btw several
keystone in big deployments/multi site talks that are very worth
watching. Major upcoming change is deprecation of v2 (which was
expected) and deprecation of PKI, since it has an unfixable severe
security bug. We should probably go switching to other backends
immediately, even for older products. It looks like they might move off
eventlet removal for another cycle although there is ongoing work to
integrate with nginx/wsgi, which seems to be a slightly saner choice
than apache2 as wsgi container. The reason on why they’re not removing
it is because eventlet is the easiest server to use for dockerized
openstack services.

Besides that I spent a lot of time on the „OpenStack RPM Packaging“
group that I’m currently PTLing. We’ve met with Haikel and Igor as well
as a couple of people from TripleO and Red Hat. Today I spent most of
the day helping Mirantis to fix their packaging so that they would be
able to switch 

Re: [openstack-dev] About the response parameters of the API List volumes

[Matt Riedemann]

On 10/27/2015 9:57 PM, chenying wrote:

hi, Folks

The API: GET/v2/​{tenant_id}​/volumes  List volumes

When we use the tenant admin to list all the created volumes, we can
list all tenant's volumes. But the response parameters do not include

the parameter tenant_id. For a administrator, it is reasonable to see
the the tenant_id of a volume form the response.

So why don't we add the tenant_id to the response parameters of this
API? What's the reason? Thanks.


Best regard.
chenying(IRC)
ying.c...@huawei.com



__
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



It might just be an oversight. There is a similar issue with listing all 
tenant server groups as an admin in nova, and a spec was proposed [1]. 
To fix that, we use microversions (in nova). Cinder is working toward 
microversion support in Mitaka I believe be able to easily make API 
changes like this which are otherwise backward incompatible since you're 
changing the response.


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

--

Thanks,

Matt Riedemann


__
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] IPAM drivers for BlueCat networks and Alcatel-Lucent VitalQIP

[Kamat, Maruti Haridas]

Hi Pavel,
  
 Thanks for the information.

 I was also looking at Infoblox driver at 
https://github.com/openstack/networking-infoblox

 Is implementation of Infoblox driver still going on? 

Thanks,
Maruti


-Original Message-
From: Pavel Bondar [mailto:pbon...@infoblox.com] 
Sent: Friday, October 30, 2015 6:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and 
Alcatel-Lucent VitalQIP

Hi Maruti,

For now only Pluggable IPAM interface with reference IPAM driver were released, 
and I am working on implementing IPAM driver for Infoblox.

But I am not aware about existense of IPAM drivers from BlueCat or Alcatel.
If you want to investigate with pluggable IPAM more you can start with IPAM 
Interface and reference IPAM driver. They can be found under [1].

[1] https://github.com/openstack/neutron/tree/master/neutron/ipam

Thanks,
Pavel

From: Kamat, Maruti Haridas 
Sent: Thursday, October 29, 2015 8:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and 
Alcatel-Lucent VitalQIP
  

Hi
 
I am exploring IPAM feature in OpenStack Neutron. In particular, I wanted to 
look at the IPAM drivers for BlueCat Networks' (Proteus) and Alcatel-Lucent's 
VitalQIP.
 
If someone can provide me with pointers, it would be of great help.
 
Thanks,
Maruti
 
 
 
__
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] Multi-ip use cases

[Shraddha Pandhe]

Hi folks,

James Penick from Yahoo! presented a talk on Thursday about how Yahoo uses
Neutron for Ironic. I would like to follow up on one particular use case
that was discussed: Multi-IP support.

Here's our use-case for Multi-ip:

For Ironic, we want user to specify the number of IPs on boot. Now, we want
scheduler to find a network with sufficient IPs and then pick a host in
that subnet (Note: static IPs for baremetal). Now, when allocating network,
we want to assign all requested IPs from the same subnet as the host's
static IP. Also, we don't want to configure those IPs on the host. We only
want to display them on "nova show".

So basically we will only create one port for the host, and append all
fixed_ips in the ports fixed_ip list field.

Questions:
1. Hows do most people use the fixed_ips field in the port? What are
different ways you can populate multiple IPs in fixed_ips? One way I know
is, using neutron-client to create port, you can specify --fixed-ip as many
times as you want, and that will append fixed_ips to the port. Any other
way?

2. Is anybody else using multi-ip?
__
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] [Infra][Nova][Neutron] 6WIND Networking CI - approval for posting comments

[Francesco Santoro]

Hi Armando,
thanks for you answer.

We actually just want approval for posting non voting comments to neutron.
As you said we don't have a significant history on Gerrit because, after
some successful tests, we stopped posting comments on neutron (and nova)
waiting for core maintainers approval.
Our current CI activity is obviously not long enough to request voting
rights.

We are still commenting back to Gerrit on ci-devstack but there is no big
activity on this project.
Since our idea (for future) is to obtain voting rights we need to post
comments to have a stronger Gerrit activity and to let you evaluate the
stability of our CI.

Do you suggest to keep posting on ci-devstack or can we enable comments to
neutron as well?

Regards,
Francesco
On Fri, Oct 30, 2015 at 1:17 AM, Armando M.  wrote:

>
>
> On 30 October 2015 at 02:49, Matt Riedemann 
> wrote:
>
>>
>>
>> On 10/29/2015 12:13 PM, Francesco Santoro wrote:
>>
>>> Dear Infra team,
>>>
>>> According to the requirements specified in [1] posting comments on
>>> patches needs approval from core maintainers of projects.
>>>
>>> Here at 6WIND we deployed and successfully tested [2] (using ci-sandbox
>>> project) our third party CI system [4] following all the steps defined
>>> in [1].
>>> We also run our CI on nova (and neutron) patches without posting
>>> comments just to test a bigger jobs load.
>>> Example artifacts are available at [3]
>>>
>>> For this reason we would like to get your official approval for posting
>>> non voting comments to both nova and neutron.
>>>
>>
> The CI hasn't been doing this long enough [1] to really see how reliable
> it is, but it's been promising so far.
>

> [1]
> https://review.openstack.org/#/q/reviewer:%226WIND+Networking+CI+%253Copenstack-networking-ci%25406wind.com%253E%22+project:openstack/neutron,n,z
>
>
>>
>>> Kind regards,
>>> Francesco
>>>
>>> [1]
>>>
>>> http://docs.openstack.org/infra/system-config/third_party.html#requirements
>>> [2] https://review.openstack.org/#/c/238139/ or
>>> https://review.openstack.org/#/c/226956/
>>> [3] http://openstack-ci.6wind.com/networking-6wind-ci/230537 or
>>> http://openstack-ci.6wind.com/networking-6wind-ci/202098
>>> [4]
>>> https://wiki.openstack.org/wiki/ThirdPartySystems/6WIND_Networking_CI
>>>
>>>
>>>
>>> __
>>> 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
>>>
>>>
>> Do you have any code in nova that's specific to your configuration?
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev