Re: [openstack-dev] [Mistral] Propose Winson Chan m4dcoder for core team

[Renat Akhmerov]

Congratulations Winson! You’re now a core member of Mistral. Welcome )

Cheers

Renat Akhmerov
@ Mirantis Inc.



> On 07 Apr 2015, at 19:28, Anastasia Kuznetsova  
> wrote:
> 
> Hello all,
> 
> As a QA Engineer of Mistral, I also appreciate Winson's contribution to the 
> project, his ideas and I will be glad to see him as a core engineer of 
> Mistral project.
> 
> On Tue, Apr 7, 2015 at 12:56 PM, Lingxian Kong  > wrote:
> Although I have jumpped into Mistral just for a short time, but really
> appreciate Winson's vision about my patches, and his work is of great
> value to Mistral.
> 
> I'm not in the core team of Mistral, but really hope to see Winson as
> a core member to bring more to Mistral.
> 
> On Tue, Apr 7, 2015 at 5:08 PM, Nikolay Makhotkin
> mailto:nmakhot...@mirantis.com>> wrote:
> > It would be good to see Winson as the core contributor in Mistral.
> >
> > +1 for Winson!
> >
> >
> >
> > On Tue, Apr 7, 2015 at 11:53 AM, Renat Akhmerov  > >
> > wrote:
> >>
> >> +1 with my both hands. Winson has been working on Mistral for about a
> >> year, was actively participating in the very first workflow engine version
> >> (what we called PoC) and keeps bringing his experience and excellent
> >> engineering skills to the project.
> >>
> >> Thanks Winson for your passionate work!
> >>
> >> Renat Akhmerov
> >> @ Mirantis Inc.
> >>
> >>
> >>
> >> > On 07 Apr 2015, at 03:04, Dmitri Zimine  >> > > wrote:
> >> >
> >> > Hi folks,
> >> >
> >> > I’d like to propose Winson Chan (m4dcoder) to become Mistral core team
> >> > member.
> >> >
> >> > Winson brings unique mix of field experience implementing Mistral
> >> > workflows in user environments, and solid development skills.
> >> >
> >> > He has been contributing to Mistral since Mar 2014. Winson did a 23
> >> > commits - a number of them are non-trivial, like moving RPC to
> >> > oslo-messaging, or introducing environments, or making full validation. 
> >> > He
> >> > has submitted 14 blueprints and detailed design proposals, contributing 
> >> > to
> >> > design and directions. He found, reported, and fixed bugs. He is becoming
> >> > more active on the review board (would encourage to do more).
> >> >
> >> > I am +1 for m4dcoder as a core team member.
> >> >
> >> > DZ.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > __
> >> > 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 
> >> 
> >
> >
> >
> >
> > --
> > Best Regards,
> > Nikolay
> >
> > __
> > 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 
> > 
> >
> 
> 
> 
> --
> Regards!
> ---
> Lingxian Kong
> 
> __
> 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 
> 
> 
> 
> 
> -- 
> Best regards,
> Anastasia Kuznetsova
> __
> 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] [Keystone] Core Reviewer Update

[Chen, Wei D]

Congrats Lin Hua for being a dual-cores role, well deserved!



Best Regards,

Dave Chen



From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
Sent: Wednesday, April 08, 2015 6:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Keystone] Core Reviewer Update



I am pleased to announce that Lin Hua Cheng has joined the Keystone Core 
Reviewer team. He has been extremely helpful and active in 
reviewing Keystone code changes throughout a number of previous development 
cycle. Lin is also a member of Horizon Core which should 
help provide a strong view on the user experience of the Keystone APIs (and 
visualizations thereof).



Cheers,

--Morgan



smime.p7s
Description: S/MIME cryptographic 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] In loving memory of Chris Yeoh

[GHANSHYAM MANN]

:( I am shocked to my core. He was so humble and helpful always. It would
be very hard to believe that he is no more.

God rest his soul in peace.


On Wed, Apr 8, 2015 at 1:49 PM, Michael Still  wrote:

> It is my sad duty to inform the community that Chris Yeoh passed away this
> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will
> remember Chris as the clever and caring person that I will remember him as.
> I haven't had a chance to confirm with the family if they want flowers or a
> donation to a charity. As soon as I know those details I will reply to this
> email.
>
> Chris worked on open source for a very long time, with OpenStack being
> just the most recent in a long chain of contributions. He worked tirelessly
> on his contributions to Nova, including mentoring other developers. He was
> dedicated to the cause, with a strong vision of what OpenStack could
> become. He even named his cat after the project.
>
> Chris might be the only person to have ever sent an email to his coworkers
> explaining what his code review strategy would be after brain surgery. It
> takes phenomenal strength to carry on in the face of that kind of
> adversity, but somehow he did. Frankly, I think I would have just sat on
> the beach.
>
> Chris was also a contributor to the Linux Standards Base (LSB), where he
> helped improve the consistency and interoperability between Linux
> distributions. He ran the 'Hackfest' programming contests for a number of
> years at Australia's open source conference -- linux.conf.au. He
> supported local Linux user groups in South Australia and Canberra,
> including involvement at installfests and speaking at local meetups. He
> competed in a programming challenge called Loki Hack, and beat out the
> world to win the event[1].
>
> Alyssa's memories of her dad need to last her a long time, so we've
> decided to try and collect some fond memories of Chris to help her along
> the way. If you feel comfortable doing so, please contribute a memory or
> two at
> https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform
>
> Chris was humble, helpful and honest. The OpenStack and broader Open
> Source communities are poorer for his passing.
>
> Michael
>
> [1] http://www.lokigames.com/hack/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks & Regards
Ghanshyam Mann
__
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] [qa][nova][ironic] How to run microversions tests on the gate

[Dmitry Tantsur]

On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:

Hi,

Now Nova and Ironic have implemented API microversions in Kilo.
Nova's microversions are v2.1 - v2.3.
Ironic's microversions are v1.1 - v1.6.

Now Tempest is testing the lowest microversion on the gate, and
Ironic's microversions test patch[1] is on the gerrit.
Before merging the patch, I'd like to propose consistent test way for
microversions of Nova and Ironic.

My suggestion is the test target microversions are:
* the lowest microversion
* the biggest microversion, but don't use the keyword "latest" on a
header and these microversions tests are operated on different gate
jobs.

The lowest microversion is already tested on check-tempest-dsvm-full
or something, so this proposes just to add the biggest microversion
job like check-tempest-dsvm-full-big-microversion.

[background]
In long-term, these microversions continue increasing and it is
difficult to run Tempest for all microversions on the gate because of
test workload. So I feel we need to select microversions which are
tested on the gate for efficient testing.

[the lowest microversion]
On microversion mechanism, if a client *doesn't* specify favorite
microversion in its request header, a Nova/Ironic server considers the
request as the lowest microversion. So the lowest microversion is
default behavior and important. I think we need to test it at least.

[the biggest microversion]
On microversion mechanism, if a client specify the keyword "latest" in
its request header instead of microversion, a Nova/Ironic server works
on the biggest microversion behavior.
During the development, there is time lag between each project dev and
Tempest dev. After adding a new API on a project, corresponding tests
are added to Tempest in most cases. So if specifying the keyword
"latest", Tempest would not handle the request/response and fail,
because Tempest can not catch the latest API changes until
corresponding Tempest patch is merged.
So it is necessary to have the target microversion config option in
Tempest and pass specific biggest microversion to Tempest with
openstack-infra/project-config.

Any thoughts?


Hi! I've already stated this point in #openstack-ironic and I'd like to 
reiterate: if we test only the lowest and the highest microversions 
essentially means (or at least might mean) that the other are broken. At 
least in Ironic only some unit tests actually touch code paths for 
versions 1.2-1.5. As we really can't test too many versions, I suggest 
we stop producing a microversion for every API feature feature change in 
L. No idea what to do with 1.2-1.5 now except for politely asking people 
not to use them :D




Thanks
Ken Ohmichi
---
[1]: https://review.openstack.org/#/c/166386/

__
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] In loving memory of Chris Yeoh

[Ken'ichi Ohmichi]

2015-04-08 13:49 GMT+09:00 Michael Still :
> It is my sad duty to inform the community that Chris Yeoh passed away this
> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will
> remember Chris as the clever and caring person that I will remember him as.
> I haven’t had a chance to confirm with the family if they want flowers or a
> donation to a charity. As soon as I know those details I will reply to this
> email.
>
> Chris worked on open source for a very long time, with OpenStack being just
> the most recent in a long chain of contributions. He worked tirelessly on
> his contributions to Nova, including mentoring other developers. He was
> dedicated to the cause, with a strong vision of what OpenStack could become.
> He even named his cat after the project.
>
> Chris might be the only person to have ever sent an email to his coworkers
> explaining what his code review strategy would be after brain surgery. It
> takes phenomenal strength to carry on in the face of that kind of adversity,
> but somehow he did. Frankly, I think I would have just sat on the beach.
>
> Chris was also a contributor to the Linux Standards Base (LSB), where he
> helped improve the consistency and interoperability between Linux
> distributions. He ran the ‘Hackfest’ programming contests for a number of
> years at Australia’s open source conference -- linux.conf.au. He supported
> local Linux user groups in South Australia and Canberra, including
> involvement at installfests and speaking at local meetups. He competed in a
> programming challenge called Loki Hack, and beat out the world to win the
> event[1].
>
> Alyssa’s memories of her dad need to last her a long time, so we’ve decided
> to try and collect some fond memories of Chris to help her along the way. If
> you feel comfortable doing so, please contribute a memory or two at
> https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform
>
> Chris was humble, helpful and honest. The OpenStack and broader Open Source
> communities are poorer for his passing.
>
> Michael
>
> [1] http://www.lokigames.com/hack/
>

It is difficult to believe that. He always helped the other developers
and many people were around him.
His contribution was not only Nova but also Tempest. He improved
quality of whole OpenStack projects through Tempest work, that was
really great.

May his soul rest in peace.

Ken Ohmichi

__
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] [sahara] Sahara + Cinder use cases?

[Daniele Venzano]

Hello,

Did you have any success in finding Sahara and Cinder use cases?

Using Cinder one loses the data locality property around which hadoop and hdfs 
are built, so I am curious of what benefits there are in such a configuration.

Thanks,
Daniele

-Original Message-
From: Jacob Liberman [mailto:jlibe...@redhat.com] 
Sent: Tuesday 24 March 2015 19:34
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [sahara] Sahara + Cinder use cases?

Hi,

I am working on a Sahara doc bug:
 https://bugs.launchpad.net/sahara/+bug/1371360
 [DOC] Features overview suggests Cinders to increase reliability

I am doing some research for this update.  What are the use cases for Sahara + 
Cinder?

 1. Cinder-backed Sahara for persistent data
 2. Booting Sahara instances from Cinder volumes

Can option #1 be used in conjunction with existing plugin images?

Are there any docs on using Cinder volumes in place of ephemeral?

(similar to the docs describing how to use Swift-backed EDP)

The Cinder integration test mounts a few volumes to instances but does not use 
them.

Thanks,

Jacob

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


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

[openstack-dev] [nova] [scheduler] select_destinations() behavior

[Lisa Zangrando]

Dear all,

just a question about the behavior of select_destinations() in Icehouse: 
this method has to select and consume resources or just select them 
without consuming?
I'm asking you because if I invoke such method for testing the resource 
availability and only when the result is OK I call run_instance(), the 
scheduler's filters see a wrong host state (e.g. wrong vcpus_used). This 
is because both methods use _schedule() which consumes resources 
(chosen_host.obj.consume_from_instance(instance_properties)).


Is this feature intentional?

Thanks in advance.
cheers,
Lisa



__
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-lbaas][tempest] tempest v2 API negative tests to be skipped

[santosh sharma]

Please find details at
https://bugs.launchpad.net/neutron/+bug/1441512

Tempest v2 api negative tests for invalid or empty tenantid fails as tenant
id is not validated at plugin layer.

1. In Case of looging noop driver (no validation is done by driver ) ,
In test , create returns success whereas it excepts BadRequest.

0}
neutron_lbaas.tests.tempest.v2.api.test_members.MemberTestJSON.test_create_member_empty_tenant_id
[0.590837s] ... FAILED

Captured traceback:
~~~
Traceback (most recent call last):
  File "neutron_lbaas/tests/tempest/v2/api/test_members.py", line 244,
in test_create_member_empty_tenant_id
self.pool_id, **member_opts)
  File
"/opt/stack/neutron-lbaas/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
line 422, in assertRaises
self.assertThat(our_callable, matcher)
  File
"/opt/stack/neutron-lbaas/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
line 435, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: > returned
{u'protocol_port': 80, u'weight': 1, u'admin_state_up': True, u'subnet_id':
u'e20c013e-33d0-4752-883d-b78bd45ef0ea', u'tenant_id': u'', u'address':
u'127.0.0.1', u'id': u'3f8d811f-ab69-44f8-ae18-8fc20a94b228'}

2.In case of if Backend Driver (Say NetScaler) ,driver is raising
BadRequest .
==
   return self._callable_object(*self._args, **self._kwargs)
  File "neutron_lbaas/tests/tempest/v2/api/base.py", line 252, in
_create_member
member = cls.members_client.create_member(pool_id, **member_kwargs)
  File "neutron_lbaas/tests/tempest/v2/clients/members_client.py", line
51, in create_member
resp, body = self.post(url, post_body)
  File
"/opt/stack/neutron-lbaas/.tox/tempest/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py",
line 252, in post
return self.request('POST', url, extra_headers, headers, body)
  File
"/opt/stack/neutron-lbaas/.tox/tempest/src/tempest/tempest/common/service_client.py",
line 83, in request
raise exceptions.ServerFault(ex)
tempest.exceptions.ServerFault: Got server fault
Details: Got server fault
Details: An error happened in the driver
===

Above behavior is observed as ,at plugin layer all Exceptions from Driver
is raised as same Driver Exception.

plugin.y
 def _call_driver_operation(self, context, driver_method, db_entity,
   old_db_entity=None):
manager_method = "%s.%s" %
(driver_method.__self__.__class__.__name__,
driver_method.__name__)
LOG.info(_LI("Calling driver operation %s") % manager_method)
try:
if old_db_entity:
driver_method(context, old_db_entity, db_entity)
else:
driver_method(context, db_entity)
# catching and reraising agent issues
except (lbaas_agentschedulerv2.NoEligibleLbaasAgent,
lbaas_agentschedulerv2.NoActiveLbaasAgent) as no_agent:
raise no_agent
except Exception:
LOG.exception(_LE("There was an error in the driver"))
self._handle_driver_error(context, db_entity)
raise loadbalancerv2.DriverError() #<-- bad request
is raised as Driver Error

Negative Testcases:-

test_create_listener_invalid_tenant_id()
test_create_listener_invalid_empty_tenant_id()
test_create_member_invalid_tenant_id()
test_create_member_empty_tenant_id()


-- 
Santosh
__
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] In loving memory of Chris Yeoh

[Alex Xu]

Feel very sad. Just few weeks ago, I still saw him active on the community.
Really hard believe this happen such suddenly.

He was my leader in IBM and mentored me on the openstack community also,
offered lots of help without reservation, really
learn a lot from him.  We have phone call meeting every morning before, he
always sounds happy and enthusiastic even after
he got health problem.

May his soul rest in peace.

2015-04-08 12:49 GMT+08:00 Michael Still :

> It is my sad duty to inform the community that Chris Yeoh passed away this
> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will
> remember Chris as the clever and caring person that I will remember him as.
> I haven’t had a chance to confirm with the family if they want flowers or a
> donation to a charity. As soon as I know those details I will reply to this
> email.
>
> Chris worked on open source for a very long time, with OpenStack being
> just the most recent in a long chain of contributions. He worked tirelessly
> on his contributions to Nova, including mentoring other developers. He was
> dedicated to the cause, with a strong vision of what OpenStack could
> become. He even named his cat after the project.
>
> Chris might be the only person to have ever sent an email to his coworkers
> explaining what his code review strategy would be after brain surgery. It
> takes phenomenal strength to carry on in the face of that kind of
> adversity, but somehow he did. Frankly, I think I would have just sat on
> the beach.
>
> Chris was also a contributor to the Linux Standards Base (LSB), where he
> helped improve the consistency and interoperability between Linux
> distributions. He ran the ‘Hackfest’ programming contests for a number of
> years at Australia’s open source conference -- linux.conf.au. He
> supported local Linux user groups in South Australia and Canberra,
> including involvement at installfests and speaking at local meetups. He
> competed in a programming challenge called Loki Hack, and beat out the
> world to win the event[1].
>
> Alyssa’s memories of her dad need to last her a long time, so we’ve
> decided to try and collect some fond memories of Chris to help her along
> the way. If you feel comfortable doing so, please contribute a memory or
> two at
> https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform
>
> Chris was humble, helpful and honest. The OpenStack and broader Open
> Source communities are poorer for his passing.
>
> Michael
>
> [1] http://www.lokigames.com/hack/
>
> __
> 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] In loving memory of Chris Yeoh

[Day, Phil]

Thanks for letting us know Michael,  and thanks for doing it in such a moving 
way.Sad news indeed

Phil


From: Michael Still [mailto:mi...@stillhq.com]
Sent: 08 April 2015 05:49
To: OpenStack Development Mailing List
Subject: [openstack-dev] In loving memory of Chris Yeoh


It is my sad duty to inform the community that Chris Yeoh passed away this 
morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will 
remember Chris as the clever and caring person that I will remember him as. I 
haven’t had a chance to confirm with the family if they want flowers or a 
donation to a charity. As soon as I know those details I will reply to this 
email.

Chris worked on open source for a very long time, with OpenStack being just the 
most recent in a long chain of contributions. He worked tirelessly on his 
contributions to Nova, including mentoring other developers. He was dedicated 
to the cause, with a strong vision of what OpenStack could become. He even 
named his cat after the project.

Chris might be the only person to have ever sent an email to his coworkers 
explaining what his code review strategy would be after brain surgery. It takes 
phenomenal strength to carry on in the face of that kind of adversity, but 
somehow he did. Frankly, I think I would have just sat on the beach.

Chris was also a contributor to the Linux Standards Base (LSB), where he helped 
improve the consistency and interoperability between Linux distributions. He 
ran the ‘Hackfest’ programming contests for a number of years at Australia’s 
open source conference -- linux.conf.au. He supported 
local Linux user groups in South Australia and Canberra, including involvement 
at installfests and speaking at local meetups. He competed in a programming 
challenge called Loki Hack, and beat out the world to win the event[1].

Alyssa’s memories of her dad need to last her a long time, so we’ve decided to 
try and collect some fond memories of Chris to help her along the way. If you 
feel comfortable doing so, please contribute a memory or two at 
https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform

Chris was humble, helpful and honest. The OpenStack and broader Open Source 
communities are poorer for his passing.

Michael

[1] http://www.lokigames.com/hack/
__
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] Mellanox request for permission for Nova CI

[Lenny Verkhovsky]

Sean, Matt,
Is there anything missing for us to start 'non-voting' Nova CI ?
Thanks.


Lenny Verkhovsky
SW Engineer,  Mellanox Technologies
www.mellanox.com 

Office:+972 74 712 9244
Mobile:  +972 54 554 0233
Fax:+972 72 257 9400

-Original Message-
From: Michael Still [mailto:mi...@stillhq.com] 
Sent: Wednesday, April 01, 2015 11:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Mellanox request for permission for Nova CI

This looks good to me, but it would be interesting to see what Sean or Matt 
thought.

Michael

On Thu, Apr 2, 2015 at 3:25 AM, Joe Gordon  wrote:
>
>
> On Wed, Apr 1, 2015 at 8:28 AM, Lenny Verkhovsky 
> wrote:
>>
>>
>>
>> Hi all,
>>
>>
>>
>> We had some issues with presentation of the logs, now it looks ok.
>>
>>
>>
>> You can see Nova CI logs here
>> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20
>> 150401_1102/
>>
>> Tempest output is
>> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20
>> 150401_1102/testr_results.html.gz
>>
>>
>>
>> We are currently running tempest api tests on Mellanox HW using SRiOV 
>> configuration,
>>
>> We are working to add tempest scenario tests with port direct 
>> configuration for SRiOV
>>
>> We are also planning to extend tests with our in-house tests developments.
>
>
> Thanks, that looks a lot better. I would like to get a second opinion 
> from another nova-core but this looks like enough to start commenting 
> on nova patches.
>
>>
>>
>>
>>
>>
>>
>>
>> Lenny Verkhovsky
>>
>> SW Engineer,  Mellanox Technologies
>>
>> www.mellanox.com
>>
>>
>>
>> Office:+972 74 712 9244
>>
>> Mobile:  +972 54 554 0233
>>
>> Fax:+972 72 257 9400
>>
>>
>>
>> From: Joe Gordon [mailto:joe.gord...@gmail.com]
>> Sent: Thursday, March 26, 2015 3:29 PM
>>
>>
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] Mellanox request for permission for Nova 
>> CI
>>
>>
>>
>>
>>
>> On Thu, Mar 19, 2015 at 5:52 AM, Nurit Vilosny 
>> wrote:
>>
>> Hi Joe,
>>
>> Sorry for the late response.
>>
>> Here are some latest logs for the Nova CI:
>>
>>
>> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20
>> 150318_1650/
>>
>>
>> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20
>> 150318_1506/
>>
>>
>> http://144.76.193.39/ci-artifacts/37/165437/1/check-nova/Check-MLNX-N
>> ova-ML2-Sriov-driver/e90a677/
>>
>>
>> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20
>> 150318_1851/
>>
>>
>>
>>
>>
>> I couldn't find the equivalent of:
>> http://logs.openstack.org/68/135768/9/check/check-tempest-dsvm-full/f
>> 6c95de/logs/testr_results.html.gz
>>
>>
>>
>> Also what tests are running and how do they actually check if sriov works?
>>
>>
>>
>> I can provide more if needed.
>>
>>
>>
>> Thanks,
>>
>> Nurit.
>>
>>
>>
>> From: Joe Gordon [mailto:joe.gord...@gmail.com]
>> Sent: Wednesday, March 11, 2015 7:50 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] Mellanox request for permission for Nova 
>> CI
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 11, 2015 at 12:49 AM, Nurit Vilosny 
>> wrote:
>>
>> Hi ,
>>
>> I would like to ask for a CI permission to start commenting on Nova 
>> branch.
>>
>> Mellanox is engaged in pci pass-through features for quite some time now.
>>
>> We have an operating Neutron CI for  ~2 years, and since the pci 
>> pass-through features are part of Nova as well, we would like to 
>> start monitoring Nova’s patches.
>>
>> Our CI had been silently running locally over the past couple of 
>> weeks, and I would like to step ahead, and start commenting in a non-voting 
>> mode.
>>
>> During this period we will be closely monitor our systems and be 
>> ready to solve any problem that might occur.
>>
>>
>>
>> Do you have a link to the output of your testing system, so we can 
>> check what its testing etc.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Nurit Vilosny
>>
>> SW Cloud Solutions Manager
>>
>>
>>
>> Mellanox Technologies
>>
>> 13 Zarchin St. Raanana, Israel
>>
>> Office: 972-74-712-9410
>>
>> Cell: 972-54-4713000
>>
>> Fax: 972-74-712-9111
>>
>>
>>
>>
>>
>>
>> _
>> _ 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: 
>> open

Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group

[Daniel Comnea]

Thanks Angus for feedback.

Best,
Dani

On Mon, Apr 6, 2015 at 11:30 PM, Angus Salkeld 
wrote:

>
> On Fri, Apr 3, 2015 at 8:51 PM, Daniel Comnea 
> wrote:
>
>> Hi all,
>>
>> Does anyone know if the above use case has made it into the convergence
>> project and in which release was/ is going to be merged?
>>
>>
> Hi
>
> Phase one of convergence should be merged in early L (we have some of the
> patches merged now).
> Phase two is to separate the "checking" of actual state into a new RPC
> service within Heat.
> Then you *could* run that checker periodically (or receive RPC
> notifications) to learn of changes
> to the stack's state during the lifetime of the stack. That *might* get
> done in L - we will just have to see
> how things go.
>
> -Angus
>
>
>> Thanks,
>> Dani
>>
>> On Tue, Oct 28, 2014 at 5:40 PM, Daniel Comnea 
>> wrote:
>>
>>> Thanks all for reply.
>>>
>>> I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed
>>> this is not possible as of today. Someone else - sorry i forgot his nicname
>>> on IRC suggested to write a Ceilometer query to count the number of
>>> instances but what @ZhiQiang said is true and this is what we have seen via
>>> the instance sample
>>>
>>> *@Clint - *that is the case indeed
>>>
>>> *@ZhiQiang* - what do you mean by "*count of resource should be queried
>>> from specific service's API*"? Is it related to Ceilometer's event
>>> types configuration?
>>>
>>> *@Mike - *my use case is very simple: i have a group of instances and
>>> in case the # of instances reach the minimum number i set, i would like a
>>> new instance to be spun up - think like a cluster where i want to maintain
>>> a minimum number of members
>>>
>>> With regards to the proposal you made -
>>> https://review.openstack.org/#/c/127884/ that works but only in a
>>> specific use case hence is not generic because the assumption is that my
>>> instances are hooked behind a LBaaS which is not always the case.
>>>
>>> Looking forward to see the 'convergence' in action.
>>>
>>>
>>> Cheers,
>>> Dani
>>>
>>> On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer 
>>> wrote:
>>>
 Daniel Comnea  wrote on 10/27/2014 07:16:32 AM:

 > Yes i did but if you look at this example
 >
 >
 https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
 >

 > the flow is simple:

 > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy"
 > which then triggers the "type: OS::Heat::AutoScalingGroup"

 Actually the ScalingPolicy does not "trigger" the ASG.  BTW,
 "ScalingPolicy" is mis-named; it is not a full policy, it is only an action
 (the condition part is missing --- as you noted, that is in the Ceilometer
 alarm).  The so-called ScalingPolicy does the action itself when
 triggered.  But it respects your configured min and max size.

 What are you concerned about making your scaling group smaller than
 your configured minimum?  Just checking here that there is not a
 misunderstanding.

 As Clint noted, there is a large-scale effort underway to make Heat
 maintain what it creates despite deletion of the underlying resources.

 There is also a small-scale effort underway to make ASGs recover from
 members stopping proper functioning for whatever reason.  See
 https://review.openstack.org/#/c/127884/ for a proposed interface and
 initial implementation.

 Regards,
 Mike
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] In loving memory of Chris Yeoh

