[openstack-dev] [Neutron][Ironic] Ironic-Neutron Integration meeting termination notification

2017-01-02 Thread Sukhdev Kapur 
Folks,

As you know we started out the charter to bring multi-tenancy for Bare
metal Service (Ironic) using Neutron networking in Liberty Cycle. We have
been meeting weekly to discuss this Ironic/ Neutron integration and make it
a reality.

 We successfully completed the charter - thanks to everybody who
participated and contributed to make it a reality.
The charter that we  laid out initially as specified in [1] has been
accomplished. We have few pieces which are in the final stages of
completion and will be completed (hopefully) in Ocata cycle.

Our weekly meetings have become more or less status meetings. Therefore, we
have decided to to discontinue our meetings and instead roll out the
sub-team status into Ironic weekly meeting.
Starting 2017, we will cancel our weekly meetings. We will roll up the
status of this sub-team into the Ironic meetings.

If anybody feels that there is a need to keep this meeting separately, feel
free to express your opinion. In the absence of any objection, I will
proceed with the plan. I will push a patch to relinquish the time slot so
that other OpenStack projects can avail that time slot.

Thanks and HAPPY NEW YEAR

regards..
-Sukhdev

[1] -
https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Tracking_Ironic.2FNeutron_integration_Discussions
__
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] Adding CONTRIBUTING.rst files to projects

2017-01-02 Thread Andreas Jaeger 
On 01/03/2017 04:01 AM, Anne Gentle wrote:
> [...]
> Doug, I think the include in Sphinx can be a raw txt file? Then we get
> the best of both worlds - rendered on both docs.openstack.org
>  and github.com .

We do not need an rst file, github handles .txt just fine. I see no
reason to move to txt.

> I'll give that a shot with these patches as a proof of concept:
> 
> 1. Change cookie-cutter file to CONTRIBUTING.txt
> https://review.openstack.org/416109
> 2. Update openstack-manuals rendered docs with an included
> CONTRIBUTING.txt https://review.openstack.org/416112
> 
> We won't really know the GitHub UI rendering of the include until
> merged, but I've tested in other repos and changing the file extension
> to .txt gives a link to that file.

Works with RST as well for me - I just created a pull request for
cookiecutter and got the contributing link as expected. There's no need
to use txt files.

> Thoughts? Please comment on the reviews or here. I can work on it if we
> think it's worthwhile to standardize upon, and/or collaborate with the
> original contributor who wanted to standardize. I do believe the GitHub
> experience is worthy of attention, similar in my mind to the recent
> badges work.

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] Adding CONTRIBUTING.rst files to projects

2017-01-02 Thread Anne Gentle 
On Mon, Jan 2, 2017 at 11:03 AM, Doug Hellmann 
wrote:

> Excerpts from Paul Belanger's message of 2016-12-24 15:23:35 -0500:
> > On Wed, Dec 21, 2016 at 10:17:42AM -0600, Ian Cordasco wrote:
> > > -Original Message-
> > > From: Andrey Kurilin 
> > > Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> > > Date: December 21, 2016 at 10:13:09
> > > To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> > > Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
> projects
> > >
> > > > On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger wrote:
> > > >
> > > > > On 2016-12-21 16:22, Ian Cordasco wrote:
> > > > > > [...]
> > > > > > That said, I think there are two better places for this
> information
> > > > > > that are already standards in OpenStack:
> > > > > >
> > > > > > * README.rst
> > > > > > * HACKING.rst
> > > > > >
> > > > > > Most projects include links to the contributing documentation in
> at
> > > > > > least one of these files. I think the effort here is to
> standardize,
> > > > > > albeit in a brand new file, and that's admirable.
> > > > >
> > > > > If that's the goal - to standardize - then I would expect that we
> move
> > > > > all the documentation out of those files in one place.
> > > > >
> > > > > Right now, the changes duplicate information that exists - and the
> new
> > > > > information is often wrong. It points to place that do not exist or
> > > > > where better places exist. ;(
> > > > >
> > > >
> > > > Duplication can be reduced by using `.. include:: ` directive.
> > >
> > > That does not render anywhere except our documentation (via Sphinx).
> Git{Hub,Lab} don't render the include directive at all.
> > >
> > > So, no, that's not an option.
> > >
> > No, this is a valid option. We do it today with various documentation.
> >
> > They will however render to docs.o.o, which we consider source of truth.
> The
> > topic of rendering RST files to github has come up a few times, but each
> time
> > comes back to the fact we simply mirror to github.
> >
> > It is possible to have git.openstack.org render RST too, but we've
> opted to do
> > it with docs.openstack.org.
> >
>
> Using include works some places, but not others.
>
> The include directive is a feature of Sphinx, not docutils. We use
> Sphinx to convert reStructuredText to HTML for docs.o.o but github does
> not use Sphinx when rendering individual reStructuredText files such as
> CONTRIBUTING.rst or README.rst.
>
> Since the point of having CONTRIBUTING.rst be a separate file is
> to take advantage of the github.com integration to guide potential
> contributors to the right forum for their contributions, we need
> to ensure that those files render correctly by placing the content
> directly into those files.  Then we can have project contributor
> documentation use the include directive to avoid duplicating the
> information elsewhere.
>

Doug, I think the include in Sphinx can be a raw txt file? Then we get the
best of both worlds - rendered on both docs.openstack.org and github.com.

I'll give that a shot with these patches as a proof of concept:

1. Change cookie-cutter file to CONTRIBUTING.txt
https://review.openstack.org/416109
2. Update openstack-manuals rendered docs with an included CONTRIBUTING.txt
https://review.openstack.org/416112

We won't really know the GitHub UI rendering of the include until merged,
but I've tested in other repos and changing the file extension to .txt
gives a link to that file.

Thoughts? Please comment on the reviews or here. I can work on it if we
think it's worthwhile to standardize upon, and/or collaborate with the
original contributor who wanted to standardize. I do believe the GitHub
experience is worthy of attention, similar in my mind to the recent badges
work.

Anne


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



-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

2017-01-02 Thread Jeffrey Zhang 
On Tue, Jan 3, 2017 at 6:23 AM, Clark Boylan  wrote:

> I don't have any answers but my first thought was maybe it is related to
> https://bugs.launchpad.net/nova/+bug/1643911; however, that affects
> libvirt 1.3.1 on Ubuntu Xenial and there is at least one instance of
> that occurring on a non Xen hypervisor so maybe they are not related.
>
​seems it is not related.​

>
> Also noticed that you appear to have two redundant sets of system logs
> in the Kolla centos job(s). See
> http://logs.openstack.org/80/415880/1/check/gate-kolla-
> dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_log/
> and
> http://logs.openstack.org/80/415880/1/check/gate-kolla-
> dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_logs/.
>

​yep. this is issue after split the kolla project into kolla-ansible and
kolla. will fix it later.​

>
> As for debugging this you may be able to install libvirt's debugging
> symbols
> (http://debuginfo.centos.org/7/x86_64/libvirt-debuginfo-2.
> 0.0-10.el7.x86_64.rpm),
> capture a core dump, load into gdb and go from there.
>
​I will try to install it and get more information.​




-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

2017-01-02 Thread Steven Dake (stdake) 
I think optimally we should check if we are running in rax-iad, and if so, set 
libvirt virtualization to qemu.  I was pretty sure the gate script that sets up 
the system sets the libvirt type to qemu.  After inspection of the gate 
scripts, this is not the case.  Perhaps it was setup this way previously and 
someone changed it.

This explains why rax gates have been so flakey for a very long time when 
running the deploy jobs.

Regards,
-steve


From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, January 2, 2017 at 3:37 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during 
launching qemu progress

XEN doesn't work well with nested kvm. We need to change nova config to pure 
qemu without kvm. I thought we did that in gates?

On Jan 2, 2017 2:25 PM, "Clark Boylan" 
> wrote:
On Sun, Jan 1, 2017, at 09:13 PM, Jeffrey Zhang wrote:
> Checked more failed gate, here is the more info:
>
> 1. only rax-iad has such issue
> 2. the failed and successful gates have the same rpm installed.
>
> So the only difference between failed gate and successful gate is the xen
> hypervisor.

I don't have any answers but my first thought was maybe it is related to
https://bugs.launchpad.net/nova/+bug/1643911; however, that affects
libvirt 1.3.1 on Ubuntu Xenial and there is at least one instance of
that occurring on a non Xen hypervisor so maybe they are not related.

Also noticed that you appear to have two redundant sets of system logs
in the Kolla centos job(s). See
http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_log/
and
http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_logs/.

As for debugging this you may be able to install libvirt's debugging
symbols
(http://debuginfo.centos.org/7/x86_64/libvirt-debuginfo-2.0.0-10.el7.x86_64.rpm),
capture a core dump, load into gdb and go from there.

Clark

__
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] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

2017-01-02 Thread Jeffrey Zhang 
On Tue, Jan 3, 2017 at 6:37 AM, Michał Jastrzębski  wrote:

> XEN doesn't work well with nested kvm. We need to change nova config to
> pure qemu without kvm. I thought we did that in gates?


​In the gate, kolla is using qemu all the time[0]. So this should be not
related.

[0]
http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/kolla_configs/nova-compute/nova.conf.txt.gz
 ​



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [legal-discuss] [kolla]is it OK to modify python code in OpenStack project?

2017-01-02 Thread Jeffrey Zhang 
Thanks all guys.

Copy python code is really a bad idea. Now i have moved to re-use
oslo.config iniparser[0][1], which works too. So we have no license issue,
now. ;)

