[openstack-dev] [heat] A question on the endpoint of Heat

[zengchen]

Hi, Heat stackers:
May I ask a question about the endpoint of Heat. I see the endpoints of 
Heat registered to Keystone look like this.
'http://10.229.45.150:8004/v1/$(project_id)s' . My question is that why use '$' 
instead of '%' as the replacement symbol.
Is there some kind of rule? 


cheers
zengchen__
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] Max open files limit for nova-api

[Van Leeuwen, Robert]

Luckily you can easily compile your own:
This post shows the source code and how to build a tool like prlimit: 
http://lzone.de/cheat-sheet/ulimit

IMHO it is quite ugly to change it this way though.
I see this more as a tool for a process that cannot be restarted without 
causing issues.
The proper way would be to use systemd unit files or whatever is relevant in 
your setup.

Cheers,
Robert



From: Prashant Shetty 
Date: Monday, December 19, 2016 at 7:30 PM
To: John Petrini 
Cc: "openstack@lists.openstack.org" 
Subject: Re: [Openstack] Max open files limit for nova-api

Thanks John. Seems like prlimit doesnt seems to be available for ubuntu 14.04 
:-(

On Mon, Dec 19, 2016 at 11:51 PM, John Petrini 
> wrote:
Hi Prashant,

On second thought that trick might only work on CentOS.  You might have success 
using prlimit instead.


___

John Petrini

NOC Systems Administrator   //   CoreDial, LLC   //   
coredial.com   //   [witter] 
[inkedIn] 
[oogle Plus] 
[log] 

Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422
P: 215.297.4400 x232   //   F: 215.297.4401   //   E: 
jpetr...@coredial.com

[xceptional people. Proven Processes. Innovative Technology. 
Discover]

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission,  dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

On Mon, Dec 19, 2016 at 1:13 PM, Prashant Shetty 
> wrote:
Hi John,
Echo option doesnt seems to work on below controller.

stack@devstackvm:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
stack@devstackvm:~$

stack@devstackvm:~$ ps aux | grep nova-api
stack 3070  1.1  0.1 271576 121092 pts/9   S+   Dec16  50:29 
/usr/bin/python /usr/local/bin/nova-api
stack 3079  0.3  0.8 1045308 881676 pts/9  S+   Dec16  14:32 
/usr/bin/python /usr/local/bin/nova-api
stack 3080  0.2  0.1 324808 161096 pts/9   S+   Dec16   9:25 
/usr/bin/python /usr/local/bin/nova-api
stack 3081  0.2  0.7 980172 816468 pts/9   S+   Dec16  10:37 
/usr/bin/python /usr/local/bin/nova-api
stack 3082  0.3  0.1 336824 173288 pts/9   S+   Dec16  16:11 
/usr/bin/python /usr/local/bin/nova-api
stack 3083  0.4  0.1 338788 175264 pts/9   S+   Dec16  19:05 
/usr/bin/python /usr/local/bin/nova-api
stack 3084  0.4  0.1 336616 172912 pts/9   S+   Dec16  17:41 
/usr/bin/python /usr/local/bin/nova-api
stack 3085  0.2  0.8 1054900 891272 pts/9  S+   Dec16  10:09 
/usr/bin/python /usr/local/bin/nova-api
stack 3086  0.2  0.1 325088 161228 pts/9   S+   Dec16   9:59 
/usr/bin/python /usr/local/bin/nova-api
stack 3097  0.2  0.1 308088 151828 pts/9   S+   Dec16  11:10 
/usr/bin/python /usr/local/bin/nova-api
stack 3098  0.2  0.1 308296 152360 pts/9   S+   Dec16  11:15 
/usr/bin/python /usr/local/bin/nova-api
stack 3099  0.2  0.1 308708 152544 pts/9   S+   Dec16  11:42 
/usr/bin/python /usr/local/bin/nova-api
stack 3100  0.2  0.1 309588 153624 pts/9   S+   Dec16  11:06 
/usr/bin/python /usr/local/bin/nova-api
stack 3101  0.2  0.1 308372 152396 pts/9   S+   Dec16  11:14 
/usr/bin/python /usr/local/bin/nova-api
stack 3102  0.2  0.1 308084 152052 pts/9   S+   Dec16  11:10 
/usr/bin/python /usr/local/bin/nova-api
stack 3103  0.2  0.1 308380 152416 pts/9   S+   Dec16  11:09 
/usr/bin/python /usr/local/bin/nova-api
stack 3104  0.2  0.1 307652 151560 pts/9   S+   Dec16  10:29 
/usr/bin/python /usr/local/bin/nova-api
stack 8087  0.0  0.0  11752  2044 pts/21   S+   10:07   0:00 grep 
--color=auto nova-api
stack@devstackvm:~$

stack@devstackvm:~$ cat /proc/3070/limits  | grep "Max open files"
Max open files1024 4096 files
stack@devstackvm:~$
stack@devstackvm:~$ echo -n "Max open files=8192:unlimited"  > /proc/3070/limits
-bash: /proc/3070/limits: Permission denied
stack@devstackvm:~$ sudo echo -n "Max open files=8192:unlimited"  > 
/proc/3070/limits
-bash: /proc/3070/limits: Permission denied
stack@devstackvm:~$

root@devstackvm:/home/stack# echo -n "Max open files=8192:unlimited" > 
/proc/3070/limits
bash: echo: write error: Invalid argument
root@devstackvm:/home/stack#

Re: [openstack-dev] [Zun][Glare][Glance] Building Docker images

[Mikhail Fedosin]

I believe we can add Glare driver to Zun [1] and allow it to pull container
images from Glare directly. Then, as Kairat mentioned, we should prepare
'container-images' artifact type for Glare [2]. For sure, we can use
'images' (which are actually vm images) to store containers, but it's ugly,
because virtual machine is not exactly the same as container. If it's
required let me know, and I'll propose related patches to Zun and Glare.

Best,
Mike

[1] https://github.com/openstack/zun/tree/master/zun/image
[2] https://github.com/openstack/glare/tree/master/glare/objects

On Fri, Dec 16, 2016 at 3:36 PM, Kairat Kushaev 
wrote:

> Hello Denis,
> unfortunately, I don't have deep knowledge of Zun so i can speak from
> Glare side only.
> So Glare can serve as some kind of artifact storage for container files
> but we need to define artifact structure first.
> Please note that artifact is immutable after activation so once you need
> to change some files you need to create new artifact.
> Also there is possibility to store container images in Glare also but this
> requires an integration from Zun to consume blobs from Glare.
> So it requires some improvements outside Glare.
>
> Best regards,
> Kairat Kushaev
>
> On Tue, Dec 13, 2016 at 8:16 PM, Hongbin Lu  wrote:
>
>> Denis,
>>
>>
>>
>> Per my understanding, container image building is out of the scope of the
>> Zun project. Zun assumes an image has been built and uploaded to a image
>> repository (i.e. Glance, docker registry), then the image will be pulled
>> down from the repo to host. However, feel free to let us know if anything
>> else we can do.
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>>
>>
>> *From:* Denis Makogon [mailto:lildee1...@gmail.com]
>> *Sent:* December-12-16 4:51 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [Zun][Glare][Glance] Building Docker images
>>
>>
>>
>> Hello to All.
>>
>>
>>
>> I’d like to get initial feedback on the idea of building Docker images
>> through Zun involving Glare as artifactory for all static components
>> required for image.
>>
>>   So, the idea here is in being capable to build a Docker image
>> through Zun API with storing all static data required for docker image
>> building in Glare or Swift. In order to keep the same UX from using Docker
>> it would be better to use Dockerfile as description format for image
>> building.
>>
>>   In image creation process Glare could take role of
>> artifactory, where users stores, let’s say source code of his applications
>> that would run in containers, static data, etc. And those artifacts will be
>> pulled during image creation and used to inject into image (similar process
>> of context creation during Docker image building using native CLI). Please
>> note that artifacts are completely optional for images, but would give a
>> capability to keep artifacts in dedicated storage instead of transferring
>> all data through Zun API (the opposite concept to Docker build context).
>>
>>
>>
>>   Once image is created, it can be stored in underlying Docker
>> in Zun or can be published into Glance or Swift for further consumption (if
>> user will need to save image, he’ll use Glance image download API). I’ve
>> mentioned Swift VS Glance because Swift has concept of temp URLs that can
>> be accessed without being authorized. Such feature allows to use Swift as
>> storage from where possible to export image to Docker using Import API [1].
>>
>>
>>
>>
>>
>> Any feedback on the idea is appreciated.
>>
>>
>>
>> Kind regards,
>>
>> Denis Makogon
>>
>>
>>
>> [1] https://docs.docker.com/engine/reference/commandline/import/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] Where will Neutron go in future?

[zhi]

Hi, Srider.

Thanks for your reply. I still have a question about SG and FWaaS. VM's
east-west traffic belongs to FWaaS or SG? What about VM's north-south
traffic?

I think that VM's east-west traffic belongs to SG and the north-south
traffic belongs to FWaaS, isn't it? :)


Thanks
Zhi Chang

2016-12-20 1:45 GMT+08:00 Sridar Kandaswamy (skandasw) :

> Hi Zhi:
>
> FWaaS has been seen more as an edge (on L3 ports) use case as opposed to
> SG which is on a VM port. Also, as u can see there are differences in the
> attributes on the Rule specification at the most basic level. At this
> point, we are working thru the implementation of FWaaS on L2 ports so that
> makes ur question more relevant. At least one school of thought that we
> have been working with is that the FWaaS API can be more open and continue
> to evolve to support for instance L4-L7 use cases amongst others, but the
> SG API will continue to stay a simpler model (some have also pointed the
> need for SG to be aligned with AWS).
>
> This is still in evolution and we would welcome participation, if u can -
> pls do drop in to our weekly team meeting [1] and we can discuss further.
>
> Thanks
>
> Sridar
> [1] http://eavesdrop.openstack.org/#Firewall_as_a_
> Service_(FWaaS)_Team_Meeting
>
>
> From: zhi 
> Reply-To: OpenStack List 
> Date: Sunday, December 18, 2016 at 7:36 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?
>
> Hi, Nate, thanks for your reply.
>
> May I ask a little stupid question? What's the difference between fwaas
> and security group? In my opinion, fwaas and security group are both using
> linux iptables now. So, what's the differences between them?
>
> Thanks
> Zhi Chang
>
> __
> 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] [Cinder] Does cinder use novaclient?

[lij...@gohighsec.com]

Hi Cinder community,

Does cinder use novaclient? What's the use of cinder/compute/nova.py?

I find that there seems to have some problems when construct novaclient in the 
file  cinder/compute/nova.py,
 but I think the file is not being used. 

Would you explain the use of this file or how does cinder communicate with nova?

Looking forward to your comments. Thanks.


BR,

Jane




__
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][nova][oslo][osprofiler] Next step of OSprofiler

[vin...@vn.fujitsu.com]

Hi Rui Wang,

We also recognize the benefit of OSProfiler and are on the way to improve it.

> 1. The integration with neutronclient,
> nova and novaclient has not been done yet.

Yes, the works in Nova are in reviewing but Nova team seems very busy
in this cycle and they want to have more tests before accepting it [1][2].
Progress on support in Neutron client is slow and temporary paused [3].

> 2. The blueprint "osprofiler-overhead-control" is not in progress.
> The spec[1] was workflow -1.
> Does it mean this feature would not been done in Ocata ?

Yes (too), this spec is in progress to finish itself, not the code.
So, I mark it with Workflow -1 to have time to finish it.
Besides, this cycle (Ocata) is very short, I don't think that we have chance
to finish the code for this in O-cycle.

> 3. We need a server/tool to collect and analysis the trace data.
> Should this implemented by OSprofiler,
> or this could be implemented by another project of OSprofiler?

OSProfiler is just a small library that support tracing and profiling requests.
I think OSProfiler should do its job (tracing) only.
Collecting and analyzing should be in other project(s) such as Monasca.
However, this is the next step after completely integrating OSProfiler
in OpenStack.

Thank you for your attention. Hope that we can collaborate in this work! :D

[1] https://review.openstack.org/#/c/254703/
[2] https://review.openstack.org/#/c/254699/
[3] https://review.openstack.org/#/c/281508/


Best regards,

Vinh Nguyen Trong (IRC, Gerrit: tovin07)
PODC – Fujitsu Vietnam 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

Re: [openstack-dev] Which service is using port 8778?

[Qiming Teng]

On Tue, Dec 20, 2016 at 06:16:59AM +, Ghanshyam Mann wrote:
> Yes, it seems placement API using it [1]
> 
> > 1. Recent changes to tempest is breaking our plugin. This is being
> >fixed.
> Tempest patch should fix issue but port issue blocking that[2]
> 
> For port think, I think we can change the placement API port to something 
> else. I will propose and we can get unused port there.
> But OpenStack port used by services are maintained here[3], may be it will be 
> good for each project to add their port in this list.
> 
> .. [1] - 
> https://github.com/openstack-dev/devstack/blob/master/lib/placement#L50 
> ..[2] https://review.openstack.org/#/c/412658/ 
> ..[3] 
> http://docs.openstack.org/newton/config-reference/firewalls-default-ports.html
>  
> 
> -gmann

Thanks for the pointer, Ghanshyam. We should have input port 8778 there
so people will know it is used.

 - Qiming
> 
> > -Original Message-
> > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
> > Sent: 20 December 2016 14:45
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] Which service is using port 8778?
> > 
> > Hi, all,
> > 
> > Starting yesterday, Senlin's gate jobs kept failing due to two reasons:
> > 
> > 1. Recent changes to tempest is breaking our plugin. This is being
> >fixed.
> > 
> > 2. Senlin API cannot bind it to port 8778 now.
> > 
> > So, we are wondering which service else is using port 8778?
> > 
> > Thanks in advance for any hints.
> > 
> > Regards,
> >   Qiming
> > 
> > 
> > __
> > 
> > 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] Which service is using port 8778?

[Ghanshyam Mann]

Changing placement API port to 8780 [1], hope this is not being used by any 
services.

But I am not sure how to check all used port currently as wiki does not seems 
to have all.

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

-gmann


> -Original Message-
> From: Ghanshyam Mann [mailto:ghanshyam.m...@nectechnologies.in]
> Sent: 20 December 2016 15:17
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] Which service is using port 8778?
> 
> Yes, it seems placement API using it [1]
> 
> > 1. Recent changes to tempest is breaking our plugin. This is being
> >fixed.
> Tempest patch should fix issue but port issue blocking that[2]
> 
> For port think, I think we can change the placement API port to something
> else. I will propose and we can get unused port there.
> But OpenStack port used by services are maintained here[3], may be it will
> be good for each project to add their port in this list.
> 
> .. [1] - https://github.com/openstack-
> dev/devstack/blob/master/lib/placement#L50
> ..[2] https://review.openstack.org/#/c/412658/
> ..[3] http://docs.openstack.org/newton/config-reference/firewalls-default-
> ports.html
> 
> -gmann
> 
> 
> > -Original Message-
> > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
> > Sent: 20 December 2016 14:45
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] Which service is using port 8778?
> >
> > Hi, all,
> >
> > Starting yesterday, Senlin's gate jobs kept failing due to two reasons:
> >
> > 1. Recent changes to tempest is breaking our plugin. This is being
> >fixed.
> >
> > 2. Senlin API cannot bind it to port 8778 now.
> >
> > So, we are wondering which service else is using port 8778?
> >
> > Thanks in advance for any hints.
> >
> > Regards,
> >   Qiming
> >
> >
> >
> __
> > 
> > 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] Which service is using port 8778?

[Ghanshyam Mann]

Yes, it seems placement API using it [1]

> 1. Recent changes to tempest is breaking our plugin. This is being
>fixed.
Tempest patch should fix issue but port issue blocking that[2]

For port think, I think we can change the placement API port to something else. 
I will propose and we can get unused port there.
But OpenStack port used by services are maintained here[3], may be it will be 
good for each project to add their port in this list.

.. [1] - 
https://github.com/openstack-dev/devstack/blob/master/lib/placement#L50 
..[2] https://review.openstack.org/#/c/412658/ 
..[3] 
http://docs.openstack.org/newton/config-reference/firewalls-default-ports.html 

-gmann


> -Original Message-
> From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
> Sent: 20 December 2016 14:45
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] Which service is using port 8778?
> 
> Hi, all,
> 
> Starting yesterday, Senlin's gate jobs kept failing due to two reasons:
> 
> 1. Recent changes to tempest is breaking our plugin. This is being
>fixed.
> 
> 2. Senlin API cannot bind it to port 8778 now.
> 
> So, we are wondering which service else is using port 8778?
> 
> Thanks in advance for any hints.
> 
> Regards,
>   Qiming
> 
> 
> __
> 
> 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] Which service is using port 8778?