[Qiao, Liyong]

+1 from me.

Chris is also my leader in IBM some time before, He is a helpful and talkative 
man. I learn lots from him, he work so hard that I see he send out email 
shortly before even he is ill in bed.

we never forget the contribution for the nova community, nova v3 api, nova v2.1 
api nova 2.1 micro version api.

I hot he will leave in peace and won’t be worry about the review duty in heaven.
I will never forget his word when ending the scrum, “let talk it tomorrow, CU”

BR, Eli(Li Yong)Qiao

From: Alex Xu [mailto:sou...@gmail.com]
Sent: Wednesday, April 08, 2015 5:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] In loving memory of Chris Yeoh

Feel very sad. Just few weeks ago, I still saw him active on the community. 
Really hard believe this happen such suddenly.

He was my leader in IBM and mentored me on the openstack community also, 
offered lots of help without reservation, really
learn a lot from him.  We have phone call meeting every morning before, he 
always sounds happy and enthusiastic even after
he got health problem.
May his soul rest in peace.

2015-04-08 12:49 GMT+08:00 Michael Still 
mailto:mi...@stillhq.com>>:

It is my sad duty to inform the community that Chris Yeoh passed away this 
morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will 
remember Chris as the clever and caring person that I will remember him as. I 
haven’t had a chance to confirm with the family if they want flowers or a 
donation to a charity. As soon as I know those details I will reply to this 
email.

Chris worked on open source for a very long time, with OpenStack being just the 
most recent in a long chain of contributions. He worked tirelessly on his 
contributions to Nova, including mentoring other developers. He was dedicated 
to the cause, with a strong vision of what OpenStack could become. He even 
named his cat after the project.

Chris might be the only person to have ever sent an email to his coworkers 
explaining what his code review strategy would be after brain surgery. It takes 
phenomenal strength to carry on in the face of that kind of adversity, but 
somehow he did. Frankly, I think I would have just sat on the beach.

Chris was also a contributor to the Linux Standards Base (LSB), where he helped 
improve the consistency and interoperability between Linux distributions. He 
ran the ‘Hackfest’ programming contests for a number of years at Australia’s 
open source conference -- linux.conf.au. He supported 
local Linux user groups in South Australia and Canberra, including involvement 
at installfests and speaking at local meetups. He competed in a programming 
challenge called Loki Hack, and beat out the world to win the event[1].

Alyssa’s memories of her dad need to last her a long time, so we’ve decided to 
try and collect some fond memories of Chris to help her along the way. If you 
feel comfortable doing so, please contribute a memory or two at 
https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform

Chris was humble, helpful and honest. The OpenStack and broader Open Source 
communities are poorer for his passing.

Michael

[1] http://www.lokigames.com/hack/

__
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] [TripleO] Consistent variable documentation for diskimage-builder elements

[Smigiel, Dariusz]

> Hello,
> 
> Id like to propse a standard for consistently documenting our diskimage-
> builder elements. I have pushed a review which transforms the apt-sources
> element to this format[1][2]. Essentially, id like to move in the direction of
> making all our element README.rst's contain a sub section called
> Environment Vairables with a Definition List[3] where each entry is the
> environment variable. Under that environment variable we will have a field
> list[4] with Required, Default, Description, and optionally Example.
> 
> The goal here is that rather than users being presented with a wall of text
> that they need to dig through to remember the name of a variable, there is a
> quick way for them to get the information they need. It also should help us
> to remember to document the vital bits of information for each vairable we
> use.
> 
> Thoughts?
> 
> Cheers,
> Greg
> 
> 1 - https://review.openstack.org/#/c/171320/
> 2 - http://docs-draft.openstack.org/20/171320/1/check/gate-diskimage-
> builder-docs/d3bdf04//doc/build/html/elements/apt-sources/README.html
> 3 - http://docutils.sourceforge.net/docs/user/rst/quickref.html#definition-
> lists
> 4 - http://docutils.sourceforge.net/docs/user/rst/quickref.html#field-lists

Looks very promising.
Are you planning to add some kind of lint[1] to RST and force formatting or 
based on common sense for all developers involved?
One minor thing: would be nice to have permalinks to Variables.

In general, it's more readable and understandable compared to previous version.
+1 from me :)

[1] https://pypi.python.org/pypi/restructuredtext_lint/0.4.0

--
Dariusz Smigiel
Intel Technology Poland

__
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] resource quotas limit per stacks within a project

[Daniel Comnea]

+ operators

Hard to believe nobody is facing this problems, even on small shops you end
up with multiple stacks part of the same tenant/ project.

Thanks,
Dani

On Wed, Apr 1, 2015 at 8:10 PM, Daniel Comnea  wrote:

> Any ideas/ thoughts please?
>
> In VMware world is basically the same feature provided by the resource
> pool.
>
>
> Thanks,
> Dani
>
> On Tue, Mar 31, 2015 at 10:37 PM, Daniel Comnea 
> wrote:
>
>> Hi all,
>>
>> I'm trying to understand what options i have for the below use case...
>>
>> Having multiple stacks (various number of instances) deployed within 1
>> Openstack project (tenant), how can i guarantee that there will be no
>> race after the project resources.
>>
>> E.g - say i have few stacks like
>>
>> stack 1 = production
>> stack 2 = development
>> stack 3 = integration
>>
>> i don't want to be in a situation where stack 3 (because of a need to run
>> some heavy tests) will use all of the resources for a short while while
>> production will suffer from it.
>>
>> Any ideas?
>>
>> Thanks,
>> Dani
>>
>> P.S - i'm aware of the heavy work being put into improving the quotas or
>> the CPU pinning however that is at the project level
>>
>
>
__
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] [RelMgt] PTL Candidacy

[Thierry Carrez]

Hello list,

I'm announcing my candidacy for OpenStack Release Cycle Management PTL
for the Liberty cycle.

Release Management is a function that existed since the inception of
OpenStack and I always filled that role, so this candidacy may sound
like business as usual. I like to think there are a lot of important
changes we need to implement during the Liberty cycle though, which
makes it extra-interesting.

First, we need to scale and evolve the various Release Cycle Management
subteams to accommodate the big-tent initiative. How to scale those
central activities to a higher number of OpenStack projects ? That
effort is already started for the stable maintenance subteam, which
implemented a number of structural changes to support more projects
while preserving the ideals outlined in the Stable branch policy. For
the release subteam, that means evolving from doing only direct release
management to providing advice, reusable tools and documented processes.
It is a pretty significant change that will require a bit of work and
recruitment in the team, and I'd like to lead that change if you give me
your trust.

Second, we need to have a discussion on long-term evolution of the
release model to better serve our users. The "6-month cycle with 3
intermediary milestones" was always a compromise between our stable
support and documentation capacity and our goal of "releasing early,
releasing often". As our base projects slowly mature and we welcome more
"OpenStack" projects, we want to reconsider that trade-off and at least
bring some flexibility to it. I think my experience there can be useful
while we navigate that treacherous pass.

You'll note that I'm not mentioning the Vulnerability Management Subteam
anymore, since that one got reassigned to the new "Security" team that
just got approved.

Thank you for your consideration !

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

Re: [openstack-dev] In loving memory of Chris Yeoh

[Chen CH Ji]

+1
I can't believe we lost him When we met in Hongkong summit his smile
give me very deep impression...
he is very helpful to me from the first day I contribute to community and I
learnt a lot from him

May his soul rest in peace

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   "Qiao, Liyong" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/08/2015 11:30 AM
Subject:Re: [openstack-dev] In loving memory of Chris Yeoh



+1 from me.

Chris is also my leader in IBM some time before, He is a helpful and
talkative man. I learn lots from him, he work so hard that I see he send
out email shortly before even he is ill in bed.

we never forget the contribution for the nova community, nova v3 api, nova
v2.1 api nova 2.1 micro version api.

I hot he will leave in peace and won’t be worry about the review duty in
heaven.
I will never forget his word when ending the scrum, “let talk it tomorrow,
CU”

BR, Eli(Li Yong)Qiao

From: Alex Xu [mailto:sou...@gmail.com]
Sent: Wednesday, April 08, 2015 5:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] In loving memory of Chris Yeoh

Feel very sad. Just few weeks ago, I still saw him active on the community.
Really hard believe this happen such suddenly.

He was my leader in IBM and mentored me on the openstack community also,
offered lots of help without reservation, really
learn a lot from him.  We have phone call meeting every morning before, he
always sounds happy and enthusiastic even after
he got health problem.
May his soul rest in peace.

2015-04-08 12:49 GMT+08:00 Michael Still :


 It is my sad duty to inform the community that Chris Yeoh passed away this
 morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will
 remember Chris as the clever and caring person that I will remember him
 as. I haven’t had a chance to confirm with the family if they want flowers
 or a donation to a charity. As soon as I know those details I will reply
 to this email.


 Chris worked on open source for a very long time, with OpenStack being
 just the most recent in a long chain of contributions. He worked
 tirelessly on his contributions to Nova, including mentoring other
 developers. He was dedicated to the cause, with a strong vision of what
 OpenStack could become. He even named his cat after the project.


 Chris might be the only person to have ever sent an email to his coworkers
 explaining what his code review strategy would be after brain surgery. It
 takes phenomenal strength to carry on in the face of that kind of
 adversity, but somehow he did. Frankly, I think I would have just sat on
 the beach.


 Chris was also a contributor to the Linux Standards Base (LSB), where he
 helped improve the consistency and interoperability between Linux
 distributions. He ran the ‘Hackfest’ programming contests for a number of
 years at Australia’s open source conference -- linux.conf.au. He supported
 local Linux user groups in South Australia and Canberra, including
 involvement at installfests and speaking at local meetups. He competed in
 a programming challenge called Loki Hack, and beat out the world to win
 the event[1].


 Alyssa’s memories of her dad need to last her a long time, so we’ve
 decided to try and collect some fond memories of Chris to help her along
 the way. If you feel comfortable doing so, please contribute a memory or
 two at
 
https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform


 Chris was humble, helpful and honest. The OpenStack and broader Open
 Source communities are poorer for his passing.


 Michael


 [1] http://www.lokigames.com/hack/

 __
 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] [qa][nova][ironic] How to run microversions tests on the gate

[Sean Dague]

On 04/08/2015 03:58 AM, Dmitry Tantsur wrote:
> On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:
>> Hi,
>>
>> Now Nova and Ironic have implemented API microversions in Kilo.
>> Nova's microversions are v2.1 - v2.3.
>> Ironic's microversions are v1.1 - v1.6.
>>
>> Now Tempest is testing the lowest microversion on the gate, and
>> Ironic's microversions test patch[1] is on the gerrit.
>> Before merging the patch, I'd like to propose consistent test way for
>> microversions of Nova and Ironic.
>>
>> My suggestion is the test target microversions are:
>> * the lowest microversion
>> * the biggest microversion, but don't use the keyword "latest" on a
>> header and these microversions tests are operated on different gate
>> jobs.
>>
>> The lowest microversion is already tested on check-tempest-dsvm-full
>> or something, so this proposes just to add the biggest microversion
>> job like check-tempest-dsvm-full-big-microversion.
>>
>> [background]
>> In long-term, these microversions continue increasing and it is
>> difficult to run Tempest for all microversions on the gate because of
>> test workload. So I feel we need to select microversions which are
>> tested on the gate for efficient testing.
>>
>> [the lowest microversion]
>> On microversion mechanism, if a client *doesn't* specify favorite
>> microversion in its request header, a Nova/Ironic server considers the
>> request as the lowest microversion. So the lowest microversion is
>> default behavior and important. I think we need to test it at least.
>>
>> [the biggest microversion]
>> On microversion mechanism, if a client specify the keyword "latest" in
>> its request header instead of microversion, a Nova/Ironic server works
>> on the biggest microversion behavior.
>> During the development, there is time lag between each project dev and
>> Tempest dev. After adding a new API on a project, corresponding tests
>> are added to Tempest in most cases. So if specifying the keyword
>> "latest", Tempest would not handle the request/response and fail,
>> because Tempest can not catch the latest API changes until
>> corresponding Tempest patch is merged.
>> So it is necessary to have the target microversion config option in
>> Tempest and pass specific biggest microversion to Tempest with
>> openstack-infra/project-config.
>>
>> Any thoughts?
> 
> Hi! I've already stated this point in #openstack-ironic and I'd like to
> reiterate: if we test only the lowest and the highest microversions
> essentially means (or at least might mean) that the other are broken. At
> least in Ironic only some unit tests actually touch code paths for
> versions 1.2-1.5. As we really can't test too many versions, I suggest
> we stop producing a microversion for every API feature feature change in
> L. No idea what to do with 1.2-1.5 now except for politely asking people
> not to use them :D

Tempest shouldn't be the *only* test for a project API. The projects
themselves need to take some ownership for their API getting full
coverage with in tree testing, including whatever microversion strategy
they are employing.

My original thoughts about this would be that Tempest tests without
versions (so the low end), plus there could be specific Tempest tests
added for new microversions.

Regression of 'latest' should be a low probability event, caught by the
project in tree. So I think that Tempest on every run for that is
excessive. Instead I'd say that should go into periodic changes instead.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [heat] autoscaling and load balancers

[Thomas Herve]

Hi,

Response inline.


> Hi,
> 
> The OS::Heat::AutoScalingGroup resource is somewhat limited at this time,
> because when a scaling even occurs it does not notify dependent resources,
> such as a load balancer, that the pool of instances has changed.

That's technically not true. If you use a neutron load balancer, and a 
PoolMember resource in each scaling unit, it will do exactly that.

> The AWS::AutoScaling::AutoScalingGroup resource, on the other side, has a
> LoadBalancerNames property that takes a list of
> AWS::ElasticLoadBalancing::LoadBalancer resources that get updated anytime
> the size of the ASG changes.
> 
> I'm trying to implement this notification mechanism for HOT templates, but
> there are a few aspects that I hope to do better.
> 
> 1. A HOT template can have get_attr function calls that invoke attributes of
> the ASG. None of these update when the ASG resizes at this time, a scaling
> even does a partial update that only affects the ASG resource. I would like
> to address this.
> 
> 2. The AWS solution relies on the well known LoadBalancer resource, but often
> load balancers are just regular instances that get loaded with a load
> balancer such as haproxy in a custom way. I'd like custom load balancers to
> also update when the ASG resizes.
> 
> The ResourceGroup is an interesting resource. It is much simpler than the
> ASG. In particular, the only way to scale the ResourceGroup is by issuing a
> stack-update with a new size. This indirectly solves #1 and #2 above,
> because when a full update is issued any references to the ResourceGroup get
> updated as well.
> 
> In my opinion, the best way to address #1 and #2 above so that they work for
> the ASG as they work for the RG, is to change what happens when there is a
> scaling event. When the ScalingPolicy resource gets a signal, it reaches
> directly to the ASG by calling asg.adjust() (or in the near future by
> sending a signal to it, when a currently proposed patch merges) with the new
> size. This bypasses the update mechanism, so only a partial update occurs,
> just the ASG resource itself is updated. I would like this to be a full
> stack update, so that all references get updated with the new ASG size. This
> will address #1 and #2.

I'm in full support of this. We already do a localized stack update on the 
nested stack, I don't see any reason why we would do a full one. It would make 
the template works without making the user do any extra declaration.

> But there is an alternative to this. I guess we could copy the update
> mechanism used on the AWS side, which is also partial, but at least covers
> the load balancers, given in the LoadBalancerNames property. We can have a
> "load_balancer_names" equivalent property for the OS::Heat::ASG resource,
> and we can then trigger the updates of the load balancer(s) exactly like the
> AWS side does it. For this option, I would like to extend the load balancer
> update mechanism to work on custom load balancers, as it currently works
> with the well known load balancer resources. I have implemented this
> approach and is currently up for review:
> https://review.openstack.org/#/c/170634/ . I honestly prefer the full
> update, seems cleaner to me.

As mentioned in the review, I don't think it's the proper approach. Especially 
considering that the load_balancer_names property would actually contain 
arbitrary resources.

> Anyway, sorry for the long email. If you can provide guidance on which of the
> approaches are preferred, or if you have other ideas, I would appreciate it.

Thanks a lot for the careful explanation and for tackling this issue.

-- 
Thomas

__
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] [qa][nova][ironic] How to run microversions tests on the gate

[Dmitry Tantsur]

On 04/08/2015 12:53 PM, Sean Dague wrote:

On 04/08/2015 03:58 AM, Dmitry Tantsur wrote:

On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:

Hi,

Now Nova and Ironic have implemented API microversions in Kilo.
Nova's microversions are v2.1 - v2.3.
Ironic's microversions are v1.1 - v1.6.

Now Tempest is testing the lowest microversion on the gate, and
Ironic's microversions test patch[1] is on the gerrit.
Before merging the patch, I'd like to propose consistent test way for
microversions of Nova and Ironic.

My suggestion is the test target microversions are:
* the lowest microversion
* the biggest microversion, but don't use the keyword "latest" on a
header and these microversions tests are operated on different gate
jobs.

The lowest microversion is already tested on check-tempest-dsvm-full
or something, so this proposes just to add the biggest microversion
job like check-tempest-dsvm-full-big-microversion.

[background]
In long-term, these microversions continue increasing and it is
difficult to run Tempest for all microversions on the gate because of
test workload. So I feel we need to select microversions which are
tested on the gate for efficient testing.

[the lowest microversion]
On microversion mechanism, if a client *doesn't* specify favorite
microversion in its request header, a Nova/Ironic server considers the
request as the lowest microversion. So the lowest microversion is
default behavior and important. I think we need to test it at least.

[the biggest microversion]
On microversion mechanism, if a client specify the keyword "latest" in
its request header instead of microversion, a Nova/Ironic server works
on the biggest microversion behavior.
During the development, there is time lag between each project dev and
Tempest dev. After adding a new API on a project, corresponding tests
are added to Tempest in most cases. So if specifying the keyword
"latest", Tempest would not handle the request/response and fail,
because Tempest can not catch the latest API changes until
corresponding Tempest patch is merged.
So it is necessary to have the target microversion config option in
Tempest and pass specific biggest microversion to Tempest with
openstack-infra/project-config.

Any thoughts?


Hi! I've already stated this point in #openstack-ironic and I'd like to
reiterate: if we test only the lowest and the highest microversions
essentially means (or at least might mean) that the other are broken. At
least in Ironic only some unit tests actually touch code paths for
versions 1.2-1.5. As we really can't test too many versions, I suggest
we stop producing a microversion for every API feature feature change in
L. No idea what to do with 1.2-1.5 now except for politely asking people
not to use them :D


Tempest shouldn't be the *only* test for a project API. The projects
themselves need to take some ownership for their API getting full
coverage with in tree testing, including whatever microversion strategy
they are employing.


Agreed, but in-tree testing is also not feasible with too many version. 
Even now we have 7 (1.0-1.6), if it continues, we'll have not less than 
12 after L, 18 after M, etc. And we have to test every one of them for 
regressions at least occasionally, provided that we don't start to 
aggressively deprecated microversions. If we do start, then we'll start 
breaking people even more often, than we should. E.g. if someone writes 
a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will 
break, though maybe it can actually work with new API.




My original thoughts about this would be that Tempest tests without
versions (so the low end), plus there could be specific Tempest tests
added for new microversions.

Regression of 'latest' should be a low probability event, caught by the
project in tree. So I think that Tempest on every run for that is
excessive. Instead I'd say that should go into periodic changes instead.

-Sean




__
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-lbaas][tempest] tempest v2 API tests failing with logging_noop driver

[santosh sharma]

It is failing at CI
https://125.22.100.252/Change_168046_PatchSet_6_2015-04-04_23_02_18/tempest_api_test.html

 Seems tests are failing at Radware  CI's also.
https://os-ci-logs.radware.com/170983_1_2015-04-06_21-19-54/lbaas_v2_tempest_tests.log

Will do necessary changes to skip.

 Thanks
Santosh

On Sun, Apr 5, 2015 at 4:04 PM, santosh sharma 
wrote:

> I am using latest git version (after
> https://review.openstack.org/#/c/165716/ merge):
>
> There are 18 tests failing( (logging noop driver) with latest changes
> Attaching tempest log files.
>
>
>
>
> Thanks
> Santosh
>



-- 
Santosh
__
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] [RelMgt] PTL Candidacy

[Tristan Cacqueray]

confirmed

On 04/08/2015 06:18 AM, Thierry Carrez wrote:
> Hello list,
> 
> I'm announcing my candidacy for OpenStack Release Cycle Management PTL
> for the Liberty cycle.
> 
> Release Management is a function that existed since the inception of
> OpenStack and I always filled that role, so this candidacy may sound
> like business as usual. I like to think there are a lot of important
> changes we need to implement during the Liberty cycle though, which
> makes it extra-interesting.
> 
> First, we need to scale and evolve the various Release Cycle Management
> subteams to accommodate the big-tent initiative. How to scale those
> central activities to a higher number of OpenStack projects ? That
> effort is already started for the stable maintenance subteam, which
> implemented a number of structural changes to support more projects
> while preserving the ideals outlined in the Stable branch policy. For
> the release subteam, that means evolving from doing only direct release
> management to providing advice, reusable tools and documented processes.
> It is a pretty significant change that will require a bit of work and
> recruitment in the team, and I'd like to lead that change if you give me
> your trust.
> 
> Second, we need to have a discussion on long-term evolution of the
> release model to better serve our users. The "6-month cycle with 3
> intermediary milestones" was always a compromise between our stable
> support and documentation capacity and our goal of "releasing early,
> releasing often". As our base projects slowly mature and we welcome more
> "OpenStack" projects, we want to reconsider that trade-off and at least
> bring some flexibility to it. I think my experience there can be useful
> while we navigate that treacherous pass.
> 
> You'll note that I'm not mentioning the Vulnerability Management Subteam
> anymore, since that one got reassigned to the new "Security" team that
> just got approved.
> 
> Thank you for your consideration !
> 




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] In loving memory of Chris Yeoh

[Anita Kuno]

On 04/08/2015 05:20 AM, Day, Phil wrote:
> Thanks for letting us know Michael,  and thanks for doing it in such a moving 
> way.Sad news indeed
> 
> Phil
> 
> 
> From: Michael Still [mailto:mi...@stillhq.com]
> Sent: 08 April 2015 05:49
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] In loving memory of Chris Yeoh
> 
> 
> It is my sad duty to inform the community that Chris Yeoh passed away this 
> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will 
> remember Chris as the clever and caring person that I will remember him as. I 
> haven’t had a chance to confirm with the family if they want flowers or a 
> donation to a charity. As soon as I know those details I will reply to this 
> email.
> 
> Chris worked on open source for a very long time, with OpenStack being just 
> the most recent in a long chain of contributions. He worked tirelessly on his 
> contributions to Nova, including mentoring other developers. He was dedicated 
> to the cause, with a strong vision of what OpenStack could become. He even 
> named his cat after the project.
> 
> Chris might be the only person to have ever sent an email to his coworkers 
> explaining what his code review strategy would be after brain surgery. It 
> takes phenomenal strength to carry on in the face of that kind of adversity, 
> but somehow he did. Frankly, I think I would have just sat on the beach.
> 
> Chris was also a contributor to the Linux Standards Base (LSB), where he 
> helped improve the consistency and interoperability between Linux 
> distributions. He ran the ‘Hackfest’ programming contests for a number of 
> years at Australia’s open source conference -- 
> linux.conf.au. He supported local Linux user groups in 
> South Australia and Canberra, including involvement at installfests and 
> speaking at local meetups. He competed in a programming challenge called Loki 
> Hack, and beat out the world to win the event[1].
> 
> Alyssa’s memories of her dad need to last her a long time, so we’ve decided 
> to try and collect some fond memories of Chris to help her along the way. If 
> you feel comfortable doing so, please contribute a memory or two at 
> https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform
> 
> Chris was humble, helpful and honest. The OpenStack and broader Open Source 
> communities are poorer for his passing.
> 
> Michael
> 
> [1] http://www.lokigames.com/hack/
> 
> 
> 
> __
> 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
> 
Thank you, Michael for telling us.

