Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Marios Andreou]

+1

On Wed, Nov 29, 2017 at 9:34 PM, John Trowbridge  wrote:

> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.
>
> __
> OpenStack Development Mailing 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] [Gnocchi][Keystone][Identity] Unable to authenticate to access Gnocchi API

[Gautham Yajamaan]

Hi Everyone,

*ISSUE*: Unable to authenticate python program to access gnocchi api.

*Request*: Please guide me how to obtain the token and access gnocchi.
Also, Please help with any documentation which will help me in knowing this
process better.

*Description*:

I have installed and running gnocchi for ceilometer. I am successfully able
to obtain measures from the metrics.

Identity service is running authentication. Keystone is not listening on
port 5000 and port 35357.

I was able to work with Postman and manage to get the token and send
request to Gnocchi.

I am trying to use GnocchiClient to access the gnocchi api to get the
measures through my own python program but I am always ending up with
errors such as BadRequest, HTTP 401 and 500 errors.

*In all my attempts, I have no been able to successfully obtain a token and
request gnocchi through program. *

I tried to follow the function *auth.password* for the Identity service and
the below mentioned code to obtain authentication.

>>> from gnocchiclient import auth>>> from gnocchiclient.v1 import client>> 
>>> auth_plugin = auth.GnocchiBasicPlugin(user="admin",>>>  
>>>  endpoint="http://localhost:8041;)>>> gnocchi = 
>>> client.Client(session_options={'auth': auth_plugin})>>> 
>>> gnocchi.resource.list("generic")

>>> from keystoneauth1 import loading>>> from oslo_config import cfg>>> from 
>>> gnocchiclient import auth>>> from gnocchiclient.v1 import client>> conf 
>>> = cfg.ConfigOpts()>>> ...>>> auth_plugin = 
>>> loading.load_auth_from_conf_options(conf, "gnocchi_credentials")>>> gnocchi 
>>> = client.Client(session_options={'auth': auth_plugin})>>> 
>>> gnocchi.resource.list("generic")


-- 
Thanks and Regards
Gautham
+1-206+295+8813
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [heat][qa] Split tempest plugin from heat

[Rabi Mishra]

On Wed, Nov 29, 2017 at 9:51 PM, Zane Bitter  wrote:

> On 19/11/17 03:08, Rabi Mishra wrote:
>
>> Hi All,
>>
>> As part of community goal[1] for Queens, we've completed the repo split
>> and created the new project[2].
>>
>> The next objective to is to use the new plugin in our jobs. As we've
>> merged some changes after the split, I've synced them and fixed some minor
>> issues before using it in the gate jobs.
>>
>> These are very small changes and I would suggest we review/land them on
>> priority (we don't have to keep syncing them again and again for broken
>> jobs). We should probably *not approve* any changes to integration tests in
>> heat before these go in.
>>
>> - Changes in heat-tempest-plugin (sync  missing patches and fixes)
>> https://review.openstack.org/#/q/project:openstack/heat-temp
>> est-plugin+topic:sync_from_heat
>>
>> - Use heat-tempest-plugin for integration jobs
>> https://review.openstack.org/#/c/508112/
>>
>> - Use heat-tempest-plugin for grenade job
>> https://review.openstack.org/#/c/521246/
>>
>> - Add heat integration jobs to heat-tempest-plugin check/gate queue
>> https://review.openstack.org/#/c/521340/
>>I guess this would result in some issues, where we can't add any
>> changes to heat that breaks the existing tests, as the changes for both
>> projects would have a circular dependency (not sure how it works atm with
>> other plugins!).
>>
>> - Remove plugin an integration tests from heat (This has -1 atm as
>> releasenote job is broken, waiting for infra to fix it)
>> https://review.openstack.org/#/c/521263/ > #/c/521263/>
>>
>> I've also created an etherpad[3] to track these.
>>
>> Also, the plugin project is expected to be branchless (we may not
>> backport these job changes to stable branches soon though), we've to find
>> a  way to run additional tests for any new feature only on >
>> . AFAIK, other projects check api microversions supported
>> and without microversions in heat, may be we've find an alternate way.
>>
>
> So from discussion on IRC today I learned that the plan agreed at the PTG
> was *not* to move all of heat_integrationtests to a separate repo, but just
> those tests that test the API and are likely to be used in the trademark
> program for verifying clouds.
>
>
Well, the etherpad[1] for the session clearly mentions "Create the new repo
and import API and *scenario* tests" and *not* "that tests the API and
likely to be used in trademark programs".  What you mentioned above is
probably the conclusion from all the discussion we had on IRC yesterday.

In my view that effectively means just the Gabbi tests.
>
>
However, what is actually happening is that *all* of the
> integration/scenario tests are moving to the separate branchless repo. This
> looks to me like it will be a disaster for developer and reviewer
> productivity, and project quality[1]. (Other folks seem inclined to agree.)
>

Just to make it clear, there had been several discussions on 'what to
move'/'branchless or not' in meetings[2] and IRC discussions[3] and the
change of plan to move functional tests was based on the following.

- All our tests are API driven. There is probably not much difference
between functional and scenario (i.e. if we only move scenario tests, we
would have the same kind of issues as we would with functional tests).

- All our tests run with tempest as test runner and use the same tempest
configuration. Unless we run remaining in-tree tests without tempest, we
would end-up with the same set problems which the goal wanted to address (
issues with in-tree tempest plugins).

- Current coverage of gabbi tests is very poor and we've never been serious
to land the patches to complete the API coverage. One of the patches have
been languishing in review queue since a year[4].

- As heat is the orchestration service, I would think testing heat from
user/operator point of view is not only testing API and interoperability,
but how it works with other services deployed and many of our functional
tests[5] do that.

As per my understanding, the issue of having tests in a separate repo and
it's impact on developer productivity was discussed by the all concerned
before accepting this as a community goal. Our problem is probably not
different from some other projects[6].

It's little unfortunate that we've started discussing about these issues
after most of stuff has been done. Having said that, it's never late to do
the right thing that saves us from a disaster, if that's what it means:)

Given the option, I would prefer:

- We keep all tests in-tree and run them with tempest for the time being,
which means we would not complete the goal.

- Complete the coverage for API tests, probably identify
functional/scenario tests that are expected to be stable across branches
and then move them out along with the API tests.

- Change the remaining in-tree tests to run without tempest at the gate,
unless there is a solution to your 

Re: [openstack-dev] [qa] [patrole] Question regarding Patrole API coverage

[Ghanshyam Mann]

On Thu, Nov 30, 2017 at 12:11 AM, Andrea Frittoli
 wrote:
>
>
> On Wed, Nov 29, 2017 at 2:28 PM Peng Liu  wrote:
>>
>> Hi Team,
>>
> Hi Peng
>
>>
>> I have a question regarding to the API coverage of Patrole. Currently,
>> Patrole as a Tempest plugin heavily relys on the Tempest code. However,
>> Tempest only contains the API tests for the most common APIs of the most
>> common projects(Nova, Neutron, Cinder, Glance, Swift, Keystone).
>>
>> So I want to know if it is possible to extend Patrole to:
>> 1) test the APIs of the common projects which was not yet covered in
>> Tempest.
>>
>> 2) test projects which was not covered in Tempest?

In case there is any gap, Patrole will not tests the API like Tempest
does. It will test only policy enforcement on API. Tempest way to test
API is different than what Patrole does. I hope you mean the same here
which means to extend the coverage of other projects' API policy tests
in Patrole.

>
>
> You can use the Patrole framework to test services not covered by Tempest by
> taking advantage of Tempest plugin mechanism.
> Patrole itself is a Tempest plugin. If you install the plugin of a service
> that includes a service client, you should be able to use it to write
> Patrole tests for that service.
> I believe this has not been done yet by any project though, so there may be
> a few technical bits to be sorted out.
>
> I don't think Patrole itself will have to be extended, however Patrole does
> not yet include stable APIs.
> If you're going to use Patrole APIs in your project you need to be aware
> that there may be backward incompatible changes happening without a
> deprecation period.
>
> There are several options on where to host such tests: in a dedicated
> plugin, in the Tempest plugin for the service or in Patrole itself.
> The latter would probably suffer from the same scalability issues that lead
> us to create the plugin mechanism to begin with.

Yea, I remember we talked about it in some of previous PTG or Summit
also. I feel having Patrole tests for other projects in separate
plugin is not the best way. It will lead to have 2 tempest plugin on
each projects side (one for Tempest and second for Patrole).  I prefer
the solution to have all tests in Patrole repo itself if possible.
Scalability might be issue with this but Patrole test are just policy
test so should not be hard as Tempest tests.
But that is something we need to discussed in detail considering all
cases of maintenance and current resources bandwidth in Patrole.

We have 2 items here to make it possible:
1. Decide the best way to tests Policy for other projects which are
not covered in Patorle. Options are 1. "Separate Patrole Plugin per
projects" 2. "In Projects Tempest Plugin" 3. "In Patrole itself".

2. If we go for Plugin approach then. make Patrole framework stable.

I do not find these 2 items very complex and can be done soon.

-gmann

>
> Andrea Frittoli (andreaf)
>
>>
>>
>> Thanks,
>> --
>> Peng Liu
>> __
>> OpenStack Development Mailing 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] [tc] Policy Goal Queens-2 Update

[da...@vn.fujitsu.com]

Hi all,

I just want to share some related things to anyone are interested in.

For the Neutron projects, I have discussed with them[1] but it is not really 
started,
they want to consider more about all of networking projects before and I'm 
still waiting for the feedback to
define the right way to implement policy-in-code for networking projects.

For the other extensions of Neutron, we got some recommendations[2][3] that we 
no need to implement
policy-in-code into those projects because we already register policy in 
Neutron, so I think we can remove
neutron-fwaas, neutron-dynamic-routing, neutron-lib or even other networking 
plugins out of "Not Started" list.

For the Swift project, I don't see oslo.policy in requirements.txt for now,
then not sure they need to implement policy in code and the we got the same 
thing with Solum.

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2017-10-31.log.html
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-lbaas/%23openstack-lbaas.2017-10-06.log.html#t2017-10-06T02:50:10
[3] https://review.openstack.org/#/c/509389/

Dai