[Qiming Teng]

Hi, all,

Starting yesterday, Senlin's gate jobs kept failing due to two reasons:

1. Recent changes to tempest is breaking our plugin. This is being
   fixed.

2. Senlin API cannot bind it to port 8778 now.

So, we are wondering which service else is using port 8778?

Thanks in advance for any hints.

Regards,
  Qiming


__
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] Help: How to make Nova official support AArch64?

[Kevin Zhao]

Hello Nova,
  Greetings from ARM and Linaro :D
  This is Kevin Zhao from ARM. Nowadays Linaro and other contributors
have submitted some patches to Nova community , fixing bugs for Nova
running on AArch64. Now we can successfully running a OpenStack cluster on
AArch64 and pass much of the tempest test. The virtuallization hypervisor
is based on Libvirt+KVM.

  Actually in Barcelona Keynote(interoperability Challenge
,
at 10:30') one of the OpenStack interoperability cloud is from Linaro, all
based on AArch64 machines.
   I see there is a Nova support matrix
. So my
question is :
*   what do we need to do, so that Nova can official support AArch64
architecture? for example add AArch64 to this support matrix?*

   Sincerely thanks for your help. Any of your response will be really
appreciated.

Best Regards,
Kevin Zhao
__
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] OpenStack Dev Digest 10- 16

[Kendall Nelson]

Use this link for HTML Version:
http://www.openstack.org/blog/2016/12/openstack-developer-mailing-list-digest-december-10-16/

On Mon, Dec 19, 2016 at 10:54 PM Kendall Nelson 
wrote:

> HTML Version: http://wp.me/p1eUil-255
>
> Updates
>
>-
>
>Release schedule clarification after Ocata [5]
>-
>
>Nova placement/resource providers [6][12]
>-
>
>Stuart McLaren stepping down from glance core [8]
>
>
> Allowing Teams Based on Vendor-specific Drivers (cont) [1]
>
>-
>
>Narrowed down options at last TC meeting to following [2]:
>-
>
>   Soft black (option 2): default option, had no negative feedback,
>   represents the current status quo
>   -
>
>   Soft white (option 4): had some positive feedback, folks liked it's
>   simple solution
>   -
>
>   Grey (option 5): had the most positive feedback, but also the least
>   amount of detail
>   -
>
>Other options’ patches are being abandoned
>-
>
>Leaning towards an amended version of the ‘Grey’ proposal [10]
>
>
> Community Goals for Pike (cont.) [3]
>
>-
>
>Need feedback [4]
>-
>
>Keep using openstack/governance for documenting goals
>-
>
>   Make sure to include guides
>   -
>
>   Consider prioritization as it may not be possible to complete all
>   the goals in the release
>   -
>
>   Think about splitting larger goals to things that can be
>   accomplished in a single release
>   -
>
>Involving users/operators through the Product WG and start face to
>face discussions on the Forums
>
>
> Python changes in OpenStack CI [7]
>
>-
>
>Python3.4 on a Trusty VM for older branches: stable/liberty and
>stable/mitaka
>-
>
>Python3.5 on a Xenial VM for newer branches: stable/newton and master
>-
>
>   Python3.4 testing is disabled for these
>   -
>
>   ACTION:
>   -
>
>  Projects should enable voting for Python3.5 jobs or add them if
>  they don’t exist yet
>  -
>
>  Projects should remove Python3.4 jobs if they run only on master
>
>
> Golang Technical Requirements [15]
>
>-
>
>Activities to adopt Go into OpenStack are ongoing
>-
>
>Areas need more discussion
>-
>
>   Common Libraries
>   -
>
>   Dependency Management
>   -
>
>  Candidates are govendor, glide and godep
>  -
>
>   Release Deliverables
>   -
>
>  Tags and/or build artifacts?
>  -
>
>  AUTHORS and ChangeLog files can be autogenerated
>  -
>
>Oaktree has golang bindings and contains generated files
>
>
> Upgrade readiness check in Nova [11]
>
>-
>
>New, separate service
>-
>
>Checks the system state and indicates how much it is ready to start
>the Ocata upgrade (success, warning, error)
>
>
> Self-service branch management [13]
>
>-
>
>Through openstack/releases repo
>-
>
>Specify your needs in a patch [14] and the rest is automated after
>it’s merged
>-
>
>New stable branch creation is best to happen close to the end of the
>cycle, when the bug fixing and stabilization activities are slowing down
>
>
> Architectural discussion about nova-compute interactions [16]
>
>-
>
>How do Nova, Neutron and Cinder interact with nova-compute
>-
>
>Should nova-compute become a standalone shared service? [9]
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-November/108074.html
>
> [2]
> http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt
>
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2016-November/108167.html
>
> [4] https://etherpad.openstack.org/p/community-goals
>
> [5]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108689.html
>
> [6]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108707.html
>
> [7]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108821.html
>
> [8]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108840.html
>
> [9] https://review.openstack.org/#/c/411527/
>
> [10] https://review.openstack.org/403829
>
> [11]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109060.html
>
> [12]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109085.html
>
> [13]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108923.html
>
> [14] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63
>
> [15]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108875.html
>
> [16]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109044.html
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Samuel Cassiba]

> 
> On Dec 19, 2016, at 14:31, Tony Breeds  wrote:
> 
> On Mon, Dec 19, 2016 at 09:18:20AM -0800, Samuel Cassiba wrote:
> 
>> The Chef OpenStack cookbooks team is way late to the party. The cookbooks
>> (openstack/cookbook-openstack-*, openstack/openstack-chef-repo ) should have
>> had their liberty branches EOL’d. I have checked and no open reviews exist
>> against liberty.
> 
> Thanks.
> 
> While I have your attention what about your older branches.  Is there any
> mertit keeping the kilo branches in openstack/cookbook-openstack-* or the
> stable/{grizzly,havana,icehouse,juno} branches in 
> openstack/openstack-chef-repo
> 

No, no merit in keeping older branches around. They can be rightfully EOL’d as 
well.

Many thanks!

> Yours Tony.
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] OpenStack Dev Digest 10- 16

[Kendall Nelson]

HTML Version: http://wp.me/p1eUil-255

Updates

   -

   Release schedule clarification after Ocata [5]
   -

   Nova placement/resource providers [6][12]
   -

   Stuart McLaren stepping down from glance core [8]


Allowing Teams Based on Vendor-specific Drivers (cont) [1]

   -

   Narrowed down options at last TC meeting to following [2]:
   -

  Soft black (option 2): default option, had no negative feedback,
  represents the current status quo
  -

  Soft white (option 4): had some positive feedback, folks liked it's
  simple solution
  -

  Grey (option 5): had the most positive feedback, but also the least
  amount of detail
  -

   Other options’ patches are being abandoned
   -

   Leaning towards an amended version of the ‘Grey’ proposal [10]


Community Goals for Pike (cont.) [3]

   -

   Need feedback [4]
   -

   Keep using openstack/governance for documenting goals
   -

  Make sure to include guides
  -

  Consider prioritization as it may not be possible to complete all the
  goals in the release
  -

  Think about splitting larger goals to things that can be accomplished
  in a single release
  -

   Involving users/operators through the Product WG and start face to face
   discussions on the Forums


Python changes in OpenStack CI [7]

   -

   Python3.4 on a Trusty VM for older branches: stable/liberty and
   stable/mitaka
   -

   Python3.5 on a Xenial VM for newer branches: stable/newton and master
   -

  Python3.4 testing is disabled for these
  -

  ACTION:
  -

 Projects should enable voting for Python3.5 jobs or add them if
 they don’t exist yet
 -

 Projects should remove Python3.4 jobs if they run only on master


Golang Technical Requirements [15]

   -

   Activities to adopt Go into OpenStack are ongoing
   -

   Areas need more discussion
   -

  Common Libraries
  -

  Dependency Management
  -

 Candidates are govendor, glide and godep
 -

  Release Deliverables
  -

 Tags and/or build artifacts?
 -

 AUTHORS and ChangeLog files can be autogenerated
 -

   Oaktree has golang bindings and contains generated files


Upgrade readiness check in Nova [11]

   -

   New, separate service
   -

   Checks the system state and indicates how much it is ready to start the
   Ocata upgrade (success, warning, error)


Self-service branch management [13]

   -

   Through openstack/releases repo
   -

   Specify your needs in a patch [14] and the rest is automated after it’s
   merged
   -

   New stable branch creation is best to happen close to the end of the
   cycle, when the bug fixing and stabilization activities are slowing down


Architectural discussion about nova-compute interactions [16]

   -

   How do Nova, Neutron and Cinder interact with nova-compute
   -

   Should nova-compute become a standalone shared service? [9]

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/108074.html

[2]
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt

[3]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/108167.html

[4] https://etherpad.openstack.org/p/community-goals

[5]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108689.html

[6]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108707.html

[7]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108821.html

[8]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108840.html

[9] https://review.openstack.org/#/c/411527/

[10] https://review.openstack.org/403829

[11]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109060.html

[12]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109085.html

[13]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108923.html

[14] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

[15]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108875.html

[16]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109044.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][zun] Effective URL for resource actions

[Alex Xu]

2016-12-20 11:34 GMT+08:00 Qiming Teng :

> On Tue, Dec 20, 2016 at 10:14:49AM +0800, Alex Xu wrote:
> > Yea, looks like no consensus at here. Look at the discussion Chris
> pointed
> > to, the "/containers//action" sounds a good API for tasks.
>
> Did you mean "/containers//actions" ?
>

yea, you are right. sorry about that.


>
> > But we also see the disadvantage for it. When we want to use URL to
> > identifying an action, we found all the actions into a single API. We
> faced
> > this problem multiple times:
>
> Then we should stop identifying actions based on URL. :)
> The following URL for representing a 'pause' action is really ugly:
>
>/containers//pause
>
> First of all, 'pause' is a verb. I cannot persuade myself that doing a
> POST to a verb is a ReST call. And I cannot do a 'GET', 'DELETE' not
> due to I'm not an admin ... rather, it is because I cannot explain what
> it means by 'deleting a pause'.
>
> > 1. In the beginning of thinking about capability discovery, an idea is
> > about returning a list of URLs if the user have the ability to execute.
> But
> > found that all the actions are into single URL
> > 2. Before there is an idea about if the policy rule name is the URL, then
> > the user can easy to know the mapping between policy rule and API. The
> same
> > problem, all the actions into single URL
>
> Neither capability discovery or policy enforcement should be based
> solely on URL, IMO. Capabilities should have its own resource
> representation if possible. As for policy, it still seems an over
> simplification of authorization. There many scenarios where users
> want a finer granularity of access control. Even if we want to stick to
> the policy.json approach today, we can somehow improve the checking, for
> example:
>
>"containers:action:reboot": "role:owner"
>
> Similarly, auditing and logging can be done in the same way.
>
> > 3. Before think about using OpenAPI(swagger) to generate api doc, but the
> > OpenAPI spec didn't support multiple "POST containers//action", that
> > means we need to put all the actions into single entry. That makes the
> > generated doc unreadable.
>
> That is history now. We are moving to the api-ref way of documenting
> APIs. Don't tell me there are plans to migrate it back, :D
>

Yea, just as I said, none of above problems block on this issue. It is also
hard to say this is key issue lead to another solution. I just provide some
info if people really care about this issue we met before.


>
> - Qiming
> > But yes, that doesn't means we block on this problem. Finally we go to
> > another direction. So just input something we met before for your
> > consideration.
> >
> > Thanks
> > Alex
> >
> > 2016-12-19 19:57 GMT+08:00 Chris Dent :
> >
>
>
> __
> 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] [api][zun] Effective URL for resource actions

[Qiming Teng]

On Tue, Dec 20, 2016 at 10:14:49AM +0800, Alex Xu wrote:
> Yea, looks like no consensus at here. Look at the discussion Chris pointed
> to, the "/containers//action" sounds a good API for tasks.

Did you mean "/containers//actions" ?
 
> But we also see the disadvantage for it. When we want to use URL to
> identifying an action, we found all the actions into a single API. We faced
> this problem multiple times:

Then we should stop identifying actions based on URL. :)
The following URL for representing a 'pause' action is really ugly:

   /containers//pause

First of all, 'pause' is a verb. I cannot persuade myself that doing a
POST to a verb is a ReST call. And I cannot do a 'GET', 'DELETE' not
due to I'm not an admin ... rather, it is because I cannot explain what
it means by 'deleting a pause'.  
 
> 1. In the beginning of thinking about capability discovery, an idea is
> about returning a list of URLs if the user have the ability to execute. But
> found that all the actions are into single URL
> 2. Before there is an idea about if the policy rule name is the URL, then
> the user can easy to know the mapping between policy rule and API. The same
> problem, all the actions into single URL

Neither capability discovery or policy enforcement should be based
solely on URL, IMO. Capabilities should have its own resource
representation if possible. As for policy, it still seems an over
simplification of authorization. There many scenarios where users
want a finer granularity of access control. Even if we want to stick to
the policy.json approach today, we can somehow improve the checking, for
example:

   "containers:action:reboot": "role:owner"

Similarly, auditing and logging can be done in the same way.

> 3. Before think about using OpenAPI(swagger) to generate api doc, but the
> OpenAPI spec didn't support multiple "POST containers//action", that
> means we need to put all the actions into single entry. That makes the
> generated doc unreadable.

That is history now. We are moving to the api-ref way of documenting
APIs. Don't tell me there are plans to migrate it back, :D

- Qiming 
> But yes, that doesn't means we block on this problem. Finally we go to
> another direction. So just input something we met before for your
> consideration.
> 
> Thanks
> Alex
> 
> 2016-12-19 19:57 GMT+08:00 Chris Dent :
> 


__
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] [api][zun] Effective URL for resource actions

[Qiming Teng]

On Mon, Dec 19, 2016 at 11:57:26AM +, Chris Dent wrote:
> On Fri, 16 Dec 2016, Hongbin Lu wrote:
> 
> >I am from the Zun team and I wanted to consult with you about the API
> >design. Our team was discussing what is the best API design for
> >exposing different container operations [1]. There are two proposed
> >options:
> >
> >1. Expose multiple URLs for individual container operation. For example:
> [...]
> >
> >2. Expose a single URL for all operations. For example:
> [...]
> 
> How to deal with "actions" is something we've struggled to reach
> consensus about in the API-WG. There have been a few proposals over
> the years (including some like both of the options you've listed),
> but none have been loved by everyone. There's a great deal of
> discussion that has happened around this issue and could still
> happen. Below is my personal perspective.
> 
> There's a third option you may wish to consider that is perhaps a
> bit more resource oriented: use PUT or PATCH to update the state of
> the containers representation. Note that the examples should be take
> as describing an option, not indicating the right choices for the
> terms involved.
> 
> a) GET /containers/
> 
>This gets you a representation including some indicator of state.
> 
>{...
> "uptime": 542819,
> "state": "running",
> ...
>}
> 
> b) Change that state value to the target and PUT the representation
>back.
> 
>PUT /containers/
> 
>{...
> "state": "rebooting"
> ...
>}
> 
>Or, if for some reason you need to save some bytes, you could
>PATCH the state attribute.
> 
> c) If the change takes time and the request is asynchronous, the
>response could be 202 and doing a GET will representing the
>change in progress:

My gut feeling is that most "actions" we are initiating fall into the
asynchronous group. For example, we are not modeling a GET request on
/containers/ as an action.
 
>GET /containers/
> 
>{...
> "state": "rebooting",
> ...
>}
> 
>[time passes..]
> 
>GET /containers/
> 
>{...
> "uptime": 30,
> "state": "running",
> ...
>}
> 
> Like everything this mode has advantages and disadvantages. One
> advantage is that we avoid adding URLs. One disadvantage (for some)
> is that passing around the full representation is complex and/or
> confusing.

Another disadvantage is about access control (aka. policy). We will have
to check who is authorized to change which field to what value. Going
further down this direction we may have, for example:

   PUT/PATCH /containers//state

But we still can see a lot limitations in this approach.
 