I'm sad to hear of his passing mostly for selfish reasons, I was looking
forward to sharing a hug with him again.

I know how grateful he was for the love that surrounded him when he
needed it most.

Thanks Michael,
Anita.

__
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] [QoS] QoS weekly meeting

[Carol Bouchard (caboucha)]

Hi Muguel:

Either works for me.

Carol

From: Vikram Choudhary [mailto:vikram.choudh...@huawei.com]
Sent: Wednesday, April 08, 2015 1:49 AM
To: Miguel Ángel Ajo
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

Hi Miguel,

Voting for timeslot: b.

Thanks
Vikram

From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: 07 April 2015 21:49
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

Hi Miguel,
Both time slots work for me. Thanks for rekindling this effort.

Thanks,
Sandhya

From: Miguel Ángel Ajo mailto:majop...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 7, 2015 1:45 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote:
On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:


On 7 April 2015 at 00:33, Armando M. 
mailto:arma...@gmail.com>> wrote:

On 6 April 2015 at 08:56, Miguel Ángel Ajo 
mailto:majop...@redhat.com>> wrote:


I'd like to co-organized a QoS weekly meeting with Sean M. Collins,

In the last few years, the interest for QoS support has increased, Sean has 
been leading
this effort [1] and we believe we should get into a consensus about how to 
model an extension
to let vendor plugins implement QoS capabilities on network ports and tenant 
networks, and
how to extend agents, and the reference implementation & others [2]

As you surely know, so far every attempt to achieve a consensus has failed in a 
pretty miserable way.
This mostly because "QoS" can be interpreted in a lot of different ways, both 
from the conceptual and practical perspective.
Yes, I'm fully aware of it, it was also a new feature, so it was out of scope 
for Kilo.
It is important in my opinion to clearly define the goals first. For instance a 
simple extensions for bandwidth limiting could be a reasonable target for the 
Liberty release.
I quite agree here, but IMHO, as you said it's a quite open field (limiting, 
guaranteeing,
marking, traffic shaping..), we should do our best in trying to define a model 
allowing us
to build that up in the future without huge changes, on the API side I guess 
micro versioning
is going to help in the API evolution.

Also, at some point, we should/could need to involve the nova folks, for 
example, to define
port flavors that can be associated to nova
instance flavors, providing them
1) different types of network port speeds/guarantees/priorities,
2) being able to schedule instance/ports in coordination to be able to met 
specified guarantees.

yes, complexity can sky rocket fast,
Moving things such as ECN into "future works" is the right thing to do in my 
opinion. Attempting to define a flexible framework that can deal with advanced 
QoS policies specification is a laudable effort, but I am a bit skeptical about 
its feasibility.

++, I think focusing on perhaps bandwidth limiting may make a lot of sense
Yes, I believe we should look into the future , but at the same pick our very 
first feature (or a
very simple set of them) for L, stick to it, and try to make a design that can 
be extended.



As per discussion we've had during the last few months [3], I believe we 
should start simple, but
prepare a model allowing future extendibility, to allow for example specific 
traffic rules (per port,
per IP, etc..), congestion notification support [4], ...

"Simple" in my mind is even more extreme then what you're proposing here... I'd 
start with bare APIs for specifying bandwidth limiting, and then phase them out 
once this "framework" is in place.
Also note that this kind of design bears some overlap with the flavor framework 
which is probably going to be another goal for Liberty.

Indeed, and the flavor framework is something I'm hoping we can land by 
Liberty-1 (yes, I just said Liberty-1).
Yes it's something I looked at, I must admit I wasn't able to see it work 
together (It doesn't
mean it doesn't play well, but most probably I was silly enough not to see it 
:) ),

I didn't want to distract attention from the Kilo cycle focus making questions, 
so it should
be a good thing to talk about during the first meetings.

Who are the flavor fathers/mothers? ;)


Morever, consider using "common" tools such as the specs repo to share and 
discuss design documents.

Also a good idea.
Yes, that was the plan now, we didn't use it before to avoid creating 
unnecessary noise during this cycle.



It's the first time I'm trying to organize an openstack/neutron meeting, 
so, I don't know what's the
best way to do it, or find the best timeslot. I guess interested people may 
have a saying, so I've
looped

Re: [openstack-dev] In loving memory of Chris Yeoh

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/07/2015 11:49 PM, Michael Still wrote:

> Chris was humble, helpful and honest. The OpenStack and broader
> Open Source communities are poorer for his passing.

I met Chris at PyCon Australia, as we held an OpenStack mini-summit
the day before. A year later when I was considering joining IBM, the
fact that he would be on my team was a very strong positive factor in
my decision. He was always a joy to work with, even these past few
months when he was fighting the ultimate battle. He was, and still is,
a true inspiration.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVJRxpAAoJEKMgtcocwZqL7r4P/it99miUFxhJz6gNGHjea9sF
d56Y0V3e205omJm4cpCQsYAXJ1BXNnMSIbjACQl/n7NnKjnyTo6GiytAZMb+ew8M
k9RzqC2AKjwMHTMC9Z7OdKZTvTMC2FFEK3RLg504CQQtL4ZaKlRnVg2DYuE6sWJS
vWhh0YA+syDdzgvV6fwBaE6ot/reSQBV/1oSkvmybYiHfVOxib5ZBWZfXWQC0uZX
W6xZydcvSEvy8f5AuLtbZy2rWWp5Iav3AkD1kEGmbKv3/gaMZeQBCkmwXe+G8Prx
gmZnrbf3uKV0RaiINT3CYCfDP6o8svtRfBXObpPXsRTwNP+lZk9mfwBRlm4OLudn
XeC5A4PG0b3yB1rdRgyjl66LVhQIwpnme+YDJ31vDOJvIkMAsEK6J9mpI2AN32PG
xcof9C8SmgU+RrN/n2AfVW6BlKY9VvQqcbu/JmuMRUOaeqwQwMKMikGaRrGZlrhe
o5uAaUhEqealxXVD+eZ1kW1p/5Lvq+QezZCSjIR6EIZ8E9v/WRuZvOnf7k5dIMfv
Lkl2TbSYu1rh4Uvb7yGb2Xva+dReVIf2wzZrsibExD94oUiKaf85hgxSooM7EoGi
jBn+fTiWAO1nE+UahFTKQnuuIs9c+2NcgK1sUkEVRaAPxs7XXeRE7wJsSIID3U0G
Z9fQX7Mca/OQF15P2pLc
=z/zF
-END 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] [qa][nova][ironic] How to run microversions tests on the gate

[Sean Dague]

On 04/08/2015 07:38 AM, Dmitry Tantsur wrote:
> On 04/08/2015 12:53 PM, Sean Dague wrote:
>> On 04/08/2015 03:58 AM, Dmitry Tantsur wrote:
>>> On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:
 Hi,

 Now Nova and Ironic have implemented API microversions in Kilo.
 Nova's microversions are v2.1 - v2.3.
 Ironic's microversions are v1.1 - v1.6.

 Now Tempest is testing the lowest microversion on the gate, and
 Ironic's microversions test patch[1] is on the gerrit.
 Before merging the patch, I'd like to propose consistent test way for
 microversions of Nova and Ironic.

 My suggestion is the test target microversions are:
 * the lowest microversion
 * the biggest microversion, but don't use the keyword "latest" on a
 header and these microversions tests are operated on different gate
 jobs.

 The lowest microversion is already tested on check-tempest-dsvm-full
 or something, so this proposes just to add the biggest microversion
 job like check-tempest-dsvm-full-big-microversion.

 [background]
 In long-term, these microversions continue increasing and it is
 difficult to run Tempest for all microversions on the gate because of
 test workload. So I feel we need to select microversions which are
 tested on the gate for efficient testing.

 [the lowest microversion]
 On microversion mechanism, if a client *doesn't* specify favorite
 microversion in its request header, a Nova/Ironic server considers the
 request as the lowest microversion. So the lowest microversion is
 default behavior and important. I think we need to test it at least.

 [the biggest microversion]
 On microversion mechanism, if a client specify the keyword "latest" in
 its request header instead of microversion, a Nova/Ironic server works
 on the biggest microversion behavior.
 During the development, there is time lag between each project dev and
 Tempest dev. After adding a new API on a project, corresponding tests
 are added to Tempest in most cases. So if specifying the keyword
 "latest", Tempest would not handle the request/response and fail,
 because Tempest can not catch the latest API changes until
 corresponding Tempest patch is merged.
 So it is necessary to have the target microversion config option in
 Tempest and pass specific biggest microversion to Tempest with
 openstack-infra/project-config.

 Any thoughts?
>>>
>>> Hi! I've already stated this point in #openstack-ironic and I'd like to
>>> reiterate: if we test only the lowest and the highest microversions
>>> essentially means (or at least might mean) that the other are broken. At
>>> least in Ironic only some unit tests actually touch code paths for
>>> versions 1.2-1.5. As we really can't test too many versions, I suggest
>>> we stop producing a microversion for every API feature feature change in
>>> L. No idea what to do with 1.2-1.5 now except for politely asking people
>>> not to use them :D
>>
>> Tempest shouldn't be the *only* test for a project API. The projects
>> themselves need to take some ownership for their API getting full
>> coverage with in tree testing, including whatever microversion strategy
>> they are employing.
> 
> Agreed, but in-tree testing is also not feasible with too many version.
> Even now we have 7 (1.0-1.6), if it continues, we'll have not less than
> 12 after L, 18 after M, etc. And we have to test every one of them for
> regressions at least occasionally, provided that we don't start to
> aggressively deprecated microversions. If we do start, then we'll start
> breaking people even more often, than we should. E.g. if someone writes
> a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will
> break, though maybe it can actually work with new API.

I do not understand how in tree testing is not feasible. In tree you
have insights into all the branching that occurs within code so can very
clearly understand what paths aren't possible. It should be a lot more
straight forward than external black box testing where that can't be assume.

-Sean

-- 
Sean Dague
http://dague.net

__
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] how to send messages (and events) to our users

[Ryan Brown]

On 04/07/2015 02:34 PM, Sandy Walsh wrote:
> 
>> Tooling in general seems to be moving towards richer event data as well.
>> The logging tools (Loggly/Logstash/PaperTrail/zillions of others) are
>> intended to take your unstructured logs and turn them into events, so
>> why not have Heat output structured events that we can present to the
>> user with Ceilometer rather than sending log lines (through syslog or
>> otherwise) and using tooling to reassemble them into events later.
> 
> The trend in the monitoring space seems to be:
> 
> 1. Alarms are issued from Metrics as Events. 
> (events can issue alarms too, but conventional alarming is metric based)
> 2. Multiple events are analyzed to produce Metrics (stream processing)
> 3. Go to Step 1
> 

Indeed. I sort of envisioned heat sending out events that are then
consumed both as metrics and by the user (where appropriate). In
StackTach I can see that being implemented as

/--> resource events > other tools
Heat --> Winchester ---> notifications stream--> user
\--> metrics stream --> alerts --/


>> TL;DR: I think what we really want is a place to send and react to
>> *events*. Logs are a way to do that, of course, but the Ceilometer way
>> sounds pretty attractive.
> 
> The difference is structured vs. unstructured data. Elasticsearch-based
> solutions tend to ignore structure by looking at keywords. Some solutions,
> like TopLog, infer a structure by gleaning regexs from logs. 
> 
> Events start as structured data. More so, we're looking at establishing 
> AVRO-based schema definitions on top of these events (slow progress).

Yeah, I'd really like to have a schema for Heat events so we can have a
single event stream and repackage events for different consumption goals
(metrics, notifications, programmatic interaction, etc).

> If anything we should consider changing the logging library to use structured 
> messages. Specifically:
> 
> log("The %(foo)s did %(thing)s" % {'foo':'x', 'thing':'action'})
> it would be
> log({'message':"The %(foo)s did %(thing)s", 'foo':'x', 'thing':'action'})
> 
> Which can still be formatted for conventional logs, but also sent as a
> notification or as a higher-level structure to things like ES, TopLog, etc.
> The driver can decide. 
> 
>> * CloudWatch has you send unstructured log messages, then build filters
>> to parse them into quantifiable events, then set alarms on those metrics.
> 
> Having to build filters is a relatively error-prone approach compared to the
> methods described above. 

I wasn't saying *we* should do the unstructured message + regex filters
strategy, I was just pointing out the CW solution for folks who hadn't
used it.

>>> [snip]
> 
> The Fujitsu team have already added logging support to Monasca (with an 
> elasticsearch backend) and HP is currently adding StackTach.v3 support for
> notification->event conversion as well as our Winchester event stream 
> processing engine. Also, this is based on Kafka vs. RabbitMQ, which has better
> scaling characteristics for this kind of data.

Oooh, I'll have a look into that, Kafka as an event bus sounds like a
good fit. I have the same concern Angus voiced earlier about Zaqar
though. What's the deployment of StackTach.v3 across OpenStack
installations? Is it mostly deployed for Helion/Rackspace, or are
smaller deployers using it as well?

> 
>> This could be extended to richer JSON events that include the stack,
>> resources affected in the update, stats like "num-deleted-resources" or
>> "num-replaced-resources", autoscaling actions, and info about stack errors.
> 
> Some of these sound more like a metrics than notifications. We should be 
> careful not to misuse the two. 

I think they're events, and have facets that are quantifiable as metrics
(num-replaced-resources on an update action) and that should be
user-visible (update is complete, or autoscaling actions taken).

>> Is there a way for users as-is to view those raw notifications, not just
>> the indexed k/v pairs?
> 
> In StackTach.v3 we ship the raw notifications to HDFS for archiving, but
> expose the reduced event via the API. The message-id links the two.
> 
> Lots more here: http://www.stacktach.com

Thanks! I'll have to read up.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

__
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] [heat] suggestion for lock/protect stack blueprint

[KOFFMAN, Noa (Noa)]

Hey,

I would like to suggest a blueprint to allow locking/protecting a 
stack. Similar to: nova server "lock" or glance-image "--is-protected" 
flag.
Once a stack is locked, the only operation allowed on the stack is 
"unlock" - heat engine should reject any stack operations and ignore 
signals that modify the stack (such as scaling).

The lock operation should have a "lock_resources" flag (default = True):
When True: perform heat lock and enable lock/protect for each stack 
resource that supports it (nova server, glance image,...).
when False: perform heat lock - which would lock the stack and all 
nested stacks (actions on resources will not be effected).

Use-cases:
1. we received several requests from application vendors, to allow 
"maintenance mode" for the application. When in maintenance no topology 
changes are permitted. For example a maintenance mode is required for 
a clustered DB app that needs a manual reboot of one of its servers - 
when the server reboots all the other servers are redistributing the 
data among themselves which causes high CPU levels which in turn might 
cause an undesired scale out (which will cause another CPU spike and so 
on...).
2. some cloud-admins have a configuration stack that initializes the 
cloud (Creating networks, flavors, images, ...) and these resources 
should always exist while the cloud exists. Locking these configuration 
stacks, will prevent someone from accidently deleting/modifying the 
stack or its resources.

This feature might even raise in significance, once convergence phase 2 
is in place, and many other automatic actions are performed by heat. 
The ability to manually perform admin actions on the stack with no 
interruptions is important.

Any thoughts/comments/suggestions are welcome.

Thanks   
Noa Koffman.



__
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] [oslo] not running for PTL for liberty cycle

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-04-03 08:50:56 -0400:
> Team,
> 
> I have decided not to run for PTL for Oslo for the next cycle.
> 
> Serving as PTL for the last three releases has been a rewarding experience, 
> and I think we’ve made some great strides together as a team. Now it’s time 
> for me to step down and let someone else take the lead position. I am still 
> committed to the mission, and I will  be contributing to Oslo, but I do also 
> want to work on some other projects that I won’t have time for if I stay in 
> the PTL role. We have several good candidates for PTL on the team, and I 
> expect us to have no trouble finding someone willing to step up and run.
> 
> Thanks,
> Doug
> 

Thank you all for your support over the past 3 cycles, and kind words
this week. I look forward to continuing to work with all of you!

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] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

[Doug Hellmann]

Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:
> On 7 April 2015 at 05:11, Joe Gordon  wrote:
> >
> >
> > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews 
> > wrote:
> >>
> >>
> >> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic  wrote:
> >>>
> >>> Jay,
> >>>
> >>>
>  Not far, IMHO. 100ms difference in startup time isn't something we
>  should spend much time optimizing. There's bigger fish to fry.
> >>>
> >>>
> >>> I agree that priority of this task shouldn't be critical or even high,
> >>> and that there are other places that can be improved in OpenStack.
> >>>
> >>> In other hand this one is as well big source of UX issues that we have in
> >>> OpenStack..
> >>>
> >>> For example:
> >>>
> >>> 1) You would like to run some command X times where X is pretty big
> >>> (admins likes to do this via bash loops). If you can execute all of them 
> >>> for
> >>> 1 and not 10 minutes you will get happier end user.
> >>
> >>
> >> +1 I'm fully in support of this effort. Shaving 100ms off the startup time
> >> of a frequently used library means that you'll save that 100ms over and
> >> over, adding up to a huge win.
> >>
> >
> >
> > Another data point on how slow our libraries/CLIs can be:
> >
> > $ time openstack -h
> > 
> > real0m2.491s
> > user0m2.378s
> > sys 0m0.111s
> 
> 
> pbr should be snappy - taking 100ms to get the version is wrong.

I have always considered pbr a packaging/installation time tool, and not
something that would be used at runtime. Why are we using pbr to get the
version of an installed package, instead of asking pkg_resources?

Doug

> 
> -Rob
> 

__
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] Liberty mid-cycle coding sprint

[Kyle Mestery]

On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana 
wrote:

>  Kyle and Neutron Team,
>
>  Having the mid-cyle just one month after the Liberty summit does not
> really fit into the definition of “mid-cycle”. It feels like we are just
> getting up to speed on Liberty BPs when we need to get ready for three days
> of sprint coding.
> Would you consider to move this at least one month after?
> I really want to go but it feels to soon to request permission to my
> management team.
>
> Thanks for your concerns Edgar. I guess you're right, and I will stop
calling this a mid-cycle, and instead just refer to it as a the Neutron
Liberty Coding Sprint. It's actually worked out really well to have it
close to the first milestone, we have a lot of things we can do very early
in the cycle, getting together and pushing towards the first milestone with
some of them will work well. Like I indicated to Russell, we'll do our best
to facilitate remote attendees over IRC and maybe Hangouts while we're
there.

Thanks!
Kyle


>  Thanks,
>
>  Edgar
>
>   From: Kyle Mestery 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, April 7, 2015 at 6:39 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
>
>On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant 
> wrote:
>
>> On 04/07/2015 12:33 AM, Ben Pfaff wrote:
>> > On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote:
>> >> I know we're not even at the Liberty Design Summit in Vancouver yet,
>> but I
>> >> wanted to take this time to announce the Neutron mid-cycle coding
>> sprint
>> >> for Liberty. HP has been gracious enough to offer to host at it's Fort
>> >> Collins, CO offices. The dates are set for June 24-26, this is
>> >> Wednesday-Friday. I've got additional information on the etherpad [1].
>> >>
>> >> We'll set the specific agenda in the coming weeks, but the idea is to
>> focus
>> >> on things like the pending neutron-lib work [2] while there, similar to
>> >> what we did with the advanced services split in Utah last year. My
>> >> experience running the past two mid-cycles has been that having these
>> >> earlier in the cycle has been helpful for landing a lot of work near
>> the
>> >> first milestone of a release. I expect this to be the same for Liberty
>> with
>> >> the sprint in Fort Collins.
>> >>
>> >> Please note attendance is not required at all. We will do our best to
>> >> facilitate virtual collaboration for those who cannot travel to the
>> event.
>> >> I wanted to get this out there for folks who have to book travel in
>> advance.
>> >
>> > I don't know anything about these events.  Naively: would OVN
>> > development (some of which is in Neutron, much of which is not) be an
>> > appropriate use of time at the event?
>>
>>  Yes, I think putting OVN hacking on the agenda makes a lot of sense!
> I'll add it to the etherpad now.
>
>
>> I suspect so.  FWIW, I'm not sure I'll be going, though.  The dates
>> aren't good for me.
>>
>>  Bummer! But, as I said, we'll try our best to include remote people
> into the coding sprint, so hopefully you can participate from afar. :)
>
>
>> --
>> Russell Bryant
>>
>> __
>> 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] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

[Flavio Percoco]

On 08/04/15 08:59 -0400, Doug Hellmann wrote:

Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:

On 7 April 2015 at 05:11, Joe Gordon  wrote:
>
>
> On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews 
> wrote:
>>
>>
>> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic  wrote:
>>>
>>> Jay,
>>>
>>>
 Not far, IMHO. 100ms difference in startup time isn't something we
 should spend much time optimizing. There's bigger fish to fry.
>>>
>>>
>>> I agree that priority of this task shouldn't be critical or even high,
>>> and that there are other places that can be improved in OpenStack.
>>>
>>> In other hand this one is as well big source of UX issues that we have in
>>> OpenStack..
>>>
>>> For example:
>>>
>>> 1) You would like to run some command X times where X is pretty big
>>> (admins likes to do this via bash loops). If you can execute all of them for
>>> 1 and not 10 minutes you will get happier end user.
>>
>>
>> +1 I'm fully in support of this effort. Shaving 100ms off the startup time
>> of a frequently used library means that you'll save that 100ms over and
>> over, adding up to a huge win.
>>
>
>
> Another data point on how slow our libraries/CLIs can be:
>
> $ time openstack -h
> 
> real0m2.491s
> user0m2.378s
> sys 0m0.111s


pbr should be snappy - taking 100ms to get the version is wrong.


I have always considered pbr a packaging/installation time tool, and not
something that would be used at runtime. Why are we using pbr to get the
version of an installed package, instead of asking pkg_resources?


Just wanted to +1 the above.

I've also considered pbr a packaging/install tool. Furthermore, I
believe having it as a runtime requirement makes packagers life more
complicated because that means pbr will obviously need to be added as
a runtime requirement for that package.


Flavio



Doug



-Rob



__
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


--
@flaper87
Flavio Percoco


pgpxE4YrjG7Mt.pgp
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] [all] how to send messages (and events) to our users

[gordon chung]

> Yeah, I'd really like to have a schema for Heat events so we can have a
> single event stream and repackage events for different consumption goals
> (metrics, notifications, programmatic interaction, etc).

Keystone and parts of Ceilometer use the CADF schema to build notification 
messages[1]. you can see example usage in ceilometermiddleware[2] but as an 
example, it basically builds a notification similar to:

 {
    'typeURI': 'http: //schemas.dmtf.org/cloud/audit/1.0/event',
    'eventTime': '2015-01-30T16: 38: 43.233621',
    'target': { # target of event
    'typeURI': 'service/storage/object',
    'id': 'account',
    },
    'observer': { 
    'id': 'target'
    },
    'eventType': 'activity',
    'measurements': [ # measurements if appplicable
    {
    'metric': {
    'metricId': 'openstack: uuid',
    'name': 'storage.objects.outgoing.bytes',
    'unit': 'B'
    },
    'result': 28
    }
    ],
    'initiator': { # who is triggering event
    'typeURI': 'service/security/account/user',
    'project_id': None,
    'id': 'openstack: 288f6260-bf37-4737-a178-5038c84ba244'
    },
    'action': 'read',
    'outcome': 'success',
    'id': 'openstack: 69972bb6-14dd-46e4-bdaf-3148014363dc'
    }

a few of the fields are generated if not given. i just mention this because 
i've found it immensely easier as a consumer to work off a consistent format.


[1] http://docs.openstack.org/developer/pycadf/
[2] 
https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L198-L227

cheers,

gord
  
__
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] [designate] PTL Candidacy

[Kiall Mac Innes]

I would like to announce my candidacy for Designate / DNS Services
Program PTL position for the Liberty cycle.

Keeping this short! I've been working on the Designate project since day
1, and believe we've made great progress over the last few cycles. For
Liberty, I expect our focus will be on tighter integration with other
OpenStack projects, scalability and reliability improvements, and
community growth.

Thanks,
Kiall

__
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] how to send messages (and events) to our users

[Flavio Percoco]

On 07/04/15 12:55 +1000, Angus Salkeld wrote:

Hi all

For quite some time we (Heat team) have wanted to be able to send messages to
our
users (by user I do not mean the Operator, but the User that is interacting
with the client).

What do I mean by "user messages", and how do they differ from our current log
messages
and notifications?
- Our current logs are for the operator and have information that the user
should not have
  (ip addresses, hostnames, configuration options, other tenant info etc..)
- Our notifications (that Ceilometer uses) *could* be used, but I am not sure
if it quite fits. 
  (they seem a bit heavy weight for a log message and aimed at higher level
events)