__
OpenStack Development Mailing 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] Meeting Thursday Nov 30th at 8:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Nov 30th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_Nov_30th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

__
OpenStack Development Mailing 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 L3 agent/Keepalived

[Ajay Kalambur (akalambu)]

I noticed that this happens when the router HA interface shows status: Down 
what can cause the ha interface to do down

Ajay


From: Ajay Kalambur >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, November 29, 2017 at 4:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [neutron] Neutron L3 agent/Keepalived

Hi
I have a case where after running the system for a while I see that floating ip 
association API gets accepted and no Errors in neutron l3 logs
But when I go into the qrouter namespace and check the qg- interface the 
floating ip is not added
Also the keepalived.conf is not updated and SIGUP of the keepalived process is 
not done

So whats the place to look in this case.  What is the flow in neutron l3 agent 
who adds the floating ip to the qg- interface
I see the router update notification received
Key log snippet attached. As you can see SIGUP of keepalived is missing and 
also I confirmed keepalived configs are not updated


2017-11-29 14:32:08.883 78 DEBUG oslo_messaging._drivers.amqpdriver [-] 
received message with unique_id: b3886b998c3049e799170bb5351300d1 __call__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:269
2017-11-29 14:32:08.885 78 DEBUG neutron.agent.l3.agent 
[req-6c505d32-2d1a-4392-8ea3-0bb888397b9e e759eebecc4648b4964d4ecf439dc0ff 
13b4f6fb188048ba9bbf211344e3342f - - -] Got routers updated notification 
:[u'a1a59e5f-d74e-404d-a3aa-1667c4442aed'] routers_updated 
/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:413
2017-11-29 14:32:08.886 78 DEBUG neutron.agent.l3.agent [-] Starting router 
update for a1a59e5f-d74e-404d-a3aa-1667c4442aed, action None, priority 0 
_process_router_update 
/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:487
2017-11-29 14:32:08.886 78 DEBUG oslo_messaging._drivers.amqpdriver [-] CALL 
msg_id: 92eb015c8c84489681b1efbe949fab8b exchange 'neutron' topic 'q-l3-plugin' 
_send /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:568