[0]
https://github.com/openstack/oslo.config/blob/master/oslo_config/iniparser.py
[1]
https://review.openstack.org/#/c/412101/5/ansible/action_plugins/merge_configs.py


On Tue, Jan 3, 2017 at 1:04 AM, Van Lindberg 
wrote:

> Thierry is correct in his analysis.
>
>
> If you really want to copy it - which I don't suggest - then copy it over
> into your repo, rename both the module and the class, and make your code
> use your derived work.
>
>
> Put a header at the top that says something like "Based on Python's
> ConfigParser.py. Original ConfigParser.py distributed under the Python
> Software Foundation license. Additions and changes copyright [YOU] and
> distributed under the Apache Software License, v2."
>
>
> Do not modify the stdlib in-place (as it sounds like you are doing) - but
> perhaps I just misunderstand.
>
>
> --
> *From:* Thierry Carrez 
> *Sent:* Monday, January 2, 2017 4:45 AM
> *To:* legal-disc...@lists.openstack.org
> *Subject:* Re: [legal-discuss] [kolla]is it OK to modify python code in
> OpenStack project?
>
> Jeffrey Zhang wrote:
> > Recently, Kolla project has requirement to modify[1] the python's
> > ConfigParser.py code[0].
> >
> > Python is using PSF license[3], which is GPL compatible. But OpenStack
> > is using Apache License.
> >
> > Here is the diff view[2].
> >
> > I want to make sure: is it OK to re-license ConfigParser.py? If not, what
> > the solution?
> >
> > [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py
> > [1] https://review.openstack.org/412101
> > [2] https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da3
> 71/revisions?diff=split
> > [3] https://docs.python.org/3/license.html
>
> I'm not a lawyer, but it sounds slightly tricky.
>
> The PSF license is Apache-compatible, which means that you can combine
> PSF-licensed and Apache-licensed code (if you retain the original
> licenses). But OpenStack code must be licensed under a license supported
> by the Contributor License Agreement (CLA) which allows redistribution
> by the OpenStack Foundation under ASLv2 (currently only ASLv2, the MIT
> and both forms of the BSD license meet this requirement).
>
> So I don't think we can really bundle PSF-licensed code within OpenStack
> code, and I think too much was copied from the original class so that
> anyone can pretend it is original work.
>
> Three solutions that should work around the problem without requiring
> lawyers to further investigate the issue:
>
> 1/ Do a clean room implementation (by someone not familiar with the
> original code)
>
> 2/ Rewrite your code so that it takes a pure ConfigParser class output
> and transforms it into what you need, rather than copying code over
>
> 3/ Publish your modified ConfigParser into its own 3rd-party PyPI
> library (licensed under the PSF license)
>
> Of those, (2) is the one that introduces the less technical debt (no
> code copy).
>
> --
> Thierry Carrez (ttx)
>
> ___
> legal-discuss mailing list
> legal-disc...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
>
> ___
> legal-discuss mailing list
> legal-disc...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [infra][devstack-gate][all]support multi-region gate environment

2017-01-02 Thread joehuang 
Hello,

Currently only one region is supported in devstack-gate, there are lots of 
projects providing multi-region involved features, for example, heat 
multi-region, tacker multi-vim, shadow multi-cloud, tricircle networking across 
multi-region, kingbird resource sync and so on.

Thanks to the patch "Introduce roles into the feature matrix", it's possible to 
assign the sub-node in devstack-gate with a new role "subnode_multi_region", so 
that all services will start and share same keystone in the primary node, this 
is the typical devstack multi-region mode. One environment variable 
MULTI_REGION is introduced to enable the sub-node running as the second 
region(currently the first step is to setup two-node two-region environment).

One patch was prepared to enhance devstack-gate: 
https://review.openstack.org/#/c/412777/
And Tricircle will begin to try the multi-region gate/check job: 
https://review.openstack.org/#/c/414909/
The devstack plugin of Tricircle is also enhanced to support multi-region job: 
https://review.openstack.org/#/c/414860/

How do you think about this idea? It's basic requirement to have multi-region 
gate/check job for Tricricle, hope this could be on board before Ocata release. 
once Tricircle can be tested through such a multi-region job, other projects 
can also benefit from the same infrastructure.

Best Regards
Chaoyi Huang (joehuang)
__
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] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

2017-01-02 Thread Michał Jastrzębski 
XEN doesn't work well with nested kvm. We need to change nova config to
pure qemu without kvm. I thought we did that in gates?

On Jan 2, 2017 2:25 PM, "Clark Boylan"  wrote:

> On Sun, Jan 1, 2017, at 09:13 PM, Jeffrey Zhang wrote:
> > Checked more failed gate, here is the more info:
> >
> > 1. only rax-iad has such issue
> > 2. the failed and successful gates have the same rpm installed.
> >
> > So the only difference between failed gate and successful gate is the xen
> > hypervisor.
>
> I don't have any answers but my first thought was maybe it is related to
> https://bugs.launchpad.net/nova/+bug/1643911; however, that affects
> libvirt 1.3.1 on Ubuntu Xenial and there is at least one instance of
> that occurring on a non Xen hypervisor so maybe they are not related.
>
> Also noticed that you appear to have two redundant sets of system logs
> in the Kolla centos job(s). See
> http://logs.openstack.org/80/415880/1/check/gate-kolla-
> dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_log/
> and
> http://logs.openstack.org/80/415880/1/check/gate-kolla-
> dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_logs/.
>
> As for debugging this you may be able to install libvirt's debugging
> symbols
> (http://debuginfo.centos.org/7/x86_64/libvirt-debuginfo-2.
> 0.0-10.el7.x86_64.rpm),
> capture a core dump, load into gdb and go from there.
>
> Clark
>
> __
> 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] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

2017-01-02 Thread Clark Boylan 
On Sun, Jan 1, 2017, at 09:13 PM, Jeffrey Zhang wrote:
> Checked more failed gate, here is the more info:
> 
> 1. only rax-iad has such issue
> 2. the failed and successful gates have the same rpm installed.
> 
> So the only difference between failed gate and successful gate is the xen
> hypervisor.

I don't have any answers but my first thought was maybe it is related to
https://bugs.launchpad.net/nova/+bug/1643911; however, that affects
libvirt 1.3.1 on Ubuntu Xenial and there is at least one instance of
that occurring on a non Xen hypervisor so maybe they are not related.

Also noticed that you appear to have two redundant sets of system logs
in the Kolla centos job(s). See
http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_log/
and
http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_logs/.

As for debugging this you may be able to install libvirt's debugging
symbols
(http://debuginfo.centos.org/7/x86_64/libvirt-debuginfo-2.0.0-10.el7.x86_64.rpm),
capture a core dump, load into gdb and go from there.

Clark

__
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][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

2017-01-02 Thread Davanum Srinivas 
Folks,

Short Story :
[1] has merged in devstack, it adds support for a python 3.5 based
up/down devstack test that just starts services and brings them down.
see [2] for a test run.

Need help from swift folks:
Swift still needs work i have gotten as far as [3] UnpicklingError on
ring data using [4][5][6][7]. Can someone from the swift team pick
this up?
Once you get this working, please add "swift" to the white list in [8]
and remove the disable_service for swift services in [9]

Other teams:
Please consider adding DSVM jobs with USE_PYTHON3=True for your
projects. This will hopefully help us get to our Pike goal for Python
3.x [10]

Please stop by #openstack-python3 channel to chat.

Thanks,
Dims

[1] https://review.openstack.org/#/c/414176/
[2] 
http://logs.openstack.org/76/414176/11/check/gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv/
[3] 
http://logs.openstack.org/00/412500/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f5a7fe7/logs/screen-s-proxy.txt.gz
[4] https://review.openstack.org/#/c/412500/
[5] https://review.openstack.org/#/c/414727/
[6] https://review.openstack.org/#/c/416064/
[7] https://review.openstack.org/#/c/416084/
[8] https://review.openstack.org/#/c/414176/11/inc/python
[9] https://review.openstack.org/#/c/413775/5/jenkins/jobs/devstack-gate.yaml
[10] https://review.openstack.org/#/c/349069/

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

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

Re: [openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

2017-01-02 Thread Jay Pipes 

Great questions, Vlad. Comments inline.

On 12/30/2016 11:40 AM, Vladyslav Drok wrote:

Hi all!

There is a long standing problem of resources reporting in ironic virt
driver.


That would be an understatement :)

> It's described in a couple of bugs I've found - [0], [1].

Switching to placement API will make things better, but still there are
some problems there. For example, there are cases when ironic needs to
say "this node is not available", and it reports the
vcpus=memory_mb=local_gb as 0 in this case. Placement API does not allow
0s, so in [2] it is proposed to remove inventory records in this case.


Correct.


But the whole logic here [3] seems not that obvious to me, so I'd like
to discuss when do we need to report 0s to placement API. I'm thinking
about the following (copy-pasted from my comment on [2]):

  * If there is an instance_uuid on the node, no matter what
provision/power state it's in, consider the resources as used. In
case it's an orphan, an admin will need to take some manual action
anyway.


The single source of truth for Ironic instances is the Ironic database. 
If Ironic's database says that a node is consumed by an instance, then 
it should be considered by Nova to be consumed.



  * If there is no instance_uuid and a node is in cleaning/clean wait
after tear down, it is a part of normal node lifecycle, report all
resources as used. This means we need a way to determine if it's a
manual or automated clean.


I don't see a need to determine manual vs. automated clean. The node is 
in a clean state; therefore the inventory of resources on that node are 
not available for a consumer of those resources to consume. So, the 
inventory should be deleted in Nova. This inventory should be re-added 
if and when the node is in a state that a consumer can grab it.



  * If there is no instance_uuid, and a node:
  o has a bad power state or
  o is in maintenance
  o or actually in any other case, consider it unavailable, report
available resources = used resources = 0. Provision state does
not matter in this logic, all cases that we wanted to take into
account are described in the first two bullets.


Correct. If there is no instance UUID for the node, that means there's 
no allocation for it. If there's no allocation for the node, its 
inventory can and should be deleted if the node cannot be consumed by an 
instance (for whatever reason).


Best,
-jay


Any thoughts?

[0]. https://bugs.launchpad.net/nova/+bug/1402658
[1]. https://bugs.launchpad.net/nova/+bug/1637449
[2]. https://review.openstack.org/414214
[3]. 
https://github.com/openstack/nova/blob/1506c36b4446f6ba1487a2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262

Happy holidays to everyone!
-Vlad


__
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] [all] Adding CONTRIBUTING.rst files to projects