These messages could be (based on Heat's use case):

- Specific user oriented log messages (distinct from our normal operator logs)
- Deprecation messages (if they are using old resource properties/template
features)
- Progress and resource state changes (an application doesn't want to poll an
api for a state change)
- Automated actions (autoscaling events, time based actions)
- Potentially integrated server logs (from in guest agents)

I wanted to raise this to "[all]" as it would be great to have a general
solution that 
all projects can make use of.

What do we have now:
- The user can not get any kind of log message from services. The closest thing
  ATM is the notifications in Ceilometer, but I have the feeling that these
have a different aim.
- nova console log
- Heat has a DB "event" table for users (we have long wanted to get rid of
this)

What do other clouds provide:
- https://devcenter.heroku.com/articles/logging
- https://cloud.google.com/logging/docs/
- https://aws.amazon.com/blogs/aws/cloudwatch-log-service/
- http://aws.amazon.com/cloudtrail/
(other examples...)

What are some options we could investigate:
1. remote syslog
    The user provides a rsyslog server IP/port and we send their messages to
that.
    [pros] simple, and the user could also send their server's log messages to
the same
              rsyslog - great visibility into what is going on.

              There are great tools like loggly/logstash/papertrailapp that
source logs from remote syslog
              It leaves the user in control of what tools they get to use.

    [cons] Would we become a spam agent (just sending traffic to an IP/Port) -
I guess that's how remote syslog
               works. I am not sure if this is an issue or not?

              This might be a lesser solution for the use case of "an
application doesn't want to poll an api for a state change"

              I am not sure how we would integrate this with horizon.

2. Zaqar
    We send the messages to a queue in Zaqar.
    [pros] multi tenant OpenStack project for messaging!

    [cons] I don't think Zaqar is installed in most installations (tho' please
correct me here if this
               is wrong). I know Mirantis does not currently support Zaqar, so
that would be a problem for me.


This is, unfortunately, true. However, adoption needs to start
somewhere and I believe this would be a good thing to use Zaqar for.
Kilo was a heads-down cycle for the Zaqar team but I believe we could
help out with making this happen in heat during Liberty.

At the Kilo summit, we discussed what was needed for Heat to consume
Zaqar and we've completed some of those features. I'm saying this to
highlight that Zaqar is now closer to Heat's needs.



              There is not the level of external tooling like in option "1"
(logstash and friends)


True again :(

There's an almost-complete puppet manifest but other than that, tools
are yet to be built.

With my Zaqar hat on, I hope we can make this happen and any help on
tools/adoption is more than appreciated.

Flavio

--
@flaper87
Flavio Percoco


pgpTGmVFmKyfa.pgp
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] [heat] suggestion for lock/protect stack blueprint

[Pavlo Shchelokovskyy]

Hi Noa,

would you kindly propose this blueprint as a spec in heat-specs project on
review.openstack.org? It is way easier to discuss specs in a Gerrit review
format than in ML. If you need a help with submitting a spec for a review,
come to our IRC channel (#heat at freenode.net), we'll gladly help you with
that.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Apr 8, 2015 at 3:43 PM, KOFFMAN, Noa (Noa) <
noa.koff...@alcatel-lucent.com> wrote:

> Hey,
>
> I would like to suggest a blueprint to allow locking/protecting a
> stack. Similar to: nova server "lock" or glance-image "--is-protected"
> flag.
> Once a stack is locked, the only operation allowed on the stack is
> "unlock" - heat engine should reject any stack operations and ignore
> signals that modify the stack (such as scaling).
>
> The lock operation should have a "lock_resources" flag (default = True):
> When True: perform heat lock and enable lock/protect for each stack
> resource that supports it (nova server, glance image,...).
> when False: perform heat lock - which would lock the stack and all
> nested stacks (actions on resources will not be effected).
>
> Use-cases:
> 1. we received several requests from application vendors, to allow
> "maintenance mode" for the application. When in maintenance no topology
> changes are permitted. For example a maintenance mode is required for
> a clustered DB app that needs a manual reboot of one of its servers -
> when the server reboots all the other servers are redistributing the
> data among themselves which causes high CPU levels which in turn might
> cause an undesired scale out (which will cause another CPU spike and so
> on...).
> 2. some cloud-admins have a configuration stack that initializes the
> cloud (Creating networks, flavors, images, ...) and these resources
> should always exist while the cloud exists. Locking these configuration
> stacks, will prevent someone from accidently deleting/modifying the
> stack or its resources.
>
> This feature might even raise in significance, once convergence phase 2
> is in place, and many other automatic actions are performed by heat.
> The ability to manually perform admin actions on the stack with no
> interruptions is important.
>
> Any thoughts/comments/suggestions are welcome.
>
> Thanks
> Noa Koffman.
>
>
>
> __
> 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] how to send messages (and events) to our users

[Sandy Walsh]

>From: Ryan Brown 
>Sent: Wednesday, April 8, 2015 9:42 AM
>
>> The trend in the monitoring space seems to be:
>>
>> 1. Alarms are issued from Metrics as Events.
>> (events can issue alarms too, but conventional alarming is metric based)
>> 2. Multiple events are analyzed to produce Metrics (stream processing)
>> 3. Go to Step 1
>>
>
>Indeed. I sort of envisioned heat sending out events that are then
>consumed both as metrics and by the user (where appropriate). In
>StackTach I can see that being implemented as
>
>/--> resource events > other tools
>Heat --> Winchester ---> notifications stream--> user
>\--> metrics stream --> alerts --/
>

Yep, you can get a lot of great info from a notification. And a lot of
metrics can be produced from them. We use them for debugging, usage/billing
and performance monitoring/tuning. Contextual data ftw! :)

>> Events start as structured data. More so, we're looking at establishing
>> AVRO-based schema definitions on top of these events (slow progress).
>
>Yeah, I'd really like to have a schema for Heat events so we can have a
>single event stream and repackage events for different consumption goals
>(metrics, notifications, programmatic interaction, etc).

Yep, that's the right approach. There are some people at Rax looking at getting
this nailed down soon. 

>> Having to build filters is a relatively error-prone approach compared to the
>> methods described above.
>
>I wasn't saying *we* should do the unstructured message + regex filters
>strategy, I was just pointing out the CW solution for folks who hadn't
>used it.

Gotcha ... agreed.

 [snip]
>>
>> The Fujitsu team have already added logging support to Monasca (with an
>> elasticsearch backend) and HP is currently adding StackTach.v3 support for
>> notification->event conversion as well as our Winchester event stream
>> processing engine. Also, this is based on Kafka vs. RabbitMQ, which has 
>> better
>> scaling characteristics for this kind of data.
>
>Oooh, I'll have a look into that, Kafka as an event bus sounds like a
>good fit. I have the same concern Angus voiced earlier about Zaqar
>though. What's the deployment of StackTach.v3 across OpenStack
>installations? Is it mostly deployed for Helion/Rackspace, or are
>smaller deployers using it as well?

We're in the short strokes of rolling STv3 into production at Rax now. No issues
with the libraries, it's all hiccups with downstream system integration. HP have
some good requirements they want added around hosted monitoring. People are 
still installing and playing around with STv2. It's battle proven and solves the
immediate OpenStack concerns. But it's more rigid than STv3. If you want to 
get going today, I'd recommend STv2, but all new efforts and partner work is
going into STv3. 

>>> This could be extended to richer JSON events that include the stack,
>>> resources affected in the update, stats like "num-deleted-resources" or
>>> "num-replaced-resources", autoscaling actions, and info about stack errors.
>>
>> Some of these sound more like a metrics than notifications. We should be
>> careful not to misuse the two.
>
>I think they're events, and have facets that are quantifiable as metrics
>(num-replaced-resources on an update action) and that should be
>user-visible (update is complete, or autoscaling actions taken).

Yep, tricky to discern sometimes. Perhaps a better way to decide if it's an
event or a metric is to consider the frequency they're generated or how
much context they contain?

>>> Is there a way for users as-is to view those raw notifications, not just
>>> the indexed k/v pairs?
>>
>> In StackTach.v3 we ship the raw notifications to HDFS for archiving, but
>> expose the reduced event via the API. The message-id links the two.
>>
>> Lots more here: http://www.stacktach.com
>
>Thanks! I'll have to read up.

By all means, reach out if you have questions. The more people we have that see
the value in events, the better. Looking at the rise of packages like storm, 
spark, reimann.io, etc. it's clear it's a big change in the distributed 
computing
monitoring space. 

-S


__
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] [heat] suggestion for lock/protect stack blueprint

[Steven Hardy]

On Wed, Apr 08, 2015 at 12:43:06PM +, KOFFMAN, Noa (Noa) wrote:
> Hey,
> 
> I would like to suggest a blueprint to allow locking/protecting a 
> stack. Similar to: nova server "lock" or glance-image "--is-protected" 
> flag.
> Once a stack is locked, the only operation allowed on the stack is 
> "unlock" - heat engine should reject any stack operations and ignore 
> signals that modify the stack (such as scaling).
> 
> The lock operation should have a "lock_resources" flag (default = True):
> When True: perform heat lock and enable lock/protect for each stack 
> resource that supports it (nova server, glance image,...).
> when False: perform heat lock - which would lock the stack and all 
> nested stacks (actions on resources will not be effected).

This sounds like a reasonable requirement to me, particularly if there are
existing "lock" operations supported by other openstack services.

We might consider making this a stack "action", e.g like suspend/resume -
actions are intended for stack-wide operations which affect the stack state
but not it's definition, so it seems like potentially a good fit.

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-dev] [all] Kilo stable branches for "other" libraries

[Thierry Carrez]

Hi everyone,

As you may know, in an effort to simplify stable branch maintenance and
increase their resilience to random changes, the following policy was
adopted:

http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html

TL;DR is that in the future, stable branches will be cut from libraries
current versions and then expressed in global-requirements using a >= <
operator combination, to allow for non-breaking security/critical fixes
updates but not backward-incompatible changes.

While Oslo libs (under the leadership of Doug) have all adopted that
procedure early, for kilo we are left with all the other OpenStack
libraries that (1) haven't cut such stable branches yet and (2) may not
have done what they consider their final kilo release yet. At this point
in the cycle any change to requirements is highly disrupting (as it
needs to be synced to consuming projects and potentially force a release
candidate respin).

The question is, how should we proceed there ? This is new procedure, so
I'm a bit unclear on the best way forward and would like to pick our
collective brain. Should we just push requirements cap for all OpenStack
libs and create stable branches from the last tagged release everywhere
? What about other libraries ? Should we push a cap there too ? Should
we just ignore the whole thing for the Kilo release for all non-Oslo stuff ?

For the record, here is a (hopefully correct) list of the OpenStack libs
directly consumed by integrated projects:

(NB: I skipped all Oslo libs since they have been taken care of already)

python-barbicanclient>=3.0.1 (now at 3.0.3, release 9 days ago)
python-ceilometerclient>=1.0.13 (released 6 weeks ago)
python-cinderclient>=1.1.0  (now at 1.1.1, released 6 months ago)
python-designateclient>=1.0.0 (now at 1.1.1, released 4 months ago)
python-heatclient>=0.3.0 (now at 0.4.0, released 7 days ago)
python-glanceclient>=0.15.0 (now at 0.17.0, released 3 weeks ago)
python-keystoneclient>=1.1.0 (now at 1.3.0, released 14 days ago)
python-neutronclient>=2.3.11,<3 (released 8 weeks ago)
python-novaclient>=2.22.0 (now at 2.23.0, released 3 weeks ago)
python-saharaclient>=0.8.0 (released 4 weeks ago)
python-swiftclient>=2.2.0 (now at 2.4.0, released 2 weeks ago)
python-troveclient>=1.0.7 (now at 1.0.9, released 3 weeks ago)
glance_store>=0.3.0 (now at 0.4.0, released 3 weeks ago)
keystonemiddleware>=1.5.0 (released 4 weeks ago)
pycadf>=0.8.0 (released 7 weeks ago)
django_openstack_auth>=1.1.7,!=1.1.8 (now at 1.1.9, released 2 months ago)

All other non-Oslo libs in the OpenStack world do not seem to be
directly consumed by projects that have stable branches, and are
therefore likely to not maintain stable branches. Please report any
glaring omission there.

I'm especially worried with python-cinderclient, python-designateclient
and django_openstack_auth which are more than 2 months old and may well
contemplate another kilo release that could be disrupting at this point.

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

Re: [openstack-dev] [designate] PTL Candidacy

[Tristan Cacqueray]

confirmed

On 04/08/2015 09:32 AM, Kiall Mac Innes wrote:
> I would like to announce my candidacy for Designate / DNS Services
> Program PTL position for the Liberty cycle.
> 
> Keeping this short! I've been working on the Designate project since day
> 1, and believe we've made great progress over the last few cycles. For
> Liberty, I expect our focus will be on tighter integration with other
> OpenStack projects, scalability and reliability improvements, and
> community growth.
> 
> Thanks,
> Kiall
> 
> __
> 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: 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] [all] Kilo stable branches for "other" libraries

[Matthias Runge]

On 08/04/15 15:55, Thierry Carrez wrote:


I'm especially worried with python-cinderclient, python-designateclient
and django_openstack_auth which are more than 2 months old and may well
contemplate another kilo release that could be disrupting at this point.

In general: a great idea, and I've been expecting this for a longer time 
now. That would save some work.


django_openstack_auth: it's quite stable now, although it would make 
sense to cut a newer release for kilo. We will merge that into horizon 
eventually, since it's a helper and we never saw anyone to use it 
outside of horizon.


Matthias

__
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][Heat] Overcloud software updates and ResourceGroups

[Steven Hardy]

On Tue, Apr 07, 2015 at 07:12:42PM -0400, Zane Bitter wrote:
> On 07/04/15 05:13, Steven Hardy wrote:
> >On Thu, Apr 02, 2015 at 06:31:39PM -0400, Zane Bitter wrote:
> >>A few of us have been looking for a way to perform software updates to
> >>servers in a TripleO Heat/Puppet-based overcloud that avoids an impedance
> >>mismatch with Heat concepts and how Heat runs its workflow. As many talented
> >>TripleO-ers who have gone before can probably testify, that's surprisingly
> >>difficult to do, but we did come up with an idea that I think might work and
> >>which I'd like to get wider feedback on. For clarity, I'm speaking here in
> >>the context of the new overcloud-without-mergepy templates.
> >>
> >>The idea is that we create a SoftwareConfig that, when run, can update some
> >>software on the server. (The exact mechanism for the update is not important
> >>for this discussion; suffice to say that in principle it could be as simple
> >>as "[yum|apt-get] update".) The SoftwareConfig would have at least one
> >>input, though it need not do anything with the value.
> >>
> >>Then each server has that config deployed to it with a SoftwareDeployment at
> >>the time it is created. However, it is set to execute only on the UPDATE
> >>action. The value of (one of) the input(s) is obtained from a parameter.
> >>
> >>As a result, we can trigger the software update by simply changing the value
> >>of the input parameter, and the regular Heat dependency graph will be
> >>respected. The actual input value could be by convention a uuid, a
> >>timestamp, a random string, or just about anything so long as it changes.
> >>
> >>Here's a trivial example of what this deployment might look like:
> >>
> >>   update_config:
> >> type: OS::Heat::SoftwareConfig
> >> properties:
> >>   config: {get_file: do_sw_update.sh}
> >>   inputs:
> >> - name: update_after_time
> >>   description: Timestamp of the most recent update request
> >>
> >>   update_deployment:
> >> type: OS::Heat::SoftwareDeployment
> >> properties:
> >>   actions:
> >> - UPDATE
> >>   config: {get_resource: update_config}
> >>   server: {get_resource: my_server}
> >>   input_values:
> >> update_after_time: {get_param: update_timestamp}
> >>
> >>
> >>(A possible future enhancement is that if you keep a mapping between
> >>previous input values and the system state after the corresponding update,
> >>you could even automatically handle rollbacks in the event the user decided
> >>to cancel the update.)
> >>
> >>And now we should be able to trigger an update to all of our servers, in the
> >>regular Heat dependency order, by simply (thanks to the fact that parameters
> >>now keep their previous values on stack updates unless they're explicitly
> >>changed) running a command like:
> >>
> >>   heat stack-update my_overcloud -f $TMPL -P "update_timestamp=$(date)"
> >>
> >>(A future goal of Heat is to make specifying the template again optional
> >>too... I don't think that change landed yet, but in this case we can always
> >>obtain the template from Tuskar, so it's not so bad.)
> >>
> >>
> >>Astute readers may have noticed that this does not actually solve our
> >>problem. In reality groups of similar servers are deployed within
> >>ResourceGroups and there are no dependencies between the members. So, for
> >>example, all of the controller nodes would be updated in parallel, with the
> >>likely result that the overcloud could be unavailable for some time even if
> >>it is deployed with HA.
> >>
> >>The good news is that a solution to this problem is already implemented in
> >>Heat: rolling updates. For example, the controller node availability problem
> >>can be solved by setting a rolling update batch size of 1. The bad news is
> >>that rolling updates are implemented only for AutoscalingGroups, not
> >>ResourceGroups.
> >>
> >>Accordingly, I propose that we switch the implementation of
> >>overcloud-without-mergepy from ResourceGroups to AutoscalingGroups. This
> >>would be a breaking change for overcloud updates (although no worse than the
> >>change from merge.py over to overcloud-without-mergepy), but that also means
> >>that there'll never be a better time than now to make it.
> >
> >I wonder if this is an opportunity to look at how we converge
> >AutoScalingGroup and ResourceGroup in Heat?
> 
> As long as it's not one of those insoluble opportunities.

No, of course - all I'm suggesting is now might not be a bad time to
enumerate the areas of divergence, and figure out a medium term plan
towards, uh, convergence ;)

> >It seems like the main barrier to transparent (non destructive)
> >substitution of
> >AutoScalingGroup for ResourceGroup is the resource naming (e.g it's a short
> >UUID vs an index derived name) - could we add a property to
> >AutoScalingGroup which allowed optionally to use index based naming, such
> >that switching from ResourceGroup to ASG in a stack-update wouldn't replac

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Evgeny Fedoruk]

Thanks for the information, Vivek
I’m not aware of any samples using neutronclient lbaas v2
I’m not familiar with Horizon project but will be glad to contribute in case of 
free cycles.
Is there anything describing this work? Any tasks bank?

Thanks,
Evg

From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Tuesday, April 07, 2015 7:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Hi Evgeny,
We have just started working on Horizon lbaasv2 support. I have to sync up with 
my team on the time-line but it is not targeted for Kilo release.
Since it is a major effort, we will need more hands. Let me know if anyone is 
interested to contribute.

On a related note, Do we have a sample code which uses neutronclient lbaas v2 
methods? That will greatly speedup our horizon integration.

Thanks,
Vivek

From: Phillip Toohill 
mailto:phillip.tooh...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 7, 2015 at 7:50 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2


​Hey Evgeny,



I believe Vivek is working on Horizon lbaasv2 support. We werent given a 
timeline or anything but sounds like its being actively worked on. I would 
reach out to him to get better timelines if concerned.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: Evgeny Fedoruk mailto:evge...@radware.com>>
Sent: Tuesday, April 7, 2015 5:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Hi guys,

LBaaS v2 has no horizon support as for now and I want to know if this work is 
planned to be done and , if yes, in what time frame.
Is there a plan to develop it for Kilo or for L release?

Thanks,
Evg
__
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] [elections] Last hours for PTL candidate announcements

[Tristan Cacqueray]

A quick reminder that we are in the last hours for PTL candidate
announcements.

If you want to stand for PTL, don't delay, follow the instructions on
the wikipage and make sure we know your intentions:
https://wiki.openstack.org/wiki/PTL_Elections_April_2015

Thank you,
Tristan



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] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

[Ryan Brown]

On 04/08/2015 09:12 AM, Flavio Percoco wrote:
> On 08/04/15 08:59 -0400, Doug Hellmann wrote:
>> Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:
>>> On 7 April 2015 at 05:11, Joe Gordon  wrote:
>>> >
>>> >
>>> > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
>>> 
>>> > wrote:
>>> >>
>>> >>
>>> >> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic
>>>  wrote:
>>> >>>
>>> >>> Jay,
>>> >>>
>>> >>>
>>>  Not far, IMHO. 100ms difference in startup time isn't something we
>>>  should spend much time optimizing. There's bigger fish to fry.
>>> >>>
>>> >>>
>>> >>> I agree that priority of this task shouldn't be critical or even
>>> high,
>>> >>> and that there are other places that can be improved in OpenStack.
>>> >>>
>>> >>> In other hand this one is as well big source of UX issues that we
>>> have in
>>> >>> OpenStack..
>>> >>>
>>> >>> For example:
>>> >>>
>>> >>> 1) You would like to run some command X times where X is pretty big
>>> >>> (admins likes to do this via bash loops). If you can execute all
>>> of them for
>>> >>> 1 and not 10 minutes you will get happier end user.
>>> >>
>>> >>
>>> >> +1 I'm fully in support of this effort. Shaving 100ms off the
>>> startup time
>>> >> of a frequently used library means that you'll save that 100ms
>>> over and
>>> >> over, adding up to a huge win.
>>> >>
>>> >
>>> >
>>> > Another data point on how slow our libraries/CLIs can be:
>>> >
>>> > $ time openstack -h
>>> > 
>>> > real0m2.491s
>>> > user0m2.378s
>>> > sys 0m0.111s
>>>
>>>
>>> pbr should be snappy - taking 100ms to get the version is wrong.
>>
>> I have always considered pbr a packaging/installation time tool, and not
>> something that would be used at runtime. Why are we using pbr to get the
>> version of an installed package, instead of asking pkg_resources?
> 
> Just wanted to +1 the above.
> 
> I've also considered pbr a packaging/install tool. Furthermore, I
> believe having it as a runtime requirement makes packagers life more
> complicated because that means pbr will obviously need to be added as
> a runtime requirement for that package.
> 

RDO actually patches out calls to pbr to avoid the runtime requirement,
FWIW.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

__
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] How to deal with microversions in 3rdparty tools

[Chris Friesen]

On 04/07/2015 11:35 PM, Michael Davies wrote:

On Tue, Apr 7, 2015 at 10:32 PM, Dmitry Tantsur mailto:dtant...@redhat.com>> wrote:

I'm seeking for advice on what to do with microversions in discoverd.
Basically I have the following options:

1. Do nothing. Get whatever behavior I can get from installed Ironic and
Ironic client. Though unlikely, may get broken by future changes.

2. Demand version = 1.6. Looks like it keeps compatibility with old clients
and servers, not sure what downsides are here.

What are we going to recommend now as upstream?


I agree with Jim R's suggestion - it's really up to the consumer as to what they
want to do.  Having said that...

I think that any consumer wants to use the latest version of the API that it can
support.

And so since we're not planning on making any breaking API changes[1], I think
any consumer wants to:

a) have a concept of the latest API version that it has been coded for
b) then, in negotiation with the server, choose a version that suffices:
b1) negotiated_version = min(your code's max version, max Ironic server 
version) and
b2) negotiated_version > your code's supported version
b3) negotiated_version > Ironic API's minimum version


Is that statement about "not planning on making any breaking API changes" an 
intention or a guarantee?


The reason I ask is that doc/source/devref/api_microversions.rst contains an 
explicit mention of making breaking changes:  "So breaking changes can be added 
to the API without breaking users who don't specifically ask for it."


Chris

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

Re: [openstack-dev] [all] Kilo stable branches for "other" libraries

[Devananda van der Veen]

Thierry,

You left out python-ironicclient, which isn't a surprise as it isn't
actually listed in Nova's requirements.txt file. I don't have a link handy
to cite the previous discussions, but Nova felt that it was not appropriate
to list a driver's dependency in their project's requirements file.

As such, it is installed from pip in devstack/lib/ironic right now.

I've tagged a 0.5.0 version two days ago, and plan a quick fix (0.5.1)
today. I think it's reasonable for this library to be capped just like the
other python-*clients, but I'm not sure how to express that, due to Nova
not allowing this dependency in their requirements.txt file.

-Devananda

On Wed, Apr 8, 2015 at 7:18 AM Matthias Runge  wrote:

> On 08/04/15 15:55, Thierry Carrez wrote:
>
> > I'm especially worried with python-cinderclient, python-designateclient
> > and django_openstack_auth which are more than 2 months old and may well
> > contemplate another kilo release that could be disrupting at this point.
> >
> In general: a great idea, and I've been expecting this for a longer time
> now. That would save some work.
>
> django_openstack_auth: it's quite stable now, although it would make
> sense to cut a newer release for kilo. We will merge that into horizon
> eventually, since it's a helper and we never saw anyone to use it
> outside of horizon.
>
> Matthias
>
> __
> 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] Kilo stable branches for "other" libraries

[Dean Troyer]

On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez 
wrote:

> The question is, how should we proceed there ? This is new procedure, so
> I'm a bit unclear on the best way forward and would like to pick our
> collective brain. Should we just push requirements cap for all OpenStack
> libs and create stable branches from the last tagged release everywhere
> ? What about other libraries ? Should we push a cap there too ? Should
> we just ignore the whole thing for the Kilo release for all non-Oslo stuff
> ?
>