2017-11-29 14:32:09.571 78 DEBUG oslo_messaging._drivers.amqpdriver [-] 
received reply msg_id: 92eb015c8c84489681b1efbe949fab8b __call__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:416
2017-11-29 14:32:09.571 78 DEBUG neutron.callbacks.manager [-] Notify callbacks 
[] for router, before_update _notify_loop 
/usr/lib/python2.7/site-packages/neutron/callbacks/manager.py:142
2017-11-29 14:32:09.572 78 DEBUG neutron.agent.l3.router_info [-] process 
router updates process 
/usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py:1105
2017-11-29 14:32:09.572 78 DEBUG neutron.agent.linux.utils [-] Running command 
(rootwrap daemon): ['ip', 'netns', 'exec', 
'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net', 
'-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
2017-11-29 14:32:09.709 78 DEBUG neutron.agent.linux.utils [-] Exit code: 0 
execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock 
"l3-agent-pd" acquired by "neutron.agent.linux.pd.sync_router" :: waited 0.000s 
inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock 
"l3-agent-pd" released by "neutron.agent.linux.pd.sync_router" :: held 0.000s 
inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
2017-11-29 14:32:09.710 78 DEBUG neutron.agent.linux.utils [-] Running command 
(rootwrap daemon): ['ip', 'netns', 'exec', 
'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net', 
'-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
2017-11-29 14:32:09.845 78 DEBUG neutron.agent.linux.utils [-] Exit code: 0 
execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
2017-11-29 14:32:09.846 78 DEBUG oslo_concurrency.lockutils [-] Acquired 
semaphore "iptables-qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed" lock 
/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
2017-11-29 14:32:09.846 78 DEBUG neutron.agent.linux.utils [-] Running command 
(rootwrap daemon): ['ip', 'netns', 'exec', 
'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'iptables-save'] 
execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
2017-11-29 14:32:09.983 78 DEBUG neutron.agent.linux.utils [-] Exit code: 0 
execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
2017-11-29 14:32:09.986 78 DEBUG neutron.agent.linux.utils [-] Running 

Re: [openstack-dev] [kolla] Ansiblize init-runonce script

[Steven Dake (stdake)]

I wrote that script ages ago.  I needed it in the repo  so I could consistently 
deploy.  It may still be entirely tailored around my environment ☺

That said, I had always hoped someone would make a generic cloud bootstrap for 
Kolla based upon the work in that script originally.  Maybe this is the time.

Cheers
-steve

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

Date: Tuesday, November 28, 2017 at 7:48 PM
To: Samuel Yaple , OpenStack Development Mailing List 

Subject: Re: [openstack-dev] [kolla] Ansiblize init-runonce script

yes. it is not
​recommend to use in prod env, i never used this script. But
the reality is
lots users are using it, at least in the test environment.
and there are patches trying to make this script ​
idempotent
​ recently.​

2017年11月28日 23:28，"Sam Yaple" >写道：
For what its worth, this init-runonce script was never meant for production 
usage. Ops *shouldn't* be running it like you suggest. It was historically for 
use in the gate and a quick-n-dirty environment setup for testing.

If you want to get into writing operations scripts, thats your prerogative, but 
it was discussed before and mostly considered a bad idea.

Thanks,
SamYaple



 Original Message 
Subject: Re: [openstack-dev] [kolla] Ansiblize init-runonce script
Local Time: November 28, 2017 8:10 AM
UTC Time: November 28, 2017 1:10 PM
From: zhang.lei@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
>

in my opinion,


idempotent scrip
t is very necessary.
for several reason

- there is already some idempotent logical in the script
- it is common that this script failed by wrong configuration,
  after fix the config,
ops will want to run this script again.

On Tue, Nov 28, 2017 at 7:14 PM, Paul Bourke 
> wrote:
I think this came up before at one stage. My position is I don't see the need 
to ansible-ise small shell scripts. init-runonce is currently just an easy to 
understand sequence of openstack commands provided to help people test/demo 
their setups. Unless we want to make it more than that, i.e. make it 
idempotent, customizable, etc. I don't see the need to wheel in Ansible.

On 28/11/17 03:23, Jeffrey Zhang wrote:
hi

check this [0]. I tried to convert it  to ansible playbooks.

[0] https://review.openstack.org/523072

On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani 
 
>> wrote:

Hi,

While exploring kolla-ansible I ran into a few issues with
init-runonce script. This lead to following bugs and patches:

https://launchpad.net/bugs/1732963 
https://review.openstack.org/51

https://review.openstack.org/521190


But it was highlighted that instead of fixing/changing the
script, 'ansibilzing' it would be the ideal solution.
Hence I hereby formally propose the same.

My thoughts:
* Playbook Name: init-stack.yml

* Playbook path can be:
kolla-ansible/ansible/init-stack.yml

* The play can be executed like:
$ kolla-ansible init-stack -i 

* The cirros test image should be downloaded in /tmp

* What should be the behavior if the play is run multiple times
against the same stack?
   - some error message OR
   - simply ignore the action

Kindly provide suggestions.

--
Best Regards,
Ravi J.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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





--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 


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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [neutron] Neutron L3 agent/Keepalived

[Ajay Kalambur (akalambu)]

Hi
I have a case where after running the system for a while I see that floating ip 
association API gets accepted and no Errors in neutron l3 logs
But when I go into the qrouter namespace and check the qg- interface the 
floating ip is not added
Also the keepalived.conf is not updated and SIGUP of the keepalived process is 
not done

So whats the place to look in this case.  What is the flow in neutron l3 agent 
who adds the floating ip to the qg- interface
I see the router update notification received
Key log snippet attached. As you can see SIGUP of keepalived is missing and 
also I confirmed keepalived configs are not updated


2017-11-29 14:32:08.883 78 DEBUG oslo_messaging._drivers.amqpdriver [-] 
received message with unique_id: b3886b998c3049e799170bb5351300d1 __call__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:269
2017-11-29 14:32:08.885 78 DEBUG neutron.agent.l3.agent 
[req-6c505d32-2d1a-4392-8ea3-0bb888397b9e e759eebecc4648b4964d4ecf439dc0ff 
13b4f6fb188048ba9bbf211344e3342f - - -] Got routers updated notification 
:[u'a1a59e5f-d74e-404d-a3aa-1667c4442aed'] routers_updated 
/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:413
2017-11-29 14:32:08.886 78 DEBUG neutron.agent.l3.agent [-] Starting router 
update for a1a59e5f-d74e-404d-a3aa-1667c4442aed, action None, priority 0 
_process_router_update 
/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:487
2017-11-29 14:32:08.886 78 DEBUG oslo_messaging._drivers.amqpdriver [-] CALL 
msg_id: 92eb015c8c84489681b1efbe949fab8b exchange 'neutron' topic 'q-l3-plugin' 
_send /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:568

2017-11-29 14:32:09.571 78 DEBUG oslo_messaging._drivers.amqpdriver [-] 
received reply msg_id: 92eb015c8c84489681b1efbe949fab8b __call__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:416
2017-11-29 14:32:09.571 78 DEBUG neutron.callbacks.manager [-] Notify callbacks 
[] for router, before_update _notify_loop 
/usr/lib/python2.7/site-packages/neutron/callbacks/manager.py:142
2017-11-29 14:32:09.572 78 DEBUG neutron.agent.l3.router_info [-] process 
router updates process 
/usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py:1105
2017-11-29 14:32:09.572 78 DEBUG neutron.agent.linux.utils [-] Running command 
(rootwrap daemon): ['ip', 'netns', 'exec', 
'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net', 
'-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
2017-11-29 14:32:09.709 78 DEBUG neutron.agent.linux.utils [-] Exit code: 0 
execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock 
"l3-agent-pd" acquired by "neutron.agent.linux.pd.sync_router" :: waited 0.000s 
inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock 
"l3-agent-pd" released by "neutron.agent.linux.pd.sync_router" :: held 0.000s 
inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
2017-11-29 14:32:09.710 78 DEBUG neutron.agent.linux.utils [-] Running command 
(rootwrap daemon): ['ip', 'netns', 'exec', 
'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net', 
'-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
2017-11-29 14:32:09.845 78 DEBUG neutron.agent.linux.utils [-] Exit code: 0 
execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
2017-11-29 14:32:09.846 78 DEBUG oslo_concurrency.lockutils [-] Acquired 
semaphore "iptables-qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed" lock 
/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
2017-11-29 14:32:09.846 78 DEBUG neutron.agent.linux.utils [-] Running command 
(rootwrap daemon): ['ip', 'netns', 'exec', 
'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'iptables-save'] 
execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
2017-11-29 14:32:09.983 78 DEBUG neutron.agent.linux.utils [-] Exit code: 0 
execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
2017-11-29 14:32:09.986 78 DEBUG neutron.agent.linux.utils [-] Running command 
(rootwrap daemon): ['ip', 'netns', 'exec', 
'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'iptables-restore', '-n'] 
execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
2017-11-29 14:32:10.120 78 DEBUG neutron.agent.linux.utils [-] Exit code: 0 
execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
2017-11-29 14:32:10.120 78 DEBUG neutron.agent.linux.iptables_manager [-] 
IPTablesManager.apply completed with success. 7 iptables commands were issued 
_apply_synchronized 

Re: [openstack-dev] [octavia] openstack CLI output don't match neutron lbaas-* output

[Michael Johnson]

 Hi Volodymyr,

This is a known issue with the neutron (neutron-lbaas) database
getting out of sync and/or not properly handling driver errors.
This is one reason we are moving to deprecate neutron-lbaas. If you
can, we recommend you move to exclusively using Octavia without
neutron-lbaas.

The fundamental issue is that neutron-lbaas does not use database
transactions properly and does not lock records and the API correctly
so multiple requests/threads can modify neutron database records for
the load balancers. This is particularly an issue if you are doing a
high rate of changes against the neutron-lbaas API. To correct all of
these would require rewriting a significant amount of the
neutron-lbaas API code which doesn't make much sense given we are
moving towards deprecating it in favor of the Octavia API that does
not have this issue.

To mitigate this to some degree you can enable the multiple
synchronization features that push data back to the neutron database
correcting the inaccuracies in the neutron database.
event_streamer_driver and sync_provisioning_status can be enabled in
the octavia.conf [health_manager] section.
https://docs.openstack.org/octavia/latest/configuration/configref.html#health_manager.event_streamer_driver

This tells octavia to be aggressive at pushing status information back
up to the neutron database getting it back in sync with reality.

Michael

On Wed, Nov 29, 2017 at 4:41 AM, Volodymyr Litovka  wrote:
> Hi colleagues,
>
> just to inform you: openstack CLI extension output don't match corresponsing
> 'neutron lbaas-*' CLI output, e.g.
>
> doka@lagavulin(admin@bush):~/heat$ neutron lbaas-loadbalancer-show
> db8ae876-b6eb-4c45-95d1-33e0ca6193de
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
> +-++
> | Field   | Value  |
> +-++
> | admin_state_up  | True   |
> | description ||
> | id  | db8ae876-b6eb-4c45-95d1-33e0ca6193de   |
> | listeners   | {"id": "3ce73276-9c80-4645-aa0c-263fae736ef5"} |
> | name| nbt-balancer   |
> | operating_status| ONLINE |
> | pools   | {"id": "e106e039-af27-4cfa-baa2-7238acd3078e"} |
> | provider| octavia|
> | provisioning_status | ACTIVE |
> | tenant_id   | c1114776e144400da17d8e060856be8c   |
> | vip_address | 10.1.1.13  |
> | vip_port_id | 6898f149-9d6c-4fa7-b16c-af582cd18efa   |
> | vip_subnet_id   | ecb891c1-b7e5-45e0-8815-8675381d70d2   |
> +-++
> doka@lagavulin(admin@bush):~/heat$ openstack loadbalancer show
> db8ae876-b6eb-4c45-95d1-33e0ca6193de
> +-+--+
> | Field   | Value|
> +-+--+
> | admin_state_up  | True |
> | created_at  | 2017-11-29T12:02:55  |
> | description |  |
> | flavor  |  |
> | id  | db8ae876-b6eb-4c45-95d1-33e0ca6193de |
> | listeners   | 3ce73276-9c80-4645-aa0c-263fae736ef5 |
> | name| nbt-balancer |
> | operating_status| OFFLINE  |
> | pools   | e106e039-af27-4cfa-baa2-7238acd3078e |
> | project_id  | c1114776e144400da17d8e060856be8c |
> | provider| octavia  |
> | provisioning_status | ACTIVE   |
> | updated_at  | 2017-11-29T12:04:40  |
> | vip_Address | 10.1.1.13|
> | vip_network_id  | 141f1af9-c309-4263-b7f9-dab3922957c3 |
> | vip_port_id | 6898f149-9d6c-4fa7-b16c-af582cd18efa |
> | vip_subnet_id   | ecb891c1-b7e5-45e0-8815-8675381d70d2 |
> +-+--+
>
> more difference between corresponding command pairs for listeners and pools.
>
> Also, member list shows NO_MONITOR status for members
>
> doka@lagavulin(admin@bush):~/heat$ openstack loadbalancer member list
> nbt-pool
> +--+--+--+-+---+---+--++
> | id   | name | 

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

[Armando M.]

On 29 November 2017 at 12:27, Korzeniewski, Artur <
artur.korzeniew...@intel.com> wrote:

> +1 from me , (even though my vote does not count)
>
> I know Slawek since Tokyo summit and I’m impressed of his knowledge and
> hands-on experience to improve Neutron quality and functionality!
>
> It is great to see him joining the core reviewers team!
>
> Congrats Sławek!
>

Rock On


>
>
> *From:* Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
> *Sent:* Wednesday, November 29, 2017 8:47 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for
> Neutron core
>
>
>
> "+1" I know, I'm not active, but I care about neutron, and slaweq is a
> great contributor.
>
>
>
> On Nov 29, 2017 8:37 PM, "Ihar Hrachyshka"  wrote:
>
> YES, FINALLY.
>
> On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton  wrote:
> > +1! ... even though I haven't been around. :)
> >
> > On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle 
> wrote:
> >>
> >> Hi Neutron Team,
> >>
> >> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core.
> Slawek
> >> has been an active contributor to the project since the Mitaka cycle.
> He has
> >> been instrumental in the development of the QoS capabilities in Neutron,
> >> becoming the lead of the sub-team focused on that set of features. More
> >> recently, he has collaborated in the implementation of OVO and is an
> active
> >> participant in the CI sub-team. His number of code reviews during the
> Queens
> >> cycle is on par with the leading core members of the team:
> >> http://stackalytics.com/?module=neutron
> >>
> >> In my opinion, his efforts are highly valuable to the team and we will
> be
> >> very lucky to have him as a fully voting core.
> >>
> >> I will keep this nomination open for a week as customary,
> >>
> >> Thank you,
> >>
> >> Miguel
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] FW: [LCOO][RBAC] Topical session 11/30 1300 UTC

[MCCABE, JAMEY A]

A topical session on Role Based Access Controls will be at 1300 UTC on Thursday 
11/30. This is a type of LCOO working group discussion  forum we plan to 
conduct on a monthly basis. Agenda and logistics to join can be found at 
https://openstack-lcoo.atlassiaBHIn.net/wiki/x/DwAvAQ
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] FW: [LCOO][RBAC] Topical session 11/30 1300 UTC

[MCCABE, JAMEY A]

A topical session on Role Based Access Controls will be at 1300 UTC on Thursday 
11/30. This is a type of LCOO working group discussion  forum we plan to 
conduct on a monthly basis. Agenda and logistics to join can be found at 
https://openstack-lcoo.atlassiaBHIn.net/wiki/x/DwAvAQ
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [nova] Etherpad for tracking nova cellsv1 to cellsv2 migration issues/questions/strategies/patches

[Matt Riedemann]

Now that some cells v1 deployments are getting serious about migrating 
to cells v2, people have questions and are tackling the migration in 
different ways.


I've started an etherpad where we can start putting notes which will 
hopefully help those getting started with the migration, and help the 
nova team with prioritizing any changes needed, be those code, docs, etc.


https://etherpad.openstack.org/p/cellsv1-to-v2-migration

--

Thanks,

Matt

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

[openstack-dev] [nova] Etherpad for tracking nova cellsv1 to cellsv2 migration issues/questions/strategies/patches

[Matt Riedemann]

Now that some cells v1 deployments are getting serious about migrating 
to cells v2, people have questions and are tackling the migration in 
different ways.


I've started an etherpad where we can start putting notes which will 
hopefully help those getting started with the migration, and help the 
nova team with prioritizing any changes needed, be those code, docs, etc.


https://etherpad.openstack.org/p/cellsv1-to-v2-migration

--

Thanks,

Matt

__
OpenStack Development Mailing 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] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Jason E. Rist]

On 11/29/2017 12:34 PM, John Trowbridge wrote:
> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

yoooge +1

__
OpenStack Development Mailing 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] [octavia] [heat] errors during loadbalancer creation

[Volodymyr Litovka]

Hi colleagues,

Note: errors, described below, don't have a visible impact in my current 
configuration. But I draw attention on this since need to understand 
whether it's expected behaviour or something wrong with something and 
what exactly.


When creating loadbalancer infra (balancer, listener, pool and members) 
in active/standby agents configuration, either using Neutron CLI or Heat 
orchestration (below), I see the following errors in _neutron-server.log_ :


* Upon listener create (below showed a single block of related messages, 
second is very similar to this; both when using either 
"lbaas-listener-create" command or Heat orchestration) -


2017-11-29 15:05:29.440 1021 DEBUG neutron.api.v2.base 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] Request body: {u'security_group_rule': {u'direction': 
u'ingress', u'protocol': 51, u'ethertype': u'IPv4', u'port_range_max': 
None, u'security_group_id': u'4669fde0-5d4e-40be-b560-21173ac4561f', 
u'port_range_min': None}} prepare_request_body 
/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py:695
2017-11-29 15:05:29.443 1021 DEBUG neutron.db.quota.driver 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] Resources 
member,graph,subnetpool,listener,healthmonitor,l7policy have unlimited 
quota limit. It is not required to calculate headroom make_reservation 
/usr/lib/python2.7/dist-packages/neutron/db/quota/driver.py:223
2017-11-29 15:05:29.446 1021 DEBUG neutron.quota.resource 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] Usage tracker for resource:security_group_rule and 
tenant:413f0da1f66146ed801b1f6ced1cda48 is out of sync, need to count 
used quota count_used 
/usr/lib/python2.7/dist-packages/neutron/quota/resource.py:274
2017-11-29 15:05:29.451 1021 DEBUG neutron.quota.resource 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] Quota usage for security_group_rule was recalculated. 
Used quota:24. count_used 
/usr/lib/python2.7/dist-packages/neutron/quota/resource.py:293
2017-11-29 15:05:29.454 1021 DEBUG neutron.db.quota.driver 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] Attempting to reserve 1 items for resource 
security_group_rule. Total usage: 24; quota limit: 100; headroom:76 
make_reservation 
/usr/lib/python2.7/dist-packages/neutron/db/quota/driver.py:255
2017-11-29 15:05:29.613 1021 DEBUG neutron_lib.callbacks.manager 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] Notify callbacks [] for security_group_rule, 
before_create _notify_loop 
/usr/lib/python2.7/dist-packages/neutron_lib/callbacks/manager.py:167
2017-11-29 15:05:29.721 1021 INFO neutron.api.v2.resource 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] *create failed (client error): There was a conflict 
when trying to complete your request.*
2017-11-29 15:05:29.722 1021 INFO neutron.wsgi 
[req-a78d573d-6cb8-4164-afac-e37bb340640c 
2a012afc274341dc81b7ea5140662e8c 413f0da1f66146ed801b1f6ced1cda48 - 
default default] 10.0.10.10 *"POST /v2.0/security-group-rules HTTP/1.1"* 
status: 409  len: 347 time: 0.2877431*