2017-01-02 Thread Doug Hellmann 
Excerpts from Paul Belanger's message of 2016-12-24 15:23:35 -0500:
> On Wed, Dec 21, 2016 at 10:17:42AM -0600, Ian Cordasco wrote:
> > -Original Message-
> > From: Andrey Kurilin 
> > Reply: OpenStack Development Mailing List (not for usage questions) 
> > 
> > Date: December 21, 2016 at 10:13:09
> > To: OpenStack Development Mailing List (not for usage questions) 
> > 
> > Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to 
> > projects
> > 
> > > On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger wrote:
> > >  
> > > > On 2016-12-21 16:22, Ian Cordasco wrote:
> > > > > [...]
> > > > > That said, I think there are two better places for this information
> > > > > that are already standards in OpenStack:
> > > > >
> > > > > * README.rst
> > > > > * HACKING.rst
> > > > >
> > > > > Most projects include links to the contributing documentation in at
> > > > > least one of these files. I think the effort here is to standardize,
> > > > > albeit in a brand new file, and that's admirable.
> > > >
> > > > If that's the goal - to standardize - then I would expect that we move
> > > > all the documentation out of those files in one place.
> > > >
> > > > Right now, the changes duplicate information that exists - and the new
> > > > information is often wrong. It points to place that do not exist or
> > > > where better places exist. ;(
> > > >
> > >  
> > > Duplication can be reduced by using `.. include:: ` directive.
> > 
> > That does not render anywhere except our documentation (via Sphinx). 
> > Git{Hub,Lab} don't render the include directive at all.
> > 
> > So, no, that's not an option.
> > 
> No, this is a valid option. We do it today with various documentation.
> 
> They will however render to docs.o.o, which we consider source of truth. The
> topic of rendering RST files to github has come up a few times, but each time
> comes back to the fact we simply mirror to github.
> 
> It is possible to have git.openstack.org render RST too, but we've opted to do
> it with docs.openstack.org.
> 

Using include works some places, but not others.

The include directive is a feature of Sphinx, not docutils. We use
Sphinx to convert reStructuredText to HTML for docs.o.o but github does
not use Sphinx when rendering individual reStructuredText files such as
CONTRIBUTING.rst or README.rst.

Since the point of having CONTRIBUTING.rst be a separate file is
to take advantage of the github.com integration to guide potential
contributors to the right forum for their contributions, we need
to ensure that those files render correctly by placing the content
directly into those files.  Then we can have project contributor
documentation use the include directive to avoid duplicating the
information elsewhere.

Doug

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

[openstack-dev] [cloudkitty] IRC Meeting

2017-01-02 Thread Christophe Sauthier 

Hello Fellow developers

The next meeting will be on Thursday 5th at 13:00 UTC on #cloudkitty.

We'll be discussing the state of the various developments we are doing 
for Ocata and the various points we have since our last meeting


You are really welcome to join if you have an interest on that !

All the best

 Christophe Sauthier, PTL of Cloudkitty


Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la Pause 
OpenStack

http://olib.re/pause-openstack


__
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][infra] All jobs broken,

2017-01-02 Thread Jeremy Stanley 
On 2016-12-29 12:08:35 +0100 (+0100), Andreas Jaeger wrote:
[...]
> Seems the machine (or network) healed itself and everything is fine again,

Yes, according to our service provider, a Nova hypervisor host
housing static.openstack.org (the instance which serves the
logs.openstack.org site) suffered some sort of outage. When they
restored the Nova host, our site returned to working order on its
own and our CI was once again able to successfully upload job logs.
-- 
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] [Ironic] Meeting for today cancelled