Provided that represents the code being used for testing at this point, and
I believe it does, this seems like a sensible default action.  Next cycle
we can make a bit more noise about when this default action will occur,
probably pick one of the other existing dates late in the cycle such as RC
or string freeze or whatever. (Maybe that already happened and I can't
remember?)

All other non-Oslo libs in the OpenStack world do not seem to be
> directly consumed by projects that have stable branches, and are
> therefore likely to not maintain stable branches. Please report any
> glaring omission there.


OSC is not used by any of the integrated release projects but due to its
dependencies on the other client libs and use in DevStack I would like to
follow the same process for it here.  The current 1.0.3 release is the one
that should be used for stable.

dt

-- 
Dean Troyer
dtro...@gmail.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] [qa][nova][ironic] How to run microversions tests on the gate

[Jay Pipes]

On 04/08/2015 05:24 AM, Sean Dague wrote:

On 04/08/2015 07:38 AM, Dmitry Tantsur wrote:

On 04/08/2015 12:53 PM, Sean Dague wrote:

On 04/08/2015 03:58 AM, Dmitry Tantsur wrote:

On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:

Hi,

Now Nova and Ironic have implemented API microversions in Kilo.
Nova's microversions are v2.1 - v2.3.
Ironic's microversions are v1.1 - v1.6.

Now Tempest is testing the lowest microversion on the gate, and
Ironic's microversions test patch[1] is on the gerrit.
Before merging the patch, I'd like to propose consistent test way for
microversions of Nova and Ironic.

My suggestion is the test target microversions are:
* the lowest microversion
* the biggest microversion, but don't use the keyword "latest" on a
header and these microversions tests are operated on different gate
jobs.

The lowest microversion is already tested on check-tempest-dsvm-full
or something, so this proposes just to add the biggest microversion
job like check-tempest-dsvm-full-big-microversion.

[background]
In long-term, these microversions continue increasing and it is
difficult to run Tempest for all microversions on the gate because of
test workload. So I feel we need to select microversions which are
tested on the gate for efficient testing.

[the lowest microversion]
On microversion mechanism, if a client *doesn't* specify favorite
microversion in its request header, a Nova/Ironic server considers the
request as the lowest microversion. So the lowest microversion is
default behavior and important. I think we need to test it at least.

[the biggest microversion]
On microversion mechanism, if a client specify the keyword "latest" in
its request header instead of microversion, a Nova/Ironic server works
on the biggest microversion behavior.
During the development, there is time lag between each project dev and
Tempest dev. After adding a new API on a project, corresponding tests
are added to Tempest in most cases. So if specifying the keyword
"latest", Tempest would not handle the request/response and fail,
because Tempest can not catch the latest API changes until
corresponding Tempest patch is merged.
So it is necessary to have the target microversion config option in
Tempest and pass specific biggest microversion to Tempest with
openstack-infra/project-config.

Any thoughts?


Hi! I've already stated this point in #openstack-ironic and I'd like to
reiterate: if we test only the lowest and the highest microversions
essentially means (or at least might mean) that the other are broken. At
least in Ironic only some unit tests actually touch code paths for
versions 1.2-1.5. As we really can't test too many versions, I suggest
we stop producing a microversion for every API feature feature change in
L. No idea what to do with 1.2-1.5 now except for politely asking people
not to use them :D


Tempest shouldn't be the *only* test for a project API. The projects
themselves need to take some ownership for their API getting full
coverage with in tree testing, including whatever microversion strategy
they are employing.


Agreed, but in-tree testing is also not feasible with too many version.
Even now we have 7 (1.0-1.6), if it continues, we'll have not less than
12 after L, 18 after M, etc. And we have to test every one of them for
regressions at least occasionally, provided that we don't start to
aggressively deprecated microversions. If we do start, then we'll start
breaking people even more often, than we should. E.g. if someone writes
a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will
break, though maybe it can actually work with new API.


I do not understand how in tree testing is not feasible. In tree you
have insights into all the branching that occurs within code so can very
clearly understand what paths aren't possible. It should be a lot more
straight forward than external black box testing where that can't be assume.


Exactly.

The whole *point* of microversions was to allow the APIs to evolve in a 
backwards-compatible, structured and advertised way. The evolution of 
the APIs response and request payloads should be tested fully for each 
microversion added to the codebase -- in tree.


-jay

__
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] Kilo stable branches for "other" libraries

[Sean Dague]

On 04/08/2015 10:42 AM, Dean Troyer wrote:
> On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez  > wrote:
> 
> The question is, how should we proceed there ? This is new procedure, so
> I'm a bit unclear on the best way forward and would like to pick our
> collective brain. Should we just push requirements cap for all OpenStack
> libs and create stable branches from the last tagged release everywhere
> ? What about other libraries ? Should we push a cap there too ? Should
> we just ignore the whole thing for the Kilo release for all non-Oslo
> stuff ?
> 
> 
> Provided that represents the code being used for testing at this point,
> and I believe it does, this seems like a sensible default action.  Next
> cycle we can make a bit more noise about when this default action will
> occur, probably pick one of the other existing dates late in the cycle
> such as RC or string freeze or whatever. (Maybe that already happened
> and I can't remember?)

Yes, due to the way we're testing client libraries, that's the right
approach. In future we should fully cap GR as the first Milestone 3
task. And everything after that should be managed as an exception to get
bumps.

> All other non-Oslo libs in the OpenStack world do not seem to be
> directly consumed by projects that have stable branches, and are
> therefore likely to not maintain stable branches. Please report any
> glaring omission there.
> 
> 
> OSC is not used by any of the integrated release projects but due to its
> dependencies on the other client libs and use in DevStack I would like
> to follow the same process for it here.  The current 1.0.3 release is
> the one that should be used for stable.

Agreed.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [sahara] PTL Candidacy

[Sergey Lukjanov]

Hey folks,

I'd like to announce my intention to continue being PTL of the Data
Processing program (Sahara).

I’m working on Sahara (ex. Savanna) project from scratch, from the
initial proof of concept implementation and till now. I have been the
acting/elected PTL since Sahara was an idea. Additionally, I’m
contributing to other OpenStack projects, especially Infrastructure
for the last three releases where I’m core/root teams member now.

My high-level focus as PTL is to coordinate work of subteams, code
review, release management and general architecture/design tracking.

During the Kilo cycle we successfully adopted specs and czars systems.
Tons of operability and supportability improvements were done as well
as number of interesting features.

For Liberty cycle my focus is to keep going in the same direction and
to ensure that everything we're working on is related to the end users
needs. So, in a few words it's about continuing moving forward in
implementing scalable and flexible Data Processing aaS for OpenStack
ecosystem by investing in quality, usability and new features.

A few words about myself: I’m Principle Software Engineer in Mirantis.
I was working a lot with  Big Data projects and technologies (Hadoop,
HDFS, Cassandra, Twitter Storm, etc.) and enterprise-grade solutions
before (and partially in parallel) working on Sahara in OpenStack ecosystem.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
__
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] [sahara] PTL Candidacy

[Tristan Cacqueray]

confirmed

On 04/08/2015 10:49 AM, Sergey Lukjanov wrote:
> Hey folks,
> 
> I'd like to announce my intention to continue being PTL of the Data
> Processing program (Sahara).
> 
> I’m working on Sahara (ex. Savanna) project from scratch, from the
> initial proof of concept implementation and till now. I have been the
> acting/elected PTL since Sahara was an idea. Additionally, I’m
> contributing to other OpenStack projects, especially Infrastructure
> for the last three releases where I’m core/root teams member now.
> 
> My high-level focus as PTL is to coordinate work of subteams, code
> review, release management and general architecture/design tracking.
> 
> During the Kilo cycle we successfully adopted specs and czars systems.
> Tons of operability and supportability improvements were done as well
> as number of interesting features.
> 
> For Liberty cycle my focus is to keep going in the same direction and
> to ensure that everything we're working on is related to the end users
> needs. So, in a few words it's about continuing moving forward in
> implementing scalable and flexible Data Processing aaS for OpenStack
> ecosystem by investing in quality, usability and new features.
> 
> A few words about myself: I’m Principle Software Engineer in Mirantis.
> I was working a lot with  Big Data projects and technologies (Hadoop,
> HDFS, Cassandra, Twitter Storm, etc.) and enterprise-grade solutions
> before (and partially in parallel) working on Sahara in OpenStack ecosystem.
> 
> 
> 
> __
> 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: 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

[openstack-dev] [Rally] PTL candidacy

[Boris Pavlovic]

Hi,

As far as https://review.openstack.org/#/c/169357/ Rally is part of
OpenStack, I would like to announce my candidacy for Rally  / Benchmark as
a Services.


I started this project in 2013 and for almost two years together we made
nice project and build even nicer project's community.

I would like to hold the position of PTL and improve Rally quality and
cover all use cases:
https://docs.google.com/a/mirantis.com/spreadsheets/d/16DXpfbqvlzMFaqaXAcJsBzzpowb_XpymaK2aFY2gA2g/edit#gid=0


Best regards,
Boris Pavlovic
__
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 in the classroom

[Shaifali Agrawal]

Hello Amrit

I liked the idea of taking OpenStack to the classroom. Thank You for taking
the initiative and sharing your knowledge of cloud computing and OpenStack
with students.

I have a suggestion, why don't you offer a MOOC
,
preparing video lectures and sharing it with world(not just educational
institutions in Massachusetts and near Toronto). We can ask to various MOOC
offering portals(like udacity.com, coursera.org etc) to add the course into
their list of courses or may be let this course offered by OpenStack
Foundation only.

This will be really helpful for those who have never studied about cloud
computing in their regular study courses curriculum and are new to
OpenStack. Such students/listners will get well prepared and *sequential
lectures* to read and learn about cloud computing and OpenStack rather than
searching on web and reading about each new terms that they encounter while
hacking in  OpenStack or similar fields.

The main reason why am I asking to prepare MOOC is that your effort will
reach to whole world and also your knowledge sharing will stay alive
forever in the form of video lectures :)

Also even though I don't have much knowledge in cloud computing and
OpenStack but if you need someone to work with you, I would love to be
that. So please let me know if you need an assistant for such stuff.

Thanks!!!
Shaifali Agrawal
about.me/shaifaliagrawal
  [image: Shaifali Agrawal on about.me]


On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar  wrote:

>  CS and EE schools today use open source software as the basis for a lot
> of coursework and as the practical example for several concepts. Most often
> the exemplar system is Linux. Yet if students are even taught about the
> cloud, they often learn about that other cloud company from Seattle.
>
>
>
> I think OpenStack is the ideal exemplar system for a whole lot of CS/EE
> courses. No matter what area of computer science you are interested in,
> there’s an OpenStack project (or in some cases several) that you can study.
>
>
>
> I think the fact that you can have the entire cloud on your laptop, source
> code and all, is incredibly powerful in the classroom. Not only can you see
> how the system works, but you can also tweak it or fix it if you find
> something to be wrong. Some students also learn about software development
> methodologies by contributing to a fictional open source project. Why do
> that when they can instead be contributing code to a real open source
> project?
>
>
>
> I think there’s a huge opportunity for us to take OpenStack in the
> Classroom (a longer post about my experience doing this last week is at
> http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and
> Kamesh Pemmaraju for helping me with this at short notice.
>
>
>
> Let us make (and I’m looking to the Foundation to support this as a formal
> initiative) it a priority to have every university offer courses on
> computer science and cloud computing with OpenStack as the exemplar system.
>
>
>
> Personally, I’m going to work with educational institutions in
> Massachusetts and near Toronto (where Tesora has offices, and where I tend
> to spend most of my time) to try and make available a course on cloud
> computing with OpenStack as the exemplar system. I’m going to make the
> materials, and offer to teach the course, and I will contribute the
> materials to the Foundation.
>
>
>
> So this is an open offer to any university in MA and near Toronto; if you
> want someone to develop and deliver a course on cloud computing, please let
> me know!
>
>
>
> I think we can all come together and take OpenStack to the Classrooms so
> that every graduating student interested in cloud computing has a working
> knowledge of OpenStack.
>
>
>
> Thanks,
>
>
>
> -amrith
>
>
>
>
>
> Amrith Kumar, Founder & CTO
>
> [image: tesora-small]
>
> Mobile: 978-563-9590
>
> Direct: 978-707-8010 x1002
>
> Twitter: @amrithkumar 
>
> Skype: amrith.skype
>
> *Check out our blog *
>
>
>
> *Twitter * *Facebook
> * *LinkedIn
> *
>
> 125 CambridgePark Drive, Suite 400,
> 
>
> *Cambridge, MA 02140
> 

Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

[Edgar Magana]

Kyle,

Thank you for your answers and also for organizing this coding sprint.
I would like to rephrase my question as follows.
If you are elected as Neutron PTL for the Liberty Cycle, would you consider to 
have either of the following options for the M cycle?:

  1.  Move the next coding sprint at least one month after the “M” summit
  2.  Having both a sprint coding and a formal mid-cycle meet-up

I know how hard is to organize these sessions and I by no means wanted to 
change people plans for attending the one in June 2015. However, raising my 
concerns and suggestions early in the process seems to be a good approach.

Kind Regards,

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 8, 2015 at 6:09 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Kyle and Neutron Team,

Having the mid-cyle just one month after the Liberty summit does not really fit 
into the definition of “mid-cycle”. It feels like we are just getting up to 
speed on Liberty BPs when we need to get ready for three days of sprint coding.
Would you consider to move this at least one month after?
I really want to go but it feels to soon to request permission to my management 
team.

Thanks for your concerns Edgar. I guess you're right, and I will stop calling 
this a mid-cycle, and instead just refer to it as a the Neutron Liberty Coding 
Sprint. It's actually worked out really well to have it close to the first 
milestone, we have a lot of things we can do very early in the cycle, getting 
together and pushing towards the first milestone with some of them will work 
well. Like I indicated to Russell, we'll do our best to facilitate remote 
attendees over IRC and maybe Hangouts while we're there.

Thanks!
Kyle

Thanks,

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 7, 2015 at 6:39 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant 
mailto:rbry...@redhat.com>> wrote:
On 04/07/2015 12:33 AM, Ben Pfaff wrote:
> On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote:
>> I know we're not even at the Liberty Design Summit in Vancouver yet, but I
>> wanted to take this time to announce the Neutron mid-cycle coding sprint
>> for Liberty. HP has been gracious enough to offer to host at it's Fort
>> Collins, CO offices. The dates are set for June 24-26, this is
>> Wednesday-Friday. I've got additional information on the etherpad [1].
>>
>> We'll set the specific agenda in the coming weeks, but the idea is to focus
>> on things like the pending neutron-lib work [2] while there, similar to
>> what we did with the advanced services split in Utah last year. My
>> experience running the past two mid-cycles has been that having these
>> earlier in the cycle has been helpful for landing a lot of work near the
>> first milestone of a release. I expect this to be the same for Liberty with
>> the sprint in Fort Collins.
>>
>> Please note attendance is not required at all. We will do our best to
>> facilitate virtual collaboration for those who cannot travel to the event.
>> I wanted to get this out there for folks who have to book travel in advance.
>
> I don't know anything about these events.  Naively: would OVN
> development (some of which is in Neutron, much of which is not) be an
> appropriate use of time at the event?

Yes, I think putting OVN hacking on the agenda makes a lot of sense! I'll add 
it to the etherpad now.

I suspect so.  FWIW, I'm not sure I'll be going, though.  The dates
aren't good for me.

Bummer! But, as I said, we'll try our best to include remote people into the 
coding sprint, so hopefully you can participate from afar. :)

--
Russell Bryant

__
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] Barbican : Unable to authenticate with keystone V3 for Barbican curl command

[Asha Seshagiri]

Thanks a lot John for your response.
The issue was were working with keystone server which is SSL enabled and we
need to configure Barbican to provide clients side certificate.

Thanks and Regards,
Asha Seshagiri

On Tue, Apr 7, 2015 at 6:26 PM, John Wood  wrote:

>  Hello Asha,
>
>  Please following the steps in the pending CR [1]. That configures v3
> usage with Keystone, and if you use the Docker Keystone instance mentioned,
> it syncs the passwords with it as well. Note the need to execute the setup
> script noted to configure Keystone properly as well.
>
>  Thanks,
> John
>
>  [1]
> https://review.openstack.org/#/c/169114/2/doc/source/setup/keystone.rst
>
>   From: Asha Seshagiri 
> Date: Tuesday, April 7, 2015 at 2:49 PM
> To: John Wood 
> Cc: openstack-dev , "Reller, Nathan
> S." , Douglas Mendizabal <
> douglas.mendiza...@rackspace.com>, "a...@redhat.com" ,
> Paul Kehrer , Adam Harwell <
> adam.harw...@rackspace.com>, Alexis Lee 
> Subject: Re: Barbican : Unable to authenticate with keystone V3 for
> Barbican curl command
>
>   Thanks a lot John for your help and response.
>
>  I had followed the same set of instructions as given in the link 1
> initially changing the version to v3  , it did not work and hence followed
> with link 2 and is not working though.
>
>  The link 1 provided  below points to keystone v2 changes with barbican
>  and not v3
> [1]  http://docs.openstack.org/developer/barbican/setup/keystone.html .
> But in this link  2 for Integration keystone V3 with barbican we have to
> modify both the configuriation files
>   *barbican-api-paste.ini and barbican-admin-paste.ini* files . There are
> some changes in the filter and pipline names  names tied with v3
>
>  pipeline = keystone_v3_authtoken context apiapp
> .
> [filter:keystone_v3_authtoken]
>
>  [2]
> https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API
>
>  Could you please confirm that we need to follow the link 1 changing the
> version from v2 to v3 with only modification in *barbican-api-paste.ini
>  file and not **barbican-admin-paste.ini so that I can start looking into
> the issue with the changes mentioned in link1 alone.*
>
>  Thanks and Regards,
> Asha Seshagiri
>
> On Tue, Apr 7, 2015 at 2:08 PM, John Wood  wrote:
>
>>  Hello Asha,
>>
>>  We are in the process of migrating our documentation to Sphinx, so I’d
>> suggest following this link for Keystone configuration options [1].
>>
>>  I’d also note that a CR is pending with a bit more details to setup via
>> a Docker Keystone here [2].
>>
>>  Thanks,
>> John
>>
>>
>>  [1]  http://docs.openstack.org/developer/barbican/setup/keystone.html
>> [2]  https://review.openstack.org/#/c/169114/
>>
>>   From: Asha Seshagiri 
>> Date: Tuesday, April 7, 2015 at 1:34 PM
>> To: openstack-dev 
>> Cc: John Wood , "Reller, Nathan S." <
>> nathan.rel...@jhuapl.edu>, Douglas Mendizabal <
>> douglas.mendiza...@rackspace.com>, "a...@redhat.com" ,
>> Paul Kehrer , Adam Harwell <
>> adam.harw...@rackspace.com>, Alexis Lee 
>> Subject: Barbican : Unable to authenticate with keystone V3 for Barbican
>> curl command
>>
>>   Hi All ,
>>
>>  Could anyone please help me on this integration issue.
>> I am unable to authenticate with keystone V3  for Barbican curl command
>> .I have followed the procedure given in the following link :
>>
>>
>> https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API
>>
>>  I was unable to authenticate with the keystone V3 even though the right
>> token was provided in the curl command
>> Please find the command to get the token and the curl command to post the
>> secret .
>>
>>  [root@keystone-versiontest ~]# openstack --insecure token issue *(Command
>> to get token from keystone v3)*
>>  ++--+
>> | Field  | Value|
>> ++--+
>> | expires| 2015-04-07T18:26:13.835641Z  |
>> |* id | f28b93f27cce4bc09f9ac50d84bde736 |*
>> | project_id | 9d37f9ecc481422aa8ab53674cb82410 |
>> | user_id| e7d02ed8e7e64b01a1d66bb86ffa90d8 |
>> ++--+
>>
>>  [root@keystone-versiontest ~]# curl -X POST -H
>> 'content-type:application/json' -H 'X-Project-Id:12345' \
>> > -H "X-Auth-Token:*f28b93f27cce4bc09f9ac50d84bde736*" -d '{"payload":
>> "my-secret-here", "payload_content_type": "text/plain"}'
>> http://localhost:9311/v1/secrets
>> *Authentication required*[root@keystone-versiontest ~]#
>>
>>  The contents of the admin.opensrc file is as given below :
>>
>>  [root@keystone-versiontest ~]# cat admin.openrc
>> export OS_USERNAME=admin
>> export OS_TENANT_NAME=admin
>> export OS_PASSWORD=admin
>> export OS_AUTH_URL=https://169.54.204.69:35357/v3
>> export OS_REGION_NAME=RegionOne
>> export OS_IDENTITY_API_VERSION=3
>> export OS_USER_DOMAIN_ID=default
>> export OS_PROJECT_DOMAIN_ID=default
>>
>>
>>  And also I have attached the  barbican-api-paste.ini and
>> barbican-ad

Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

[Kyle Mestery]

On Wed, Apr 8, 2015 at 10:14 AM, Edgar Magana 
wrote:

>  Kyle,
>
>  Thank you for your answers and also for organizing this coding sprint.
> I would like to rephrase my question as follows.
> If you are elected as Neutron PTL for the Liberty Cycle, would you
> consider to have either of the following options for the M cycle?:
>
>1. Move the next coding sprint at least one month after the “M” summit
>2. Having both a sprint coding and a formal mid-cycle meet-up
>
> I know how hard is to organize these sessions and I by no means wanted to
> change people plans for attending the one in June 2015. However, raising my
> concerns and suggestions early in the process seems to be a good approach.
>
> The Liberty coding spring is actually more than a month after the Liberty
Summit, so the M coding spring would be the same. I don't think having a
coding spring and a mid-cycle makes sense. In fact, I am against mid-cycles
where the focus is not on code. Personally, we need to continue evolving
the projects in OpenStack so decisions do not need to be made in person.
Mid-cycles perpetuate the notion you have to go there and be present so you
can be a part of the decision making process. Coding sprints are focused on
actually writing code together. Thus, I won't support mid-cycles where
decisions are expected to be made, but will continue to support coding
sprints.

Hope that makes sense.

Thanks,
Kyle


>  Kind Regards,
>
>  Edgar
>
>   From: Kyle Mestery 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, April 8, 2015 at 6:09 AM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
>
>On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana 
> wrote:
>
>>  Kyle and Neutron Team,
>>
>>  Having the mid-cyle just one month after the Liberty summit does not
>> really fit into the definition of “mid-cycle”. It feels like we are just
>> getting up to speed on Liberty BPs when we need to get ready for three days
>> of sprint coding.
>> Would you consider to move this at least one month after?
>> I really want to go but it feels to soon to request permission to my
>> management team.
>>
>>   Thanks for your concerns Edgar. I guess you're right, and I will stop
> calling this a mid-cycle, and instead just refer to it as a the Neutron
> Liberty Coding Sprint. It's actually worked out really well to have it
> close to the first milestone, we have a lot of things we can do very early
> in the cycle, getting together and pushing towards the first milestone with
> some of them will work well. Like I indicated to Russell, we'll do our best
> to facilitate remote attendees over IRC and maybe Hangouts while we're
> there.
>
>  Thanks!
>  Kyle
>
>
>>  Thanks,
>>
>>  Edgar
>>
>>   From: Kyle Mestery 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, April 7, 2015 at 6:39 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
>>
>>On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant 
>> wrote:
>>
>>> On 04/07/2015 12:33 AM, Ben Pfaff wrote:
>>> > On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote:
>>> >> I know we're not even at the Liberty Design Summit in Vancouver yet,
>>> but I
>>> >> wanted to take this time to announce the Neutron mid-cycle coding
>>> sprint
>>> >> for Liberty. HP has been gracious enough to offer to host at it's Fort
>>> >> Collins, CO offices. The dates are set for June 24-26, this is
>>> >> Wednesday-Friday. I've got additional information on the etherpad [1].
>>> >>
>>> >> We'll set the specific agenda in the coming weeks, but the idea is to
>>> focus
>>> >> on things like the pending neutron-lib work [2] while there, similar
>>> to
>>> >> what we did with the advanced services split in Utah last year. My
>>> >> experience running the past two mid-cycles has been that having these
>>> >> earlier in the cycle has been helpful for landing a lot of work near
>>> the
>>> >> first milestone of a release. I expect this to be the same for
>>> Liberty with
>>> >> the sprint in Fort Collins.
>>> >>
>>> >> Please note attendance is not required at all. We will do our best to
>>> >> facilitate virtual collaboration for those who cannot travel to the
>>> event.
>>> >> I wanted to get this out there for folks who have to book travel in
>>> advance.
>>> >
>>> > I don't know anything about these events.  Naively: would OVN
>>> > development (some of which is in Neutron, much of which is not) be an
>>> > appropriate use of time at the event?
>>>
>>>  Yes, I think putting OVN hacking on the agenda makes a lot of sense!
>> I'll add it to the etherpad now.
>>
>>
>>> I suspect so.  FWIW, I'm not sure I'll be going, though.  The dates
>>>

[openstack-dev] [Neutron][L3] L3 Subteam Meeting Tomorrow