*
* Upon creation of pool members (2 members), these errors appear only 
when creating infra using Heat (no errors when using neutron 
"lbaas-member-create" CLI command ) :


2017-11-29 12:04:30.229 1018 DEBUG neutron.api.v2.base 
[req-e3d66438-da0c-4b68-be6c-d47b3bce55b1 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] Request body: {u'member': {u'subnet_id': 
u'ecb891c1-b7e5-45e0-8815-8675381d70d2', u'protocol_port': 8080, 
u'admin_state_up': True, u'weight': 1, u'address': u'10.1.1.11'}} 
prepare_request_body 
/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py:695
2017-11-29 12:04:30.232 1018 DEBUG neutron.db.quota.driver 
[req-e3d66438-da0c-4b68-be6c-d47b3bce55b1 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] Resources 
member,graph,subnetpool,listener,healthmonitor,l7policy have unlimited 
quota limit. It is not required to calculate headroom make_reservation 
/usr/lib/python2.7/dist-packages/neutron/db/quota/driver.py:223
2017-11-29 12:04:30.690 1018 INFO neutron.api.v2.resource 
[req-e3d66438-da0c-4b68-be6c-d47b3bce55b1 
e6406606bd9d48aabc413468f9703cf6 c1114776e144400da17d8e060856be8c - 
default default] *create failed (client error): There was a conflict 
when trying to complete your request.*
2017-11-29 12:04:30.691 1018 INFO neutron.wsgi 
[req-e3d66438-da0c-4b68-be6c-d47b3bce55b1 
e6406606bd9d48aabc413468f9703cf6 

Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[mathieu bultel]

+1 indeed :)

On 11/29/2017 08:34 PM, John Trowbridge wrote:
> I would like to propose Ronelle be given +2 for the above repos. She
> has been a solid contributor to tripleo-quickstart and extras almost
> since the beginning. She has solid review numbers, but more
> importantly has always done quality reviews. She also has been working
> in the very intense rover role on the CI squad in the past CI sprint,
> and has done very well in that role.
>
>
> __
> OpenStack Development Mailing 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] Propose Slawek Kaplonski for Neutron core

[Korzeniewski, Artur]

+1 from me , (even though my vote does not count)
I know Slawek since Tokyo summit and I’m impressed of his knowledge and 
hands-on experience to improve Neutron quality and functionality!
It is great to see him joining the core reviewers team!
Congrats Sławek!

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Wednesday, November 29, 2017 8:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

"+1" I know, I'm not active, but I care about neutron, and slaweq is a great 
contributor.

On Nov 29, 2017 8:37 PM, "Ihar Hrachyshka" 
> wrote:
YES, FINALLY.

On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton 
> wrote:
> +1! ... even though I haven't been around. :)
>
> On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle 
> > wrote:
>>
>> Hi Neutron Team,
>>
>> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
>> has been an active contributor to the project since the Mitaka cycle. He has
>> been instrumental in the development of the QoS capabilities in Neutron,
>> becoming the lead of the sub-team focused on that set of features. More
>> recently, he has collaborated in the implementation of OVO and is an active
>> participant in the CI sub-team. His number of code reviews during the Queens
>> cycle is on par with the leading core members of the team:
>> http://stackalytics.com/?module=neutron
>>
>> In my opinion, his efforts are highly valuable to the team and we will be
>> very lucky to have him as a fully voting core.
>>
>> I will keep this nomination open for a week as customary,
>>
>> Thank you,
>>
>> Miguel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Wesley Hayutin]

+1 woot

On Wed, Nov 29, 2017 at 2:44 PM, Alex Schultz  wrote:

> +1
>
> On Wed, Nov 29, 2017 at 12:34 PM, John Trowbridge 
> wrote:
> > I would like to propose Ronelle be given +2 for the above repos. She has
> > been a solid contributor to tripleo-quickstart and extras almost since
> the
> > beginning. She has solid review numbers, but more importantly has always
> > done quality reviews. She also has been working in the very intense rover
> > role on the CI squad in the past CI sprint, and has done very well in
> that
> > role.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

[Miguel Angel Ajo Pelayo]

"+1" I know, I'm not active, but I care about neutron, and slaweq is a
great contributor.

On Nov 29, 2017 8:37 PM, "Ihar Hrachyshka"  wrote:

> YES, FINALLY.
>
> On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton  wrote:
> > +1! ... even though I haven't been around. :)
> >
> > On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle 
> wrote:
> >>
> >> Hi Neutron Team,
> >>
> >> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core.
> Slawek
> >> has been an active contributor to the project since the Mitaka cycle.
> He has
> >> been instrumental in the development of the QoS capabilities in Neutron,
> >> becoming the lead of the sub-team focused on that set of features. More
> >> recently, he has collaborated in the implementation of OVO and is an
> active
> >> participant in the CI sub-team. His number of code reviews during the
> Queens
> >> cycle is on par with the leading core members of the team:
> >> http://stackalytics.com/?module=neutron
> >>
> >> In my opinion, his efforts are highly valuable to the team and we will
> be
> >> very lucky to have him as a fully voting core.
> >>
> >> I will keep this nomination open for a week as customary,
> >>
> >> Thank you,
> >>
> >> Miguel
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Alex Schultz]

+1

On Wed, Nov 29, 2017 at 12:34 PM, John Trowbridge  wrote:
> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.
>
> __
> OpenStack Development Mailing 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] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Gabriele Cerami]

On 29 Nov, John Trowbridge wrote:
> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.

+1

She's been a reliable, scrupulous contributor for all the parts related
to CI.

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

Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Emilien Macchi]

On Wed, Nov 29, 2017 at 11:34 AM, John Trowbridge  wrote:
> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.

solid +1 :-)

Thanks for your work Ronelle!
-- 
Emilien Macchi

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

Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Harry Rybacki]

On Wed, Nov 29, 2017 at 2:34 PM, John Trowbridge  wrote:
> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.
>
+100
> __
> OpenStack Development Mailing 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] Propose Slawek Kaplonski for Neutron core

[Ihar Hrachyshka]

YES, FINALLY.

On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton  wrote:
> +1! ... even though I haven't been around. :)
>
> On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle  wrote:
>>
>> Hi Neutron Team,
>>
>> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
>> has been an active contributor to the project since the Mitaka cycle. He has
>> been instrumental in the development of the QoS capabilities in Neutron,
>> becoming the lead of the sub-team focused on that set of features. More
>> recently, he has collaborated in the implementation of OVO and is an active
>> participant in the CI sub-team. His number of code reviews during the Queens
>> cycle is on par with the leading core members of the team:
>> http://stackalytics.com/?module=neutron
>>
>> In my opinion, his efforts are highly valuable to the team and we will be
>> very lucky to have him as a fully voting core.
>>
>> I will keep this nomination open for a week as customary,
>>
>> Thank you,
>>
>> Miguel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[John Trowbridge]

I would like to propose Ronelle be given +2 for the above repos. She has
been a solid contributor to tripleo-quickstart and extras almost since the
beginning. She has solid review numbers, but more importantly has always
done quality reviews. She also has been working in the very intense rover
role on the CI squad in the past CI sprint, and has done very well in that
role.
__
OpenStack Development Mailing 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] Propose Slawek Kaplonski for Neutron core

[Kevin Benton]

+1! ... even though I haven't been around. :)

On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle  wrote:

> Hi Neutron Team,
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He
> has been instrumental in the development of the QoS capabilities in
> Neutron, becoming the lead of the sub-team focused on that set of features.
> More recently, he has collaborated in the implementation of OVO and is an
> active participant in the CI sub-team. His number of code reviews during
> the Queens cycle is on par with the leading core members of the team:
> http://stackalytics.com/?module=neutron
>
> In my opinion, his efforts are highly valuable to the team and we will be
> very lucky to have him as a fully voting core.
>
> I will keep this nomination open for a week as customary,
>
> Thank you,
>
> Miguel
>
> __
> OpenStack Development Mailing 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] Propose Slawek Kaplonski for Neutron core

[Miguel Lavalle]

Hi Neutron Team,

I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
has been an active contributor to the project since the Mitaka cycle. He
has been instrumental in the development of the QoS capabilities in
Neutron, becoming the lead of the sub-team focused on that set of features.
More recently, he has collaborated in the implementation of OVO and is an
active participant in the CI sub-team. His number of code reviews during
the Queens cycle is on par with the leading core members of the team:
http://stackalytics.com/?module=neutron

In my opinion, his efforts are highly valuable to the team and we will be
very lucky to have him as a fully voting core.

I will keep this nomination open for a week as customary,

Thank you,