> As discussed on the abandoned review[1] referenced from the etherpad
> it is important to distinguish between actions which are atomic (at
> least from the perspective of the user-agent) and don't need
> observation and sequences of tasks which may need observation and
> may need to be interrupted and continued.
> 
> The former are changes in resource state, and thus could be
> represented as such (as I've described above).
> 
> In the latter, the task is (or tasks are ) the actual resource and
> should be the thing that is addressed by URL. That resource should
> make reference to the other entities which are being manipulated by
> the task.

Having a single URI /containers//actions to model this seems a
better option in my opinion. These tasks are the things we are
authorizing, validating, performing, verifying, auditing... A
single task/action may change more than one states. Abstracting these
operations into state changes doesn't look the right to do.

- Qiming
> From a user's standpoint stop, start, pause, unpause, reboot etc are
> isolated actions that describe a state of the container resource.
> [1] https://review.openstack.org/#/c/234994/
> 
> -- 
> Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
> freenode: cdent tw: @anticdent


__
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] Any way to disable zuul status page auto-refresh?

[Joshua Hesketh]

You could try saving the status page and modifying the refresh time, or
similarly you could checkout zuul and run the webapp locally[0]. You'd have
to point it at [1] and modify the refresh times here [2]. (The status page
in the zuul tree is different to the one on status.o.o).

Cheers,
Josh

[0] http://git.openstack.org/cgit/openstack-infra/zuul/tree/etc/status
[1] http://zuul.openstack.org/status.json
[2]
http://git.openstack.org/cgit/openstack-infra/zuul/tree/etc/status/public_html/jquery.zuul.js#n627
& 631

On Tue, Dec 20, 2016 at 5:22 AM, Ben Nemec  wrote:

> The subject pretty much covers it.  When there are a lot of jobs on the
> zuul status page, it kind of brings my browser to its knees, which makes it
> hard to navigate the page.  I know you can filter it, but sometimes I want
> to see all of the jobs in a queue so that isn't always an option. If there
> were a way to let me refresh it on demand (or maybe auto-refresh less
> often?) that would be awesome.
>
> -Ben
>
> __
> 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] multi-attach-volume for rbd

[Matt Riedemann]

On 12/19/2016 2:24 AM, Avishay Traeger wrote:

Multi-attach also happens during VM migration: (attach volume to
destination host, move VM to destination host, detach volume from source
host).  It's not clear if rbd's limitation affects this as well - it's
not clear from the bug report or the patch.

On Thu, Dec 15, 2016 at 1:30 AM, Matt Riedemann
> wrote:

On 12/14/2016 3:53 PM, Shane Peters wrote:

Hello all,

Per https://review.openstack.org/#/c/283695/
 multi-attach was disabled
for rbd volumes.

Does anyone know what features are missing or aren't compatible
in rbd
for it to support multi-attach?

Thanks
Shane



__
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 



Nova doesn't support multiattach volumes for any Cinder backend.
That's being worked by the Nova and Cinder teams but won't be
something that's implemented on the Nova side in the Ocata release,
and will be a stretch probably for Pike. There are weekly meetings
about this though, see:

http://eavesdrop.openstack.org/#Cinder,_Nova


--

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





--
*Avishay Traeger, PhD*
/System Architect/

Mobile: +972 54 447 1475
E-mail: avis...@stratoscale.com 



Web  | Blog
 | Twitter
 | Google+

 | Linkedin




__
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



The live migration CI job runs Rbd-backed block live migration but we 
haven't yet enabled that for volume-backed live migration, but I thought 
that was possible, and was a big reason why a lot of deployments choose 
Ceph for storage, the ease of use for live migration. Timofey Durakov 
has been working on enabling the volume-backed live migration + Ceph 
storage in our CI jobs so he'd know more.


--

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] Upgrade skip release

[Matt Riedemann]

On 12/19/2016 4:26 PM, Chris Friesen wrote:

On 12/19/2016 03:17 PM, Ajay Kalambur (akalambu) wrote:

Hi Chris
Thanks for the response. What were the specific problem areas you saw
when upgrading from Kilo to Mitaka which were introduced by skipping
Liberty?


There were issues with RPC incompatibility, object versioning, DB
upgrades, etc.

Liberty had compatibility code for this stuff, but then it got ripped
out early in Mitaka since it was assumed to be no longer needed.

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



Right, it's not only about database schema migrations anymore, which in 
the before times you could generally just roll those forward and skip a 
release.


Nova has been doing online data migrations since Kilo, and assumptions 
are made that you're doing lock-step N to N+1 upgrades and running the 
schema and online data migrations, and rolling services forward in that 
fashion so that we can drop compatibility code after a full release of 
that compat code being in place.


We only test N to N+1 in the CI system (the grenade jobs) so while 
things might work in practice by skipping a release, it's not tested 
that way upstream at all so any chance of it working is accidental and 
shouldn't be relied upon or really expected to be supported that way 
upstream.


--

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] [api][zun] Effective URL for resource actions

[Alex Xu]

Yea, looks like no consensus at here. Look at the discussion Chris pointed
to, the "/containers//action" sounds a good API for tasks.

But we also see the disadvantage for it. When we want to use URL to
identifying an action, we found all the actions into a single API. We faced
this problem multiple times:

1. In the beginning of thinking about capability discovery, an idea is
about returning a list of URLs if the user have the ability to execute. But
found that all the actions are into single URL
2. Before there is an idea about if the policy rule name is the URL, then
the user can easy to know the mapping between policy rule and API. The same
problem, all the actions into single URL
3. Before think about using OpenAPI(swagger) to generate api doc, but the
OpenAPI spec didn't support multiple "POST containers//action", that
means we need to put all the actions into single entry. That makes the
generated doc unreadable.

But yes, that doesn't means we block on this problem. Finally we go to
another direction. So just input something we met before for your
consideration.

Thanks
Alex

2016-12-19 19:57 GMT+08:00 Chris Dent :

> On Fri, 16 Dec 2016, Hongbin Lu wrote:
>
> I am from the Zun team and I wanted to consult with you about the API
>> design. Our team was discussing what is the best API design for
>> exposing different container operations [1]. There are two proposed
>> options:
>>
>> 1. Expose multiple URLs for individual container operation. For example:
>>
> [...]
>
>>
>> 2. Expose a single URL for all operations. For example:
>>
> [...]
>
> How to deal with "actions" is something we've struggled to reach
> consensus about in the API-WG. There have been a few proposals over
> the years (including some like both of the options you've listed),
> but none have been loved by everyone. There's a great deal of
> discussion that has happened around this issue and could still
> happen. Below is my personal perspective.
>
> There's a third option you may wish to consider that is perhaps a
> bit more resource oriented: use PUT or PATCH to update the state of
> the containers representation. Note that the examples should be take
> as describing an option, not indicating the right choices for the
> terms involved.
>
> a) GET /containers/
>
>This gets you a representation including some indicator of state.
>
>{...
> "uptime": 542819,
> "state": "running",
> ...
>}
>
> b) Change that state value to the target and PUT the representation
>back.
>
>PUT /containers/
>
>{...
> "state": "rebooting"
> ...
>}
>
>Or, if for some reason you need to save some bytes, you could
>PATCH the state attribute.
>
> c) If the change takes time and the request is asynchronous, the
>response could be 202 and doing a GET will representing the
>change in progress:
>
>GET /containers/
>
>{...
> "state": "rebooting",
> ...
>}
>
>[time passes..]
>
>GET /containers/
>
>{...
> "uptime": 30,
> "state": "running",
> ...
>}
>
> Like everything this mode has advantages and disadvantages. One
> advantage is that we avoid adding URLs. One disadvantage (for some)
> is that passing around the full representation is complex and/or
> confusing.
>
> As discussed on the abandoned review[1] referenced from the etherpad
> it is important to distinguish between actions which are atomic (at
> least from the perspective of the user-agent) and don't need
> observation and sequences of tasks which may need observation and
> may need to be interrupted and continued.
>
> The former are changes in resource state, and thus could be
> represented as such (as I've described above).
>
> In the latter, the task is (or tasks are ) the actual resource and
> should be the thing that is addressed by URL. That resource should
> make reference to the other entities which are being manipulated by
> the task.
>
> From a user's standpoint stop, start, pause, unpause, reboot etc are
> isolated actions that describe a state of the container resource.
>
> [1] https://review.openstack.org/#/c/234994/
>
> --
> Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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] [Congress] [infra] tempest job timeout appears shorter than configured

[Jeremy Stanley]

On 2016-12-19 17:33:10 -0800 (-0800), Eric K wrote:
> The congress {pipeline}-congress-dsvm-api-{node}{suffix} check/gate job
> seems to timeout around the 60 minute mark even though the project config
> appears to set it for 70min. Any hints as to why? Are there two different
> measures of time? Thanks so much!
[...]

Technically, yes, two different measures of time. The
devstack-vm-gate-wrap.sh script has some additional buffers built in
so that it can stop the job with enough time remaining to gather
logs and perform any necessary post-processing before the job
scheduler kills the machine it's running on. For details, see the
handling of the BUILD_TIMEOUT, DEVSTACK_GATE_TIMEOUT_BUFFER and
DEVSTACK_GATE_TIMEOUT variables starting at
http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n382
 >.
-- 
Jeremy Stanley

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

[openstack-dev] [Congress] [infra] tempest job timeout appears shorter than configured

[Eric K]

The congress {pipeline}-congress-dsvm-api-{node}{suffix} check/gate job
seems to timeout around the 60 minute mark even though the project config
appears to set it for 70min. Any hints as to why? Are there two different
measures of time? Thanks so much!
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/c
ongress.yaml#L7

Here¹s an example: 
http://logs.openstack.org/24/410524/2/check/gate-congress-dsvm-api-ubuntu-xe
nial/45f6991/console.html


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

Re: [openstack-dev] [Release-job-failures] Tag of openstack/openstack-ansible-security failed

[Tony Breeds]

On Tue, Dec 20, 2016 at 12:29:59AM +, jenk...@openstack.org wrote:
> Build failed.
> 
> - openstack-ansible-security-releasenotes 
> http://logs.openstack.org/6c/6cf9e9174441a071b3071e468235fc18a4c08478/tag/openstack-ansible-security-releasenotes/f814d7f/
>  : FAILURE in 51s

This should be fixed with:
https://review.openstack.org/#/q/I008f7388762d326bec7cb60526f03e68823330c4,n,z

Yours Tony.


signature.asc
Description: PGP signature
__
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] [classifier] No Common Classifier / Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Tomorrow, Tuesday 20th December 2016, there will be no Common Classification 
Framework meeting, as there are no major topics to discuss.
Meanwhile we are working on an initial PoC for the framework. As a reminder, 
please take a look at the respective spec: 
https://review.openstack.org/#/c/333993.

Best regards,
Igor.

__
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-operators] live migration fails and libvirtd(?) lockup after trusty > xenial/mitaka > newton upgrade

[Vladimir Prokofev]

Hello Ops.

I want to pick your brains on a live migration issue, cause I'm kinda stuck
atm.

I'm running a small HA Ubuntu Openstack cloud - 3 controllers(VMs on
Ubuntu/KVM) with ha-proxy LB, corosync/pacemaker manages VIP, Galera DB, 3
compute nodes(using KVM hypervisor), 3 network nodes(VMs on Ubuntu/KVM),
CEPH cluster(4 OSD nodes, 3 MON nodes(VMs on Ubuntu/KVM)).
Nova, cinder, and glance use CEPH as backend. Neutron uses linux-bridge.

We were running Ubuntu Trusty 14.04/Mitaka, and decided to upgrade to
Ubuntu Xenial 16.04/Newton. The issue appeared sometime after upgrade of
all Mitaka packages to the latest version prior to Xenial upgrade, and
stayed even after upgrade to Xenial/Newton. It's hard to tell for sure as
we didn't use LM for a while. It worked fine under Trusty/Mitaka, and broke
under Xenial/latest-Mitaka.


With a chance of 20-30% live migration will fail. The instance will pause
on a source node, but will not be resumed on target node. Target node will
destroy instance assuming LM failed, and on source node instance will stay
paused. On source node no new messages appear in nova-compute.log, and
commands such as "virsh list" won't provide any output, or even exit for
that matter. nova-compute can be restarted, but after normal startup
messages it once again doesn't provide any new log entries. Nova considers
compute node as up and running.
In dashboard you can see that instance is now residing at a new host, and
is in shutoff state.

If I restart libvirtd on target or source node then whole system
"unfreezes". Source host unpauses instance, and it is live again. But it
now resides on a source node, while database thinks it's on a target node
and is shutdown. Warning messages will appear on source host:

2016-12-20 01:13:37.095 20025 WARNING nova.compute.manager
[req-b3879539-989f-4075-9ef0-d23ef8868102 - - - - -] While synchronizing
instance power states, found 3 instances in the database and 4 instances on
the hypervisor.

Currenly I'm stopping/destroying/undefining instance on a source node, and
launching it via standart Openstack means, but this leads to an instance
reboot.


Last messages in nova-compute.log on source node after LM start:
2016-12-20 00:09:35.961 16834 INFO nova.virt.libvirt.migration
[req-51801b5e-b77a-4d76-ad87-176326ac910e 84498aa7e26443c4908d973f3e86d530
ecee1197f46e453dba25669554226ce5 - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] Increasing downtime to 1251 ms after
0 sec elapsed time
2016-12-20 00:09:36.127 16834 INFO nova.virt.libvirt.driver
[req-51801b5e-b77a-4d76-ad87-176326ac910e 84498aa7e26443c4908d973f3e86d530
ecee1197f46e453dba25669554226ce5 - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] Migration running for 0 secs, memory
100% remaining; (bytes processed=0, remaining=0, total=0)
2016-12-20 00:09:36.894 16834 INFO nova.compute.manager
[req-3a2a828f-8b76-4a65-b49b-ea8d232a3de5 - - - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] VM Paused (Lifecycle Event)
2016-12-20 00:09:37.046 16834 INFO nova.compute.manager
[req-3a2a828f-8b76-4a65-b49b-ea8d232a3de5 - - - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] During sync_power_state the instance
has a pending task (migrating). Skip.
2016-12-20 00:09:37.300 16834 INFO nova.virt.libvirt.driver
[req-51801b5e-b77a-4d76-ad87-176326ac910e 84498aa7e26443c4908d973f3e86d530
ecee1197f46e453dba25669554226ce5 - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] Migration operation has completed
2016-12-20 00:09:37.301 16834 INFO nova.compute.manager
[req-51801b5e-b77a-4d76-ad87-176326ac910e 84498aa7e26443c4908d973f3e86d530
ecee1197f46e453dba25669554226ce5 - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] _post_live_migration() is started..
2016-12-20 00:09:39.718 16834 INFO os_vif
[req-51801b5e-b77a-4d76-ad87-176326ac910e 84498aa7e26443c4908d973f3e86d530
ecee1197f46e453dba25669554226ce5 - - -] Successfully unplugged vif
VIFBridge(active=False,address=fa:16:3e:e3:c4:c7,bridge_name='brq0b7e75ee-b6',has_traffic_filtering=True,id=2a141727-77a7-4b43-b4cd-21fb415a6a55,network=Network(0b7e75ee-b691-4851-9b29-08c3c62a96e0),plugin='linux_bridge',port_profile=,preserve_on_delete=False,vif_name='tap2a141727-77')
2016-12-20 00:09:39.777 16834 INFO nova.virt.libvirt.driver
[req-51801b5e-b77a-4d76-ad87-176326ac910e 84498aa7e26443c4908d973f3e86d530
ecee1197f46e453dba25669554226ce5 - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] Deleting instance files
/var/lib/nova/instances/cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53_del
2016-12-20 00:09:39.778 16834 INFO nova.virt.libvirt.driver
[req-51801b5e-b77a-4d76-ad87-176326ac910e 84498aa7e26443c4908d973f3e86d530
ecee1197f46e453dba25669554226ce5 - - -] [instance:
cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53] Deletion of
/var/lib/nova/instances/cd8cb1db-dca3-4b0f-a03e-c0befbbd7b53_del complete
2016-12-20 00:10:33.644 16834 INFO nova.compute.resource_tracker
[req-00c4c403-d039-4347-b7ad-3098834a891c - - - - -] Auditing locally
available compute resources for 

Re: [Openstack-operators] Analogs of EC2 dedicated instances & dedicated hosts?

[Blair Bethwaite]

Hi Conrad,

On 20 December 2016 at 09:24, Kimball, Conrad  wrote:
> · Dedicated instances:  an OpenStack tenant can deploy VM instances
> that are guaranteed to not share a compute host with any other tenant (for
> example, as the tenant I want physical segregation of my compute).

You can certainly do this, however you will need to configure either
scheduler and/or host aggregates on a per case/tenant basis for
projects that have this isolation requirement - depending on how
dynamic this is in your environment you may want to automate that. In
any case, the AggregateMultiTenancyIsolation scheduler filter is what
you want I think. Alternatively, if the requirement can be met using
VM images then the IsolatedHostsFilter may also be an option (e.g. the
VM image is kept private and only tenant/s allowed to use that image
on that host will have Glance member access to the image).