[Carl Baldwin]

I will not be available to chair or attend the L3 sub team meeting
tomorrow.  Are others okay with canceling the meeting?  Let me know if
you have something to discuss.

Carl

__
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] need help regarding openstack

[Deepika Agrawal]

Thnku for ur reply.



On Wed, Apr 8, 2015 at 11:57 AM, Chen, Weiting 
wrote:

>  Could you provide more detail log in sahara?
>
> Your situation usually is because the VMs cannot be ssh, so they are
> waiting for the VMs get ready.
>
> One thing you can do is to make sure you can ssh into the VM using private
> ip/floating ip.
>
>
>
> *From:* Deepika Agrawal [mailto:deepika...@gmail.com]
> *Sent:* Wednesday, April 8, 2015 12:11 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] need help regarding openstack
>
>
>
> hi guys!
>
>  I installed Openstack and in that i installed Hadoop i.e., sahara for
> distributed storage. But the problem I am facing is that when i am going to
> run node cluster, system will go in the waiting state because I have only
> 4GB RAM in my laptop. and my college also dint provide me sufficient space.
> This is for my Btech project. Can Someone tell me what I can be done with
> open stack so that I'll show this to my mentors as my Btech project.
>
> I need help. Please help me.
>
>
>
> --
>
> Deepika Agrawal
>
>
>
> __
> 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
>
>


-- 
Deepika Agrawal
__
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] need help regarding openstack

[Deepika Agrawal]

give me any code for open stack.
i am unable to do it.

On Wed, Apr 8, 2015 at 8:57 PM, Deepika Agrawal 
wrote:

> Thnku for ur reply.
>
>
>
> On Wed, Apr 8, 2015 at 11:57 AM, Chen, Weiting 
> wrote:
>
>>  Could you provide more detail log in sahara?
>>
>> Your situation usually is because the VMs cannot be ssh, so they are
>> waiting for the VMs get ready.
>>
>> One thing you can do is to make sure you can ssh into the VM using
>> private ip/floating ip.
>>
>>
>>
>> *From:* Deepika Agrawal [mailto:deepika...@gmail.com]
>> *Sent:* Wednesday, April 8, 2015 12:11 PM
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* [openstack-dev] need help regarding openstack
>>
>>
>>
>> hi guys!
>>
>>  I installed Openstack and in that i installed Hadoop i.e., sahara for
>> distributed storage. But the problem I am facing is that when i am going to
>> run node cluster, system will go in the waiting state because I have only
>> 4GB RAM in my laptop. and my college also dint provide me sufficient space.
>> This is for my Btech project. Can Someone tell me what I can be done with
>> open stack so that I'll show this to my mentors as my Btech project.
>>
>> I need help. Please help me.
>>
>>
>>
>> --
>>
>> Deepika Agrawal
>>
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Deepika Agrawal
>
>


-- 
Deepika Agrawal
__
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] [Launchpad] Fwd: How to correctly change the bug milestone...

[Timur Sufiev]

The mail being forwarded was originally intended for MIrantis internal
mailing list, but then I've realized that it fits as well to the general
Openstack mailing list.

-- Forwarded message --
From: Timur Sufiev 
Date: Wed, Apr 8, 2015 at 6:22 PM
Subject: How to correctly change the bug milestone...
To: mos-dev 


... or why we shouldn't use Launchpad at all

Hello all!

Recently thanks to our new LP reports tool I've discovered that we "lost" 3
bugs in MOS Horizon. Well, they weren't actually deleted, instead they were
set to "Won't fix" in the Milestone/Series they were originally filed to.
I've decided to find out what it takes to correctly change the bug
milestone to not lose it. Here is the absolute minimum of steps tested on
~10 bugs I've just moved from 6.1 milestone to 7.0.

1. Nominate the bug for series 7.0 (and make sure it's also nominated for
6.1)
2. Change status in 6.1 to "Won't fix"
3. Refresh the page (it's important!)
4. Observe the new link in the rightmost column of the top row in a list of
affected series - 'Mirantis Openstack 6.1' and change it to 'Mirantis
Openstack 7.0'.
5. Repeat for whatever number of bugs you have for the milestone that's
almost soft code-freezed.

That's it! Now, you will see all the bugs (in my case, with 'horizon' tag,
query https://bugs.launchpad.net/mos/+bugs?field.tag=horizon) in the
standard Launchpad view, which wouldn't be the case if they were still
tracked as of 'Mirantis Openstack 6.1' series which got "Won't Fix" status.
Of course, you could also use LP Reports tool, but it's still slower than
native LP UI due to a larger number of calls it makes.

And frankly speaking, I'm eager to see Storyboard project ready to finally
move away from this sordid piece of software called 'Launchpad'.

-- 
Timur Sufiev



-- 
Timur Sufiev
__
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 in the classroom

[Amrith Kumar]

Shaifali,

These are two related but slightly different things. The first is, as you 
suggest, to offer courses that teach OpenStack and cloud computing. The other 
which I believe has broader applicability is to teach computing with OpenStack 
as the exemplar system.

Your suggestion of offering courses through a MOOC is a good one in either 
case, and certainly worth pursuing.

Thanks,

-amrith

From: Shaifali Agrawal [mailto:agrawalshaifal...@gmail.com]
Sent: Wednesday, April 08, 2015 11:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] OpenStack in the classroom

Hello Amrit
I liked the idea of taking OpenStack to the classroom. Thank You for taking the 
initiative and sharing your knowledge of cloud computing and OpenStack with 
students.

I have a suggestion, why don't you offer a 
MOOC,
 preparing video lectures and sharing it with world(not just educational 
institutions in Massachusetts and near Toronto). We can ask to various MOOC 
offering portals(like udacity.com, 
coursera.org etc) to add the course into their list of 
courses or may be let this course offered by OpenStack Foundation only.
This will be really helpful for those who have never studied about cloud 
computing in their regular study courses curriculum and are new to OpenStack. 
Such students/listners will get well prepared and *sequential lectures* to read 
and learn about cloud computing and OpenStack rather than searching on web and 
reading about each new terms that they encounter while hacking in  OpenStack or 
similar fields.

The main reason why am I asking to prepare MOOC is that your effort will reach 
to whole world and also your knowledge sharing will stay alive forever in the 
form of video lectures :)
Also even though I don't have much knowledge in cloud computing and OpenStack 
but if you need someone to work with you, I would love to be that. So please 
let me know if you need an assistant for such stuff.

Thanks!!!

Shaifali Agrawal
about.me/shaifaliagrawal







On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar 
mailto:amr...@tesora.com>> wrote:
CS and EE schools today use open source software as the basis for a lot of 
coursework and as the practical example for several concepts. Most often the 
exemplar system is Linux. Yet if students are even taught about the cloud, they 
often learn about that other cloud company from Seattle.

I think OpenStack is the ideal exemplar system for a whole lot of CS/EE 
courses. No matter what area of computer science you are interested in, there’s 
an OpenStack project (or in some cases several) that you can study.

I think the fact that you can have the entire cloud on your laptop, source code 
and all, is incredibly powerful in the classroom. Not only can you see how the 
system works, but you can also tweak it or fix it if you find something to be 
wrong. Some students also learn about software development methodologies by 
contributing to a fictional open source project. Why do that when they can 
instead be contributing code to a real open source project?

I think there’s a huge opportunity for us to take OpenStack in the Classroom (a 
longer post about my experience doing this last week is at 
http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and 
Kamesh Pemmaraju for helping me with this at short notice.

Let us make (and I’m looking to the Foundation to support this as a formal 
initiative) it a priority to have every university offer courses on computer 
science and cloud computing with OpenStack as the exemplar system.

Personally, I’m going to work with educational institutions in Massachusetts 
and near Toronto (where Tesora has offices, and where I tend to spend most of 
my time) to try and make available a course on cloud computing with OpenStack 
as the exemplar system. I’m going to make the materials, and offer to teach the 
course, and I will contribute the materials to the Foundation.

So this is an open offer to any university in MA and near Toronto; if you want 
someone to develop and deliver a course on cloud computing, please let me know!

I think we can all come together and take OpenStack to the Classrooms so that 
every graduating student interested in cloud computing has a working knowledge 
of OpenStack.

Thanks,

-amrith


Amrith Kumar, Founder & CTO

[tesora-small]

Mobile: 978-563-9590

Direct: 978-707-8010 x1002

Twitter: @amrithkumar

Skype: amrith.skype

Check out our blog



Twitter 
Facebook 
LinkedIn

Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

[Edgar Magana]

Kyle,

I do understand it. My suggestions were related to timing and not related to 
the objectives of this meet-up, I do agree totally with you that we should get 
together to make a big push on the code and BPs and not to discuss and  make 
more decisions.
For the next coding sprint I will plan it better with my sponsor company, in 
the meantime let me apologize with you and the Neutron team because I will not 
be able to attend it in person but I will be in IRC and if available hangouts.

Cheers,

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 8, 2015 at 8:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

On Wed, Apr 8, 2015 at 10:14 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Kyle,

Thank you for your answers and also for organizing this coding sprint.
I would like to rephrase my question as follows.
If you are elected as Neutron PTL for the Liberty Cycle, would you consider to 
have either of the following options for the M cycle?:

  1.  Move the next coding sprint at least one month after the “M” summit
  2.  Having both a sprint coding and a formal mid-cycle meet-up

I know how hard is to organize these sessions and I by no means wanted to 
change people plans for attending the one in June 2015. However, raising my 
concerns and suggestions early in the process seems to be a good approach.

The Liberty coding spring is actually more than a month after the Liberty 
Summit, so the M coding spring would be the same. I don't think having a coding 
spring and a mid-cycle makes sense. In fact, I am against mid-cycles where the 
focus is not on code. Personally, we need to continue evolving the projects in 
OpenStack so decisions do not need to be made in person. Mid-cycles perpetuate 
the notion you have to go there and be present so you can be a part of the 
decision making process. Coding sprints are focused on actually writing code 
together. Thus, I won't support mid-cycles where decisions are expected to be 
made, but will continue to support coding sprints.

Hope that makes sense.

Thanks,
Kyle

Kind Regards,

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 8, 2015 at 6:09 AM

To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Kyle and Neutron Team,

Having the mid-cyle just one month after the Liberty summit does not really fit 
into the definition of “mid-cycle”. It feels like we are just getting up to 
speed on Liberty BPs when we need to get ready for three days of sprint coding.
Would you consider to move this at least one month after?
I really want to go but it feels to soon to request permission to my management 
team.

Thanks for your concerns Edgar. I guess you're right, and I will stop calling 
this a mid-cycle, and instead just refer to it as a the Neutron Liberty Coding 
Sprint. It's actually worked out really well to have it close to the first 
milestone, we have a lot of things we can do very early in the cycle, getting 
together and pushing towards the first milestone with some of them will work 
well. Like I indicated to Russell, we'll do our best to facilitate remote 
attendees over IRC and maybe Hangouts while we're there.

Thanks!
Kyle

Thanks,

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 7, 2015 at 6:39 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint

On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant 
mailto:rbry...@redhat.com>> wrote:
On 04/07/2015 12:33 AM, Ben Pfaff wrote:
> On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote:
>> I know we're not even at the Liberty Design Summit in Vancouver yet, but I
>> wanted to take this time to announce the Neutron mid-cycle coding sprint
>> for Liberty. HP has been gracious enough to offer to host at it's Fort
>> Collins, CO offices. The dates are set for June 24-26, this is
>> Wednesday-Friday. I've got additional information on the etherpad [1].
>>
>> We'll set the specific agenda in the coming weeks, but the idea is to focus
>> on things like the pending neutron-lib work [2] while there, similar to
>> what we did with the advanced services split in Utah last year. My
>> experience running th

[openstack-dev] Neutron and ACLs

[Rich Wellner]

Hello everyone,

I (and my sponsor) are interested in adding ACLs to neutron and after 
trying IRC, emailing some githubbers directly and asking in a couple 
other places I've been told that this might be the place to have the 
discussion.


Here's what I've been told so far:

1) There was a proposal for Quantum ACLs that was never approved.

2) There might be a push to put ACLs in Keystone and have other services 
depend on this central resource for ACL information.


3) Swift has ACLs built into it (notably, not using Keystone)

4) I don't see ACLs in any service other than Swift.

So my question is: How can I meaningfully engage with the right people 
to understand what the current thoughts are for ACLs for all of open 
stack as well as Neutron?


If you google my name and open source you'll see that I've been in the 
game a while and have worked in a few different communities. As such, I 
found one piece of advice I was given while researching Neutron "code up 
your proposal and submit it" to be a bit naive. It's clear there have 
been some conversations about this in the past and I would really not 
want to spend a couple months starting from zero, coming up with a 
solution that *I* like and is objectively good but have it rejected 
because the community already has inertia going in a different direction.


So what I think I need to understand is something like:

o What are the current thoughts on ACLs globally and with regard to Neutron
o What people should I engage with (both for neutron and other services 
like keystone)


Thanks in advance to all who reply.

rw2



__
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 and ACLs

[Kevin Benton]

What do you mean by ACLs? Is it anything similar to the following?
https://review.openstack.org/#/c/132661/

On Wed, Apr 8, 2015 at 9:02 AM, Rich Wellner  wrote:

> Hello everyone,
>
> I (and my sponsor) are interested in adding ACLs to neutron and after
> trying IRC, emailing some githubbers directly and asking in a couple other
> places I've been told that this might be the place to have the discussion.
>
> Here's what I've been told so far:
>
> 1) There was a proposal for Quantum ACLs that was never approved.
>
> 2) There might be a push to put ACLs in Keystone and have other services
> depend on this central resource for ACL information.
>
> 3) Swift has ACLs built into it (notably, not using Keystone)
>
> 4) I don't see ACLs in any service other than Swift.
>
> So my question is: How can I meaningfully engage with the right people to
> understand what the current thoughts are for ACLs for all of open stack as
> well as Neutron?
>
> If you google my name and open source you'll see that I've been in the
> game a while and have worked in a few different communities. As such, I
> found one piece of advice I was given while researching Neutron "code up
> your proposal and submit it" to be a bit naive. It's clear there have been
> some conversations about this in the past and I would really not want to
> spend a couple months starting from zero, coming up with a solution that
> *I* like and is objectively good but have it rejected because the community
> already has inertia going in a different direction.
>
> So what I think I need to understand is something like:
>
> o What are the current thoughts on ACLs globally and with regard to Neutron
> o What people should I engage with (both for neutron and other services
> like keystone)
>
> Thanks in advance to all who reply.
>
> rw2
>
>
>
> __
> 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
>



-- 
Kevin Benton
__
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] how to send messages (and events) to our users

[Clint Byrum]

Excerpts from Angus Salkeld's message of 2015-04-06 19:55:37 -0700:
> Hi all
> 
> For quite some time we (Heat team) have wanted to be able to send messages
> to our
> users (by user I do not mean the Operator, but the User that is interacting
> with the client).
> 
> What do I mean by "user messages", and how do they differ from our current
> log messages
> and notifications?
> - Our current logs are for the operator and have information that the user
> should not have
>   (ip addresses, hostnames, configuration options, other tenant info etc..)
> - Our notifications (that Ceilometer uses) *could* be used, but I am not
> sure if it quite fits.
>   (they seem a bit heavy weight for a log message and aimed at higher level
> events)
> 
> These messages could be (based on Heat's use case):
> 
> - Specific user oriented log messages (distinct from our normal operator
> logs)

These currently go in the Heat events API, yes?

> - Deprecation messages (if they are using old resource properties/template
> features)

I think this could fit with the bits above.

> - Progress and resource state changes (an application doesn't want to poll
> an api for a state change)

These also go in the current Heat events.

> - Automated actions (autoscaling events, time based actions)

As do these?

> - Potentially integrated server logs (from in guest agents)
> 
> I wanted to raise this to "[all]" as it would be great to have a general
> solution that
> all projects can make use of.
> 
> What do we have now:
> - The user can not get any kind of log message from services. The closest
> thing
>   ATM is the notifications in Ceilometer, but I have the feeling that these
> have a different aim.
> - nova console log
> - Heat has a DB "event" table for users (we have long wanted to get rid of
> this)

So if we forget the DB part of it, the API is also lacking things like
pagination and search that one would want in an event/logging API.

> 
> What do other clouds provide:
> - https://devcenter.heroku.com/articles/logging
> - https://cloud.google.com/logging/docs/
> - https://aws.amazon.com/blogs/aws/cloudwatch-log-service/
> - http://aws.amazon.com/cloudtrail/
> (other examples...)
> 
> What are some options we could investigate:
> 1. remote syslog
> The user provides a rsyslog server IP/port and we send their messages
> to that.
> [pros] simple, and the user could also send their server's log messages
> to the same
>   rsyslog - great visibility into what is going on.
> 
>   There are great tools like loggly/logstash/papertrailapp that
> source logs from remote syslog
>   It leaves the user in control of what tools they get to use.
> 
> [cons] Would we become a spam agent (just sending traffic to an
> IP/Port) - I guess that's how remote syslog
>works. I am not sure if this is an issue or not?
> 
>   This might be a lesser solution for the use case of "an
> application doesn't want to poll an api for a state change"
> 
>   I am not sure how we would integrate this with horizon.
> 

I think this one puts too much burden on the user to setup a good
receiver.

> 2. Zaqar
> We send the messages to a queue in Zaqar.
> [pros] multi tenant OpenStack project for messaging!
> 
> [cons] I don't think Zaqar is installed in most installations (tho'
> please correct me here if this
>is wrong). I know Mirantis does not currently support Zaqar,
> so that would be a problem for me.
> 
>   There is not the level of external tooling like in option "1"
> (logstash and friends)
>

I agree with your con, and would also add that after the long
discussions we had in the past we had some concerns about scaling.

> 3. Other options:
>Please chip in with suggestions/links!
> 

There's this:

https://wiki.openstack.org/wiki/Cue

I think that could be a bit like 1, but provide the user with an easy
target for the messages.

I also want to point out that what I'd actually rather see is that all
of the services provide functionality like this. Users would be served
by having an event stream from Nova telling them when their instances
are active, deleted, stopped, started, error, etc.

Also, I really liked Sandy's suggestion to use the notifications on the
backend, and then funnel them into something that the user can consume.
The project they have, yagi, for putting them into atom feeds is pretty
interesting. If we could give people a simple API that says "subscribe
to Nova/Cinder/Heat/etc. notifications for instance X, and put them
in an atom feed", that seems like something that would make sense as
an under-the-cloud service that would be relatively low cost and would
ultimately reduce load on API servers.

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

Re: [openstack-dev] OpenStack in the classroom

[Ganesh Narayanan (ganeshna)]

Yes, offering courses on OpenStack in Coursera kind of platform will be a good 
idea.  Currently there are some cloud computing courses being offered in 
Coursera along with a capstone project:
https://www.coursera.org/specialization/cloudcomputing/19/courses

Thanks,
Ganesh

From: Amrith Kumar mailto:amr...@tesora.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, 8 April 2015 9:01 pm
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] OpenStack in the classroom

Shaifali,

These are two related but slightly different things. The first is, as you 
suggest, to offer courses that teach OpenStack and cloud computing. The other 
which I believe has broader applicability is to teach computing with OpenStack 
as the exemplar system.

Your suggestion of offering courses through a MOOC is a good one in either 
case, and certainly worth pursuing.

Thanks,

-amrith

From: Shaifali Agrawal [mailto:agrawalshaifal...@gmail.com]
Sent: Wednesday, April 08, 2015 11:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] OpenStack in the classroom

Hello Amrit
I liked the idea of taking OpenStack to the classroom. Thank You for taking the 
initiative and sharing your knowledge of cloud computing and OpenStack with 
students.

I have a suggestion, why don't you offer a 
MOOC,
 preparing video lectures and sharing it with world(not just educational 
institutions in Massachusetts and near Toronto). We can ask to various MOOC 
offering portals(like udacity.com, 
coursera.org etc) to add the course into their list of 
courses or may be let this course offered by OpenStack Foundation only.
This will be really helpful for those who have never studied about cloud 
computing in their regular study courses curriculum and are new to OpenStack. 
Such students/listners will get well prepared and *sequential lectures* to read 
and learn about cloud computing and OpenStack rather than searching on web and 
reading about each new terms that they encounter while hacking in  OpenStack or 
similar fields.

The main reason why am I asking to prepare MOOC is that your effort will reach 
to whole world and also your knowledge sharing will stay alive forever in the 
form of video lectures :)
Also even though I don't have much knowledge in cloud computing and OpenStack 
but if you need someone to work with you, I would love to be that. So please 
let me know if you need an assistant for such stuff.

Thanks!!!

Shaifali Agrawal
about.me/shaifaliagrawal







On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar 
mailto:amr...@tesora.com>> wrote:
CS and EE schools today use open source software as the basis for a lot of 
coursework and as the practical example for several concepts. Most often the 
exemplar system is Linux. Yet if students are even taught about the cloud, they 
often learn about that other cloud company from Seattle.

I think OpenStack is the ideal exemplar system for a whole lot of CS/EE 
courses. No matter what area of computer science you are interested in, there’s 
an OpenStack project (or in some cases several) that you can study.

I think the fact that you can have the entire cloud on your laptop, source code 
and all, is incredibly powerful in the classroom. Not only can you see how the 
system works, but you can also tweak it or fix it if you find something to be 
wrong. Some students also learn about software development methodologies by 
contributing to a fictional open source project. Why do that when they can 
instead be contributing code to a real open source project?

I think there’s a huge opportunity for us to take OpenStack in the Classroom (a 
longer post about my experience doing this last week is at 
http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and 
Kamesh Pemmaraju for helping me with this at short notice.

Let us make (and I’m looking to the Foundation to support this as a formal 
initiative) it a priority to have every university offer courses on computer 
science and cloud computing with OpenStack as the exemplar system.

Personally, I’m going to work with educational institutions in Massachusetts 
and near Toronto (where Tesora has offices, and where I tend to spend most of 
my time) to try and make available a course on cloud computing with OpenStack 
as the exemplar system. I’m going to make the materials, and offer to teach the 
course, and I will contribute the materials to the Foundation.

So this is an open offer to any university in MA and near Toronto

Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

[Dolph Mathews]

On Wed, Apr 8, 2015 at 9:33 AM, Ryan Brown  wrote:

> On 04/08/2015 09:12 AM, Flavio Percoco wrote:
> > On 08/04/15 08:59 -0400, Doug Hellmann wrote:
> >> Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:
> >>> On 7 April 2015 at 05:11, Joe Gordon  wrote:
> >>> >
> >>> >
> >>> > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
> >>> 
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic
> >>>  wrote:
> >>> >>>
> >>> >>> Jay,
> >>> >>>
> >>> >>>
> >>>  Not far, IMHO. 100ms difference in startup time isn't something we
> >>>  should spend much time optimizing. There's bigger fish to fry.
> >>> >>>
> >>> >>>
> >>> >>> I agree that priority of this task shouldn't be critical or even
> >>> high,
> >>> >>> and that there are other places that can be improved in OpenStack.
> >>> >>>
> >>> >>> In other hand this one is as well big source of UX issues that we
> >>> have in
> >>> >>> OpenStack..
> >>> >>>
> >>> >>> For example:
> >>> >>>
> >>> >>> 1) You would like to run some command X times where X is pretty big
> >>> >>> (admins likes to do this via bash loops). If you can execute all
> >>> of them for
> >>> >>> 1 and not 10 minutes you will get happier end user.
> >>> >>
> >>> >>
> >>> >> +1 I'm fully in support of this effort. Shaving 100ms off the
> >>> startup time
> >>> >> of a frequently used library means that you'll save that 100ms
> >>> over and
> >>> >> over, adding up to a huge win.
> >>> >>
> >>> >
> >>> >
> >>> > Another data point on how slow our libraries/CLIs can be:
> >>> >
> >>> > $ time openstack -h
> >>> > 
> >>> > real0m2.491s
> >>> > user0m2.378s
> >>> > sys 0m0.111s
> >>>
> >>>
> >>> pbr should be snappy - taking 100ms to get the version is wrong.
> >>
> >> I have always considered pbr a packaging/installation time tool, and not
> >> something that would be used at runtime. Why are we using pbr to get the
> >> version of an installed package, instead of asking pkg_resources?
> >
> > Just wanted to +1 the above.
> >
> > I've also considered pbr a packaging/install tool. Furthermore, I
> > believe having it as a runtime requirement makes packagers life more
> > complicated because that means pbr will obviously need to be added as
> > a runtime requirement for that package.
> >
>
> RDO actually patches out calls to pbr to avoid the runtime requirement,
> FWIW.
>

How does RDO handle --version arguments?


>
> --
> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>
> __
> 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] [barbican] Utilizing the KMIP plugin

[Christopher N Solis]

Hey John.
I do have the barbican-api.conf file located in the /etc/barbican folder.
But that does not seem to be the one that barbican
reads from. It seems to be reading from the barbican-api.conf file locate
in my home directory.
Either way, both have the exact same configurations.

I also checked the setup.cfg file and it does have the line for
kmip_plugin .

Regards,

  CHRIS SOLIS