Miguel
__
OpenStack Development Mailing 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] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Jay Pipes]

On 11/29/2017 11:26 AM, Monty Taylor wrote:
For instance - an OpenStack Availability Zone and an AWS AZ are **not** 
the same thing.


This deserves repeating every week on the OpenStack mailing list.

-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] [E] Re: nova diagnostics in client library/SDK

[Gordon, Kent S]

On Tue, Nov 28, 2017 at 2:15 PM, Monty Taylor  wrote:

> On 11/03/2017 11:31 AM, Gordon, Kent S wrote:
>
>> Do any of the python client libraries implement the nova diagnostics API?
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.op
>> enstack.org_wiki_Nova-5FVM-5FDiagnostics=DwIGaQ=udBTRvFv
>> XC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakp
>> X0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-
>> q5M0kTDNg=RI4HTKLenL00VdvmCqFfjr5IMJV4HfWW_UkH1R1BWSU=
>>
>
> Not to my knowledge, no. However, adding support for it should be easy
> enough to accomplish and would be a welcome addition.
>
> This is the API you're talking about?
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__develop
> er.openstack.org_api-2Dref_compute_-23servers-2Ddiagnosti
> cs-2Dservers-2Ddiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJl
> Pps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22
> bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=2GH
> 64mANdI_uV67Gt2YvoBJlR7uHHl17EB-URrOMN-E=
>
> yes


> If you feel like hacking on it, a patch to openstack/python-openstacksdk
> would be the best way to go.
>
> However, this is microversion-protected, and this would be the first such
> feature in the SDK. So if diving that far down the rabbithole sounds like
> too much, either bug me until I get around to it - or do as much of it as
> makes sense (like adding a Resource class based on openstack.resource2) but
> ignore the microversion bit and I can help finish it off.
>

It has been a while since I did a lot of development.  Let me see how far I
can get.


>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.op
> enstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=
> DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r
> 0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFE
> xdHuyh-NeUTzyu-q5M0kTDNg=8xuC0FW6XEkzqUVphNPBbC5REiT04D5dbJL09S1mhC0=
>



-- 
Kent S. Gordon
kent.gor...@verizonwireless.com Work:682-831-3601 Mobile: 817-905-6518
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [all] TC Report 48

[gordon chung]

On 2017-11-29 12:34 PM, Chris Dent wrote:
> Sufficent answer?

speaking for myself, yes.

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

Re: [openstack-dev] [tc] [all] TC Report 48

[gordon chung]

On 2017-11-29 12:31 PM, Anne Bertucio wrote:
> Rereading your question, Gord, the tl;dr of my message is that current 
> roadmap is not intended to dictate work or what future features should 
> be—just captures and communicates work already in motion.

ah, i see. i was mainly curious to see how different the roadmap was vs 
reality. thanks for the explanation and link to resources.

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

Re: [openstack-dev] [tc] [all] TC Report 48

[Chris Dent]

On Wed, 29 Nov 2017, gordon chung wrote:

On 2017-11-28 11:36 AM, Chris Dent wrote:

* A somewhat bizarre presentation suggesting the Board and the TC
   manage the OpenStack roadmap. There wasn't time to actually discuss
   this as previous topics ran _way_ over, but at a superficial glance
   it appeared to involve a complete misunderstanding of not just how
   open source works in OpenStack, but how open source works in
   general.


was this topic to discuss how to implement an existing roadmap or how
the board/tc should build a roadmap or something else completely? if the
first, is there a link to this 'roadmap'?


As usual your trenchant insights are welcome and put the lie to your
claims of disaffection and disability.

The "roadmap, what/which roadmap?" was part of what made things
"bizarre". As we didn't actually get deeply into the presentation,
the slides or the discussion it's hard to be sure so what follows is
entirely speculation, I really have no idea.

However, if I were to guess, the roadmap in this case is a sort of
notional or platonic roadmap standing in for the idea of "wouldn't
it be great if there were a unified direction for OpenStack?" With
that in place you can then come around to the idea of "wouldn't
it be great if that direction was somehow effectively managed?"

When you put it like that it doesn't sound half bad, but when
sourced from a place that often smells of "OpenStack is not
addressing the needs of telcos and NFV fast enough" it gets a taint
on it.

Sufficent answer?

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [all] TC Report 48

[Anne Bertucio]

Rereading your question, Gord, the tl;dr of my message is that current roadmap 
is not intended to dictate work or what future features should be—just captures 
and communicates work already in motion. 


Anne Bertucio
Marketing and Certification, OpenStack Foundation
a...@openstack.org | 206-992-7961




> On Nov 29, 2017, at 9:27 AM, Anne Bertucio  wrote:
> 
> The community does have an existing Roadmap, albeit this cycle we decided we 
> need to change how we design the Roadmap and its final form. We have a small 
> community Roadmap team (anyone want to join?!) who compiles this information. 
>  
> 
> In the past, the Roadmap aimed to be a document for both project teams, end 
> users, and anyone in between. It tried to capture what was coming in the next 
> release as well as predict up to 3 releases forward. We decided this was 
> biting off far too much—trying to be all things to all people. 
> 
> What we’re trying to do now is be a user-focused document that communicates 
> critical changes and exciting features coming in the next release. We want to 
> help people who are evaluating OpenStack see future features, and help people 
> who are less privy to the day-to-day dev channels be aware of features that 
> may affect them. 
> 
> The Roadmap that was presented in Sydney lives here: 
> https://www.openstack.org/software/roadmap 
> 
> 
>  
> Anne Bertucio
> OpenStack Foundation
> a...@openstack.org  
> 
> 
> 
> 
>> On Nov 29, 2017, at 9:10 AM, gordon chung > > wrote:
>> 
>> 
>> 
>> On 2017-11-28 11:36 AM, Chris Dent wrote:
>>> * A somewhat bizarre presentation suggesting the Board and the TC
>>>   manage the OpenStack roadmap. There wasn't time to actually discuss
>>>   this as previous topics ran _way_ over, but at a superficial glance
>>>   it appeared to involve a complete misunderstanding of not just how
>>>   open source works in OpenStack, but how open source works in
>>>   general.
>> 
>> was this topic to discuss how to implement an existing roadmap or how 
>> the board/tc should build a roadmap or something else completely? if the 
>> first, is there a link to this 'roadmap'?
>> 
>> 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 Development Mailing 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] [tc] [all] TC Report 48

[Anne Bertucio]

The community does have an existing Roadmap, albeit this cycle we decided we 
need to change how we design the Roadmap and its final form. We have a small 
community Roadmap team (anyone want to join?!) who compiles this information.  

In the past, the Roadmap aimed to be a document for both project teams, end 
users, and anyone in between. It tried to capture what was coming in the next 
release as well as predict up to 3 releases forward. We decided this was biting 
off far too much—trying to be all things to all people. 

What we’re trying to do now is be a user-focused document that communicates 
critical changes and exciting features coming in the next release. We want to 
help people who are evaluating OpenStack see future features, and help people 
who are less privy to the day-to-day dev channels be aware of features that may 
affect them. 

The Roadmap that was presented in Sydney lives here: 
https://www.openstack.org/software/roadmap 


 
Anne Bertucio
OpenStack Foundation
a...@openstack.org 




> On Nov 29, 2017, at 9:10 AM, gordon chung  wrote:
> 
> 
> 
> On 2017-11-28 11:36 AM, Chris Dent wrote:
>> * A somewhat bizarre presentation suggesting the Board and the TC
>>   manage the OpenStack roadmap. There wasn't time to actually discuss
>>   this as previous topics ran _way_ over, but at a superficial glance
>>   it appeared to involve a complete misunderstanding of not just how
>>   open source works in OpenStack, but how open source works in
>>   general.
> 
> was this topic to discuss how to implement an existing roadmap or how 
> the board/tc should build a roadmap or something else completely? if the 
> first, is there a link to this 'roadmap'?
> 
> 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 Development Mailing 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] Community managed tech/dev blog: Call for opinions and ideas

[Joshua Harlow]

Thierry Carrez wrote:

Jimmy McArthur wrote:

Thierry Carrez wrote:

Historically blog.o.o used to be our only blog outlet, so almost
anything would go in:

"OpenStack Events Sponsorship Webinar"
"New Foundation Gold Members&  Corporate Sponsors"
"HP Announces Private Beta Program for OpenStack Cloud"
"2016 OpenStack T-Shirt Design Contest"

What Josh wants is a curated technical blog, so if we reused blog.o.o
for this (and I think it's a good idea), we'd likely want to have a bit
more rules on what's appropriate.

Agreed. It's almost solely used for developer digest now and isn't
frequently updated. Most of the promotion of sponsors and news goes into
o.o/News, SuperUser, or one of our other marketing channels. It's a good
time for the community to repurpose it :)


Perfect, we have a plan.

Before we make it tech-only and boring, let us all take a minute to
remember the OpenStack jingle:

https://www.openstack.org/blog/2011/07/openstack-the-best-sounding-cloud/



Errr, ummm, woah, lol

We might need to work on our DJ skills, lol

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

Re: [openstack-dev] [tc] [all] TC Report 48

[gordon chung]

On 2017-11-28 11:36 AM, Chris Dent wrote:
> * A somewhat bizarre presentation suggesting the Board and the TC
>    manage the OpenStack roadmap. There wasn't time to actually discuss
>    this as previous topics ran _way_ over, but at a superficial glance
>    it appeared to involve a complete misunderstanding of not just how
>    open source works in OpenStack, but how open source works in
>    general.

was this topic to discuss how to implement an existing roadmap or how 
the board/tc should build a roadmap or something else completely? if the 
first, is there a link to this 'roadmap'?

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] [docs] Documentation meeting minutes for 2017-11-29

[Petr Kovar]

===
#openstack-doc: docteam
===


Meeting started by pkovar at 16:00:16 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2017/docteam.2017-11-29-16.00.log.html
.



Meeting summary
---

* roll call  (pkovar, 16:00:42)

* Docs team vision document  (pkovar, 16:05:20)
  * Merged  (pkovar, 16:05:28)
  * LINK: https://docs.openstack.org/doc-contrib-guide/team-vision.html
(pkovar, 16:05:33)