2017-01-02 Thread Julia Kreger 
Greetings everyone!

It seems everyone is still enjoying some well deserved time off and we have an 
insufficient number of participants awake and active in IRC today to justify a 
meeting today.  As such, we’ve reached the consensus in #openstack-ironic, of 
us who are active/awake, to cancel today’s meeting.

Have a wonderful day, and we will see everyone next week!

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

Re: [openstack-dev] [tripleo] [ci] recheck impact on CI infrastructure

2017-01-02 Thread Sven Anderson 
Hi Emilien and all,

On 16.12.2016 01:26, Emilien Macchi wrote:
> On Thu, Dec 15, 2016 at 12:22 PM, Sven Anderson  wrote:
>> Hi all,
>>
>> while I was waiting again for the CI to be fixed and didn't want to
>> torture it with additional rechecks, I wanted to find out, how much of
>> our CI infrastructure we waste with rechecks. My assumption was that
>> every recheck is a waste of resources based on a false negative, because
>> it renders the previous build useless. So I wrote a small script[1] to
>> calculate how many rechecks are made on average per built patch-set. It
>> calculates the number of patch-sets of merged changes that CI was
>> testing (some patch-sets are not, because they were updated before CI
>> started testing), the number of rechecks issued on these patch-sets, and
>> a value "CI-factor", which is the factor by which the rechecks increased
>> the the CI runs, that is, without rechecks it would be 1, if every
>> tested patch-set would have exactly one recheck it would be 2.
> 
> I see 2 different topics here.
> 
> # One is not related to $topic but still worth mentioning:
> "while I was waiting again for the CI to be fixed"
> 
> This week has been tough, and many of us burnt our time to resolve
> different complex problems in TripleO CI, mostly related to external
> dependencies (qemu upgrade, centos 7.3 upgrade, tripleo-ci infra,
> etc).
> Resolving these problems is very challenging and you'll notice that
> only a few of us actually work on this task, while a lot of people
> continue to push their features "hoping" that it will pass CI
> sometimes and if not, well, we'll do 'recheck'.
> That is a way of working I would say. I personally can't continue to
> code if the project I'm working on has broken CI.
> 
> In a previous experience, I've been working in a team where everyone
> stopped regular work when CI was broken and focus on fixing it.
> I'm not saying everyone should stop their tasks and help, but this
> "wait and see" comment doesn't actually help us to move forward.
> People need to get more involved in CI and be more helpful. I know
> it's difficult, but it's something anyone can learn, like you would
> learn how to write Python code for example.

I think you got my mail in the wrong way. I didn't want to say that
anyone is not doing it's job right and I didn't want to complain. I know
how challenging this is. In my previous job I was the person running the
CI (among other things). I just wanted to share the results, because I
think it's interesting how much percentage of our CI infrastructure is
"wasted" by rechecks, to on one hand raise awareness that we not just
blindly "recheck until verified", and on the other hand, how valuable it
is to keep CI stable.

Is it really the case that more CI people would help here? I would have
expected, as long as we don't do more modularized testing, that it
doesn't scale. Would more CI people fix the problems more quickly? Or is
it more like: the burden could be distributed on more shoulders, so not
always the same people have to interrupt their work? The second wouldn't
improve the situation but just spread the burden in a more fair manner.

With my post I mainly wanted to provide reliable data and emphasize how
important a stable CI and the work on this is, and that we all restrain
ourselves from blindly rechecking.


Happy New Year to everyone!

Sven

__
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] [swift]Connection error with swift mitaka version

2017-01-02 Thread Ajitha Robert 
Hi all,

We have installed swift(mitaka version). its able to authenticate with
keystone.. but couldnt process the request in swift side.. swift(proxy
server) is not accepting the request/token..


I got the following error when i give openstack container list


Starting new HTTP connection (1): swifthost

Unable to establish connection to
http://swifthost:8080/v1/AUTH_080e4cf4b97846fe846fd3f679d7f5a3

Traceback (most recent call last):

File "/usr/local/lib/python2.7/dist-packages/cliff/app.py", line 387, in
run_subcommand

result = cmd.run(parsed_args)

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/common/command.py",
line 38, in run

return super(Command, self).run(parsed_args)

File "/usr/local/lib/python2.7/dist-packages/cliff/display.py", line 100,
in run

column_names, data = self.take_action(parsed_args)

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/object/v1/container.py",
line 151, in take_action

**kwargs

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/api/object_store_v1.py",
line 124, in container_list

return self.list('', **params)

File "/usr/local/lib/python2.7/dist-packages/openstackclient/api/api.py",
line 197, in list

params=params,

File "/usr/local/lib/python2.7/dist-packages/openstackclient/api/api.py",
line 83, in _request

return session.request(url, method, **kwargs)

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/common/session.py",
line 40, in request