> · Dedicated hosts: goes beyond dedicated instances, allowing an
> OpenStack tenant to explicitly place only specific VM instances onto the
> same compute host (for example, as the tenant I want to place VMs foo and
> bar onto the same compute host to share a software license that is licensed
> per host).

As Kris said, ServerGroup filters are probably the way to go for this
one, but the IsolatedHostsFilter may also work if the licensing
requirements can be expressed at the Glance image level.

-- 
Cheers,
~Blairo

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [tripleo] [puppet] A week in CI

[Emilien Macchi]

On Sat, Dec 17, 2016 at 4:30 PM, Emilien Macchi  wrote:
> This week was outstanding for CI and I found useful to share what
> happened in TripleO and Puppet CIs, and where we are now.
> TL;DR:
> - Puppet OpenStack: full green on ocata/newton/mitaka
> - TripleO CI: full green except ovb-nonha (introspection is failing)
>
> Detailed version:
>
> Closed issues:
>
> # nodepool slaves failing to boot
> https://bugs.launchpad.net/tripleo/+bug/1650503
> The issue has been solved in nodepool but a bug in the centos7 image
> with dracut was causing all nodes to fail at boot.
> Kudos to infra for their responsiveness as usual.
>
> # postci timeouts on ovb-ha and ovb-updates
> https://bugs.launchpad.net/tripleo/+bug/1649742
> We enabled SSL on the undercloud to resolve this problem:
> https://review.openstack.org/#/c/411514
> Thanks Ben for helping on this one!
>
> # Undercloud running out of disk space in CI
> https://bugs.launchpad.net/tripleo/+bug/1649615
> Kudos to Ben, Sagi, and Derek for your precious time, hopefully we
> won't run into this problem again thanks to the improvements we
> brought in tripleo-ci.
>
> # rh1 compute nodes not spawning vms correctly
> https://bugs.launchpad.net/tripleo/+bug/1649252
> Again, Sagi, Derek and Ben spent time on the infra to cleanup things
> and we could spawn VMs again.
>
> # CentOS 7.3 / qemu-kvm 2.6
> https://www.redhat.com/archives/rdo-list/2016-December/msg00028.html
> Fixed in TripleO and Puppet OpenStack, thanks to David and Alfredo (+
> reviewers).
> Alfredo, your help on Puppet OpenStack CI was outstanding this week!
>
>
>
> Bug still in progress:
>
> # CI: nonha jobs fails in introspection
> https://bugs.launchpad.net/tripleo/+bug/1609688/comments/8
> It sounds like Introspection is broken since December 16th, we haven't
> investigated much on this one yet. Any help from Mistral / Ironic
> folks is highly welcome.
> Could it be related to https://bugs.launchpad.net/tripleo/+bug/1649350 ?

So we had to revert a patch in puppet-mistral:
https://review.openstack.org/#/c/412602/

that broke us. It will require some work to see how to configure
Mistral / Ironic to work together correctly when authtoken is
configured.
To avoid this problem in the future, we added ovb-non ha job into
puppet-mistral gate: https://review.openstack.org/#/c/412601/

> # Ocata requires additional cellvs2 setup
> https://bugs.launchpad.net/tripleo/+bug/1649341
> Alex is still working on this one but we're very close of closing it.
> It will help us to promote packages in TripleO CI.

note: this is not a blocker but some ongoing work for Ocata.

>
> CI status now:
> - all jobs in Puppet OpenStack CI should be green and stable now,
> please report us any new problem on #puppet-openstack (feel free to
> ping me).
> - all TripleO scenarios and also OVB HA jobs are green.
> - TripleO OVB non-ha is red, because of the introspection problem.
> - TripleO OVB jobs for Mitaka are red, not investigated yet (I'll
> start on Monday, but feel free to help).

That's the next step, we need to find out why Mitaka jobs are failing
(I saw some pingtests issues when creating a VM from volume).

Also, Ben opened a bug for multinode timeouts:
https://bugs.launchpad.net/tripleo/+bug/1651267

Any help is welcome on the remaining work!
Thanks,

> Some links you need to bookmark:
> http://tripleo.org/cistatus.html
> http://status-tripleoci.rhcloud.com/
> http://dashboards.rdoproject.org/rdo-dev
>
> I probably missed some details, but here what we've been working on
> this week. Feel free to add more details on the bugs, and give any
> feedback.
> Again, I would like to thank all people involved in debugging,
> patching and reviewing fixes to unblock CI this week, it was not easy
> but we made it as a team!
>
> Enjoy the week-end,
> --
> Emilien Macchi



-- 
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

[openstack-dev] [tripleo] newton-2 release

[Emilien Macchi]

I'm proposing a new Newton release for TripleO, as we scheduled it a
few weeks ago:
https://review.openstack.org/#/c/412643/

Please let me know any blocker or any backport you want to see in this release.
Thanks,
-- 
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-operators] Analogs of EC2 dedicated instances & dedicated hosts?

[Mohammed Naser]

> On Dec 19, 2016, at 5:24 PM, Kimball, Conrad  
> wrote:
> 
> Hi All,
>  
> What mechanisms does OpenStack provide that would enable me to implement 
> behaviors analogous to AWS EC2 dedicated instances and dedicated hosts?
>  
> · Dedicated instances:  an OpenStack tenant can deploy VM instances 
> that are guaranteed to not share a compute host with any other tenant (for 
> example, as the tenant I want physical segregation of my compute).

I don’t think this type of thing exists yet (unless you’re talking bare-metal / 
Ironic).

> · Dedicated hosts: goes beyond dedicated instances, allowing an 
> OpenStack tenant to explicitly place only specific VM instances onto the same 
> compute host (for example, as the tenant I want to place VMs foo and bar onto 
> the same compute host to share a software license that is licensed per host).

http://docs.openstack.org/newton/config-reference/compute/schedulers.html#samehostfilter

>  
> Conrad Kimball
> Associate Technical Fellow
> Chief Architect, Enterprise Cloud Services
> Engineering, Operations & Technology / Information Technology / Core 
> Infrastructure Engineering
> conrad.kimb...@boeing.com 
> P.O. Box 3707, Mail Code 7M-TE
> Seattle, WA  98124-2207
> Bellevue 33-11 bldg, office 3A6-3.9
> Mobile:  425-591-7802
>  
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Analogs of EC2 dedicated instances & dedicated hosts?

[Kris G. Lindgren]

Not aware of an easy answer for #1, without creating a flavor or image with 
metadata on it and adding specific hosts to a host_aggregate that has the same 
metadata on it.
http://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html
 - Look at isolatedhostfilter or the aggregate_instance_extra_specs and the 
config example for specifying a compute host with SSD’s.


#2 just sounds like affinity/anti-affinity rules? Combined with #1.

ServerGroupAffinityFilter
The ServerGroupAffinityFilter ensures that an instance is scheduled on to a 
host from a set of group hosts. To take advantage of this filter, the requester 
must create a server group with anʼ/span>affinityʼ/span>policy, and pass a 
scheduler hint, usingʼ/span>groupʼ/span>as the key and the server group UUID as 
the value. Using theʼ/span>novaʼ/span>command-line tool, use 
theʼ/span>--hintʼ/span>flag. For example:
$ nova server-group-create --policy affinity group-1
$ nova boot --image IMAGE_ID --flavor 1 --hint group=SERVER_GROUP_UUID server-1
ServerGroupAntiAffinityFilter
The ServerGroupAntiAffinityFilter ensures that each instance in a group is on a 
different host. To take advantage of this filter, the requester must create a 
server group with anʼ/span>anti-affinityʼ/span>policy, and pass a scheduler 
hint, usinggroupʼ/span>as the key and the server group UUID as the value. Using 
theʼ/span>novaʼ/span>command-line tool, use theʼ/span>--hintʼ/span>flag. For 
example:
$ nova server-group-create --policy anti-affinity group-1
$ nova boot --image IMAGE_ID --flavor 1 --hint group=SERVER_GROUP_UUID server-1

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kimball, Conrad" 
Date: Monday, December 19, 2016 at 3:24 PM
To: "openstack-operators@lists.openstack.org" 

Subject: [Openstack-operators] Analogs of EC2 dedicated instances & dedicated 
hosts?

Hi All,

What mechanisms does OpenStack provide that would enable me to implement 
behaviors analogous to AWS EC2 dedicated instances and dedicated hosts?


· Dedicated instances:  an OpenStack tenant can deploy VM instances 
that are guaranteed to not share a compute host with any other tenant (for 
example, as the tenant I want physical segregation of my compute).


· Dedicated hosts: goes beyond dedicated instances, allowing an 
OpenStack tenant to explicitly place only specific VM instances onto the same 
compute host (for example, as the tenant I want to place VMs foo and bar onto 
the same compute host to share a software license that is licensed per host).

Conrad Kimball
Associate Technical Fellow
Chief Architect, Enterprise Cloud Services
Engineering, Operations & Technology / Information Technology / Core 
Infrastructure Engineering
conrad.kimb...@boeing.com
P.O. Box 3707, Mail Code 7M-TE
Seattle, WA  98124-2207
Bellevue 33-11 bldg, office 3A6-3.9
Mobile:  425-591-7802

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Mon, Dec 19, 2016 at 09:18:20AM -0800, Samuel Cassiba wrote:

> The Chef OpenStack cookbooks team is way late to the party. The cookbooks
> (openstack/cookbook-openstack-*, openstack/openstack-chef-repo ) should have
> had their liberty branches EOL’d. I have checked and no open reviews exist
> against liberty.

Thanks.

While I have your attention what about your older branches.  Is there any
mertit keeping the kilo branches in openstack/cookbook-openstack-* or the
stable/{grizzly,havana,icehouse,juno} branches in openstack/openstack-chef-repo

Yours Tony.


signature.asc
Description: PGP signature
__
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] Upgrade skip release

[Chris Friesen]

On 12/19/2016 03:17 PM, Ajay Kalambur (akalambu) wrote:

Hi Chris
Thanks for the response. What were the specific problem areas you saw when 
upgrading from Kilo to Mitaka which were introduced by skipping Liberty?


There were issues with RPC incompatibility, object versioning, DB upgrades, etc.

Liberty had compatibility code for this stuff, but then it got ripped out early 
in Mitaka since it was assumed to be no longer needed.


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-operators] Analogs of EC2 dedicated instances & dedicated hosts?

[Kimball, Conrad]

Hi All,

What mechanisms does OpenStack provide that would enable me to implement 
behaviors analogous to AWS EC2 dedicated instances and dedicated hosts?


* Dedicated instances:  an OpenStack tenant can deploy VM instances 
that are guaranteed to not share a compute host with any other tenant (for 
example, as the tenant I want physical segregation of my compute).


* Dedicated hosts: goes beyond dedicated instances, allowing an 
OpenStack tenant to explicitly place only specific VM instances onto the same 
compute host (for example, as the tenant I want to place VMs foo and bar onto 
the same compute host to share a software license that is licensed per host).

Conrad Kimball
Associate Technical Fellow
Chief Architect, Enterprise Cloud Services
Engineering, Operations & Technology / Information Technology / Core 
Infrastructure Engineering
conrad.kimb...@boeing.com
P.O. Box 3707, Mail Code 7M-TE
Seattle, WA  98124-2207
Bellevue 33-11 bldg, office 3A6-3.9
Mobile:  425-591-7802

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators][openstack-ansible]

[Wade Holler]

Hi JP,

Firstly thank you for your response.

Over the weekend, I did something kind of similar to what you describe.

1. Built a AIO (inside main OSA) @ 16.04/Newton
2. took it's venv files and placed them in the higher level OSAs repo
but as - Example: glance-xenial.tgz
3. copied the existing (14.04 based) venv files to glance.-trusty.tgz
4. Updated the os-{component}-install.yml playbooks to have '-{{
ansible_distribution_release | lower }}' in their respective
_venv_download_url: variable.
5. cleared facts, destroyed containers (the new ones), ran
setup-hosts,setup-infra(without repo-install), setup-openstack.
6.  All good.

Today I am proceeding with my other infrastructure nodes.  When I make
it through all 16.04 upgrades I plan on rebuilding the repo_container
for all repo_hosts.

I didn't do something like shut off the other || old-14.04 containers
as you described above as I thought that it would deploy 16.04 based
venvs to my existing 14.04 servers as I roll through them one at a
time.  Is that correct ?

again thank you very much for your time.

Best Regards,
Wade

On Mon, Dec 19, 2016 at 2:35 AM, Jean-Philippe Evrard
 wrote:
> Hello,
>
> This sounds like an interesting issue that we should fix as soon as possible.
> May I ask you more details on the channel?
>
> It’s still brainstorming, but I think that if you clear facts, 
> destroy/upgrade one controller node, then make sure this controller node has 
> a repo under 16.04, it should be the basis for the rest of the 
> infrastructure, and ssl libs linking shouldn’t be an issue.
> Could you make sure the other repo containers are stopped, this way your load 
> balancer always returns the repo server on the new controller?
> Then, we doing openstack services upgrade, could you continue the way you 
> explained by destroying the container (let’s say for glance for example) and 
> rebuilding? It should be taking the new repo server with the new venv, which 
> should be fine (in theory).
>
> When all of that is done, I think we could have lots of fun with the ssl libs 
> issue :D
>
> Best regards,
> JP
>
> On 17/12/2016, 00:36, "Wade Holler"  wrote:
>
> Hi All,
>
> I am trying to upgrade a multinode cluster that has been very valuable
> in our environment.
>
> The idea was to start at trusty/mitaka and get to xenial/newton.
>
> Step1 mitaka -> newton on a trusty environment went fine.
> Step2 trusty to xenial is not going well and I could use some help.
>
> So far I rebuilt the 1st of 3 infra nodes with Xenial. Then re-ran
> setup-hosts, setup-infrastructure, setup-openstack.
>
> All playbooks ran fairly clean ( relative to the current issue ) -
> HOWEVER the services don't actually start on the Xenial / 16.04 based
> containers.  They just keep dying.
>
> Example error from a glance container here: http://pastebin.com/E6DvWdHy
>
> I jumped on IRC and "logan" was nice enough to help.  We deleted the
> glance container, cleared ansible_facts and rebuilt.  Same errors
> though.  "logan" mentioned that he thought since the repo-build  /
> requirement wheels were getting built on a trusty base / container
> that the wheels / venvs that make it to the 16.04 container are not
> compatible.
>
>
> So, can anyone advise on how to proceed ?
>
> Is there someway to not use the repo_server for the 16.04 hosts, then
> when all infra is at 16.04 re-enable the repo_server.  Just brain
> storming.  Any help would be very welcome.
>
> Best Regards,
> Wade
> wade.hol...@gmail.com
> irc: wadeholler
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [MassivelyDistributed] Next IRC meeting - Jan 4 2017

[lebre . adrien]

Dear all, 

Due to the vacation period, I propose to cancel our meeting this week. 
The next meeting will be held on Jan, the 4th. 

Season's greetings, 
ad_rien_

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [MassivelyDistributed] Next IRC meeting - Jan 4 2017

[lebre . adrien]

Dear all, 

Due to the vacation period, I propose to cancel our meeting this week. 
The next meeting will be held on Jan, the 4th. 

Season's greetings, 
ad_rien_

__
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] Upgrade skip release

[Ajay Kalambur (akalambu)]

Hi Chris
Thanks for the response. What were the specific problem areas you saw when 
upgrading from Kilo to Mitaka which were introduced by skipping Liberty?
Ajay




On 12/19/16, 12:36 PM, "Chris Friesen"  wrote:

>On 12/19/2016 01:56 PM, Ajay Kalambur (akalambu) wrote:
>> Hi
>> Does openstack support skipping releases if one is performing a maintanance
>> upgrade. Would alembic migrations work for instance from Liberty to Newton
>
>OpenStack as a whole only supports N to N+1 upgrades, though it's possible 
>some 
>services may support more than that.
>
>We did Kilo->Mitaka for various reasons and had to resolve a bunch of problems.
>
>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 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] Upgrade skip release

[Chris Friesen]

On 12/19/2016 01:56 PM, Ajay Kalambur (akalambu) wrote:

Hi
Does openstack support skipping releases if one is performing a maintanance
upgrade. Would alembic migrations work for instance from Liberty to Newton


OpenStack as a whole only supports N to N+1 upgrades, though it's possible some 
services may support more than that.


We did Kilo->Mitaka for various reasons and had to resolve a bunch of problems.

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] Upgrade skip release

[Ajay Kalambur (akalambu)]

Hi
Does openstack support skipping releases if one is performing a maintanance 
upgrade. Would alembic migrations work for instance from Liberty to Newton