* Docs retention policy changes  (pkovar, 16:07:32)
  * WIP  (pkovar, 16:07:40)
  * LINK: https://review.openstack.org/#/c/521961/  (pkovar, 16:07:47)
  * ACTION: eumel8 to ask the language teams about restoring language
landing pages  (pkovar, 16:13:26)
  * Flagging deprecated releases  (pkovar, 16:15:21)
  * LINK:
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123381.html
(pkovar, 16:15:22)
  * jamesmcarthur to work on patch, dhellmann to help with Q's.
(pkovar, 16:17:58)
  * LINK: https://review.openstack.org/#/c/509297/  (pkovar, 16:24:17)
  * pdf spec ^  (pkovar, 16:24:32)
  * think about providing a watermark too, possibly as a separate patch.
good for pdfs  (pkovar, 16:25:07)

* OpenStack Summit Sydney  (pkovar, 16:26:13)
  * Summary of docs sessions posted  (pkovar, 16:26:18)
  * LINK:

https://www.rdoproject.org/blog/2017/11/summary-openstack-summit-docs-sessions/
(pkovar, 16:26:23)

* Rocky PTG  (pkovar, 16:27:40)
  * Planning etherpad for docs+i18n created  (pkovar, 16:27:48)
  * LINK: https://etherpad.openstack.org/p/docs-i18n-ptg-rocky  (pkovar,
16:27:54)
  * Parcel time into small chunks or have full-day focus on one team
agenda?  (pkovar, 16:28:43)
  * for PTG, two days planned, ca.  8-12 people  (pkovar, 16:35:19)
  * ACTION: send an email to start gathering input wrt ptg agenda
(pkovar, 16:36:59)
  * ACTION: pkovar to send an email for both teams to openstack-dev
(pkovar, 16:39:14)
  * ACTION: when getting input, let's also ask people to sign up and
share their day and time preferences  (pkovar, 16:42:54)

* closing openstack-docs mailing list  (pkovar, 16:45:55)
  * ACTION: close the list for new mail and subscribers tomorrow
(pkovar, 16:49:29)

* Branches vs everything in master  (pkovar, 16:51:11)

* sitemap automation suggestions  (pkovar, 16:52:49)
  * LINK:
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123228.html
(pkovar, 16:52:56)
  * ACTION: mguiney working on this  (pkovar, 16:55:37)

* Bug Triage Team  (pkovar, 16:57:48)
  * LINK: https://wiki.openstack.org/wiki/Documentation/SpecialityTeams
(pkovar, 16:57:52)

* Open discussion  (pkovar, 16:59:44)

* PDF builds  (pkovar, 17:00:56)
  * LINK: https://review.openstack.org/#/c/509297/  (pkovar, 17:01:02)
  * the proposal needs more review from other people  (pkovar, 17:01:11)



Meeting ended at 17:01:57 UTC.



Action items, by person
---

* eumel8
  * eumel8 to ask the language teams about restoring language landing
pages
* mguiney
  * mguiney working on this
* openstack
  * pkovar to send an email for both teams to openstack-dev
* pkovar
  * pkovar to send an email for both teams to openstack-dev
* **UNASSIGNED**
  * send an email to start gathering input wrt ptg agenda
  * when getting input, let's also ask people to sign up and share their
day and time preferences
  * close the list for new mail and subscribers tomorrow



People present (lines said)
---

* pkovar (151)
* eumel8 (31)
* jamesmcarthur (17)
* dhellmann (11)
* jungleboyj (7)
* openstack (4)
* chason (3)
* mguiney (1)



Generated by `MeetBot`_ 0.1.4


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

[openstack-dev] [monasca] Monasca at PTG in Dublin

[Bedyk, Witold]

Hello,

As discussed in the meeting today I would like to ask for your opinion if 
Monasca team should gather at the Project Teams Gathering (PTG) event in 
Dublin, February 26 - March 2nd [1]. The goal of the PTG is "to discuss 
priorities for the upcoming cycle, iterate quickly on solutions for complex 
issues, and make fast progress on critical items". Alternatively we can hold a 
remote video conference, as we have done previously.

Please fill in the following form until Dec 4th if you want to participate in 
planning the work for the next release:
https://goo.gl/forms/yLn0vi1A03OXfO843

[1] https://www.openstack.org/ptg/

Best greetings
Witek

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

Re: [openstack-dev] [oaktree] Follow up to Multi-cloud Management in OpenStack Summit session

[Monty Taylor]

On 11/28/2017 07:14 PM, Joshua Harlow wrote:

Small side-question,

Why would this just be limited to openstack clouds?

>

Would it be?


That's a great question. I think, at least for now, attempting to 
support non-OpenStack clouds would be too much and would cause us to 
have a thing that tries to solve all the problems and ends up solving 
none of them.


The problem is that, as much as there are deployer differences between 
OpenStack clouds, papering over them isn't THAT bad from an interface 
perspective, since the fundamental concepts are all the same.


Once you add non-OpenStack clouds, you have to deal with the extreme 
impedence mismatch between core concepts, and the use of similar names 
for different things.


For instance - an OpenStack Availability Zone and an AWS AZ are **not** 
the same thing. So you'd either need to use a different word mapped to 
each one (which would confuse either OpenStack or AWS users) or you'd 
have an oaktree concept mean different things depending on which cloud 
happened to be there.


All that said - I don't think there's anything architecturally that 
would prevent such work from happening- I just think it's fraught with 
peril and unlikely to be super successful and that we should focus on 
making sure OpenStack users can consume multi-cloud and 
multi-cloud-region sanely. Then, once we're happy with that and have 
served the needs of our OpenStack users, if someone comes up with a plan 
that adds support for non-OpenStack backend drivers for oaktree in a way 
that does not make life worse for the OpenStack users - then why not.



Monty Taylor wrote:

Hey everybody!

https://etherpad.openstack.org/p/sydney-forum-multi-cloud-management

I've CC'd everyone who listed interest directly, just in case you're not
already on the openstack-dev list. If you aren't, and you are in fact
interested in this topic, please subscribe and make sure to watch for
[oaktree] subject headings.

We had a great session in Sydney about the needs of managing resources
across multiple clouds. During the session I pointed out the work that
had been started in the Oaktree project [0][1] and offered that if the
people who were interested in the topic thought we'd make progress best
by basing the work on oaktree, that we should bootstrap a new core team
and kick off some weekly meetings. This is, therefore, the kickoff email
to get that off the ground.

All of the below is thoughts from me and a description of where we're at
right now. It should all be considered up for debate, except for two
things:

- gRPC API
- backend implementation based on shade

As those are the two defining characteristics of the project. For those
who weren't in the room, justifications for those two characteristics 
are:


gRPC API


There are several reasons why gRPC.

* Make it clear this is not a competing REST API.

OpenStack has a REST API already. This is more like a 'federation' API
that knows how to talk to one or more clouds (similar to the kubernetes
federation API)

* Streaming and async built in

One of the most costly things in using the OpenStack API is polling.
gRPC is based on HTTP/2 and thus supports streaming and other exciting
things. This means an oaktree running in or on a cloud can do its
polling loops over the local network and the client can just either wait
on a streaming call until the resource is ready, or can fire an async
call and deal with it later on a notification channel.

* Network efficiency

Protobuf over HTTP/2 is a super-streamlined binary protocol, which
should actually be really nice for our friends in Telco land who are
using OpenStack for Edge-related tasks in 1000s of sites. All those
roundtrips add up at scale.

* Multi-language out of the box

gRPC allows us to directly generate consistent consumption libs for a
bunch of languages - or people can grab the proto files and integrate
those into their own build if they prefer.

* The cool kids are doing it

To be fair, Jay Pipes and I tried to push OpenStack to use Protobuf
instead of JSON for service-to-service communication back in 2010 - so
it's not ACTUALLY a new idea... but with Google pushing it and support
from the CNCF, gRPC is actually catching on broadly. If we're writing a
new thing, let's lean forward into it.

Backend implementation in shade
---

If the service is defined by gRPC protos, why not implement the service
itself in Go or C++?

* Business logic to deal with cloud differences

Adding a federation API isn't going to magically make all of those
clouds work the same. We've got that fairly well sorted out in shade and
would need to reimplement basically all of shade in other other language.

* shade is battle tested at scale

shade is what Infra's nodepool uses. In terms of high-scale API
consumption, we've learned a TON of lessons. Much of the design inside
of shade is the result of real-world scaling issues. It's Open Source,
so we could obviously copy all of 

Re: [openstack-dev] [heat][qa] Split tempest plugin from heat

[Zane Bitter]

On 19/11/17 03:08, Rabi Mishra wrote:

Hi All,

As part of community goal[1] for Queens, we've completed the repo split 
and created the new project[2].


The next objective to is to use the new plugin in our jobs. As we've 
merged some changes after the split, I've synced them and fixed some 
minor issues before using it in the gate jobs.


These are very small changes and I would suggest we review/land them on 
priority (we don't have to keep syncing them again and again for broken 
jobs). We should probably *not approve* any changes to integration tests 
in heat before these go in.


- Changes in heat-tempest-plugin (sync  missing patches and fixes)
https://review.openstack.org/#/q/project:openstack/heat-tempest-plugin+topic:sync_from_heat

- Use heat-tempest-plugin for integration jobs
https://review.openstack.org/#/c/508112/

- Use heat-tempest-plugin for grenade job
https://review.openstack.org/#/c/521246/

- Add heat integration jobs to heat-tempest-plugin check/gate queue
https://review.openstack.org/#/c/521340/
   I guess this would result in some issues, where we can't add any 
changes to heat that breaks the existing tests, as the changes for both 
projects would have a circular dependency (not sure how it works atm 
with other plugins!).


- Remove plugin an integration tests from heat (This has -1 atm as 
releasenote job is broken, waiting for infra to fix it)
https://review.openstack.org/#/c/521263/ 



I've also created an etherpad[3] to track these.

Also, the plugin project is expected to be branchless (we may not 
backport these job changes to stable branches soon though), we've to 
find  a  way to run additional tests for any new feature only on > 
. AFAIK, other projects check api microversions 
supported and without microversions in heat, may be we've find an 
alternate way.


So from discussion on IRC today I learned that the plan agreed at the 
PTG was *not* to move all of heat_integrationtests to a separate repo, 
but just those tests that test the API and are likely to be used in the 
trademark program for verifying clouds.