From:   John Wood 
To: "openstack-dev@lists.openstack.org"

Date:   04/07/2015 10:39 AM
Subject:Re: [openstack-dev] [barbican] Utilizing the KMIP plugin



Hello Christopher,

Just checking, but is that barbican-api.conf file located in your local
system’s /etc/barbican folder? If not that is the preferred place for local
development. Modifying the copy that is in your local git repository will
have no effect.

Also, please double check that your local git repository’s setup.cfg has a
line like this in there (at/around #35):

kmip_plugin = barbican.plugin.kmip_secret_store:KMIPSecretStore

Thanks,
John




From: Christopher N Solis 
Reply-To: "openstack-dev@lists.openstack.org" <
openstack-dev@lists.openstack.org>
Date: Monday, April 6, 2015 at 10:25 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [barbican] Utilizing the KMIP plugin



Hello!

Sorry to Kaitlin Farr for not responding directly to your e-mail.
My openstack settings were misconfigured and I was not receiving e-mail
from the dev mailing list.
Thanks for looking into the issue.

I double checked the permissions at the bottom of the kmip_plugin part in
the barbican-api.conf file
and they are set to 400.

I would also like to note that I do not think the code ever actually
entered the __init__ function
of KMIPSecretStore. I put a breakpoint in the __init__ function but the
debugger never gets open.
The error occurs and returns without ever seeming to enter the init
function.

Here are the parts of the barbican-api.conf file that concern the
kmip_plugin:
.
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = kmip_plugin
.
[kmip_plugin]
username = '**'
password = '**'
host = 
port = 
keyfile = '/etc/barbican/rootCA.key'
certfile = '/etc/barbican/rootCA.pem'
ca_certs = '/etc/barbican/rootCA.pem'
...

Thank You!!

Regards,
Christopher Solis
__
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] Neutron scaling datapoints?

[Neil Jerram]

My team is working on experiments looking at how far the Neutron server
will scale, with increasing numbers of compute hosts and VMs.  Does
anyone have any datapoints on this that they can share?  Or any clever
hints?

I'm already aware of the following ones:

https://javacruft.wordpress.com/2014/06/18/168k-instances/
 Icehouse
 118 compute hosts
 80 Neutron server processes (10 per core on each of 8 cores, on the
 controller node)
 27,000 VMs - but only after disabling all security/iptables

http://www.opencontrail.org/openstack-neutron-at-scale/
 1000 hosts
 5000 VMs
 3 Neutron servers (via a load balancer)
 But doesn't describe if any specific configuration is needed for this.
 (Other than using OpenContrail! :-))

Many 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

[openstack-dev] [Trove] PTL Candidacy

[Nikhil Manchanda]

I'd like to announce my candidacy for the PTL role of the Database
(Trove) program for Liberty.

I have been the PTL for Trove for Juno, and Kilo. During this time
frame we made some really good progress on multiple fronts. In Kilo
specifically, we completed the oslo-messaging integration work that
we had started in Juno. We added support for GTID based mysql
master-slave replication.  We added support for new datastores
including CouchDB, Vertica and DB2, and an initial implementation of
clustering for Vertica as well.  We furthered the testability of
Trove, by moving all testing off of our deprecated 3rd party CI
infrastructure and fully into OpenStack CI. We are continuing to make
good progress updating and cleaning up our developer docs, install
guide, and user documentation.

For Liberty, I'd like us to keep working on clustering, with the end
goal of being able to provision fully HA database clusters for the
various datastores in Trove. This means a continued focus on
clustering for datastores including a semi-synchronous mysql
clustering solution.  I'd also like to ensure that we make progress
towards our goal of integrating trove with a monitoring solution to
enable scenarios like auto-failover, which will be crucial to HA and a
fully managed database service. Additionally, I'd like to keep our
momentum going with regards to improving Trove testability
documentation, and reviews.

Some of the other work-items that I hope we can get to in Liberty include:

- Separating out the Guest Agent from the other Trove services.
- User access of datastore logs.
- Scheduled Tasks for instances - especially backups.
- Tackling control plane, guest agent, and datastore updates

No PTL candidate email is complete without some commit / review stats,
so here they are:

* My Patches:
  https://review.openstack.org/#/q/owner:slicknik,n,z

* My Reviews:
  https://review.openstack.org/#/q/-owner:slicknik+reviewer:slicknik,n,z

Thanks for taking the time to make it this far,
-Nikhil
__
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] how to send messages (and events) to our users

[Sandy Walsh]

>From: Clint Byrum 
>Sent: Wednesday, April 8, 2015 1:15 PM
>
>There's this:
>
>https://wiki.openstack.org/wiki/Cue

Hmm, that looks interesting. Will read.

>I also want to point out that what I'd actually rather see is that all
>of the services provide functionality like this. Users would be served
>by having an event stream from Nova telling them when their instances
>are active, deleted, stopped, started, error, etc.
>
>Also, I really liked Sandy's suggestion to use the notifications on the
>backend, and then funnel them into something that the user can consume.
>The project they have, yagi, for putting them into atom feeds is pretty
>interesting. If we could give people a simple API that says "subscribe
>to Nova/Cinder/Heat/etc. notifications for instance X, and put them
>in an atom feed", that seems like something that would make sense as
>an under-the-cloud service that would be relatively low cost and would
>ultimately reduce load on API servers.

THIS!

Yes. It would be so good to pull apart the state-machine that is Nova and
just emit completed actions via notifications. Then, have something like
TaskFlow externalize the orchestration. Do away with RPC-over-AMQP. 

And, anyone that is interested in the transitions can eavesdrop on the
notifications.

In our transition from StackTach.v2 to StackTach.v3 in production we simply
cloned the notification feeds so the two systems can run in parallel*. No
changes to OpenStack, no disruption of service. Later, we'll just kill off 
the v2 queues.

-S

* we did this in Yagi, since olso-messaging doesn't support multiple queues
from one routing key. 
__
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 and ACLs

[Rich Wellner]

On 4/8/15 11:17 AM, Kevin Benton wrote:
What do you mean by ACLs? Is it anything similar to the following? 
https://review.openstack.org/#/c/132661/
Yes, our goals are very closely aligned with yours. And the rst doc as 
well as the messages on that thread file in a lot of gaps for me. Thanks.


What's your plan going forward?

rw2


__
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] [Trove] PTL Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 8, 2015 at 9:33 AM, Nikhil Manchanda  wrote:
> I'd like to announce my candidacy for the PTL role of the Database
> (Trove) program for Liberty.
>
> I have been the PTL for Trove for Juno, and Kilo. During this time
> frame we made some really good progress on multiple fronts. In Kilo
> specifically, we completed the oslo-messaging integration work that
> we had started in Juno. We added support for GTID based mysql
> master-slave replication.  We added support for new datastores
> including CouchDB, Vertica and DB2, and an initial implementation of
> clustering for Vertica as well.  We furthered the testability of
> Trove, by moving all testing off of our deprecated 3rd party CI
> infrastructure and fully into OpenStack CI. We are continuing to make
> good progress updating and cleaning up our developer docs, install
> guide, and user documentation.
>
> For Liberty, I'd like us to keep working on clustering, with the end
> goal of being able to provision fully HA database clusters for the
> various datastores in Trove. This means a continued focus on
> clustering for datastores including a semi-synchronous mysql
> clustering solution.  I'd also like to ensure that we make progress
> towards our goal of integrating trove with a monitoring solution to
> enable scenarios like auto-failover, which will be crucial to HA and a
> fully managed database service. Additionally, I'd like to keep our
> momentum going with regards to improving Trove testability
> documentation, and reviews.
>
> Some of the other work-items that I hope we can get to in Liberty include:
>
> - Separating out the Guest Agent from the other Trove services.
> - User access of datastore logs.
> - Scheduled Tasks for instances - especially backups.
> - Tackling control plane, guest agent, and datastore updates
>
> No PTL candidate email is complete without some commit / review stats,
> so here they are:
>
> * My Patches:
>   https://review.openstack.org/#/q/owner:slicknik,n,z
>
> * My Reviews:
>   https://review.openstack.org/#/q/-owner:slicknik+reviewer:slicknik,n,z
>
> Thanks for taking the time to make it this far,
> -Nikhil
>
>
> __
> 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
>



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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 and ACLs

[Kevin Benton]

My plan is to repropose that for Liberty. I will re upload it to the spec
repo in the next couple of weeks. When I do that it would be great to get
your feedback. Perhaps we can divide up the work or you can expand the
model to things other than subnets.
On Apr 8, 2015 9:43 AM, "Rich Wellner"  wrote:

> On 4/8/15 11:17 AM, Kevin Benton wrote:
>
>> What do you mean by ACLs? Is it anything similar to the following?
>> https://review.openstack.org/#/c/132661/
>>
> Yes, our goals are very closely aligned with yours. And the rst doc as
> well as the messages on that thread file in a lot of gaps for me. Thanks.
>
> What's your plan going forward?
>
> rw2
>
>
> __
> 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] Neutron scaling datapoints?

[Mike Spreitzer]

Are you looking at scaling the numbers of tenants, Neutron routers, and 
tenant networks as you scale hosts and guests?  I think this is a 
plausible way to grow.  The compartmentalizations that comes with growing 
those things may make a difference in results.

Thanks,
Mike



From:   Neil Jerram 
To: 
Date:   04/08/2015 12:29 PM
Subject:[openstack-dev] [neutron] Neutron scaling datapoints?



My team is working on experiments looking at how far the Neutron server
will scale, with increasing numbers of compute hosts and VMs.  Does
anyone have any datapoints on this that they can share?  Or any clever
hints?

I'm already aware of the following ones:

https://javacruft.wordpress.com/2014/06/18/168k-instances/
 Icehouse
 118 compute hosts
 80 Neutron server processes (10 per core on each of 8 cores, on the
 controller node)
 27,000 VMs - but only after disabling all security/iptables

http://www.opencontrail.org/openstack-neutron-at-scale/
 1000 hosts
 5000 VMs
 3 Neutron servers (via a load balancer)
 But doesn't describe if any specific configuration is needed for this.
 (Other than using OpenContrail! :-))

Many 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


__
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] [qa][nova][ironic] How to run microversions tests on the gate

[Adam Gandelman]

FWIW the Ironic microversion test patch mentioned on gerrit is only
targeted at Tempest because thats where the API tests currenty live and
from which our infra is setup to run. The eventual goal is to move all of
tempest.api.baremetal.* to the Ironic tree, there's no reason why those
proposed new tests wouldn't either.

Those tests were designed to allow running against all available
microversions or some configured subset, and to ensure tests for previous
microversions run against newer.  I think its perfectly feasible to test
many microversions in tree or out, provided test coverage is kept
sufficiently up to date as the APIs evolve.

Adam

On Wed, Apr 8, 2015 at 7:45 AM, Jay Pipes  wrote:

> On 04/08/2015 05:24 AM, Sean Dague wrote:
>
>> On 04/08/2015 07:38 AM, Dmitry Tantsur wrote:
>>
>>> On 04/08/2015 12:53 PM, Sean Dague wrote:
>>>
 On 04/08/2015 03:58 AM, Dmitry Tantsur wrote:

> On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote:
>
>> Hi,
>>
>> Now Nova and Ironic have implemented API microversions in Kilo.
>> Nova's microversions are v2.1 - v2.3.
>> Ironic's microversions are v1.1 - v1.6.
>>
>> Now Tempest is testing the lowest microversion on the gate, and
>> Ironic's microversions test patch[1] is on the gerrit.
>> Before merging the patch, I'd like to propose consistent test way for
>> microversions of Nova and Ironic.
>>
>> My suggestion is the test target microversions are:
>> * the lowest microversion
>> * the biggest microversion, but don't use the keyword "latest" on a
>> header and these microversions tests are operated on different gate
>> jobs.
>>
>> The lowest microversion is already tested on check-tempest-dsvm-full
>> or something, so this proposes just to add the biggest microversion
>> job like check-tempest-dsvm-full-big-microversion.
>>
>> [background]
>> In long-term, these microversions continue increasing and it is
>> difficult to run Tempest for all microversions on the gate because of
>> test workload. So I feel we need to select microversions which are
>> tested on the gate for efficient testing.
>>
>> [the lowest microversion]
>> On microversion mechanism, if a client *doesn't* specify favorite
>> microversion in its request header, a Nova/Ironic server considers the
>> request as the lowest microversion. So the lowest microversion is
>> default behavior and important. I think we need to test it at least.
>>
>> [the biggest microversion]
>> On microversion mechanism, if a client specify the keyword "latest" in
>> its request header instead of microversion, a Nova/Ironic server works
>> on the biggest microversion behavior.
>> During the development, there is time lag between each project dev and
>> Tempest dev. After adding a new API on a project, corresponding tests
>> are added to Tempest in most cases. So if specifying the keyword
>> "latest", Tempest would not handle the request/response and fail,
>> because Tempest can not catch the latest API changes until
>> corresponding Tempest patch is merged.
>> So it is necessary to have the target microversion config option in
>> Tempest and pass specific biggest microversion to Tempest with
>> openstack-infra/project-config.
>>
>> Any thoughts?
>>
>
> Hi! I've already stated this point in #openstack-ironic and I'd like to
> reiterate: if we test only the lowest and the highest microversions
> essentially means (or at least might mean) that the other are broken.
> At
> least in Ironic only some unit tests actually touch code paths for
> versions 1.2-1.5. As we really can't test too many versions, I suggest
> we stop producing a microversion for every API feature feature change
> in
> L. No idea what to do with 1.2-1.5 now except for politely asking
> people
> not to use them :D
>

 Tempest shouldn't be the *only* test for a project API. The projects
 themselves need to take some ownership for their API getting full
 coverage with in tree testing, including whatever microversion strategy
 they are employing.

>>>
>>> Agreed, but in-tree testing is also not feasible with too many version.
>>> Even now we have 7 (1.0-1.6), if it continues, we'll have not less than
>>> 12 after L, 18 after M, etc. And we have to test every one of them for
>>> regressions at least occasionally, provided that we don't start to
>>> aggressively deprecated microversions. If we do start, then we'll start
>>> breaking people even more often, than we should. E.g. if someone writes
>>> a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will
>>> break, though maybe it can actually work with new API.
>>>
>>
>> I do not understand how in tree testing is not feasible. In tree you
>> have insights into all the branching that occurs within code so can very
>> clearl

Re: [openstack-dev] Neutron and ACLs

[Rich Wellner]

Yeah, sounds like a plan.

FWIW, our target implementation will be Arista switches.

rw2

On 4/8/15 11:52 AM, Kevin Benton wrote:


My plan is to repropose that for Liberty. I will re upload it to the 
spec repo in the next couple of weeks. When I do that it would be 
great to get your feedback. Perhaps we can divide up the work or you 
can expand the model to things other than subnets.


On Apr 8, 2015 9:43 AM, "Rich Wellner" > wrote:


On 4/8/15 11:17 AM, Kevin Benton wrote:

What do you mean by ACLs? Is it anything similar to the
following? https://review.openstack.org/#/c/132661/

Yes, our goals are very closely aligned with yours. And the rst
doc as well as the messages on that thread file in a lot of gaps
for me. Thanks.

What's your plan going forward?

rw2


__
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] [all] how to send messages (and events) to our users

[Duncan Thomas]

>From a security point, it certainly scares the hell out of me

On 7 April 2015 at 08:45, Chris Friesen  wrote:

> On 04/06/2015 10:08 PM, Angus Salkeld wrote:
>
>> On Tue, Apr 7, 2015 at 1:53 PM, Chris Friesen <
>> chris.frie...@windriver.com
>> > wrote:
>>
>> On 04/06/2015 08:55 PM, Angus Salkeld wrote:
>>
>> Hi all
>>
>> For quite some time we (Heat team) have wanted to be able to send
>> messages to our
>> users (by user I do not mean the Operator, but the User that is
>> interacting with
>> the client).
>>
>> What do I mean by "user messages", and how do they differ from our
>> current log
>> messages and notifications?
>> - Our current logs are for the operator and have information that
>> the user
>> should not have
>> (ip addresses, hostnames, configuration options, other tenant
>> info
>> etc..)
>> - Our notifications (that Ceilometer uses) *could* be used, but I
>> am not
>> sure if
>> it quite fits.
>> (they seem a bit heavy weight for a log message and aimed at
>> higher
>> level events)
>>
>>
>> 
>>
>> What are some options we could investigate:
>> 1. remote syslog
>> 2. Zaqar
>> 3. Other options:
>>  Please chip in with suggestions/links!
>>
>>
>> What about a per-user notification topic using the existing
>> notification
>> backend?
>>
>>
>> Wouldn't that require the Operator to provide the end user with access to
>> the
>> message bus?
>> Seems scary to me.
>>
>
> AMQP supports access controls, so is it really all that scary?  Maybe set
> up a virtual host per user if we want to be paranoid? (Just throwing it out
> there as an option since we're already using it...)
>
>
> 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
>



-- 
Duncan Thomas
__
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] [qa] official clients and tempest

[David Kranz]

Since tempest no longer uses the official clients as a literal code 
dependency, except for the cli tests which are being removed, the 
clients have been dropping from requirements.txt. But when debugging 
issues uncovered by tempest, or when debugging tempest itself, it is 
useful to use the cli to check various things. I think it would be a 
good service to users of tempest to include the client libraries when 
tempest is installed on a machine. Is there a reason to not do this?


 -David

__
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] [Rally] PTL candidacy

[Elizabeth K. Joseph]

On Wed, Apr 8, 2015 at 8:02 AM, Boris Pavlovic  wrote:
> Hi,
>
> As far as https://review.openstack.org/#/c/169357/ Rally is part of
> OpenStack, I would like to announce my candidacy for Rally  / Benchmark as a
> Services.

Tristan has informed me that we've confirmed with Thierry that
recently-added projects Rally and Security won't run elections this
time around and will keep their current PTLs.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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][L3] L3 Subteam Meeting Tomorrow

[John Belamaric]

Carl,

I did want to discuss the refactoring for IPAM but we can do it over the
ML. Looks like Salvatore didn't have a chance to play with it over the
weekend, so I will be looking at it today (hopefully).

John


On 4/8/15, 11:26 AM, "Carl Baldwin"  wrote:

>I will not be available to chair or attend the L3 sub team meeting
>tomorrow.  Are others okay with canceling the meeting?  Let me know if
>you have something to discuss.
>
>Carl
>
>__
>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][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

[Ben Nemec]

On 04/08/2015 11:25 AM, Dolph Mathews wrote:
> On Wed, Apr 8, 2015 at 9:33 AM, Ryan Brown  wrote:
> 
>> On 04/08/2015 09:12 AM, Flavio Percoco wrote:
>>> On 08/04/15 08:59 -0400, Doug Hellmann wrote:
 Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:
> On 7 April 2015 at 05:11, Joe Gordon  wrote:
>>
>>
>> On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
> 
>> wrote:
>>>
>>>
>>> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic
>  wrote:

 Jay,


> Not far, IMHO. 100ms difference in startup time isn't something we
> should spend much time optimizing. There's bigger fish to fry.


 I agree that priority of this task shouldn't be critical or even
> high,
 and that there are other places that can be improved in OpenStack.

 In other hand this one is as well big source of UX issues that we
> have in
 OpenStack..

 For example:

 1) You would like to run some command X times where X is pretty big
 (admins likes to do this via bash loops). If you can execute all
> of them for
 1 and not 10 minutes you will get happier end user.
>>>
>>>
>>> +1 I'm fully in support of this effort. Shaving 100ms off the
> startup time
>>> of a frequently used library means that you'll save that 100ms
> over and
>>> over, adding up to a huge win.
>>>
>>
>>
>> Another data point on how slow our libraries/CLIs can be:
>>
>> $ time openstack -h
>> 
>> real0m2.491s
>> user0m2.378s
>> sys 0m0.111s
>
>
> pbr should be snappy - taking 100ms to get the version is wrong.

 I have always considered pbr a packaging/installation time tool, and not
 something that would be used at runtime. Why are we using pbr to get the
 version of an installed package, instead of asking pkg_resources?
>>>
>>> Just wanted to +1 the above.
>>>
>>> I've also considered pbr a packaging/install tool. Furthermore, I
>>> believe having it as a runtime requirement makes packagers life more
>>> complicated because that means pbr will obviously need to be added as
>>> a runtime requirement for that package.
>>>
>>
>> RDO actually patches out calls to pbr to avoid the runtime requirement,
>> FWIW.
>>
> 
> How does RDO handle --version arguments?

The version is hard-coded as part of the patch process.  Not useful in
non-package based environments where the version isn't static,
unfortunately.


__
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 in the classroom

[Shaifali Agrawal]

Amrit,

Yeah, I thought you are planning to teach cloud computing and OpenStack,
but computing with OpenStack is also no doubt worth spreading to world as
you said.

Thanks!!!
Shaifali Agrawal
about.me/shaifaliagrawal
  [image: Shaifali Agrawal on about.me]


On Wed, Apr 8, 2015 at 9:48 PM, Ganesh Narayanan (ganeshna) <
ganes...@cisco.com> wrote:

>  Yes, offering courses on OpenStack in Coursera kind of platform will be
> a good idea.  Currently there are some cloud computing courses being
> offered in Coursera along with a capstone project:
> https://www.coursera.org/specialization/cloudcomputing/19/courses
>
>  Thanks,
>  Ganesh
>
>   From: Amrith Kumar 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, 8 April 2015 9:01 pm
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
> Subject: Re: [openstack-dev] OpenStack in the classroom
>
>   Shaifali,
>
>
>
> These are two related but slightly different things. The first is, as you
> suggest, to offer courses that teach OpenStack and cloud computing. The
> other which I believe has broader applicability is to teach computing with
> OpenStack as the exemplar system.
>
>
>
> Your suggestion of offering courses through a MOOC is a good one in either
> case, and certainly worth pursuing.
>
>
>
> Thanks,
>
>
>
> -amrith
>
>
>
> *From:* Shaifali Agrawal [mailto:agrawalshaifal...@gmail.com
> ]
> *Sent:* Wednesday, April 08, 2015 11:05 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] OpenStack in the classroom
>
>
>
> Hello Amrit
>
> I liked the idea of taking OpenStack to the classroom. Thank You for
> taking the initiative and sharing your knowledge of cloud computing and
> OpenStack with students.
>
>
> I have a suggestion, why don't you offer a MOOC
> ,
> preparing video lectures and sharing it with world(not just educational
> institutions in Massachusetts and near Toronto). We can ask to various MOOC
> offering portals(like udacity.com, coursera.org etc) to add the course
> into their list of courses or may be let this course offered by OpenStack
> Foundation only.
>
> This will be really helpful for those who have never studied about cloud
> computing in their regular study courses curriculum and are new to
> OpenStack. Such students/listners will get well prepared and *sequential
> lectures* to read and learn about cloud computing and OpenStack rather than
> searching on web and reading about each new terms that they encounter while
> hacking in  OpenStack or similar fields.
>
> The main reason why am I asking to prepare MOOC is that your effort will
> reach to whole world and also your knowledge sharing will stay alive
> forever in the form of video lectures :)
>
> Also even though I don't have much knowledge in cloud computing and
> OpenStack but if you need someone to work with you, I would love to be
> that. So please let me know if you need an assistant for such stuff.
>
>
>   Thanks!!!
>
> *Shaifali Agrawal*
>
> about.me/shaifaliagrawal
>
> [image: Shaifali Agrawal on about.me]
>
>
>
>
>
>
>
> On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar  wrote:
>
>  CS and EE schools today use open source software as the basis for a lot
> of coursework and as the practical example for several concepts. Most often
> the exemplar system is Linux. Yet if students are even taught about the
> cloud, they often learn about that other cloud company from Seattle.
>
>
>
> I think OpenStack is the ideal exemplar system for a whole lot of CS/EE
> courses. No matter what area of computer science you are interested in,
> there’s an OpenStack project (or in some cases several) that you can study.
>
>
>
> I think the fact that you can have the entire cloud on your laptop, source
> code and all, is incredibly powerful in the classroom. Not only can you see
> how the system works, but you can also tweak it or fix it if you find
> something to be wrong. Some students also learn about software development
> methodologies by contributing to a fictional open source project. Why do
> that when they can instead be contributing code to a real open source
> project?
>
>
>
> I think there’s a huge opportunity for us to take OpenStack in the
> Classroom (a longer post about my experience doing this last week is at
> http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and
> Kamesh Pemmaraju for helping me with this at short notice.
>
>
>
> Let us make (and I’m looking to the Foundation to support this as a formal
> initiative) it a priority to have every university offer c

Re: [openstack-dev] [all] how to send messages (and events) to our users

[Chris Dent]

On Wed, 8 Apr 2015, Sandy Walsh wrote:


Yes. It would be so good to pull apart the state-machine that is Nova and
just emit completed actions via notifications. Then, have something like
TaskFlow externalize the orchestration. Do away with RPC-over-AMQP.


YES! I've got notes going back to my first few weeks in OpenStack
land that essentially say "What's with this RPC? Let's have
(observable) events!"

It was basically the first thing I noticed that stood out as a significant
limitation.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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][L3] L3 Subteam Meeting Tomorrow