resp = super(TimingSession, self).request(url, method, **kwargs)

File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line
101, in inner

return wrapped(*args, **kwargs)

File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py",
line 555, in request

resp = send(**kwargs)

File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py",
line 599, in _send_request

raise exceptions.ConnectFailure(msg)

ConnectFailure: Unable to establish connection to
http://swifthost:8080/v1/AUTH_080e4cf4b97846fe846fd3f679d7f5a3

clean_up ListContainer: Unable to establish connection to
http://swifthost:8080/v1/AUTH_080e4cf4b97846fe846fd3f679d7f5a3

Traceback (most recent call last):

File "/usr/local/lib/python2.7/dist-packages/openstackclient/shell.py",
line 118, in run

ret_val = super(OpenStackShell, self).run(argv)

File "/usr/local/lib/python2.7/dist-packages/cliff/app.py", line 267, in run

result = self.run_subcommand(remainder)

File "/usr/local/lib/python2.7/dist-packages/openstackclient/shell.py",
line 153, in run_subcommand

ret_value = super(OpenStackShell, self).run_subcommand(argv)

File "/usr/local/lib/python2.7/dist-packages/cliff/app.py", line 387, in
run_subcommand

result = cmd.run(parsed_args)

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/common/command.py",
line 38, in run

return super(Command, self).run(parsed_args)

File "/usr/local/lib/python2.7/dist-packages/cliff/display.py", line 100,
in run

column_names, data = self.take_action(parsed_args)

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/object/v1/container.py",
line 151, in take_action

**kwargs

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/api/object_store_v1.py",
line 124, in container_list

return self.list('', **params)

File "/usr/local/lib/python2.7/dist-packages/openstackclient/api/api.py",
line 197, in list

params=params,

File "/usr/local/lib/python2.7/dist-packages/openstackclient/api/api.py",
line 83, in _request

return session.request(url, method, **kwargs)

File
"/usr/local/lib/python2.7/dist-packages/openstackclient/common/session.py",
line 40, in request

resp = super(TimingSession, self).request(url, method, **kwargs)

File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line
101, in inner

return wrapped(*args, **kwargs)

File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py",
line 555, in request

resp = send(**kwargs)

File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py",
line 599, in _send_request

raise exceptions.ConnectFailure(msg)

ConnectFailure: Unable to establish connection to
http://swifthost:8080/v1/AUTH_080e4cf4b97846fe846fd3f679d7f5a3


END return value: 1




Also my swift.log always throwing 404 error which follows

Jan 2 19:05:12 swifthost2 proxy-server: 10.208.252.2 10.208.252.2
02/Jan/2017/13/35/12 OPTIONS / HTTP/1.0 404 - - - - 70 -
tx333cbe62e4234c8aa7abc-00586a5710 - 0.0015 - - 1483364112.814496994
1483364112.816014051 -

Jan 2 19:05:12 swifthost2 proxy-server: 10.208.252.2 10.208.252.2
02/Jan/2017/13/35/12 OPTIONS / HTTP/1.0 404 - - - - 70 -
tx410e29ac554c4d6bbb7ea-00586a5710 - 0.0016 - - 1483364112.815314054
1483364112.816864967 -

Jan 2 19:05:14 swifthost2 object-auditor: Begin object audit "forever" mode
(ZBF)

Jan 2 19:05:14 swifthost2 object-auditor: Object audit (ZBF) "forever" mode
completed: 0.00s. Total quarantined: 0, Total errors: 0, Total files/sec:
0.00, Total bytes/sec: 0.00, Auditing time: 0.00, Rate: 0.00

Jan 2

[openstack-dev] [pbr] py35 gate broken

2017-01-02 Thread Julien Danjou 
Hi,

It seems the gate for Python 3.5/3.6 for pbr is broken:

  http://logs.openstack.org/95/413795/2/gate/gate-pbr-python35/68b2053/

As anyone looked into it yet?

I'm volunteering but I don't want to step on someone else's foot.

Cheers,
-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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] Overlay network installation support using networking-ovn(devstack) guide.

2017-01-02 Thread pranab boruah 
Hello folks,
We are newbies, trying to deploy a multi-node OpenStack (networking-ovn)
set-up for dev purposes. Requirements are:
1) version : Newton
2) CentOS7.2
3) Different networks for Management and Overlay tunnel networks.
4) Prefer a reliable deployment tool out there.

Followed the official guide :
http://docs.openstack.org/developer/networking-ovn/testing.html

The above guide uses DevStack and installs everything(management and
overlay) in a single network.

My question is, how to modify the localrc file on the individual nodes to
get what I need?
Please share if you know are any other online sources that meets our
requirements, it will be extremely helpful.

Happy New Year!!

Thanks,
Pranab
__
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] [tc] Re: [kolla] A new kolla-salt deliverable