In my view that effectively means just the Gabbi tests.

However, what is actually happening is that *all* of the 
integration/scenario tests are moving to the separate branchless repo. 
This looks to me like it will be a disaster for developer and reviewer 
productivity, and project quality[1]. (Other folks seem inclined to agree.)


The QA team assures us that the project-wide goal does not preclude 
keeping tests that are designed for Heat CI purposes (rather than cloud 
verification purposes) in-tree - even continuing to use tempest as a 
testrunner. However, it's not at all clear how to reconcile that with 
the goal description listing the evils of having an in-tree tempest 
plugin.[2] This appears to be the reason for the change in plan.


Does anybody remember what the mechanism for dealing with this that was 
agreed at the PTG was?


Basically we need a way to:

* Run a bunch of integration tests in Heat CI jobs
* against a full OpenStack cloud
* preferably using tempest as a testrunner, but this is optional
* without any danger of e.g. breaking tempest test discovery just 
because Heat was installed on the same machine as tempest


How do we do it?

thanks,
Zane.

[1] 
http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2017-11-29.log.html#t2017-11-29T15:17:00
[2] 
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html#split-tempest-plugins-into-separate-repos-projects



--
Regards,
Rabi Mishra

[1] 
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html

[2] https://git.openstack.org/cgit/openstack/heat-tempest-plugin
[3] https://etherpad.openstack.org/p/heat-tempest-plugin


__
OpenStack Development Mailing 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] [patrole] Question regarding Patrole API coverage

[Graham Hayes]

On 29/11/17 15:11, Andrea Frittoli wrote:
> 
> 
> On Wed, Nov 29, 2017 at 2:28 PM Peng Liu  > wrote:
> 
> Hi Team,
> 
> Hi Peng
>  
> 
> I have a question regarding to the API coverage of Patrole.
> Currently, Patrole as a Tempest plugin heavily relys on the Tempest
> code. However, Tempest only contains the API tests for the most
> common APIs of the most common projects(Nova, Neutron, Cinder,
> Glance, Swift, Keystone). 
> 
> So I want to know if it is possible to extend Patrole to:
> 1) test the APIs of the common projects which was not yet covered in
> Tempest.  
> 
> 2) test projects which was not covered in Tempest?
> 
> 
> You can use the Patrole framework to test services not covered by
> Tempest by taking advantage of Tempest plugin mechanism.
> Patrole itself is a Tempest plugin. If you install the plugin of a
> service that includes a service client, you should be able to use it to
> write Patrole tests for that service.
> I believe this has not been done yet by any project though, so there may
> be a few technical bits to be sorted out.

There has been a start with Designate + Neutron [1], it is just underway
now though.

It could cause an issue as all of a sudden the internals of a project's
plugin may need to be a stable interface, which may not be something
they expect.

1 - https://review.openstack.org/#/c/520237/
  
> I don't think Patrole itself will have to be extended, however Patrole
> does not yet include stable APIs.
> If you're going to use Patrole APIs in your project you need to be aware
> that there may be backward incompatible changes happening without a
> deprecation period.
> 
> There are several options on where to host such tests: in a dedicated
> plugin, in the Tempest plugin for the service or in Patrole itself.
> The latter would probably suffer from the same scalability issues that
> lead us to create the plugin mechanism to begin with.
> 
> Andrea Frittoli (andreaf)
>  
> 
> 
> Thanks,
> -- 
> Peng Liu 
> __
> OpenStack Development Mailing 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
> 



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] [qa] [patrole] Question regarding Patrole API coverage

[Andrea Frittoli]

On Wed, Nov 29, 2017 at 2:28 PM Peng Liu  wrote:

> Hi Team,
>
> Hi Peng


> I have a question regarding to the API coverage of Patrole. Currently,
> Patrole as a Tempest plugin heavily relys on the Tempest code. However,
> Tempest only contains the API tests for the most common APIs of the most
> common projects(Nova, Neutron, Cinder, Glance, Swift, Keystone).
>
> So I want to know if it is possible to extend Patrole to:
> 1) test the APIs of the common projects which was not yet covered in
> Tempest.
>
2) test projects which was not covered in Tempest?
>

You can use the Patrole framework to test services not covered by Tempest
by taking advantage of Tempest plugin mechanism.
Patrole itself is a Tempest plugin. If you install the plugin of a service
that includes a service client, you should be able to use it to write
Patrole tests for that service.
I believe this has not been done yet by any project though, so there may be
a few technical bits to be sorted out.

I don't think Patrole itself will have to be extended, however Patrole does
not yet include stable APIs.
If you're going to use Patrole APIs in your project you need to be aware
that there may be backward incompatible changes happening without a
deprecation period.

There are several options on where to host such tests: in a dedicated
plugin, in the Tempest plugin for the service or in Patrole itself.
The latter would probably suffer from the same scalability issues that lead
us to create the plugin mechanism to begin with.

Andrea Frittoli (andreaf)


>
> Thanks,
> --
> Peng Liu
> __
> OpenStack Development Mailing 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-operators] DNS failure with fuel

[Braihan Cantera]

Hi People! I have a strange issue, I'm using mirantis fuel 9.2 and I have
an already deployed testing environment, I had never changed the domain and
searchdomain for it, and I tested changing it from default to fuellab.tld
and name resolving stopped working :/ now I can access my nodes only by IP
adress, I changed this configuration back to the domain that I have before
and it remains failing resolving names, any idea of what could be wrong?
Thanks in adv!
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [keystone] Queens-2 Retrospective

[Lance Bragstad]

Hey all,

Just like for Queens-1, we're going to reuse the weekly meeting time [0]
for the retrospective. That means we'll be holding our retrospective on
December 12th during normal meeting hours. Some information can be found
in Trello [1]. We had some issues last time with video conferencing, but
maybe we can use BlueJeans again instead.

Thanks and let me know if you have questions.

Lance


[0] http://eavesdrop.openstack.org/#Keystone_Team_Meeting
[1] https://trello.com/c/le6Gdalb/61-schedule-queens-2-retrospective




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] [keystone] Queens-2 Retrospective

[Lance Bragstad]

Hey all,

Just like for Queens-1, we're going to reuse the weekly meeting time [0]
for the retrospective. That means we'll be holding our retrospective on
December 12th during normal meeting hours. Some information can be found
in Trello [1]. We had some issues last time with video conferencing, but
maybe we can use BlueJeans again instead.

Thanks and let me know if you have questions.

Lance


[0] http://eavesdrop.openstack.org/#Keystone_Team_Meeting
[1] https://trello.com/c/le6Gdalb/61-schedule-queens-2-retrospective




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] Dublin PTG format

[Jean-Philippe Evrard]

On 29 November 2017 at 03:20, Masayuki Igawa  wrote:
> On 11/28, Ghanshyam Mann wrote:
>> Mon-Tue/Wed-Fri works as most suitable format. There are always
>> conflict for many of us but that can be adjusted by working with team
>> planning.
>>
>> Another thing can help is to give flexibility to team to have team
>> topic even on Mon-Tue, which mean team need dedicated room on Mon-Tue
>> also. For example, if QA want to discuss few of the topic on Mon-Tue
>> and have Code sprint/Help room etc on rest of week. This can help me
>> or other QA members to join other team discussion on Wed-Fri. But that
>> is based on special request and team requirement of number of topics
>> to discuss.
>>
>> morning/afternoon format will be little hectic and less productive due
>> to changing rooms and topic etc, at least for me :)
>
> Yeah, I totally agree with that. Regarding to the QA team members,
> most of members are not dedicated to the upstream work. So, if we can
> concentrate on it during the rest of 3 days, the days could be really
> productive. And I felt it in the past PTG.
>
> -- Masayuki
>
>
>>
>> -gmann
>>
>>
>> On Mon, Nov 27, 2017 at 7:58 PM, Thierry Carrez  
>> wrote:
>> > Hi everyone,
>> >
>> > We are in the final step in the process of signing the contract with the
>> > PTG venue. We should be able to announce the location this week !
>> >
>> > So it's time to start preparing. We'll have 5 days, like in Denver. One
>> > thing we'd like to change for this round is to give a bit more
>> > flexibility in the topics being discussed, especially in the first two 
>> > days.
>> >
>> > In Denver, we selected a number of general "themes" and gave them all a
>> > room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
>> > project team meeting could get a room for 2 or 3 days on
>> > Wednesday-Friday. That resulted in a bit of flux during the first two
>> > days, with a lot of empty rooms as most of the themes did not really
>> > need 2 days, and a lot of conflicts were present.
>> >
>> > For Dublin, the idea would be to still predetermine topics (themes and
>> > teams) and assign them rooms in advance. But we would be able to assign
>> > smaller amounts of time (per half-day) based on the expressed needs.
>> > Beyond those pre-assigned themes/teams we'd add flexibility for other
>> > groups to book the remaining available rooms in 90-min slots on-demand.
>> > A bit like how we did reservable rooms in the past, but more integrated
>> > with the rest of the event. It would all be driven by the PTGbot, which
>> > would show which topic is being discussed in which room, in addition to
>> > the current discussion subject within each topic.
>> >
>> > We have two options in how we do the split for predetermined topics. We
>> > used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
>> > general idea there was to allow some people only interested in a team
>> > meeting to only attend the second part of the week. However most people
>> > attend all 5 days, and during event feedback some people suggested that
>> > "themes" should be in the mornings and "teams" in the afternoons (and
>> > all Friday).
>> >
>> > What would be your preference ? The Mon-Tue/Wed-Fri split means less
>> > room changes, which make it easier on the events team. So all else being
>> > equal we'd rather keep it the way it is, but I'm open to changing it if
>> > attendees think it's a good idea.
>> >
>> > If you have any other suggestion (that we could implement in the 3
>> > months we have between now and the event) please let me know :)
>> >
>> > --
>> > Thierry Carrez (ttx)
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing 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
>

I like the 2+3 days format. I'd prefer that to fragmenting. If people
want to roam around they are free.
On top of that PTG bot is a helper to find what's going to happen next.

I heard once (ok, maybe more than once): "If it ain't broke, don't fix it"!

Best regards,
JP

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [qa] [patrole] Question regarding Patrole API coverage

[Peng Liu]