I think we would have to stop all existing services since API backward 
compatiblity is only 1 release front and back right?

Ajay

__
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] [Ironic] Retiring ironic-webclient

[Julia Kreger]

As discussed at the last summit during the contributor meet-up, as well as 
during today’s Ironic team meeting[0], we will be retiring the 
ironic-webclient. This is due to a number of factors, the largest being that 
the primary contributor has changed positions and is no longer contributing, 
nor does he have any interest in continuing to develop or maintain the 
ironic-webclient. Beyond that, no contributions have landed in the last six 
months, nor has there ever been an official release of the ironic-webclient.  
This should not be confused with ironic-ui which is a horizon plug-in.

Since there have been no releases, nor objections thus far, I will begin the 
process of retiring ironic-webclient this week.

-Julia

[0] 
http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-12-19-17.00.log.html


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

Re: [openstack-dev] [all][ptls][tc][goals] community goals for Pike

[Doug Hellmann]

Excerpts from Emilien Macchi's message of 2016-11-29 19:39:03 -0500:

> 3) Choose Goals for Pike.
> Some of us already did, but we might want to start looking at what
> Goals we would like to achieve during Pike cycle.
> I was thinking at giving a score to the Goals, that could be
> calculated by its priority (I know it's vague but we know what is
> really urgent for us versus what can wait 6 months); but also the
> number of people who are interested to contribute on a Goal (if this
> Goal doesn't have a team yet).
> For now, openstack/governance is the repository for Goals, please
> propose them here.

I have updated the Python 3 goal, previously discussed for Ocata, to
reflect some of the feedback and prepare it for discussion for Pike.

https://review.openstack.org/349069

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

Re: [openstack-dev] [Cinder] Marking Cloudbyte driver as unsupported

[Erlon Cruz]

Hmm, nice! Thanks!

On Mon, Dec 19, 2016 at 11:48 AM, Sean McGinnis 
wrote:

> On Mon, Dec 19, 2016 at 08:27:52AM -0200, Erlon Cruz wrote:
> > Hi Sean, what is the command to generate this output?
> >
> > On Fri, Dec 16, 2016 at 6:27 PM, Sean McGinnis 
> > wrote:
>
> I'm using a modified version of the lastcomment script:
>
> https://github.com/openstack/third-party-ci-tools/tree/
> master/monitoring/lastcomment-scoreboard
>
>
> __
> 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] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

We are delighted to present this week's priorities and subteam report for 
Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and 
formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. attach/detach: review code: https://review.openstack.org/#/c/327046/
2. rolling upgrades spec for dbsync online-db-migration. need to approve: 
https://bugs.launchpad.net/ironic/+bug/1585141
3. boot from volume: next up: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691
4. next notifications: review code for CRUD notifications: 
https://review.openstack.org/#/c/356541/


Bugs (dtantsur)
===
- Stats (diff between 12 Dec 2016 and 19 Dec 2016)
- Ironic: 218 bugs (+1) + 233 wishlist items (+2). 9 new (+2), 186 in progress 
(+3), 0 critical (-3), 29 high and 28 incomplete (-1)
- Inspector: 11 bugs + 22 wishlist items. 1 new (+1), 12 in progress, 1 
critical (+1), 1 high and 4 incomplete
- Nova bugs with Ironic tag: 10. 0 new, 0 critical, 0 high

Portgroups support (sambetts, vdrok)

* trello: https://trello.com/c/KvVjeK5j/29-portgroups-support
- status as of most recent weekly meeting:
- just one patch left on the ironic side (OSC): 
https://review.openstack.org/#/q/topic:bug/1618754
- Another one needed is adding mode/properties to the portgroups in client, 
will be done soon :)
- once those land, will need a client release and then nova patches
- note that the nova patch cannot land until after the attach/detach 
API nova-patch lands

CI refactoring (dtantsur, lucasagomes)
==
* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- (lucasagomes) No updates

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rolling-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- RFE for online-db-migration, need to approve: 
https://bugs.launchpad.net/ironic/+bug/1585141
- patches need reviews: https://review.openstack.org/#/q/topic:bug/1526283
- Testing work:
- Tempest "smoke" tests are now passing for multi-node/multi-tenant 
with various patches!
- Grenade patch has one +2: https://review.openstack.org/407502
- merged
- Sort of blocked by tempest becoming a plugin. Merged 19-Dec-2016.
- Work is ongoing for enabling Grenade with multi-tenant: 
https://review.openstack.org/389268

Interface attach/detach API (sambetts)
==
* trello: https://trello.com/c/nryU4w58/39-interface-attach-detach-api
- status as of most recent weekly meeting:
- Spec merged and Nova BP approved
- Ironic patch up for review: 
https://review.openstack.org/#/q/topic:bug/1582188
- IronicClient - https://review.openstack.org/364420
- Patches need updating still:
- Nova - https://review.openstack.org/364413

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- API side changes for volume connector information have a procedural -2 
until we can begin making use of the data in the conductor, but should stil be 
reviewed
- https://review.openstack.org/#/c/214586/
- Boot from volume/storage interface work was rebased on top of the driver 
composition work this past week.
- 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691
- TheJulia intends to begin work on the iPXE iscsi boot work required this 
week.

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- the patch introducing hardware types defining and loading: 
https://review.openstack.org/336626 merged
- generic hardware types: https://review.openstack.org/400678 merged
- Maybe 4-6 more patches to go before work is completed.
- next patch is still WIP but a review or two wouldn't hurt: 
https://review.openstack.org/#/c/409812/
- jroll hopes to have some API patches started before the holidays

Rescue mode (JayF)
==
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- 12/19 status
- spec update needs reviews: https://review.openstack.org/#/c/407236
- patch for API/conductor methods needs an update, failing tests 
https://review.openstack.org/#/c/350831/
- agent driver implementation needs an update for additional tests and a 
rebase: https://review.openstack.org/#/c/400437

etags in the REST API (gzholtkevych)

Re: [Openstack] Max open files limit for nova-api

[Prashant Shetty]

Thanks John. Seems like prlimit doesnt seems to be available for ubuntu
14.04 :-(

On Mon, Dec 19, 2016 at 11:51 PM, John Petrini 
wrote:

> Hi Prashant,
>
> On second thought that trick might only work on CentOS.  You might have
> success using prlimit instead.
>
> ___
>
> John Petrini
>
> NOC Systems Administrator   //   *CoreDial, LLC*   //   coredial.com
>//   [image: Twitter]    [image:
> LinkedIn]    [image: Google Plus]
>    [image: Blog]
> 
> Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422
> *P: *215.297.4400 x232   //   *F: *215.297.4401   //   *E: *
> jpetr...@coredial.com
>
> [image: Exceptional people. Proven Processes. Innovative Technology.
> Discover CoreDial - watch our video]
> 
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission,  dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> On Mon, Dec 19, 2016 at 1:13 PM, Prashant Shetty <
> prashantshetty1...@gmail.com> wrote:
>
>> Hi John,
>>
>> Echo option doesnt seems to work on below controller.
>>
>> stack@devstackvm:~$ cat /etc/lsb-release
>> DISTRIB_ID=Ubuntu
>> DISTRIB_RELEASE=14.04
>> DISTRIB_CODENAME=trusty
>> DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
>> stack@devstackvm:~$
>>
>> stack@devstackvm:~$ ps aux | grep nova-api
>> stack 3070  1.1  0.1 271576 121092 pts/9   S+   Dec16  50:29
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3079  0.3  0.8 1045308 881676 pts/9  S+   Dec16  14:32
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3080  0.2  0.1 324808 161096 pts/9   S+   Dec16   9:25
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3081  0.2  0.7 980172 816468 pts/9   S+   Dec16  10:37
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3082  0.3  0.1 336824 173288 pts/9   S+   Dec16  16:11
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3083  0.4  0.1 338788 175264 pts/9   S+   Dec16  19:05
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3084  0.4  0.1 336616 172912 pts/9   S+   Dec16  17:41
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3085  0.2  0.8 1054900 891272 pts/9  S+   Dec16  10:09
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3086  0.2  0.1 325088 161228 pts/9   S+   Dec16   9:59
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3097  0.2  0.1 308088 151828 pts/9   S+   Dec16  11:10
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3098  0.2  0.1 308296 152360 pts/9   S+   Dec16  11:15
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3099  0.2  0.1 308708 152544 pts/9   S+   Dec16  11:42
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3100  0.2  0.1 309588 153624 pts/9   S+   Dec16  11:06
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3101  0.2  0.1 308372 152396 pts/9   S+   Dec16  11:14
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3102  0.2  0.1 308084 152052 pts/9   S+   Dec16  11:10
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3103  0.2  0.1 308380 152416 pts/9   S+   Dec16  11:09
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 3104  0.2  0.1 307652 151560 pts/9   S+   Dec16  10:29
>> /usr/bin/python /usr/local/bin/nova-api
>> stack 8087  0.0  0.0  11752  2044 pts/21   S+   10:07   0:00 grep
>> --color=auto nova-api
>> stack@devstackvm:~$
>>
>> stack@devstackvm:~$ cat /proc/3070/limits  | grep "Max open files"
>> Max open files1024 4096
>> files
>> stack@devstackvm:~$
>> stack@devstackvm:~$ echo -n "Max open files=8192:unlimited"  >
>> /proc/3070/limits
>> -bash: /proc/3070/limits: Permission denied
>> stack@devstackvm:~$ sudo echo -n "Max open files=8192:unlimited"  >
>> /proc/3070/limits
>> -bash: /proc/3070/limits: Permission denied
>> stack@devstackvm:~$
>>
>> root@devstackvm:/home/stack# echo -n "Max open files=8192:unlimited" >
>> /proc/3070/limits
>> bash: echo: write error: Invalid argument
>> root@devstackvm:/home/stack#
>>
>> On Mon, Dec 19, 2016 at 11:27 PM, John Petrini 
>> wrote:
>>
>>> Hi Preshant,
>>>
>>> You can change the open file limit of the running process by echoing the
>>> value to it. For example...
>>>
>>> echo -n "Max open files=8192:unlimited"  > /proc//limits
>>>
>>>
>>> ___
>>>
>>> John Petrini
>>>
>>>
>>>
>>> On Mon, Dec 19, 2016 at 12:21 PM, Prashant Shetty <
>>> prashantshetty1...@gmail.com> wrote:
>>>
 Hi Arne,
 Thanks for your reply. Currently all these services 

Re: [Openstack] Max open files limit for nova-api

[Remo Mattei]

That will work until you reboot the system. 

In Red Hat you can modify the /etc/security/limits.conf

Remo 



> On Dec 19, 2016, at 09:57, John Petrini  wrote:
> 
> Hi Preshant,
> 
> You can change the open file limit of the running process by echoing the 
> value to it. For example...
> 
> echo -n "Max open files=8192:unlimited"  > /proc//limits
> 
> ___
> 
> John Petrini
> 
> 
> 
>  
> On Mon, Dec 19, 2016 at 12:21 PM, Prashant Shetty 
> > wrote:
> Hi Arne, 
> Thanks for your reply. Currently all these services are running on ubuntu 
> controller under screen.
> Do we have any option to set the file limit option for n-api service in this 
> case?. I am not using systemd in my setup to run these services.
> 
> Thanks,
> Prashant
> 
> On Mon, Dec 19, 2016 at 10:19 PM, Arne Wiebalck  > wrote:
> Prashant,
> 
> If this is for systemd, how about changing the nova-api unit file?
> 
> Something like
> 
> —>
> [Service]
> ...
> LimitNOFILE=65536
> <—
> 
> should do it. 
> 
> Cheers,
>  Arne
> 
> 
> 
>> On 19 Dec 2016, at 17:23, Prashant Shetty > > wrote:
>> 
>> Team,
>>  
>> I have scale setup and metadata requests are seems to fail from instance. 
>> Main reason for failure is "Max open files" limit(1024) set on nova-api 
>> service. 
>> Though on controller we have set max open file limit of 65k(limit.conf), 
>> nova-api always comes up with 1024 limit causing failure.
>>  
>> Could someone let me know how can we change the max open files limit of 
>> nova-api service?
>> 
>> Setup Details:
>>  
>> · Single controller
>> · 500 KVM computes
>> · Devstack branch: stable/newton
>> · We have native metadata and dhcp running on platform
>> · 3750 instances
>>  
>> 
>> stack@controller:/opt/stack/logs$ ps aux | grep nova-api
>> stack 14998 2.2 0.3 272104 121648 pts/8 S+ 09:53 0:14 /usr/bin/python 
>> /usr/local/bin/nova-api
>> stack@controller:/opt/stack/logs$
>> stack@controller:/opt/stack/logs$
>> stack@controller:/opt/stack/logs$ cat /proc/14998/limits
>> Limit Soft Limit Hard Limit Units
>> Max cpu time unlimited unlimited seconds
>> Max file size unlimited unlimited bytes
>> Max data size unlimited unlimited bytes
>> Max stack size 8388608 unlimited bytes
>> Max core file size unlimited unlimited bytes
>> Max resident set unlimited unlimited bytes
>> Max processes 128611 128611 processes
>> Max open files 1024 4096 files
>> Max locked memory 65536 65536 bytes
>> Max address space unlimited unlimited bytes
>> Max file locks unlimited unlimited locks
>> Max pending signals 128611 128611 signals
>> Max msgqueue size 819200 819200 bytes
>> Max nice priority 0 0
>> Max realtime priority 0 0
>> Max realtime timeout unlimited unlimited us
>> stack@controller:/opt/stack/logs$
>>  
>> n-api:
>> 
>> 
>> 2016-11-08 18:44:26.168 30069 INFO nova.metadata.wsgi.server 
>> [req-fb4d729b-a1cd-4df1-aaf8-3f854a739cce - -] (30069) wsgi exited, 
>> is_accepting=True
>> 
>> Traceback (most recent call last):
>> 
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 
>> 457, in fire_timers
>> 
>> timer()
>> 
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/timer.py", line 
>> 58, in __call__
>> 
>> cb(*args, **kw)
>> 
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line 168, 
>> in _do_send
>> 
>> waiter.switch(result)
>> 
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", 
>> line 214, in main
>> 
>> result = function(*args, **kwargs)
>> 
>>   File "/opt/stack/nova/nova/utils.py", line 1066, in context_wrapper
>> 
>> return func(*args, **kwargs)
>> 
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 865, 
>> in server
>> 
>> client_socket = sock.accept()
>> 
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", 
>> line 214, in accept
>> 
>> res = socket_accept(fd)
>> 
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", 
>> line 56, in socket_accept
>> 
>> return descriptor.accept()
>> 
>>   File "/usr/lib/python2.7/socket.py", line 206, in accept
>> 
>> sock, addr = self._sock.accept()
>> 
>> error: [Errno 24] Too many open files
>> 
>> 
>> 
>> Thanks,
>> Prashant
>>  
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
>> 
>> Post to : openstack@lists.openstack.org 
>> 
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
>> 
> 
> --
> Arne Wiebalck
> CERN IT
> 
> 
> 
> ___
> 

[openstack-dev] [infra] Any way to disable zuul status page auto-refresh?

[Ben Nemec]

The subject pretty much covers it.  When there are a lot of jobs on the 
zuul status page, it kind of brings my browser to its knees, which makes 
it hard to navigate the page.  I know you can filter it, but sometimes I 
want to see all of the jobs in a queue so that isn't always an option. 
If there were a way to let me refresh it on demand (or maybe 
auto-refresh less often?) that would be awesome.


-Ben

__
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] Max open files limit for nova-api

[John Petrini]

Hi Prashant,

On second thought that trick might only work on CentOS.  You might have
success using prlimit instead.

___

John Petrini

NOC Systems Administrator   //   *CoreDial, LLC*   //   coredial.com
//   [image:
Twitter]    [image: LinkedIn]
   [image: Google Plus]
   [image: Blog]

Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422
*P: *215.297.4400 x232   //   *F: *215.297.4401   //   *E: *
jpetr...@coredial.com

[image: Exceptional people. Proven Processes. Innovative Technology.
Discover CoreDial - watch our video]


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission,  dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

On Mon, Dec 19, 2016 at 1:13 PM, Prashant Shetty <
prashantshetty1...@gmail.com> wrote:

> Hi John,
>
> Echo option doesnt seems to work on below controller.
>
> stack@devstackvm:~$ cat /etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=14.04
> DISTRIB_CODENAME=trusty
> DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
> stack@devstackvm:~$
>
> stack@devstackvm:~$ ps aux | grep nova-api
> stack 3070  1.1  0.1 271576 121092 pts/9   S+   Dec16  50:29
> /usr/bin/python /usr/local/bin/nova-api
> stack 3079  0.3  0.8 1045308 881676 pts/9  S+   Dec16  14:32
> /usr/bin/python /usr/local/bin/nova-api
> stack 3080  0.2  0.1 324808 161096 pts/9   S+   Dec16   9:25
> /usr/bin/python /usr/local/bin/nova-api
> stack 3081  0.2  0.7 980172 816468 pts/9   S+   Dec16  10:37
> /usr/bin/python /usr/local/bin/nova-api
> stack 3082  0.3  0.1 336824 173288 pts/9   S+   Dec16  16:11
> /usr/bin/python /usr/local/bin/nova-api
> stack 3083  0.4  0.1 338788 175264 pts/9   S+   Dec16  19:05
> /usr/bin/python /usr/local/bin/nova-api
> stack 3084  0.4  0.1 336616 172912 pts/9   S+   Dec16  17:41
> /usr/bin/python /usr/local/bin/nova-api
> stack 3085  0.2  0.8 1054900 891272 pts/9  S+   Dec16  10:09
> /usr/bin/python /usr/local/bin/nova-api
> stack 3086  0.2  0.1 325088 161228 pts/9   S+   Dec16   9:59
> /usr/bin/python /usr/local/bin/nova-api
> stack 3097  0.2  0.1 308088 151828 pts/9   S+   Dec16  11:10
> /usr/bin/python /usr/local/bin/nova-api
> stack 3098  0.2  0.1 308296 152360 pts/9   S+   Dec16  11:15
> /usr/bin/python /usr/local/bin/nova-api
> stack 3099  0.2  0.1 308708 152544 pts/9   S+   Dec16  11:42
> /usr/bin/python /usr/local/bin/nova-api
> stack 3100  0.2  0.1 309588 153624 pts/9   S+   Dec16  11:06
> /usr/bin/python /usr/local/bin/nova-api
> stack 3101  0.2  0.1 308372 152396 pts/9   S+   Dec16  11:14
> /usr/bin/python /usr/local/bin/nova-api
> stack 3102  0.2  0.1 308084 152052 pts/9   S+   Dec16  11:10
> /usr/bin/python /usr/local/bin/nova-api
> stack 3103  0.2  0.1 308380 152416 pts/9   S+   Dec16  11:09
> /usr/bin/python /usr/local/bin/nova-api
> stack 3104  0.2  0.1 307652 151560 pts/9   S+   Dec16  10:29
> /usr/bin/python /usr/local/bin/nova-api
> stack 8087  0.0  0.0  11752  2044 pts/21   S+   10:07   0:00 grep
> --color=auto nova-api
> stack@devstackvm:~$
>
> stack@devstackvm:~$ cat /proc/3070/limits  | grep "Max open files"
> Max open files1024 4096
> files
> stack@devstackvm:~$
> stack@devstackvm:~$ echo -n "Max open files=8192:unlimited"  >
> /proc/3070/limits
> -bash: /proc/3070/limits: Permission denied
> stack@devstackvm:~$ sudo echo -n "Max open files=8192:unlimited"  >
> /proc/3070/limits
> -bash: /proc/3070/limits: Permission denied
> stack@devstackvm:~$
>
> root@devstackvm:/home/stack# echo -n "Max open files=8192:unlimited" >
> /proc/3070/limits
> bash: echo: write error: Invalid argument
> root@devstackvm:/home/stack#
>
> On Mon, Dec 19, 2016 at 11:27 PM, John Petrini 
> wrote:
>
>> Hi Preshant,
>>
>> You can change the open file limit of the running process by echoing the
>> value to it. For example...
>>
>> echo -n "Max open files=8192:unlimited"  > /proc//limits
>>
>>
>> ___
>>
>> John Petrini
>>
>>
>>
>> On Mon, Dec 19, 2016 at 12:21 PM, Prashant Shetty <
>> prashantshetty1...@gmail.com> wrote:
>>
>>> Hi Arne,
>>> Thanks for your reply. Currently all these services are running on
>>> ubuntu controller under screen.
>>> Do we have any option to set the file limit option for n-api service in
>>> this case?. I am not using systemd in my setup to run these services.
>>>
>>> Thanks,
>>> Prashant
>>>
>>> On Mon, Dec 19, 2016 at 10:19 PM, Arne Wiebalck 
>>> 

Re: [Openstack] Max open files limit for nova-api

[John Petrini]

Hi Preshant,

You can change the open file limit of the running process by echoing the
value to it. For example...

echo -n "Max open files=8192:unlimited"  > /proc//limits


___

John Petrini



On Mon, Dec 19, 2016 at 12:21 PM, Prashant Shetty <
prashantshetty1...@gmail.com> wrote:

> Hi Arne,
> Thanks for your reply. Currently all these services are running on ubuntu
> controller under screen.
> Do we have any option to set the file limit option for n-api service in
> this case?. I am not using systemd in my setup to run these services.
>
> Thanks,
> Prashant
>
> On Mon, Dec 19, 2016 at 10:19 PM, Arne Wiebalck 
> wrote:
>
>> Prashant,
>>
>> If this is for systemd, how about changing the nova-api unit file?
>>
>> Something like
>>
>> —>
>> [Service]
>> ...
>> LimitNOFILE=65536
>> <—
>>
>> should do it.
>>
>> Cheers,
>>  Arne
>>
>>
>>
>> On 19 Dec 2016, at 17:23, Prashant Shetty 
>> wrote:
>>
>> Team,
>>
>> I have scale setup and metadata requests are seems to fail from instance.
>> Main reason for failure is "Max open files" limit(1024) set on nova-api
>> service.
>> Though on controller we have set max open file limit of 65k(limit.conf),
>> nova-api always comes up with 1024 limit causing failure.
>>
>> Could someone let me know how can we change the max open files limit of
>> nova-api service?
>>
>> Setup Details:
>>
>> · Single controller
>> · 500 KVM computes
>> · Devstack branch: stable/newton
>> · We have native metadata and dhcp running on platform
>> · 3750 instances
>>
>>
>> stack@controller:/opt/stack/logs$ ps aux | grep nova-api
>> stack 14998 2.2 0.3 272104 121648 pts/8 S+ 09:53 0:14 /usr/bin/python
>> /usr/local/bin/nova-api
>> stack@controller:/opt/stack/logs$
>> stack@controller:/opt/stack/logs$
>> stack@controller:/opt/stack/logs$ cat /proc/14998/limits
>> Limit Soft Limit Hard Limit Units
>> Max cpu time unlimited unlimited seconds
>> Max file size unlimited unlimited bytes
>> Max data size unlimited unlimited bytes
>> Max stack size 8388608 unlimited bytes
>> Max core file size unlimited unlimited bytes
>> Max resident set unlimited unlimited bytes
>> Max processes 128611 128611 processes
>> Max open files 1024 4096 files
>> Max locked memory 65536 65536 bytes
>> Max address space unlimited unlimited bytes
>> Max file locks unlimited unlimited locks
>> Max pending signals 128611 128611 signals
>> Max msgqueue size 819200 819200 bytes
>> Max nice priority 0 0
>> Max realtime priority 0 0
>> Max realtime timeout unlimited unlimited us
>> stack@controller:/opt/stack/logs$
>>
>> n-api:
>>
>> 2016-11-08 18:44:26.168 30069 INFO nova.metadata.wsgi.server
>> [req-fb4d729b-a1cd-4df1-aaf8-3f854a739cce - -] (30069) wsgi exited,
>> is_accepting=True
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py",
>> line 457, in fire_timers
>> timer()
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/timer.py",
>> line 58, in __call__
>> cb(*args, **kw)
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line
>> 168, in _do_send
>> waiter.switch(result)
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py",
>> line 214, in main
>> result = function(*args, **kwargs)
>>   File "/opt/stack/nova/nova/utils.py", line 1066, in context_wrapper
>> return func(*args, **kwargs)
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line
>> 865, in server
>> client_socket = sock.accept()
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
>> line 214, in accept
>> res = socket_accept(fd)
>>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
>> line 56, in socket_accept
>> return descriptor.accept()
>>   File "/usr/lib/python2.7/socket.py", line 206, in accept
>> sock, addr = self._sock.accept()
>> error: [Errno 24] Too many open files
>>
>> Thanks,
>> Prashant
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
>> --
>> Arne Wiebalck
>> CERN IT
>>
>>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] Where will Neutron go in future?

[Sridar Kandaswamy (skandasw)]

Hi Zhi:

FWaaS has been seen more as an edge (on L3 ports) use case as opposed to SG 
which is on a VM port. Also, as u can see there are differences in the 
attributes on the Rule specification at the most basic level. At this point, we 
are working thru the implementation of FWaaS on L2 ports so that makes ur 
question more relevant. At least one school of thought that we have been 
working with is that the FWaaS API can be more open and continue to evolve to 
support for instance L4-L7 use cases amongst others, but the SG API will 
continue to stay a simpler model (some have also pointed the need for SG to be 
aligned with AWS).

This is still in evolution and we would welcome participation, if u can - pls 
do drop in to our weekly team meeting [1] and we can discuss further.

Thanks

Sridar
[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting


From: zhi >
Reply-To: OpenStack List 
>
Date: Sunday, December 18, 2016 at 7:36 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

Hi, Nate, thanks for your reply.

May I ask a little stupid question? What's the difference between fwaas and 
security group? In my opinion, fwaas and security group are both using linux 
iptables now. So, what's the differences between them?

Thanks
Zhi Chang
__
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] Max open files limit for nova-api

[Prashant Shetty]

Hi Arne,
Thanks for your reply. Currently all these services are running on ubuntu
controller under screen.
Do we have any option to set the file limit option for n-api service in
this case?. I am not using systemd in my setup to run these services.

Thanks,
Prashant

On Mon, Dec 19, 2016 at 10:19 PM, Arne Wiebalck 
wrote:

> Prashant,
>
> If this is for systemd, how about changing the nova-api unit file?
>
> Something like
>
> —>
> [Service]
> ...
> LimitNOFILE=65536
> <—
>
> should do it.
>
> Cheers,
>  Arne
>
>
>
> On 19 Dec 2016, at 17:23, Prashant Shetty 
> wrote:
>
> Team,
>
> I have scale setup and metadata requests are seems to fail from instance.
> Main reason for failure is "Max open files" limit(1024) set on nova-api
> service.
> Though on controller we have set max open file limit of 65k(limit.conf),
> nova-api always comes up with 1024 limit causing failure.
>
> Could someone let me know how can we change the max open files limit of
> nova-api service?
>
> Setup Details:
>
> · Single controller
> · 500 KVM computes
> · Devstack branch: stable/newton
> · We have native metadata and dhcp running on platform
> · 3750 instances
>
>
> stack@controller:/opt/stack/logs$ ps aux | grep nova-api
> stack 14998 2.2 0.3 272104 121648 pts/8 S+ 09:53 0:14 /usr/bin/python
> /usr/local/bin/nova-api
> stack@controller:/opt/stack/logs$
> stack@controller:/opt/stack/logs$
> stack@controller:/opt/stack/logs$ cat /proc/14998/limits
> Limit Soft Limit Hard Limit Units
> Max cpu time unlimited unlimited seconds
> Max file size unlimited unlimited bytes
> Max data size unlimited unlimited bytes
> Max stack size 8388608 unlimited bytes
> Max core file size unlimited unlimited bytes
> Max resident set unlimited unlimited bytes
> Max processes 128611 128611 processes
> Max open files 1024 4096 files
> Max locked memory 65536 65536 bytes
> Max address space unlimited unlimited bytes
> Max file locks unlimited unlimited locks
> Max pending signals 128611 128611 signals
> Max msgqueue size 819200 819200 bytes
> Max nice priority 0 0
> Max realtime priority 0 0
> Max realtime timeout unlimited unlimited us
> stack@controller:/opt/stack/logs$
>
> n-api:
>
> 2016-11-08 18:44:26.168 30069 INFO nova.metadata.wsgi.server
> [req-fb4d729b-a1cd-4df1-aaf8-3f854a739cce - -] (30069) wsgi exited,
> is_accepting=True
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py",
> line 457, in fire_timers
> timer()
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/timer.py",
> line 58, in __call__
> cb(*args, **kw)
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line
> 168, in _do_send
> waiter.switch(result)
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py",
> line 214, in main
> result = function(*args, **kwargs)
>   File "/opt/stack/nova/nova/utils.py", line 1066, in context_wrapper
> return func(*args, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line
> 865, in server
> client_socket = sock.accept()
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
> line 214, in accept
> res = socket_accept(fd)
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
> line 56, in socket_accept
> return descriptor.accept()
>   File "/usr/lib/python2.7/socket.py", line 206, in accept
> sock, addr = self._sock.accept()
> error: [Errno 24] Too many open files
>
> Thanks,
> Prashant
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
> --
> Arne Wiebalck
> CERN IT
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Samuel Cassiba]

On Nov 21, 2016, at 18:35, Tony Breeds  wrote:
> 
> Hi all,
>I'm late in sending this announement, but I'm glad to see several projects
> have already requested EOL releases to make it trivial and obvious where to
> apply the tag.
> 
> I'm proposing to EOL all projects that meet one or more of the following
> criteria:
> 
> - The project is openstack-dev/devstack, openstack-dev/grenade or
>  openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
>  project-config:zuul/layout.yaml
> - The project gates with either devstack or grenade jobs
> - The project is listed in governance:reference/projects.yaml and is tagged
>  with 'stable:follows-policy'.
> 
> 
> Some statistics:
> All Repos  : 1493 (covered in zuul/layout.yaml)
> Checked Repos  :  406 (match one or more of the above 
> criteria)
> Repos with liberty branches:  305
> EOL Repos  :  171 (repos that match the criteria *and* 
> have
>   a liberty branch) [1]
> NOT EOL Repos  :  134 (repos with a liberty branch but
>   otherwise do not match) [2]
> DSVM Repos (staying)   :   68 (repos that use dsvm but don't have
>   liberty branches)
> Open Reviews   :   94 (reviews to close)
> 
> 
> Please look over both lists by 2016-11-27 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing 
> and
>  why.  Note doing this will amost certainly reduce the testing coverage you
>  have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
> 
> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed.  I'm very happy to do this, or if I don't have permissios to
> do it ask a gerrit admin to do it.
> 
> I'll batch the removal of the stable/liberty branches between Nov 28th and Dec
> 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup 
> zuul/layout.yaml
> to remove liberty exclusions and jobs.
> 
> Yours Tony.
> 
> [1] 
> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L1
> [2] 
> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L181
> __
> 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


The Chef OpenStack cookbooks team is way late to the party. The cookbooks 
(openstack/cookbook-openstack-*, openstack/openstack-chef-repo ) should have 
had their liberty branches EOL’d. I have checked and no open reviews exist 
against liberty.

--
Best,

Samuel Cassiba


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Max open files limit for nova-api

[Arne Wiebalck]

Prashant,

If this is for systemd, how about changing the nova-api unit file?

Something like

—>
[Service]
...
LimitNOFILE=65536
<—

should do it.

Cheers,
 Arne



On 19 Dec 2016, at 17:23, Prashant Shetty 
> wrote:

Team,

I have scale setup and metadata requests are seems to fail from instance. Main 
reason for failure is "Max open files" limit(1024) set on nova-api service.
Though on controller we have set max open file limit of 65k(limit.conf), 
nova-api always comes up with 1024 limit causing failure.

Could someone let me know how can we change the max open files limit of 
nova-api service?

Setup Details:

· Single controller
· 500 KVM computes
· Devstack branch: stable/newton
· We have native metadata and dhcp running on platform
· 3750 instances


stack@controller:/opt/stack/logs$ ps aux | grep nova-api
stack 14998 2.2 0.3 272104 121648 pts/8 S+ 09:53 0:14 /usr/bin/python 
/usr/local/bin/nova-api
stack@controller:/opt/stack/logs$
stack@controller:/opt/stack/logs$
stack@controller:/opt/stack/logs$ cat /proc/14998/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 128611 128611 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 128611 128611 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
stack@controller:/opt/stack/logs$

n-api:

2016-11-08 18:44:26.168 30069 INFO nova.metadata.wsgi.server 
[req-fb4d729b-a1cd-4df1-aaf8-3f854a739cce - -] (30069) wsgi exited, 
is_accepting=True
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 457, 
in fire_timers
timer()
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/timer.py", line 
58, in __call__
cb(*args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line 168, in 
_do_send
waiter.switch(result)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 
214, in main
result = function(*args, **kwargs)
  File "/opt/stack/nova/nova/utils.py", line 1066, in context_wrapper
return func(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 865, in 
server
client_socket = sock.accept()
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 
214, in accept
res = socket_accept(fd)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 
56, in socket_accept
return descriptor.accept()
  File "/usr/lib/python2.7/socket.py", line 206, in accept
sock, addr = self._sock.accept()
error: [Errno 24] Too many open files

Thanks,
Prashant

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

--
Arne Wiebalck
CERN IT

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Jeremy Stanley]

On 2016-12-19 11:29:51 +1100 (+1100), Tony Breeds wrote:
[...]
> Given that we can't just re-run the job and expect success what
> options do we have to publish an 11.0.2 tarball?
> 
> I'm assuming this will be a somewhat manual process, given that is
> there anything preventing us from tagging glance liberty-eol?

The easiest option is to just declare that a missing tarball is
acceptable for this last point release. Next easiest is for someone
to manually create and upload a tarball to the tarballs site, then
perhaps retrigger the signing (and PyPI upload if relevant) jobs for
it.

Longer term, we need to come up with a solution for this scenario,
since clearly the current behavior where tarballs can end up
generated on a different platform for release tags than their
corresponding branches use is a problem. Some ideas are floating
around, but will probably rely on/wait for Zuul v3.
-- 
Jeremy Stanley

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

[Openstack] Max open files limit for nova-api

[Prashant Shetty]

Team,

I have scale setup and metadata requests are seems to fail from instance.
Main reason for failure is "Max open files" limit(1024) set on nova-api
service.
Though on controller we have set max open file limit of 65k(limit.conf),
nova-api always comes up with 1024 limit causing failure.

Could someone let me know how can we change the max open files limit of
nova-api service?

Setup Details:

· Single controller
· 500 KVM computes
· Devstack branch: stable/newton
· We have native metadata and dhcp running on platform
· 3750 instances


stack@controller:/opt/stack/logs$ ps aux | grep nova-api
stack 14998 2.2 0.3 272104 121648 pts/8 S+ 09:53 0:14 /usr/bin/python
/usr/local/bin/nova-api
stack@controller:/opt/stack/logs$
stack@controller:/opt/stack/logs$
stack@controller:/opt/stack/logs$ cat /proc/14998/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 128611 128611 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 128611 128611 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
stack@controller:/opt/stack/logs$

n-api:

2016-11-08 18:44:26.168 30069 INFO nova.metadata.wsgi.server
[req-fb4d729b-a1cd-4df1-aaf8-3f854a739cce - -] (30069) wsgi exited,
is_accepting=True
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line
457, in fire_timers
timer()
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/timer.py",
line 58, in __call__
cb(*args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line
168, in _do_send
waiter.switch(result)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py",
line 214, in main
result = function(*args, **kwargs)
  File "/opt/stack/nova/nova/utils.py", line 1066, in context_wrapper
return func(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 865,
in server
client_socket = sock.accept()
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
line 214, in accept
res = socket_accept(fd)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
line 56, in socket_accept
return descriptor.accept()
  File "/usr/lib/python2.7/socket.py", line 206, in accept
sock, addr = self._sock.accept()
error: [Errno 24] Too many open files

Thanks,
Prashant
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all][rdo][kolla] Recommending the RDO tag for the mailing list

[Jason Rist]

On 12/19/2016 07:21 AM, Steven Dake (stdake) wrote:
> Folks,
>
> I am in favor of using a new tag called [rdo] such that RDO (or its 
> transitive dependencies) can be discussed and filtered by email clients as it 
> relates to development topics that affect the broader OpenStack ecosystem.  
> As RDO is a community driven project which is very much related to OpenStack, 
> I think sharing a little bit of OpenStack list bandwidth isn’t too much to 
> ask.
>
> Further I’d invite the broader Kolla team to subscribe to the rdo-list, which 
> is a much more comprehensive coverage of RDO (both users and devs with 
> significant traffic) and filter rdo-list as you prefer:
>
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> Thanks!
> -steve
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
+1

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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][upgrades] no meetings till Jan 9th

[Ihar Hrachyshka]

Ihar Hrachyshka  wrote:


Hi,

we skip two next meeting slots and will meet again Jan 9th usual time.

Happy holidays y’all!
Ihar


OK just to clarify, I am talking about *UPGRADES* neutron meeting, not  
general neutron team meeting. Sorry for any misunderstanding.


Ihar

__
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][upgrades] no meetings till Jan 9th

[Ihar Hrachyshka]

Hi,

we skip two next meeting slots and will meet again Jan 9th usual time.

Happy holidays y’all!
Ihar

__
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] Where will Neutron go in future?

[German Eichberger]

You are correct LBaaS development has moved to the Octavia team. However, 
Octavia will have a way for 3rd party load balancers to plug in instead of the 
Octavia load balancing solution. The Octavia team is currently deciding if it 
should continue to support the Haproxy namespace driver as part of Octavia. If 
you have questions, feel free to stop by the Octavia meeting [1] or send an 
e-mail tagged [Octavia].

German

[1] http://eavesdrop.openstack.org/#Octavia_Meeting

From: Nate Johnston 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Sunday, December 18, 2016 at 10:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

The neutron-fwaas team is an active and enthusiastic participant in the Neutron 
stadium, and is targeting FWaaS v2 to complete in the Ocala release. Once FWaaS 
v2 is complete, the neutron-fwaas team will start deprecating FWaaS v1 in the 
Pike cycle.

--N.

On Sun, Dec 18, 2016 at 9:56 PM zhi 
> wrote:
Deal all.

I have some questions about what will Neutron does in next releases.

As far as I know, LBaaSv2 will be deprecated in next 2 releases, maybe P 
release, we will not see LBaaSv2 anymore, isn't it? Instead of LBaaSv2( HAProxy 
driver based ), Octavia will be the only LBaaS solution, isn't it?

What's about namespace based L3 router? Do we have any ideas about NFV solution 
in L3 router just like Octavia?

Finally, where will Neutron *aaS go in future? Now, vpnaas was not part of 
neutron governance. What about fwaas? Do we deprecated it in next releases?

I wish someone could give some exact words about these. I will thanks a lot. :)


Thanks
Zhi Chang


__

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] proposing Ryan Tidwell and Nate Johnston as service LTs

[German Eichberger]

+1

On 12/16/16, 12:35 PM, "Brandon Logan"  wrote:

+1!

On Fri, 2016-12-16 at 00:58 +0100, Armando M. wrote:
> Hi neutrinos,
> 
> I would like to propose Ryan and Nate as the go-to fellows for
> service-related patches.
> 
> Both are core in their repos of focus, namely neutron-dynamic-routing 
> and neutron-fwaas, and have a good understanding of the service
> framework, the agent framework and other bits and pieces. At this
> point, entrusting them with the responsibility is almost a formality.
> 
> Cheers,
> Armando
> 
> [1] https://review.openstack.org/#/c/411536/
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] Create a domain, projects, users, and roles

[Dariusz Śmigiel]

Atif,
It seems like, you didn't export your admin parameters.
Here [1] you can find similar issue described. If it's not the answer,
you can try to export admin_token [2] and retry step of creating
services.

Dariusz

[1] 
https://ask.openstack.org/en/question/98041/missing-value-auth-url-required-for-auth-plugin-password/
[2] http://docs.openstack.org/developer/keystone/configuration.html#admin-token

2016-12-18 22:41 GMT-06:00 Atif Munir :
>
> Hi Dariusz, I have used the procedure suggested by your and below is the
> output. Thank you for your kind reply and support.
>
>
>
> root@ubuntu:~# openstack --debug project create --domain default
> --description
> START with options: [u'--debug', u'project', u'create', u'--domain',
> u'default', u'--description']
> options: Namespace(access_key='', access_secret='***', access_token='***',
> access_token_endpoint='', access_token_type='', auth_type='', auth_url='',
> cacert=None, cert='', client_id='', client_secret='***', cloud='', code='',
> consumer_key='', consumer_secret='***', debug=True,
> default_domain='default', default_domain_id='', default_domain_name='',
> deferred_help=False, discovery_endpoint='', domain_id='', domain_name='',
> endpoint='', identity_provider='', identity_provider_url='', insecure=None,
> interface='', key='', log_file=None, old_profile=None, openid_scope='',
> os_baremetal_api_version='1.9', os_beta_command=False,
> os_compute_api_version='', os_dns_api_version='2',
> os_identity_api_version='', os_image_api_version='',
> os_key_manager_api_version='1', os_network_api_version='',
> os_object_api_version='', os_orchestration_api_version='1',
> os_project_id=None, os_project_name=None, os_volume_api_version='',
> passcode='', password='***', profile=None, project_domain_id='',
> project_domain_name='', project_id='', project_name='', protocol='',
> redirect_uri='', region_name='', timing=False, token='***', trust_id='',
> url='', user_domain_id='', user_domain_name='', user_id='', username='',
> verbose_level=3, verify=None)
> Auth plugin password selected
> auth_config_hook(): {'auth_type': 'password', 'beta_command': False,
> u'compute_api_version': u'2', u'orchestration_api_version': '1',
> u'database_api_version': u'1.0', u'metering_api_version': u'2',
> u'network_api_version': u'2', u'message': u'', u'image_format': u'qcow2',
> 'networks': [], u'image_api_version': u'2', 'verify': True,
> u'dns_api_version': '2', u'object_store_api_version': u'1', u'status':
> u'active', 'verbose_level': 3, 'region_name': '', 'api_timeout': None,
> u'baremetal_api_version': '1.9', 'auth': {}, 'default_domain': 'default',
> u'container_api_version': u'1', u'image_api_use_tasks': False,
> u'floating_ip_source': u'neutron', 'key': None, 'timing': False, 'cacert':
> None, u'key_manager_api_version': '1', 'deferred_help': False,
> u'identity_api_version': u'2.0', u'volume_api_version': u'2', 'cert': None,
> u'secgroup_source': u'neutron', 'debug': True, u'interface': None,
> u'disable_vendor_agent': {}}
> Deferring keystone exception: argument of type 'OSC_Config' is not iterable
> defaults: {u'auth_type': 'password', u'status': u'active',
> u'compute_api_version': u'2', 'key': None, u'database_api_version': u'1.0',
> 'api_timeout': None, u'baremetal_api_version': u'1', u'image_api_version':
> u'2', u'metering_api_version': u'2', u'image_api_use_tasks': False,
> u'floating_ip_source': u'neutron', u'orchestration_api_version': u'1',
> 'cacert': None, u'network_api_version': u'2', u'message': u'',
> u'image_format': u'qcow2', u'key_manager_api_version': u'v1', 'verify':
> True, u'identity_api_version': u'2.0', u'volume_api_version': u'2', 'cert':
> None, u'secgroup_source': u'neutron', u'container_api_version': u'1',
> u'dns_api_version': u'2', u'object_store_api_version': u'1', u'interface':
> None, u'disable_vendor_agent': {}}
> cloud cfg: {'auth_type': 'password', 'beta_command': False,
> u'compute_api_version': u'2', u'orchestration_api_version': '1',
> u'database_api_version': u'1.0', u'metering_api_version': u'2',
> u'network_api_version': u'2', u'message': u'', u'image_format': u'qcow2',
> 'networks': [], u'image_api_version': u'2', 'verify': True,
> u'dns_api_version': '2', u'object_store_api_version': u'1', u'status':
> u'active', 'verbose_level': 3, 'region_name': '', 'api_timeout': None,
> u'baremetal_api_version': '1.9', 'auth': {}, 'default_domain': 'default',
> u'container_api_version': u'1', u'image_api_use_tasks': False,
> u'floating_ip_source': u'neutron', 'key': None, 'timing': False, 'cacert':
> None, u'key_manager_api_version': '1', 'deferred_help': False,
> u'identity_api_version': u'2.0', u'volume_api_version': u'2', 'cert': None,
> u'secgroup_source': u'neutron', 'debug': True, u'interface': None,
> u'disable_vendor_agent': {}}
> compute API version 2, cmd group openstack.compute.v2
> network API version 2, cmd group openstack.network.v2
> image API version 2, cmd group openstack.image.v2
> volume API version 

Re: [openstack-dev] [TripleO] DB cleanup cron jobs added to rh1

[Derek Higgins]

On 16 December 2016 at 21:40, Ben Nemec  wrote:
> Just a heads up for everyone, I've added some DB cleanup jobs to rh1 which
> will hopefully prevent the performance degradations over time that we've
> been seeing in that environment.  Specifically, the crontab now looks like
> this:
>
> # Clean up heat db
> 0 5 * * * heat-manage purge_deleted 7
> # Archive nova db entries 5 times so we get everything
> 0,10,20,30,40 6 * * * nova-manage db archive_deleted_rows --max_rows 10
>

lgtm, We did a number of things last week in order to deal with the
performance problems, these db archive commands cover part of it and
needed to be added.

The other thing we need to keep an eye on is the number of OVS ports
on each compute node, on some compute nodes we had over 2000 ovs ports
and ovs couldn't be restarted(and some other services). Ultimately to
deal with this we rebooted each compute node and allowed
neutron-ovs-cleanup to delete the unused ports. This wasn't ideal
because
1) neutron-ovs-cleanup in some cases took a long time to delete the
ports, and delayed nova-compute from starting up, so compute nodes
couldn't be used for a extended period of time.
2) This also caused a reboot of the infrastructure nodes we run on rh1
(e.g. proxy, te-broker etc...) some of these didn't come back as
expected, where needed patches have been submitted[1][2]

I haven't done anything to prevent the ports building up again, so
this is probably still a ongoing issue we need to look into

[1] - https://review.openstack.org/#/c/409930/
[2] - https://review.openstack.org/#/c/406927/

> I picked 5 and 6 AM UTC because I think that's before most people in the EU
> are starting and well after the US is done so the cloud should be pretty
> quiet at that time.
>
> I think it's worth noting that we should probably be setting up this sort of
> thing on initial deployment by default.  Maybe we are now (rh1 is still back
> on Mitaka), but if not we should figure out some appropriate defaults.
>
> -Ben
>
> __
> 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][nova][oslo][osprofiler] Next step of OSprofiler

[Worry Wang]

Hi folks,



I’m glad to tell that OSprofiler would help a lot for us to find problems
and slowness in system. I really hope to help improve it.

I noticed some problems:



1.   The integration with neutronclient, nova and novaclient has not
been done yet.

2.   The blueprint “osprofiler-overhead-control” is not in progress.
The spec[1] was workflow -1.

  Does it mean this feature would not been done in Ocata ?

3.   We need a server/tool to collect and analysis the trace data.
Should this implemented by OSprofiler,

  or this could be implemented by another project of OSprofiler ?



Any suggestions would be helpful.



Thanks and best regards,

Rui Wang


[1] https://review.openstack.org/#/c/406880/
__
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] [all][rdo][kolla] Recommending the RDO tag for the mailing list

[Steven Dake (stdake)]

Folks,

I am in favor of using a new tag called [rdo] such that RDO (or its transitive 
dependencies) can be discussed and filtered by email clients as it relates to 
development topics that affect the broader OpenStack ecosystem.  As RDO is a 
community driven project which is very much related to OpenStack, I think 
sharing a little bit of OpenStack list bandwidth isn’t too much to ask.

Further I’d invite the broader Kolla team to subscribe to the rdo-list, which 
is a much more comprehensive coverage of RDO (both users and devs with 
significant traffic) and filter rdo-list as you prefer:

https://www.redhat.com/mailman/listinfo/rdo-list

Thanks!
-steve

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

[Openstack-operators] [midcycle-ops-meetup-MIL] call for sponsors - Milano

[Mariano Cunietti]

Dear all,
as some of you may already know, Milano (Italy, Europe, Earth) has been chosen 
as the next city to host the mid-cycle Openstack Operators Meetup scheduled on 
March 15-16, 2017.

While we’re setting up everything to give you the best Italian lifestyle 
experience, we need to find the resources to make it...awesome.
Therefore we’re looking for partners and sponsors to support us while we figure 
out how to make your stay here amazing.

We’re going to host 120-130 people here: http://www.coworkinglogin.it/ 
. A night event is under definition on the 
evening of March 15.
More details at: https://etherpad.openstack.org/p/MIL-ops-meetup 


If you’re interested, please join us on IRC every Tuesday at 3PM UTC with the 
Ops Meetup Team (https://wiki.openstack.org/wiki/Ops_Meetups_Team 
) or drop me an email at 
mcunie...@enter.eu.

Ciao!

M.


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Cinder] Marking Cloudbyte driver as unsupported

[Sean McGinnis]

On Mon, Dec 19, 2016 at 08:27:52AM -0200, Erlon Cruz wrote:
> Hi Sean, what is the command to generate this output?
> 
> On Fri, Dec 16, 2016 at 6:27 PM, Sean McGinnis 
> wrote:

I'm using a modified version of the lastcomment script:

https://github.com/openstack/third-party-ci-tools/tree/master/monitoring/lastcomment-scoreboard


__
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] [api][zun] Effective URL for resource actions

[Chris Dent]

On Fri, 16 Dec 2016, Hongbin Lu wrote:


I am from the Zun team and I wanted to consult with you about the API
design. Our team was discussing what is the best API design for
exposing different container operations [1]. There are two proposed
options:

1. Expose multiple URLs for individual container operation. For example:

[...]


2. Expose a single URL for all operations. For example:

[...]

How to deal with "actions" is something we've struggled to reach
consensus about in the API-WG. There have been a few proposals over
the years (including some like both of the options you've listed),
but none have been loved by everyone. There's a great deal of
discussion that has happened around this issue and could still
happen. Below is my personal perspective.

There's a third option you may wish to consider that is perhaps a
bit more resource oriented: use PUT or PATCH to update the state of
the containers representation. Note that the examples should be take
as describing an option, not indicating the right choices for the
terms involved.

a) GET /containers/

   This gets you a representation including some indicator of state.

   {...
"uptime": 542819,
"state": "running",
...
   }

b) Change that state value to the target and PUT the representation
   back.

   PUT /containers/

   {...
"state": "rebooting"
...
   }

   Or, if for some reason you need to save some bytes, you could
   PATCH the state attribute.

c) If the change takes time and the request is asynchronous, the
   response could be 202 and doing a GET will representing the
   change in progress:

   GET /containers/

   {...
"state": "rebooting",
...
   }

   [time passes..]

   GET /containers/

   {...
"uptime": 30,
"state": "running",
...
   }

Like everything this mode has advantages and disadvantages. One
advantage is that we avoid adding URLs. One disadvantage (for some)
is that passing around the full representation is complex and/or
confusing.

As discussed on the abandoned review[1] referenced from the etherpad
it is important to distinguish between actions which are atomic (at
least from the perspective of the user-agent) and don't need
observation and sequences of tasks which may need observation and
may need to be interrupted and continued.

The former are changes in resource state, and thus could be
represented as such (as I've described above).

In the latter, the task is (or tasks are ) the actual resource and
should be the thing that is addressed by URL. That resource should
make reference to the other entities which are being manipulated by
the task.


From a user's standpoint stop, start, pause, unpause, reboot etc are

isolated actions that describe a state of the container resource.

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

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Issues with libvirt transition 1.2.7 -> 2.0.0 (CentOS 7.3)

[Neil Jerram]

On Fri, Dec 16, 2016 at 4:16 PM Neil Jerram  wrote:

> On Fri, Dec 16, 2016 at 4:08 PM Steve Gordon  wrote:
>
> > If you haven't already I would suggest grabbing qemu-kvm-ev from the
> CentOS
> > > Virt SIG repos:
> > >
> > > http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/
> > >
> > > You can enable the repository using this release RPM:
> > >
> > >
> > >
> http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/centos-release-qemu-ev-1.0-1.el7.noarch.rpm
> > >
> > >
> > Would you expect that to help with virt_type = qemu (as well as with
> > virt_type = kvm, which I assume is the more common setting)?  If so I'll
> be
> > very excited to try this!
>
> For this particular flag issue I am not 100% sure yet as I'm still
> checking with some of the qemu folks, but I think it would still be worth a
> try.
>
>
> Well I have at least one booting instance now, and there is no mention of
> 'tsc_adjust not found' in the instance's log.
>
> So looking more promising - thanks!
>
>

Most of my testing on CentOS 7.3 is now working again, but I am reliably
seeing issues in 3 cases connected with
- multiple interfaces into a VM
- a VM being rebooted.

Should I report those in more detail here, or is there some better place
such as a CentOS- or libvirt-focussed list?

Thanks,
 Neil
__
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] [Cinder] Marking Cloudbyte driver as unsupported

[Erlon Cruz]

Hi Sean, what is the command to generate this output?

On Fri, Dec 16, 2016 at 6:27 PM, Sean McGinnis 
wrote:

> Checking name: CloudByte CI
> last seen: 2016-09-27 11:49:45 (80 days, 5:38:50 old)
> last success: 2016-09-27 11:49:45 (80 days, 5:38:30 old)
> success rate: 72%
>
> Per Cinder's non-compliance policy [1] this patch [2] marks
> the driver as unsupported and deprecated and it will be
> approved if the issue is not corrected by the next cycle.
>
> [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-
> drivers#Non-Compliance_Policy
> [2] https://review.openstack.org/#/c/411958/
>
> __
> 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] Performance issue on single physical host

[Kostyantyn Volenbovskyi]

Hi, 

a few thoughts:
-analyze what exactly time is spent on using Nova logs 
(api+scheduler+conductor+compute)+Neutron (agent, bind port stuff)+Libvirt/QEMU 
logs. Use req-id and UUID of instance to identify the ’slow’ case across logs.
Take a look at the create instance’ flow that is present in bunch of websites 
in internet and make a draft of distribution of time for each stage
(side note: maybe there is tool that will allow such thing?). Turn on debug 
logging in Nova and Neutron to narrow it down in case necessary .
-compare CPU/RAM consumption in normal case and ‘slow’ case’

> How do I bound my vCPU all the way to the physical host?

Answer is CPU pinning. But yup, that is about CPU utilization on host , not 
related to time of VM launch.
Note that for general-purpose case CPU pinning can be an overkill in a way that 
general-purpose relies
on scheduling by host OS and it should not be problematic. And most 
configurations run with oversubscription of CPU 16 which is default (1 physical 
CPU=16 virtual)
'Specific purpose' cases are like NFV/Telco where CPU pinning is much-much more 
used.

BR, 
Konstantin


> On Dec 19, 2016, at 5:27 AM, Vikram Chhibber  
> wrote:
> 
> Hi All,
> 
> I am using Kilo release 1:2015.1.4-0ubuntu2 for my lab deployment on single 
> physical host. The issue is that I am getting very low performance when I 
> launch multiple VM instances. The first one boots up within seconds but the 
> second takes noticeable time. If I instantiate the third instance when two 
> instances are already running, it may take 30 minutes to come up. Moreover, 
> the CPU idle % for a given instance keeps decreasing as number of running 
> instances increase.
> I am suspecting that this behavior is because be lack of bounding of vCPUs 
> with physical CPUs.
> Because of single node installation, the compute node itself becomes 
> virtualized and run my instances within it. How do I bound my vCPU all the 
> way to the physical host? I did not see any documentation regarding this for 
> Kilo release and there is no mention of bounding CPU for the virtualized 
> compute node on single node installation.
> 
> This is the specification of the host:
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bita
> Byte Order:Little Endian
> CPU(s):36
> On-line CPU(s) list:   0-35
> Thread(s) per core:2
> Core(s) per socket:18
> Socket(s): 1
> NUMA node(s):  1
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 63
> Stepping:  2
> CPU MHz:   1200.000
> BogoMIPS:  4599.94
> Virtualization:VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  256K
> L3 cache:  46080K
> NUMA node0 CPU(s): 0-35
> 
> 
> Spec. for the compute node:
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):26
> On-line CPU(s) list:   0-25
> Thread(s) per core:1
> Core(s) per socket:1
> Socket(s): 26
> NUMA node(s):  1
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 6
> Stepping:  3
> CPU MHz:   2299.996
> BogoMIPS:  4599.99
> Virtualization:VT-x
> Hypervisor vendor: KVM
> Virtualization type:   full
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  4096K
> NUMA node0 CPU(s): 0-25
> 
> 
> Spec for my instance:
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):4
> On-line CPU(s) list:   0-3
> Thread(s) per core:1
> Core(s) per socket:1
> Socket(s): 4
> NUMA node(s):  1
> Vendor ID: GenuineIntel
> CPU family:15
> Model: 6
> Stepping:  1
> CPU MHz:   2299.994
> BogoMIPS:  4599.98
> Virtualization:VT-x
> Hypervisor vendor: KVM
> Virtualization type:   full
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  4096K
> NUMA node0 CPU(s): 0-3
> 
> Thanks
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0074] Nova metadata service should not be used for sensitive information

[Luke Hinds]

OpenStack Security Note: 0074

Nova metadata service should not be used for sensitive information

---

### Summary ###
A recent security report has highlighted how users may be using the
metadata service to store security sensitive information.

The Nova metadata service should not be considered a secure repository
of confidential information required by compute instances.

### Affected Services / Software ###
Nova, All Versions

### Discussion ###
A recent vulnerability report for Nova stated that the metadata service
will obey the `X-Forwarded-For` HTTP header. This header is often
supplied by proxies so that the end service can identify which IP the
request originated from.

The Nova metadata service typically uses the source IP address of the
incoming request to respond with the appropriate data for the compute
instance making the request. This is a sort of weak authentication,
designed to ensure that metadata for one tenant isn't accidentally
provided to another.

If the request contains a `X-Forwarded-For` HTTP header then the
metadata service will use that for the source authentication rather than
the actual TCP/IP source.

An attacker with access to a compute instance in the cloud could send a
request to the metadata service and include the `X-Forwarded-For` header
in order to effectively spoof their source and cause the metadata
service to provide information that should not have been provided to
that instance.

Consider the following:
Alice creates a compute instance. She places the root password for that
instance in the metadata service. The instance is assigned a 10.1.2.2
IP address. Alice believes that the root password for her instance is
safe within the metadata service.

Alice retrieves metadata by running a command similar to:
`curl http://169.254.169.254/latest/meta-data
`
this will retrieve any metadata stored for Alice's compute instance,
which has an IP address of 10.1.2.2

Bob has a compute instance with IP address 10.1.9.9 however Bob wants
access to the metadata for Alice's compute instance. If Bob runs a
similar command to Alice, but includes a customer header as below, he
will get access to all of Alice's metadata, including the root password
she chose to store there:
`curl -H "X-Forwarded-For:
10.1.2.2" http://169.254.169.254/latest/meta-data
`

The Nova metadata service is a useful utility within OpenStack but
clearly not intended as a strongly authenticated system for storing
sensitive data such as private keys or passwords.

### Recommended Actions ###
The metadata service should not be used to store sensitive information.

The IP forwarding issue is not a defect of itself, it exists to allow
the metadata service to provide IP addresses for instances that are
behind a proxy as may be the case in more complex deployments.

Cloud users who have a requirement to store sensitive information that
compute instances require for operation should instead look to the
Config drive to provide this service. It's operation is much more
tightly bound to individual compute instances.

Where use of config drive is not an option, operators should consider
other mitigations such as placing a proxy in front of the metadata service
which can filter out these sorts of malicious activities.

### Contacts / References ###
Author: Robert Clark, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0074
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1563954

Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Config Drive
: http://docs.openstack.org/user-guide/cli-config-drive.html




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [OSSN-0074] Nova metadata service should not be used for sensitive information

[Luke Hinds]

OpenStack Security Note: 0074

Nova metadata service should not be used for sensitive information

---

### Summary ###
A recent security report has highlighted how users may be using the
metadata service to store security sensitive information.

The Nova metadata service should not be considered a secure repository
of confidential information required by compute instances.

### Affected Services / Software ###
Nova, All Versions

### Discussion ###
A recent vulnerability report for Nova stated that the metadata service
will obey the `X-Forwarded-For` HTTP header. This header is often
supplied by proxies so that the end service can identify which IP the
request originated from.

The Nova metadata service typically uses the source IP address of the
incoming request to respond with the appropriate data for the compute
instance making the request. This is a sort of weak authentication,
designed to ensure that metadata for one tenant isn't accidentally
provided to another.

If the request contains a `X-Forwarded-For` HTTP header then the
metadata service will use that for the source authentication rather than
the actual TCP/IP source.

An attacker with access to a compute instance in the cloud could send a
request to the metadata service and include the `X-Forwarded-For` header
in order to effectively spoof their source and cause the metadata
service to provide information that should not have been provided to
that instance.

Consider the following:
Alice creates a compute instance. She places the root password for that
instance in the metadata service. The instance is assigned a 10.1.2.2
IP address. Alice believes that the root password for her instance is
safe within the metadata service.

Alice retrieves metadata by running a command similar to:
`curl http://169.254.169.254/latest/meta-data
`
this will retrieve any metadata stored for Alice's compute instance,
which has an IP address of 10.1.2.2

Bob has a compute instance with IP address 10.1.9.9 however Bob wants
access to the metadata for Alice's compute instance. If Bob runs a
similar command to Alice, but includes a customer header as below, he
will get access to all of Alice's metadata, including the root password
she chose to store there:
`curl -H "X-Forwarded-For:
10.1.2.2" http://169.254.169.254/latest/meta-data
`

The Nova metadata service is a useful utility within OpenStack but
clearly not intended as a strongly authenticated system for storing
sensitive data such as private keys or passwords.

### Recommended Actions ###
The metadata service should not be used to store sensitive information.

The IP forwarding issue is not a defect of itself, it exists to allow
the metadata service to provide IP addresses for instances that are
behind a proxy as may be the case in more complex deployments.

Cloud users who have a requirement to store sensitive information that
compute instances require for operation should instead look to the
Config drive to provide this service. It's operation is much more
tightly bound to individual compute instances.

Where use of config drive is not an option, operators should consider
other mitigations such as placing a proxy in front of the metadata service
which can filter out these sorts of malicious activities.

### Contacts / References ###
Author: Robert Clark, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0074
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1563954

Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Config Drive
: http://docs.openstack.org/user-guide/cli-config-drive.html




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
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] Is it possible that creating a port and binding it with 2 IPs

[Vincent.Chao]

Thank you very much for the reply, and the reply are work!

Vincent Chao

2016-12-06 18:45 GMT+09:00 Kevin Benton :

> +1. Also, if you just need an additional IP for the instance that isn't
> used by other instances, you can do a port update and add additional IPs to
> the fixed_ips field.
>
> On Tue, Dec 6, 2016 at 1:09 AM, Neil Jerram  wrote:
>
>> Hi Vincent,
>>
>> Your initial observation is correct: each port is associated with a
>> Neutron network, and will get one IPv4 and one IPv6 address from the
>> subnets associated with that network.
>>
>> To add additional IPs to a port, you can use the allowed-address-pairs
>> extension.
>>
>> Regards,
>>  Neil
>>
>>
>> *From: *Vincent.Chao
>> *Sent: *Tuesday, 6 December 2016 06:43
>> *To: *OpenStack Development Mailing List (not for usage questions)
>> *Reply To: *OpenStack Development Mailing List (not for usage questions)
>> *Subject: *[openstack-dev] [neutron] Is it possible that creating a port
>> and binding it with 2 IPs
>>
>> Hi Neutrons,
>>
>> As my observation from the flow table, every created port seems bound
>> with only one IP address.
>> I was wondering is neutron support this function which can bind a port
>> with two IPs?
>>
>> For example, a VNF load balancer, which has a VIP and a real IP.
>> And this VNF receives packets with the destination of a VIP or a real IP
>> through one port.
>>
>> Any corrections or suggestions are welcome.
>> Thanks in advance.
>>
>> Vincent
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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-dev] [monasca] Team meeting on 28 Dec

[witold.be...@est.fujitsu.com]

Hello everyone, 

should we cancel the team meeting on 28 Dec? Most of us will be in vacation I 
assume.

Greetings
Witek

__
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] multi-attach-volume for rbd

[Avishay Traeger]

Multi-attach also happens during VM migration: (attach volume to
destination host, move VM to destination host, detach volume from source
host).  It's not clear if rbd's limitation affects this as well - it's not
clear from the bug report or the patch.

On Thu, Dec 15, 2016 at 1:30 AM, Matt Riedemann 
wrote:

> On 12/14/2016 3:53 PM, Shane Peters wrote:
>
>> Hello all,
>>
>> Per https://review.openstack.org/#/c/283695/ multi-attach was disabled
>> for rbd volumes.
>>
>> Does anyone know what features are missing or aren't compatible in rbd
>> for it to support multi-attach?
>>
>> Thanks
>> Shane
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> Nova doesn't support multiattach volumes for any Cinder backend. That's
> being worked by the Nova and Cinder teams but won't be something that's
> implemented on the Nova side in the Ocata release, and will be a stretch
> probably for Pike. There are weekly meetings about this though, see:
>
> http://eavesdrop.openstack.org/#Cinder,_Nova
>
> --
>
> 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
>



-- 
*Avishay Traeger, PhD*
*System Architect*

Mobile: +972 54 447 1475
E-mail: avis...@stratoscale.com



Web  | Blog 
 | Twitter  | Google+

 | Linkedin 
__
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