2017-01-02 Thread Thierry Carrez 
Michał Jastrzębski wrote:
> I agree this would make good PTG discussion for us, and maybe someone
> from TC could join in. We are somehow special beast as Kolla itself is
> just meant to be consumed. Kolla to me is similar to Oslo in that
> matter. But still we don't have oslo-compute projects, we have nova,
> but we would have kolla-salt, even tho core teams would be totally
> different potentially. As Britt said, growing pains.

Happy to join in any discussion at the PTG on that topic.

As far as our governance is concerned, "teams" decide what git
repositories they vouch for -- the team's opinion being represented by
the PTL. Each team is of course free to add more complex ways of
gathering the "team's opinion" :)

Cheers,

-- 
Thierry Carrez (ttx)

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

2017-01-02 Thread Sanjana Pai Nagarmat 
Hello,


I have a clean install of monasca-api and monasca-log-management plugins with 
devstack on ubuntu 14.04.
However when I try using the monasca CLI, I get HTTP 503:Service Unavailable 
error.
I tried accessing the monasca dashboard in Horizon, but that also throws error.

ubuntu@monasca:~$ monasca metric-list
ERROR (exc:80) exception: {"message": "The server is currently unavailable. 
Please try again at a later time.\n\n\n", "code": "503 Service 
Unavailable", "title": "Service Unavailable"}
HTTPException code=503 message={"message": "The server is currently 
unavailable. Please try again at a later time.\n\n\n", "code": "503 
Service Unavailable", "title": "Service Unavailable"}
ubuntu@monasca:~$


The monasca-api log file has the following contents:
2017-01-02 08:15:20,158 DEBUG [gunicorn.error][GreenThread-2] Closing 
connection.
2017-01-02 08:15:24,952 DEBUG [gunicorn.error][GreenThread-5] GET /v2.0/metrics
2017-01-02 08:15:24,954 DEBUG [keystonemiddleware.auth_token][GreenThread-5] 
Authenticating user token
2017-01-02 08:15:24,957 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:24,964 INFO 
[requests.packages.urllib3.connectionpool][GreenThread-5] Resetting dropped 
connection: 127.0.0.1
2017-01-02 08:15:27,342 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,343 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,345 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,346 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,346 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Retrying validation
2017-01-02 08:15:27,347 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:27,535 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,536 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,536 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,536 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,536 CRITICAL [keystonemiddleware.auth_token][GreenThread-5] 
Unable to validate token: Identity server rejected authorization necessary to 
fetch token data
2017-01-02 08:15:27,539 DEBUG [gunicorn.error][GreenThread-5] Closing 
connection.


Further the AUTH_URL is set
ubuntu@monasca:/var/log/monasca/api$ echo $OS_AUTH_URL
http://127.0.0.1:35357/v3/

I would like to mention the status of services:
ubuntu@monasca:~$ sudo service monasca-log-api status
monasca-log-api start/running, process 7938

ubuntu@monasca:~$ sudo service monasca-api status
monasca-api start/running, process 21465

ubuntu@monasca:~/devstack$ keystone service list
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
+--+-++
| ID   | Name| Type   |
+--+-++
| 301f29e503c845828ce4a24d61924ded | cinderv3| volumev3   |
| 36ee63e1df644d4780cc2f16e93bc379 | monasca | monitoring |
| 448e665048314cc2af41bbfc99bdf7af | cinderv2| volumev2   |
| 68db6f5f85be4007b0c6550b3fd8468e | neutron | network|
| 7b9313963b094fa0986016adbd6b92fd | cinder  | volume |
| 7fccd72315ba4f6cbd400274054a5c88 | keystone| identity   |
| 8cd5c25a911e468797bad4d709ff1adf | glance  | image  |
| b4c2a0986f674a93b7636d18ef4e81cb | nova| compute|
| f19e24d3633141c4892d10cdead98f20 | nova_legacy | compute_legacy |
+--+-++

Please let me know how I can fix this issue. I want to use monasca logging 
service for my openstack environment.
Thanks in advance.



--Sanjana





__
OpenStack Development Mailing List

Re: [openstack-dev] [heat] project specific question for the next user survey

2017-01-02 Thread Gary Kotton 
Hi,
Are there any questions related to Terraform? Is this affecting Heat in some 
way or form? Or just an alternative?
Thanks
Gary

From: Rabi Mishra 
Reply-To: OpenStack List 
Date: Monday, January 2, 2017 at 6:18 AM
To: OpenStack List 
Subject: [openstack-dev] [heat] project specific question for the next user 
survey

Hi All,

We have an opportunity to submit a heat adoption related question (for those 
who are USING, TESTING, or INTERESTED in heat) to be included in the User 
Survey.

Please provide your suggestions/questions.The deadline for this is 9th Jan.

--
Regards,
Rabi Misra

__
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