[Carl Baldwin]

John,

I will be around and looking for your posts to the ML.

Carl

On Wed, Apr 8, 2015 at 11:15 AM, John Belamaric  wrote:
> Carl,
>
> I did want to discuss the refactoring for IPAM but we can do it over the
> ML. Looks like Salvatore didn't have a chance to play with it over the
> weekend, so I will be looking at it today (hopefully).
>
> John
>
>
> On 4/8/15, 11:26 AM, "Carl Baldwin"  wrote:
>
>>I will not be available to chair or attend the L3 sub team meeting
>>tomorrow.  Are others okay with canceling the meeting?  Let me know if
>>you have something to discuss.
>>
>>Carl
>>
>>__
>>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] [all] how to send messages (and events) to our users

[Sandy Walsh]

Yeah, I don't think anyone would give access to the production rabbitmq 
directly.


We use Yagi [1] to pipe it to AtomHopper [2] for downstream 
consumption/sanitizing.


-S


[1] https://github.com/rackerlabs/yagi

[2] http://atomhopper.org/




From: Duncan Thomas 
Sent: Wednesday, April 8, 2015 2:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] how to send messages (and events) to our 
users

>From a security point, it certainly scares the hell out of me

On 7 April 2015 at 08:45, Chris Friesen 
mailto:chris.frie...@windriver.com>> wrote:
On 04/06/2015 10:08 PM, Angus Salkeld wrote:
On Tue, Apr 7, 2015 at 1:53 PM, Chris Friesen 
mailto:chris.frie...@windriver.com>
>> wrote:

On 04/06/2015 08:55 PM, Angus Salkeld wrote:

Hi all

For quite some time we (Heat team) have wanted to be able to send
messages to our
users (by user I do not mean the Operator, but the User that is
interacting with
the client).

What do I mean by "user messages", and how do they differ from our
current log
messages and notifications?
- Our current logs are for the operator and have information that the 
user
should not have
(ip addresses, hostnames, configuration options, other tenant info
etc..)
- Our notifications (that Ceilometer uses) *could* be used, but I am not
sure if
it quite fits.
(they seem a bit heavy weight for a log message and aimed at higher
level events)




What are some options we could investigate:
1. remote syslog
2. Zaqar
3. Other options:
 Please chip in with suggestions/links!


What about a per-user notification topic using the existing notification
backend?


Wouldn't that require the Operator to provide the end user with access to the
message bus?
Seems scary to me.

AMQP supports access controls, so is it really all that scary?  Maybe set up a 
virtual host per user if we want to be paranoid? (Just throwing it out there as 
an option since we're already using it...)


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



--
Duncan Thomas
__
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] Regarding neutron bug # 1432582

[Sudipto Biswas]

Hi Guys, I'd really appreciate your feedback on this.

Thanks,
Sudipto

On Monday 30 March 2015 12:11 PM, Sudipto Biswas wrote:
Someone from my team had installed the OS on baremetal with a wrong 
'date'

When this node was added to the Openstack controller, the logs from the
neutron-agent on the compute node showed - "AMQP connected". But the 
neutron

agent-list command would not list this agent at all.

I could figure out the problem when the neutron-server debug logs were 
enabled
and it vaguely pointed at the rejection of AMQP connections due to a 
timestamp
miss match. The neutron-server was treating these requests as stale 
due to the
timestamp of the node being behind the neutron-server. However, 
there's no
good way to detect this if the agent runs on a node which is ahead of 
time.


I recently raised a bug here: 
https://bugs.launchpad.net/neutron/+bug/1432582


And tried to resolve this with the review:
https://review.openstack.org/#/c/165539/

It went through quite a few +2s after 15 odd patch sets but we still 
are not

in common ground w.r.t addressing this situation.

My fix tries to log better and throw up an exception to the neutron 
agent on

FIRST time boot of the agent for better detection of the problem.

I would like to get your thoughts on this fix. Whether this seems 
legit to have
the fix per the patch OR could you suggest a approach to tackle this 
OR suggest

just abandoning the change.



__ 


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] how to send messages (and events) to our users

[Flavio Percoco]

On 08/04/15 16:38 +, Sandy Walsh wrote:



From: Clint Byrum 
Sent: Wednesday, April 8, 2015 1:15 PM

There's this:

https://wiki.openstack.org/wiki/Cue


Hmm, that looks interesting. Will read.


I also want to point out that what I'd actually rather see is that all
of the services provide functionality like this. Users would be served
by having an event stream from Nova telling them when their instances
are active, deleted, stopped, started, error, etc.

Also, I really liked Sandy's suggestion to use the notifications on the
backend, and then funnel them into something that the user can consume.
The project they have, yagi, for putting them into atom feeds is pretty
interesting. If we could give people a simple API that says "subscribe
to Nova/Cinder/Heat/etc. notifications for instance X, and put them
in an atom feed", that seems like something that would make sense as
an under-the-cloud service that would be relatively low cost and would
ultimately reduce load on API servers.


THIS!

Yes. It would be so good to pull apart the state-machine that is Nova and
just emit completed actions via notifications. Then, have something like
TaskFlow externalize the orchestration. Do away with RPC-over-AMQP.


Sorry for being nitpicky but, saying "RPC-over-AMQP" is way too
generic. What AMQP version? On top of what technology?

Considering all the issues OPs have with our current broker story, I
think considering implementing this on top of pure AMQP (which is how
that phrase reads) would not be good.

If you meant "RPC-over-messaging" then I think you should just keep
using oslo.nmessaging, which abstracts the problem of picking one
broker.

Unfortunately, this means users will need to consume this messages
from the "messaging source" using oslo.messaging as well. I say
"unfortunately" because I believe the API - or even the protocol - as
it is exposed through this library - or simply the broker - is not
something users should deal with. There are services that try to make
this interaction simpler - yes, Zaqar.

Flavio



And, anyone that is interested in the transitions can eavesdrop on the
notifications.

In our transition from StackTach.v2 to StackTach.v3 in production we simply
cloned the notification feeds so the two systems can run in parallel*. No
changes to OpenStack, no disruption of service. Later, we'll just kill off
the v2 queues.

-S

* we did this in Yagi, since olso-messaging doesn't support multiple queues
from one routing key.
__
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


--
@flaper87
Flavio Percoco


pgpYZZIXGaONk.pgp
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] [Nova] Regarding deleting snapshot when instance is OFF

[Deepak Shetty]

Hi,
Cinder w/ GlusterFS backend is hitting the below error as part of
test_volume_boot_pattern tempest testcase

(at the end of testcase when it deletes the snap)

"/usr/local/

lib/python2.7/dist-packages/libvirt.py", line 792, in blockRebase
2015-04-08 07:22:44.376 32701 TRACE nova.virt.libvirt.driver if ret == -1:
raise libvirtError ('virDomainBlockRebase() failed', dom=self)
2015-04-08 07:22:44.376 32701 TRACE nova.virt.libvirt.driver
libvirtError: *Requested
operation is not valid: domain is not running*
2015-04-08 07:22:44.376 32701 TRACE nova.virt.libvirt.driver

More details in the LP bug [1]

In looking closely at the testcase, it waits for the Instance to turn OFF
post which the cleanup starts which tried to delete the snap, but since the
cinder volume is attached state (in-use) it lets nova take control of the
snap del operation, and nova fails as it cannot do blockRebase as domain is
offline.

Questions:

1) Is this a valid scenario being tested ? Some say yes, I am not sure,
since the test makes sure that instance is OFF before snap is deleted and
this doesn't work for fs-backed drivers as they use hyp assisted snap which
needs domain to be active.


2) If this is valid scenario, then it means libvirt.py in nova should be
modified NOT to raise error, but continue with the snap delete (as if
volume was not attached) and take care of the dom xml (so that domain is
still bootable post snap deletion), is this the way to go ?


Appreciate suggestions/comments


thanx,

deepak

[1]: https://bugs.launchpad.net/cinder/+bug/1441050
__
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] hosts table of nova datasource driver

[Alex Yip]

Hi Masahito,

Thanks for the reminder.  We do intend to keep the hosts table.  The code is 
commented out only because there is a bug that keeps the driver from working 
with the hosts table right now.  I don't know if anyone is looking into it, but 
I just created a bug report for it:

https://bugs.launchpad.net/congress/+bug/1441778

thanks, Alex


From: Masahito MUROI 
Sent: Tuesday, April 7, 2015 11:11 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Congress] hosts table of nova datasource driver

Hi, congress folks

I'm new to congress and I'd like to use hosts table of nova datasource
driver in my usecase.  I, however, found out the hosts table is
commented out in current master.  Is there any reason to comment out it?
or will it be removed from an official datasource in the future?

best regard,
masa

--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539


__
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] Keystone, python3 and python-ldap

[Dimitri John Ledkov]

Heya,

Looking at keystone test requirements and the
https://wiki.openstack.org/wiki/Python3 is there a plan for
python-ldap & ldappool ?

I see some mentions on the mailing list, but not a concrete solution.

It seems to me that both python-ldap & ldappool could be replaced by
ldap3 (previously known as python3-ldap, retro-fitted with python2.6+
support)

https://ldap3.readthedocs.org/en/latest/welcome.html

https://pypi.python.org/pypi/ldap3

It is licensed under LGPLv3, is that ok? Note that currently
python-ldap license is quite iffy, and one of the optional deps is
BSD-4-Clause which also not nice for everyone.

Is it ok for me to work on transitioning to ldap3?

-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

__
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][lbaas] Horizon support for neutron-lbaas v2

[Eichberger, German]

Hi,

We briefly talked about it a few Neutron meetings back (LBaaS is now on demand) 
and created an etherpad to track things: 
https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases

Susanne and I met with HP’s UX designer to work on the design for some flows 
for the Horizon panel (cc’d) but I am glad that Vivek is taking the lead. 
Please check that etherpad for more information and feel free to update as 
things happen…

Thanks,
German


From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Tuesday, April 07, 2015 9:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Hi Evgeny,
We have just started working on Horizon lbaasv2 support. I have to sync up with 
my team on the time-line but it is not targeted for Kilo release.
Since it is a major effort, we will need more hands. Let me know if anyone is 
interested to contribute.

On a related note, Do we have a sample code which uses neutronclient lbaas v2 
methods? That will greatly speedup our horizon integration.

Thanks,
Vivek

From: Phillip Toohill 
mailto:phillip.tooh...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 7, 2015 at 7:50 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2


​Hey Evgeny,



I believe Vivek is working on Horizon lbaasv2 support. We werent given a 
timeline or anything but sounds like its being actively worked on. I would 
reach out to him to get better timelines if concerned.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: Evgeny Fedoruk mailto:evge...@radware.com>>
Sent: Tuesday, April 7, 2015 5:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Hi guys,

LBaaS v2 has no horizon support as for now and I want to know if this work is 
planned to be done and , if yes, in what time frame.
Is there a plan to develop it for Kilo or for L release?

Thanks,
Evg
__
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] PTL Candidacy

[John Garbutt]

Hi,

I am johnthetubaguy on IRC.

I would like to run for the OpenStack Compute (Nova) PTL position.

I currently work as a Principal Engineer at Rackspace, focusing on
software development for the Rackspace public cloud.

Background
==

I started working with Nova in late 2010, working on a private cloud
style packaging of XenServer and OpenStack at Citrix. Later in 2010,
my efforts moved towards helping maintain the upstream XenServer
support. In early 2013 I moved to Rackspace to work on their public
cloud.

Over the last few releases, I have been helping with some of the
release management, running some nova meetings, blueprint/specs
management and in various other Nova relating activities.

I would like to build on this experience and help continue Nova’s evolution.

Code Contributions
==

Its no secret that many contributors are finding it harder and harder
to get their code merged into Nova.

We need to ensure we maintain (ideally increase) code quality and
consistency, but we also need to scale out our processes. Its a hard
problem, but I am sure we can do better.

I support the idea of moving to a kind of “tick-tock” release for
Nova. Adopting this would mean Liberty has more room for new
‘features’, and the M release will have a similar focus on stability
to Kilo.

During Kilo, the focus on fixing bugs and working on fixing up some of
the technical debt we have accrued. That of course, meant there were
many features we were unable to merge, because we were focusing more
on other things.

There are some really promising ideas, and we need to start trying out
some of these solutions very soon. I think a key part of why its hard
to expand nova-core is because it currently means too much to be
dropped from nova-core. We need that group to be more fluid.

Process
===

Not all process is good, but some can be helpful to communication
between such a large community.

We are now better at agreeing priorities for a release, and following
through on that. We are better at reviving, agreeing and documenting
plans for features in specs. We are now making better use of dev ref
to capture longer term work streams, and their aims.

More importantly, we relaxed a lot of the nova-spec process for
blueprints that don’t need that level of overhead.

When we focus our review effort, such as with the trivial patch list,
we have seen great results. I think we need to expand the groups of
reviews that need immediate attention to include reviews that a sub
group feels is now “ready”. As trust builds between the central team
and the sub group, we can look at how much that can evolve to a more
formal federated system, as the sub group gains trust. But I hope
better ideas will come along that we can consider and look at
adopting.

The key thing, lets continue this evolution, so we can scale out the
community, keep the quality high, but while keeping everyone
productive.

Users and Operators
===

The API v2.1 effort is a great start on the road towards better
interoperability. This is a key step towards ensuring the compute API
looks and feels the same regardless of what Nova deployment you are
pointing at.

I feel we need to be more upfront about what is known to work, and
what is unknown. We started down this path for Hypervisor drivers, I
feel we need to revive this effort, and look at other combinations:
https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status

We can look at defining how well tested particular combinations are,
using a similar methodology to devcore. But the important thing is
having open information on what is known to work.

We are getting clear feedback from our users about some areas of the
code that need attention. We need to continue to be responsive to
those requests, and look at ways to improve that process.

Conclusion
==

This email has got too long and writing is not my strong point. But
for those who don’t know me, I hope it gives you a good idea about
where I stand on some of the key issues facing the Nova community.

Thanks for reading.

johnthetubaguy

__
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] [qa] official clients and tempest

[Matthew Treinish]

On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote:
> Since tempest no longer uses the official clients as a literal code
> dependency, except for the cli tests which are being removed, the clients
> have been dropping from requirements.txt. But when debugging issues
> uncovered by tempest, or when debugging tempest itself, it is useful to use
> the cli to check various things. I think it would be a good service to users
> of tempest to include the client libraries when tempest is installed on a
> machine. Is there a reason to not do this?
i> 

Umm, so that is not what requirements.txt is for, we should only put what is
required to run the tempest in the requirements file. It's a package 
dependencies
list, not a list of everything you find useful for developing tempest code.

I get what you're going for but doing that as part of the tempest install is not
the right place for it. We can put it as a recommendation in the developer
documentation or have scripts somewhere which sets setups up a dev env or
something. 

-Matt Treinish


pgpJHRB3WudHt.pgp
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] FWaaS iptables implementation

[Rajesh Mohan]

Hi Miyashita,

The second rule is 'accept' on state being 'established' or 'related'. In
case of ICMP, if a request has gone out from inside network, then the reply
to that will match this rule. A new ICMP message initiated from outside
will not match this rule.

I hope I understood your question correctly. Let me know if this addresses
your concern.

Thanks,
-Rajesh Mohan



On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro 
wrote:

>  Hi,
>
>
>
> I want to ask about FWaaS iptables rule implementation.
>
> firewall rule are deployed as iptables rules in network node , and ACCEPT
> target is set at second rule(*).
>
>
>
> 
>
> Chain neutron-l3-agent-iv431d7bfbc (1 references)
>
> pkts bytes target prot opt in out source
>destination
>
> 0 0 DROP   all  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state INVALID
>
> 0 0 ACCEPT all  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state RELATED,ESTABLISHED   (*)
>
> 0 0 neutron-l3-agent-liA31d7bfbc  tcp  --  *  *
> 172.16.2.0/231.2.3.4 tcp spts:1025:65535 dpt:80
>
> 0 0 neutron-l3-agent-liA31d7bfbc  tcp  --  *  *
> 172.16.6.0/241.2.3.4 tcp spts:1025:65535 dpt:80
>
>0 0 neutron-l3-agent-liA31d7bfbc  tcp  --  *  *
> 1.2.3.4  172.16.14.0/24  tcp spts:1025:65535 dpt:11051
>
> 0 0 neutron-l3-agent-liA31d7bfbc  tcp  --  *  *
> 10.3.0.0/24  1.2.3.4 tcp spts:1025:65535 dpt:22
>
> 0 0 neutron-l3-agent-liD31d7bfbc  all  --  *  *
> 0.0.0.0/00.0.0.0/0
>
> 
>
>
>
> Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP
> or other protocol such as UDP/TCP)?
>
>
>
> This causes some wrong scenario for example...
>
>
>
> [outside openstack cloud] ---> Firewall(FWaaS) --> [inside openstack cloud]
>
>
>
> 1) admin create Firewall and create Filrewall rule accepting ICMP request
> from outside openstack cloud, and
>
> 2) ICMP request packets incoming from outside to inside, and
>
> 3) someday, admin detects that ICMP rule is security vulnerability and
> create Firewall rule blocking ICMP request from outside.
>
>
>
> but ICMP request packets still incoming due to ACCEPT rule(*), because
> ICMP connection still hit rule at second(*).
>
>
>
> Thanks.
>
>
>
> kazuhiro MIYASHITA
>
>
>
>
>
> __
> 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] [qa] official clients and tempest

[David Kranz]

On 04/08/2015 02:36 PM, Matthew Treinish wrote:

On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote:

Since tempest no longer uses the official clients as a literal code
dependency, except for the cli tests which are being removed, the clients
have been dropping from requirements.txt. But when debugging issues
uncovered by tempest, or when debugging tempest itself, it is useful to use
the cli to check various things. I think it would be a good service to users
of tempest to include the client libraries when tempest is installed on a
machine. Is there a reason to not do this?

i>

Umm, so that is not what requirements.txt is for, we should only put what is
required to run the tempest in the requirements file. It's a package 
dependencies
list, not a list of everything you find useful for developing tempest code.
I was more thinking of users of tempest than developers of tempest, 
though it is useful to both.
But we can certainly say that this is an issue for those who provide 
tempest to users.


 -David




I get what you're going for but doing that as part of the tempest install is not
the right place for it. We can put it as a recommendation in the developer
documentation or have scripts somewhere which sets setups up a dev env or
something.

-Matt Treinish


__
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][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

[Brant Knudson]

On Wed, Apr 8, 2015 at 7:59 AM, Doug Hellmann  wrote:

> Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:
> > On 7 April 2015 at 05:11, Joe Gordon  wrote:
> > >
> > >
> > > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews  >
> > > wrote:
> > >>
> > >>
> > >> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic 
> wrote:
> > >>>
> > >>> Jay,
> > >>>
> > >>>
> >  Not far, IMHO. 100ms difference in startup time isn't something we
> >  should spend much time optimizing. There's bigger fish to fry.
> > >>>
> > >>>
> > >>> I agree that priority of this task shouldn't be critical or even
> high,
> > >>> and that there are other places that can be improved in OpenStack.
> > >>>
> > >>> In other hand this one is as well big source of UX issues that we
> have in
> > >>> OpenStack..
> > >>>
> > >>> For example:
> > >>>
> > >>> 1) You would like to run some command X times where X is pretty big
> > >>> (admins likes to do this via bash loops). If you can execute all of
> them for
> > >>> 1 and not 10 minutes you will get happier end user.
> > >>
> > >>
> > >> +1 I'm fully in support of this effort. Shaving 100ms off the startup
> time
> > >> of a frequently used library means that you'll save that 100ms over
> and
> > >> over, adding up to a huge win.
> > >>
> > >
> > >
> > > Another data point on how slow our libraries/CLIs can be:
> > >
> > > $ time openstack -h
> > > 
> > > real0m2.491s
> > > user0m2.378s
> > > sys 0m0.111s
> >
> >
> > pbr should be snappy - taking 100ms to get the version is wrong.
>
> I have always considered pbr a packaging/installation time tool, and not
> something that would be used at runtime. Why are we using pbr to get the
> version of an installed package, instead of asking pkg_resources?
>
> Doug
>
> >
> > -Rob
> >
>
>
I have no idea if one is better than the other, but I figured It was easy
enough to post the change for keystoneclient:
https://review.openstack.org/#/c/171720/ .

- Brant
__
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] [qa] official clients and tempest

[Sean Dague]

On 04/08/2015 02:58 PM, David Kranz wrote:
> On 04/08/2015 02:36 PM, Matthew Treinish wrote:
>> On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote:
>>> Since tempest no longer uses the official clients as a literal code
>>> dependency, except for the cli tests which are being removed, the clients
>>> have been dropping from requirements.txt. But when debugging issues
>>> uncovered by tempest, or when debugging tempest itself, it is useful to use
>>> the cli to check various things. I think it would be a good service to users
>>> of tempest to include the client libraries when tempest is installed on a
>>> machine. Is there a reason to not do this?
>> i> 
>>
>> Umm, so that is not what requirements.txt is for, we should only put what is
>> required to run the tempest in the requirements file. It's a package 
>> dependencies
>> list, not a list of everything you find useful for developing tempest code.
> I was more thinking of users of tempest than developers of tempest,
> though it is useful to both.
> But we can certainly say that this is an issue for those who provide
> tempest to users.

I'm in agreement with Matt here. Tempest requirements should be what
Tempest actually requires.

Installing the CLI is pretty easy, it's package installed in any Linux
distro. apt-get, yum, or even pip install and you are off and running.

I don't think having Tempest side effect dragging in the CLI tools is
useful. Those should instead be something people install themselves.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Nova] PTL Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 8, 2015 at 11:25 AM, John Garbutt  wrote:
> Hi,
>
> I am johnthetubaguy on IRC.
>
> I would like to run for the OpenStack Compute (Nova) PTL position.
>
> I currently work as a Principal Engineer at Rackspace, focusing on
> software development for the Rackspace public cloud.
>
> Background
> ==
>
> I started working with Nova in late 2010, working on a private cloud
> style packaging of XenServer and OpenStack at Citrix. Later in 2010,
> my efforts moved towards helping maintain the upstream XenServer
> support. In early 2013 I moved to Rackspace to work on their public
> cloud.
>
> Over the last few releases, I have been helping with some of the
> release management, running some nova meetings, blueprint/specs
> management and in various other Nova relating activities.
>
> I would like to build on this experience and help continue Nova's evolution.
>
> Code Contributions
> ==
>
> Its no secret that many contributors are finding it harder and harder
> to get their code merged into Nova.
>
> We need to ensure we maintain (ideally increase) code quality and
> consistency, but we also need to scale out our processes. Its a hard
> problem, but I am sure we can do better.
>
> I support the idea of moving to a kind of "tick-tock" release for
> Nova. Adopting this would mean Liberty has more room for new
> 'features', and the M release will have a similar focus on stability
> to Kilo.
>
> During Kilo, the focus on fixing bugs and working on fixing up some of
> the technical debt we have accrued. That of course, meant there were
> many features we were unable to merge, because we were focusing more
> on other things.
>
> There are some really promising ideas, and we need to start trying out
> some of these solutions very soon. I think a key part of why its hard
> to expand nova-core is because it currently means too much to be
> dropped from nova-core. We need that group to be more fluid.
>
> Process
> ===
>
> Not all process is good, but some can be helpful to communication
> between such a large community.
>
> We are now better at agreeing priorities for a release, and following
> through on that. We are better at reviving, agreeing and documenting
> plans for features in specs. We are now making better use of dev ref
> to capture longer term work streams, and their aims.
>
> More importantly, we relaxed a lot of the nova-spec process for
> blueprints that don't need that level of overhead.
>
> When we focus our review effort, such as with the trivial patch list,
> we have seen great results. I think we need to expand the groups of
> reviews that need immediate attention to include reviews that a sub
> group feels is now "ready". As trust builds between the central team
> and the sub group, we can look at how much that can evolve to a more
> formal federated system, as the sub group gains trust. But I hope
> better ideas will come along that we can consider and look at
> adopting.
>
> The key thing, lets continue this evolution, so we can scale out the
> community, keep the quality high, but while keeping everyone
> productive.
>
> Users and Operators
> ===
>
> The API v2.1 effort is a great start on the road towards better
> interoperability. This is a key step towards ensuring the compute API
> looks and feels the same regardless of what Nova deployment you are
> pointing at.
>
> I feel we need to be more upfront about what is known to work, and
> what is unknown. We started down this path for Hypervisor drivers, I
> feel we need to revive this effort, and look at other combinations:
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status
>
> We can look at defining how well tested particular combinations are,
> using a similar methodology to devcore. But the important thing is
> having open information on what is known to work.
>
> We are getting clear feedback from our users about some areas of the
> code that need attention. We need to continue to be responsive to
> those requests, and look at ways to improve that process.
>
> Conclusion
> ==
>
> This email has got too long and writing is not my strong point. But
> for those who don't know me, I hope it gives you a good idea about
> where I stand on some of the key issues facing the Nova community.
>
> Thanks for reading.
>
> johnthetubaguy
>
> __
> 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



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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