Hi Team,

I have a question regarding to the API coverage of Patrole. Currently,
Patrole as a Tempest plugin heavily relys on the Tempest code. However,
Tempest only contains the API tests for the most common APIs of the most
common projects(Nova, Neutron, Cinder, Glance, Swift, Keystone).

So I want to know if it is possible to extend Patrole to:
1) test the APIs of the common projects which was not yet covered in
Tempest.
2) test projects which was not covered in Tempest?

Thanks,
-- 
Peng Liu
__
OpenStack Development Mailing 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] Community managed tech/dev blog: Call for opinions and ideas

[Jean-Philippe Evrard]

On 29 November 2017 at 11:30, Thierry Carrez  wrote:
> Jimmy McArthur wrote:
>> Thierry Carrez wrote:
>>> Historically blog.o.o used to be our only blog outlet, so almost
>>> anything would go in:
>>>
>>> "OpenStack Events Sponsorship Webinar"
>>> "New Foundation Gold Members & Corporate Sponsors"
>>> "HP Announces Private Beta Program for OpenStack Cloud"
>>> "2016 OpenStack T-Shirt Design Contest"
>>>
>>> What Josh wants is a curated technical blog, so if we reused blog.o.o
>>> for this (and I think it's a good idea), we'd likely want to have a bit
>>> more rules on what's appropriate.
>>
>> Agreed. It's almost solely used for developer digest now and isn't
>> frequently updated. Most of the promotion of sponsors and news goes into
>> o.o/News, SuperUser, or one of our other marketing channels. It's a good
>> time for the community to repurpose it :)
>
> Perfect, we have a plan.
>
> Before we make it tech-only and boring, let us all take a minute to
> remember the OpenStack jingle:
>
> https://www.openstack.org/blog/2011/07/openstack-the-best-sounding-cloud/

I haven't moved. Then I laughed. Thanks for that share Thierry!

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

__
OpenStack Development Mailing 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] [octavia] openstack CLI output don't match neutron lbaas-* output

[Volodymyr Litovka]

Hi colleagues,

just to inform you: openstack CLI extension output don't match 
corresponsing 'neutron lbaas-*' CLI output, e.g.


doka@lagavulin(admin@bush):~/heat$ neutron lbaas-loadbalancer-show 
db8ae876-b6eb-4c45-95d1-33e0ca6193de
neutron CLI is deprecated and will be removed in the future. Use 
openstack CLI instead.

+-++
| Field   | Value  |
+-++
| admin_state_up  | True   |
| description |    |
| id  | db8ae876-b6eb-4c45-95d1-33e0ca6193de   |
| listeners   | {"id": "3ce73276-9c80-4645-aa0c-263fae736ef5"} |
| name    | nbt-balancer   |
*| operating_status    | ONLINE |*
| pools   | {"id": "e106e039-af27-4cfa-baa2-7238acd3078e"} |
| provider    | octavia    |
| provisioning_status | ACTIVE |
| tenant_id   | c1114776e144400da17d8e060856be8c   |
| vip_address | 10.1.1.13  |
| vip_port_id | 6898f149-9d6c-4fa7-b16c-af582cd18efa   |
| vip_subnet_id   | ecb891c1-b7e5-45e0-8815-8675381d70d2   |
+-++
doka@lagavulin(admin@bush):~/heat$ openstack loadbalancer show 
db8ae876-b6eb-4c45-95d1-33e0ca6193de

+-+--+
| Field   | Value    |
+-+--+
| admin_state_up  | True |
| created_at  | 2017-11-29T12:02:55  |
| description |  |
| flavor |  |
| id  | db8ae876-b6eb-4c45-95d1-33e0ca6193de |
| listeners   | 3ce73276-9c80-4645-aa0c-263fae736ef5 |
| name    | nbt-balancer |
*| operating_status    | OFFLINE  |*
| pools   | e106e039-af27-4cfa-baa2-7238acd3078e |
| project_id  | c1114776e144400da17d8e060856be8c |
| provider    | octavia  |
| provisioning_status | ACTIVE   |
| updated_at  | 2017-11-29T12:04:40  |
| vip_Address | 10.1.1.13    |
| vip_network_id  | 141f1af9-c309-4263-b7f9-dab3922957c3 |
| vip_port_id | 6898f149-9d6c-4fa7-b16c-af582cd18efa |
| vip_subnet_id   | ecb891c1-b7e5-45e0-8815-8675381d70d2 |
+-+--+

more difference between corresponding command pairs for listeners and pools.

Also, member list shows NO_MONITOR status for members

doka@lagavulin(admin@bush):~/heat$ openstack loadbalancer member list 
nbt-pool

+--+--+--+-+---+---+--++
| id   | name | 
project_id   | provisioning_status | address   | 
protocol_port | operating_status | weight |

+--+--+--+-+---+---+--++
| f7f0d598-7e23-4f42-bb8e-6c5818b1b2cb |  | 
c1114776e144400da17d8e060856be8c | ACTIVE  | 10.1.1.14 
|  8080 | NO_MONITOR   |  1 |
| a369460a-6b0d-4c3d-8c84-9c76460719d0 |  | 
c1114776e144400da17d8e060856be8c | ACTIVE  | 10.1.1.11 
|  8080 | NO_MONITOR   |  1 |

+--+--+--+-+---+---+--++

while healthmonitor exists

doka@lagavulin(admin@bush):~/heat$ neutron lbaas-healthmonitor-list
neutron CLI is deprecated and will be removed in the future. Use 
openstack CLI instead.

+--+--+--+--++
| id   | name | 
tenant_id    | type | admin_state_up |

+--+--+--+--++
| 71cc7956-7c54-448a-96a7-709905c2bf4f |  | 
c1114776e144400da17d8e060856be8c | PING | True   |

+--+--+--+--++
doka@lagavulin(admin@bush):~/heat$ neutron lbaas-healthmonitor-show 
71cc7956-7c54-448a-96a7-709905c2bf4f
neutron 

[Openstack] [xenserver][ocata] overcommit vcpu

[Adhi Priharmanto]

Hi,

I've been running ocata release with xenserver as hypervisor, my question,
how to overcommit vCPU of xenserver ?

my xenserver have 4 physical core and 8 vcpu. I already add
"cpu_allocation_ratio = 16.0" option into my nova.conf at compute nodes,
but its still read 8 vCPUs by scheduler.


-- 
​​

Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

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

Re: [openstack-dev] [all] Community managed tech/dev blog: Call for opinions and ideas

[Thierry Carrez]

Jimmy McArthur wrote:
> Thierry Carrez wrote:
>> Historically blog.o.o used to be our only blog outlet, so almost
>> anything would go in:
>>
>> "OpenStack Events Sponsorship Webinar"
>> "New Foundation Gold Members & Corporate Sponsors"
>> "HP Announces Private Beta Program for OpenStack Cloud"
>> "2016 OpenStack T-Shirt Design Contest"
>>
>> What Josh wants is a curated technical blog, so if we reused blog.o.o
>> for this (and I think it's a good idea), we'd likely want to have a bit
>> more rules on what's appropriate.
> 
> Agreed. It's almost solely used for developer digest now and isn't
> frequently updated. Most of the promotion of sponsors and news goes into
> o.o/News, SuperUser, or one of our other marketing channels. It's a good
> time for the community to repurpose it :)

Perfect, we have a plan.

Before we make it tech-only and boring, let us all take a minute to
remember the OpenStack jingle:

https://www.openstack.org/blog/2011/07/openstack-the-best-sounding-cloud/

-- 
Thierry Carrez (ttx)

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

[Openstack] Tx/Rx count not increasing

[abhishek jain]

Hi Team

Hi Team


I'm having 2 VMs running with ovs-dpdk as a networking agent on
openstack compute node.
When I'm checking the external connectivity of the VMs by pinging to
the external world,the Tx/Rx count of the VMs is not increasing.


However I'm able to ping the local-Ip of the respective Vms.
Let me know the possible solution for this.

Regards

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

Re: [Openstack] Devstack -Ocata - Failed to launch instance on Host

[Bernd Bausch]

Things you could check:

- on the compute node, nova compute log (DevStack names it n-cpu), are there 
messages indicating that the node can't contact the placement service.

- if so, find out why. 
The error message might contain clues. Likely causes are misconfiguration in 
nova.conf, some networking misconfiguration, firewall etc. Ultimately, the root 
of the problem is in local.conf, I would guess.

- if it can contact the placement service, something is wrong at a different 
level. Again, I would hope that the compute log contains useful information.

-Original Message-
From: Ramu, MohanX [mailto:mohanx.r...@intel.com] 
Sent: Tuesday, November 28, 2017 4:47 PM
To: Brian Haley ; openstack@lists.openstack.org
Subject: Re: [Openstack] Devstack -Ocata - Failed to launch instance on Host

After running discover host command also not able to populate the compute node 
data into Resource_providers table.

The cell mapping table ahs cello and Null not cell0, post updating cell1 also 
-nothing resolved.


su -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova 
nova-manage cell_v2 discover_hosts




-Original Message-
From: Brian Haley [mailto:haleyb@gmail.com]
Sent: Monday, November 27, 2017 10:21 PM
To: Ramu, MohanX ; openstack@lists.openstack.org
Subject: Re: [Openstack] Devstack -Ocata - Failed to launch instance on Host

On 11/27/2017 10:24 AM, Ramu, MohanX wrote:
> Hi All,
> 
> Not bale to launch an instance on Compute Node. instead of it, 
> instance is trying to launch on the same controller.
> 
> The added compute node is not there in resource provider table.
> 
> Could you please help us what we missed.
> 
> Is placement API not configured on compute node side and Is there 
> Placement API configurations coming by default along with basic 
> Devstack set up?

There is a section on multinode setup in the devstack repo, 
doc/source/guides/multinode-lab.rst, that I think covers the issue you're 
seeing.  Assuming your compute node shows up in  'nova service-list' output, 
you need to run ./tools/discover_hosts.sh to have a cell mapping added for the 
node.

-Brian

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


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

[openstack-dev] [acceleration]Cyborg Team Weekly Meeting 2017.11.29

[Zhipeng Huang]

Hi team,

We will have our weekly meeting as usual at #openstack-cyborg starting from
UTC1500, initial agenda could be found at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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