[openstack-dev] [mistral] Proposing time slots for Mistral office hours

[Renat Akhmerov]

Hi,

Not so long ago we decided to stop holding weekly meetings in one of the 
general IRC channel (it was #openstack-meeting-3 for the last several months). 
The main reason was that we usually didn’t have a good representation of the 
team there because the team is distributed across the world. We tried to find a 
time slot several times that would work well for all the team members but 
failed to. Another reason is that we didn’t always have a clear reason to 
gather because everyone was just focused on their tasks and a discussion wasn’t 
much needed so a meeting was even a distraction.

However, despite all this we still would like channels to communicate, the team 
members and people who have user questions and/or would like to start 
contributing.

Similarly to other teams in OpenStack we’d like to try the “Office hours” 
concept. If we follow it we’re supposed to have team members, for whom the time 
slot is OK, available in our channel #openstack-mistral during certain hours. 
These hours can be used for discussing our development stuff between team 
members from different time zones and people outside the team would know when 
they can come and talk to us.

Just to start the discussion on what the office hours time slots could be I’m 
proposing the following time slots:

1. Mon 16.00 UTC (it used to be our time of weekly meetings)
2. Wed 3.00 UTC
3. Fri 8.00 UTC

Each slot is one hour.

Assumingly, #1 would be suitable for people in Europe and America. #2 for 
people in Asia and America. And #3 for people living in Europe and Asia. At 
least that was my thinking when I was wondering what the time slots should be.

Please share your thoughts on this. The idea itself and whether the time slots 
look ok.

Thanks

Renat Akhmerov
@Nokia
__
OpenStack Development Mailing 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] [CI][Keystone][Requirements][Release] What happened to the gate on Feb 4th?

[Andreas Jaeger]

On 2018-02-05 05:44, Qiming Teng wrote:
> Starting about 24 hours ago, we have been notified CI gate failure
> although we haven't changed anything to our project locally. Before that
> we have spent quite some time making the out-of-tree tempest plugins
> work on gate.

What is *your* project? PLease provide also links to full failure logs,

Andreas

> After checking the log again and again ... we found the following logs
> from Keystone:
> 
> Feb 05 03:31:12.609492 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
> req-dfcbf106-fbf5-41bd-9012-3c65d1de5f9a None admin] Could not find
> project: service.: ProjectNotFound: Could not find project: service.
> 
> Feb 05 03:31:13.845694 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
> req-50feed46-7c15-425d-bec7-1b4a7ccf6859 None admin] Could not find
> service: clustering.: ServiceNotFound: Could not find service:
> clustering.
> 
> Feb 05 03:31:12.552647 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
> req-0a5e660f-dad6-4779-aea4-dd6969c728e6 None admin] Could not find
> domain: Default.: DomainNotFound: Could not find domain: Default.
> 
> Feb 05 03:31:12.441128 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
> req-7eb9ed90-28fc-40aa-8a41-d560f7a156c9 None admin] Could not find
> user: senlin.: UserNotFound: Could not find user: senlin.
> 
> Feb 05 03:31:12.336572 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
> req-19e52d02-5471-49a2-8acd-360199d8c6e0 None admin] Could not find
> role: admin.: RoleNotFound: Could not find role: admin.
> 
> Feb 05 03:28:33.797665 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
> req-544cd822-18a4-4f7b-913d-297716418239 None admin] Could not find
> user: glance.: UserNotFound: Could not find user: glance.
> 
> Feb 05 03:28:29.993214 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING py.warnings [None
> req-dc411d9c-6ab9-44e3-9afb-20e5e7034f12 None admin]
> /usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py:865:
> UserWarning: Policy identity:create_endpoint failed scope check. The
> token used to make the request was project scoped but the policy
> requires ['system'] scope. This behavior may change in the future where
> using the intended scope is required
> 
> Feb 05 03:28:29.920892 ubuntu-xenial-ovh-gra1-0002362092
> devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
> req-32a4a378-d6d3-411e-9842-2178e577af27 None admin] Could not find
> service: compute.: ServiceNotFound: Could not find service: compute.
> 
> 
> 
> --
> 
> So I'm wondering what the hack happened? Keystone version bump?
> Devstack changed? Tempest settings changed? 
> Why are we merging these changes near the end of a cycle when people are
> focusing on stabilizing things?
>
> Any hints on these are highly appreciated.


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


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

Re: [openstack-dev] [glance] FFE request for --check feature

[Abhishek Kekane]

We have discussed this in glance weekly meeting [1] and most of the core
reviewers are inclined towards accepting this FFE.

+1 from my side as this --check command will be very helpful for operators.

Thank you Bhagyashri for working on this.

Abhishek Kekane

On Wed, Jan 31, 2018 at 7:29 PM, Shewale, Bhagyashri <
bhagyashri.shew...@nttdata.com> wrote:

> Hi Glance Folks,
>
> I'm requesting an Feature Freeze Exception for the lite-spec
> http://specs.openstack.org/openstack/glance-specs/specs/
> untargeted/glance/lite-spec-db-sync-check.html
> which is implemented by https://review.openstack.org/#/c/455837/8/
>
> Regards,
> Bhagyashri Shewale
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
> __
> OpenStack Development Mailing 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] [tricircle] Rocky Tricircle PTL candidacy

[Vega Cai]

Hi folks,

I would like to announce my self nomination for the PTL candidacy in
Tricircle Rocky cycle. My name is Zhiyuan Cai, and my IRC handle is
zhiyuan. I am currently the PTL of Tricircle for Queens cycle and have been
actively participating in the development of this project since Mitaka
cycle.

During the Queens cycle, we begin to bring QoS and LBaas support to
Tricircle, test scenario coverage is improved in our smoke test, we also
start to solve the resource deletion reliability problem and have figured
out a solution.

For the coming Rocky cycle, here are some works we can focus on:

* The QoS and LBaas features are not fully supported in Queens cycle so we
can improve them in Rocky cycle.
* Implement the new cross-Neutron L3 networking model that doesn't depend
on host routes.
* Finish the resource deletion reliability solution.

Hope everyone will enjoy running and developing Tricircle.

Thank you for your kind consideration of my candidacy.

BR
Zhiyuan Cai
-- 
BR
Zhiyuan
__
OpenStack Development Mailing 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] [mistral][ptl] PTL candidacy

[Renat Akhmerov]

Hi,

I'm Renat Akhmerov. I'm running for PTL of Mistral in Rocky.

Mistral is a workflow service developed within the OpenStack community from
the ground up.

In queens we mainly focused on bugfixing, improving performance and
documentation. Performance was again significantly improved (~100%)
by optimizing DB operations and data schema (mostly additional indexex)
and using caching technics. We also made Mistral more robust in various
failure situations. To achieve that we came up with a number of protection
mechanisms.

The two other noticeable features we added are:

* We can now start a Mistral workflow based on an existing workflow
  execution, no matter if it's still running or finished. Given an ID of
  an execution Mistral copies all needed parameters (input, env etc.) and
  creates a new execution.
* When creating a workflow execution, we can now pass an ID of the new
  execution. If an execution with this ID already exists the REST endpoint
  just returns details of this execution as if it was GET operation. If
  not, it create a execution with this ID. Thus creation of workflow
  execution can be idempotent.


For the next cycle I'd like to propose the following roadmap:

* Keep improving multi-node mode and HA
* Rearchitect Mistral Scheduler, make it more suitable for HA
* Optimize ‘join’ tasks
* Close all the gaps in the documentation and restructure it so it is more
  convenient to read and navigate
* Usability
  * New CLI/API (more consistent and human friendly interface)
  * Debugging workflows
  * Workflow failure analysis (error messages, navigate through nested
    workflows etc.)
* Refactor Actions subsystem
  * Actions testability
  * Move OpenStack actions into mistral-extra and with better test coverage
    and usability

Some of those items have now been in progress for a few months. We keep
working on them and I hope most of them will be completed in the next
cycle.

Should you have any ideas on these points we're always happy to discuss and
correct our plans.

We're always happy to get new contributors on the project and always ready
to help people interested in Mistral development get up to speed. The best
way to get in touch with us is IRC channel #openstack-mistral.


The corresponding patch to openstack/election:
https://review.openstack.org/#/c/540720/

Thanks

Renat Akhmerov
@Nokia
__
OpenStack Development Mailing 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] [CI][Keystone][Requirements][Release] What happened to the gate on Feb 4th?

[Qiming Teng]

Starting about 24 hours ago, we have been notified CI gate failure
although we haven't changed anything to our project locally. Before that
we have spent quite some time making the out-of-tree tempest plugins
work on gate.

After checking the log again and again ... we found the following logs
from Keystone:

Feb 05 03:31:12.609492 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-dfcbf106-fbf5-41bd-9012-3c65d1de5f9a None admin] Could not find
project: service.: ProjectNotFound: Could not find project: service.

Feb 05 03:31:13.845694 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-50feed46-7c15-425d-bec7-1b4a7ccf6859 None admin] Could not find
service: clustering.: ServiceNotFound: Could not find service:
clustering.

Feb 05 03:31:12.552647 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-0a5e660f-dad6-4779-aea4-dd6969c728e6 None admin] Could not find
domain: Default.: DomainNotFound: Could not find domain: Default.

Feb 05 03:31:12.441128 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-7eb9ed90-28fc-40aa-8a41-d560f7a156c9 None admin] Could not find
user: senlin.: UserNotFound: Could not find user: senlin.

Feb 05 03:31:12.336572 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-19e52d02-5471-49a2-8acd-360199d8c6e0 None admin] Could not find
role: admin.: RoleNotFound: Could not find role: admin.

Feb 05 03:28:33.797665 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-544cd822-18a4-4f7b-913d-297716418239 None admin] Could not find
user: glance.: UserNotFound: Could not find user: glance.

Feb 05 03:28:29.993214 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING py.warnings [None
req-dc411d9c-6ab9-44e3-9afb-20e5e7034f12 None admin]
/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py:865:
UserWarning: Policy identity:create_endpoint failed scope check. The
token used to make the request was project scoped but the policy
requires ['system'] scope. This behavior may change in the future where
using the intended scope is required

Feb 05 03:28:29.920892 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-32a4a378-d6d3-411e-9842-2178e577af27 None admin] Could not find
service: compute.: ServiceNotFound: Could not find service: compute.



--

So I'm wondering what the hack happened? Keystone version bump?
Devstack changed? Tempest settings changed? 
Why are we merging these changes near the end of a cycle when people are
focusing on stabilizing things?

Any hints on these are highly appreciated.

- Qiming


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

Re: [openstack-dev] [oslo] PTL candidacy

[ChangBo Guo]

Thanks for stepping up to take the role,  Ben
 looking forward to making oslo better with your lead .

2018-02-03 2:43 GMT+08:00 Ben Nemec :

> Hi,
>
> I am submitting my candidacy for Oslo PTL.
>
> I have been an Oslo core since 2014 and although my involvement in the
> project
> has at times been limited by other responsibilities, I have always kept up
> on
> what is going on in Oslo.
>
> For the Rocky cycle my primary goals would be:
>
> * Continue to maintain the stability and quality of the existing Oslo code.
>
> * Help drive the oslo.config improvements that are underway.
>
> * Encourage new and existing contributors to ensure the long-term health of
>   the project.
>
> I am, of course, always open to suggestions on other areas of focus for
> Oslo.
>
> Thanks.
>
> -Ben
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Gilles Dubreuil]

As you said RESTful is not a standard but brings guidelines of good 
practices. Which in turn doesn't preclude adding ideas, as long as 
respecting RESTful approach. So we get from both sides.


Therefore a good schema structure adds to a de-facto standard, once the 
practice is commonly used.



On 02/02/18 19:11, Duncan Thomas wrote:
So I guess my question here is why is being RESTful good? Sure it's 
(very, very loosely) a standard, but what are the actual advantages? 
Standards come and go, what we want most of all is a good quality, 
easy to use API.


I'm not saying that going RESTful is wrong, but I don't see much 
discussion about what the advantages are, only about how close we are 
to implementing it.


On 1 Feb 2018 10:55 pm, "Ed Leafe" > wrote:


On Jan 18, 2018, at 4:07 AM, TommyLike Hu > wrote:

>    Recently We found an issue related to our OpenStack action
APIs. We usually expose our OpenStack APIs by registering them to
our API Gateway (for instance Kong [1]), but it becomes very
difficult when regarding to action APIs. We can not register and
control them seperately because them all share the same request
url which will be used as the identity in the gateway service, not
say rate limiting and other advanced gateway features, take a look
at the basic resources in OpenStack

We discussed your email at today’s API-SIG meeting [0]. This is an
area that is always contentious in the RESTful world. Actions,
tasks, and state changes are not actual resources, and in a pure
REST design they should never be part of the URL. Instead, you
should POST to the actual resource, with the desired action in the
body. So in your example:

> URL:/volumes/{volume_id}/action
> BODY:{'extend':{}}

the preferred way of achieving this is:

URL: POST /volumes/{volume_id}
BODY: {‘action’: ‘extend’, ‘params’: {}}

The handler for the POST action should inspect the body, and call
the appropriate method.

Having said that, we realize that a lot of OpenStack services have
adopted the more RPC-like approach that you’ve outlined. So while
we strongly recommend a standard RESTful approach, if you have
already released an RPC-like API, our advice is:

a) avoid having every possible verb in the URL. In other words,
don’t use:
  /volumes/{volume_id}/mount
  /volumes/{volume_id}/umount
  /volumes/{volume_id}/extend
This moves you further into RPC-land, and will make updating your
API to a more RESTful design more difficult.

b) choose a standard term for the item in the URL. In other words,
always use ‘action’ or ‘task’ or whatever else you have adopted.
Don’t mix terminology. Then pass the action to perform, along with
any parameters in the body. This will make it easier to transition
to a RESTful design by later updating the handlers to first
inspect the BODY instead of relying upon the URL to determine what
action to perform.

You might also want to contact the Kong developers to see if there
is a way to work with a RESTful API design.

-- Ed Leafe

[0]

http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-01-16.02.log.html#l-28






__
OpenStack Development Mailing 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] FFE - Feuture Freeze Exception request for Routed Spine and Leaf Deployment

[Emilien Macchi]

On Fri, Feb 2, 2018 at 3:28 AM, Harald Jensås  wrote:

> Requesting:
>   Feuture Freeze Exception request for Routed Spine and Leaf Deployment
>
> Blueprints:
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
> ironic-inspector
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
> deployment
>
> All external dependencies for Routed Spine and Leaf Deployement have
> finally landed. (Except puppet module changes.)
>
>
> Pros
> 
>
> This delivers a feature that has been requested since the Kilo release.
> It makes TripleO more viable in large deployments as well as in edge
> use cases where openstack services are not deployed in one datacenter.
>
> The core piece in this is the neutron segments service_plugin. This has
> been around since newton. Most of the instack-undercloud patches were
> first proposed during ocata.
>
> The major change is in the undercloud. In tripleo-heat-templates we
> need just a small change to ensure we get ip addresses allocated from
> neutron when segments service plug-in is enabled in neutron. The
> overcloud configuration stays the same, we already do have users
> deploying routed networks in the isolated networks using composable
> networks so we know it works.
>
>
> Risks
> =
>
> I see little risk introducing a regression to current functionality
> with these changes. The major part of the undercloud patches has been
> around for a long time and passing CI.
>
> The format of undercloud.conf is changed, options are deprecated and
> new options are added to enable multiple control plane subnets/l2-
> segments to be defined. All options are properly deprectated, so
> using a configuration file from pike will still work.
>
>
>
> =
> The list of patches that need to land
> =
>
> instack-undercloud
> --
>
> * Tripleo routed networks ironic inspector, and Undercloud
>   https://review.openstack.org/#/c/437544/
> * Move ctlplane network/subnet setup to python
>   https://review.openstack.org/533364
> * Update config to use per network groups
>   https://review.openstack.org/533365
> * Update validations to validate all subnets
>   https://review.openstack.org/533366
> * Add support for multiple inspection subnets
>   https://review.openstack.org/533367
> * Create static routes for remote subnets
>   https://review.openstack.org/533368
> * Add per subnet network cidr nat rules
>   https://review.openstack.org/533369
> * Add per subnet masquerading
>   https://review.openstack.org/533370
> * Install and enable neutron baremetal mech plugin
>   https://review.openstack.org/537830
>
> tripleo-heat-templates
> --
>
> * Add subnet property to ctlplane network for server resources
>   https://review.openstack.org/473817
>
> tripleo-docs
> 
>
> * Documentation - TripleO routed-spine-and-leaf
>   https://review.openstack.org/#/c/539939/
>
> puppet-neutron
> --
>
> * Add networking-baremetal ml2 plug-in
>   https://review.openstack.org/537826
> * Add networking-baremetal - ironic-neutron-agent
>   https://review.openstack.org/539405
>
>
I'm a bit concerned by the delay of this request. Feature freeze request
deadline was 10 days ago:
https://releases.openstack.org/queens/schedule.html#q-ff

We're now in the process on producing a release candidate. The amount of
code that needs to land to have the feature completed isn't small but it
looks like well tested and you seems pretty confident.
I'm not sure what to vote on this one tbh because yeah the use-case is
super important, and we know how Queens release is important to us. But at
the same time there is a risk to introduce problems, and delay the
potentially delay the release and after the delivery of other features...

I guess I'm ok as long as all patches pass ALL CI jobs without exception
and are carefully tested and reviewed.

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

Re: [openstack-dev] [requirement][cyborg]FFE - pyspdk requirement dependency

[We We]

Hi,
Thank you for your kind reply. 
I'm not thinking enough about this part of my work. I am sorry for that, please 
close the  FFE of the pyspdk.

Thanks,
Helloway
> 在 2018年1月31日，上午1:54，We We  写道：
> 
>> Hi,
> 
>> I have modified and resubmitted  pyspdk to the pypi. Please check it.
> 
>> Thx,
> 
>> Helloway
> 
>> 在 2018年1月30日，下午12:52，We We > 
>> 写道：
>> 
>> Hi,
>> The pyspdk is a important tool library [1] which  supports Cyborg SPDK 
>> driver [2] to manage the backend SPDK-base app, so we need to upload pyspdk 
>> into the pypi [3]  and then append 'pyspdk>=0.0.1’ item into 
>> ‘OpenStack/Cyborg/requirements.txt’ , so that  SPDK driver can be built 
>> correctly when zuul runs. However, It's not what we thought it would be, if 
>> we want to  add the new requirements, we should get support from upstream 
>> OpenStack/requirements [4] to append 'pyspdk>=0.0.1’ item.
>> 
>> I'm sorry for propose the request so late. Please Please help.
>> 
>> 
>> [1] https://review.gerrithub.io/#/c/379741/ 
>> 
>> [2] https://review.openstack.org/#/c/538164/11 
>> 
>> [3] https://pypi.python.org/pypi/pyspdk/0.0.1 
>> 
>> [4] https://github.com/openstack/requirements 
>> 
>> 
>> 
>> Regards,
>> Helloway
>> 
> 

__
OpenStack Development Mailing 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] FFE nfs_ganesha integration

[Tom Barron]

Just to follow up, CI is passing for the three patches outstanding
and the last one has a release note for the overall feature.  The trick to
getting CI to pass was to introduce a new variant Controller
role for when we actually deploy with CephNFS and the VIP for the
server on the StorageNFS network.  Using the variant controller role and
'-n'
with network_data_ganesha.yaml (1) enables the new feature to
work correctly while (2) making the new feature entirely optional so
that current CI runs without being affected by it.

I think the three outstanding patches here are ready to merge:

https://review.openstack.org/#/q/status:open+topic:bp/nfs-ganesha

I want to get them in so they'll show in downstream puddles for QE but
my full attention will immediately turn to upstream TripleO CI and doc for
this
new functionality.  In that regard I *think* we'll need Dan Sneddon's work
here:

https://review.openstack.org/#/c/523638

so that actual deployment of the StorageNFS network doesn't have to
involve copying and editing

network/config/*/{ceph,compute,controller}/.yaml

as done in the DNM patch that I've used for testing actual integration of
the
feature here:

https://review.openstack.org/533767

All said, this one seems to be a good poster child for composable roles +
composable networks!

-- Tom Barron


On Tue, Jan 23, 2018 at 2:48 PM, Emilien Macchi  wrote:

> I agree this would be a great addition but I'm worried about the
> patches which right now don't pass the check pipeline.
> Also I don't see any release notes explaining the changes to our users
> and it's supposed to improve user experience...
>
> Please add release notes, make CI passing and we'll probably grant it for
> FFE.
>
> On Mon, Jan 22, 2018 at 8:34 AM, Giulio Fidente 
> wrote:
> > hi,
> >
> > I would like to request an FFE for the integration of nfs_ganesha, which
> > will provide a better user experience to manila users
> >
> > This work was slown down by a few factors:
> >
> > - it depended on the migration of tripleo to the newer Ceph version
> > (luminous), which happened during the queens cycle
> >
> > - it depended on some additional functionalities to be implemented in
> > ceph-ansible which were only recently been made available to tripleo/ci
> >
> > - it proposes the addition of on an additional (and optional) network
> > (storagenfs) so that guests don't need connectivity to the ceph frontend
> > network to be able to use the cephfs shares
> >
> > The submissions are on review and partially testable in CI [1]. If
> accepted,
> > I'd like to reassign the blueprint [2] back to the queens cycle, as it
> was
> > initially.
> >
> > Thanks
> >
> > 1. https://review.openstack.org/#/q/status:open+topic:bp/nfs-ganesha
> > 2. https://blueprints.launchpad.net/tripleo/+spec/nfs-ganesha
> > --
> > Giulio Fidente
> > GPG KEY: 08D733BA
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [sdk][release][requirements] FFE request for openstacksdk 0.11.3

[Monty Taylor]

On 02/04/2018 01:35 PM, Matthew Thode wrote:

On 18-02-04 09:32:25, Monty Taylor wrote:

Hi!

I'd like to request another FFE to fix several neutron commands in
python-openstackclient for queens and also to unbreak
python-openstackclient's gate.

The release proposal patch is here:

https://review.openstack.org/540657

The issue at hand was:

The osc-functional-devstack-tips job, which tests master changes of
openstackclient and openstacksdk against each other with
openstackclient's functional tests was broken and was not testing
master against master but rather master of openstackclient against
released version of SDK. Therefore, the gate that was protecting us
against breakages like these was incorrect and let us land a patch that made
invalid query parameters raise errors instead of silently not filtering -
without also adding missing but needed query parameters as valid.

The gate job has been fixed and SDK as of the proposed commit fixes the
osc-functional-devstack-tips job. That can be seen in
https://review.openstack.org/540554/ The osc-functional-devstack job, which
checks OSC master against released SDK is broken with sdk 0.11.2 because of
the bug fixed in the SDK patch.

We would want to bump the upper-constraints from 0.11.2 to 0.11.3 in both
stable/queens and master upper-constraints files.



As a UC bump you have my +2

It seems like these things require a gr bump even more now, which would
cause client re-releases iirc.  My question has more to do with having
this not happen again.  Do you cross gate with other projects (clients)?
That would allow you to check what's going into your master with what's
in the client master to ensure no breakage.


Yah - we do ... the problem was that we had a bug in this one which 
caused it to be testing against released versions not master versions. 
That has been rectified, so we SHOULD be good moving forward.


Also - as we find or grow more things that consume SDK, we'll add 
appropriate cross-gate jobs for them as well.


Thanks!
Monty

__
OpenStack Development Mailing 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] [sdk][release][requirements] FFE request for openstacksdk 0.11.3

[Matthew Thode]

On 18-02-04 09:32:25, Monty Taylor wrote:
> Hi!
> 
> I'd like to request another FFE to fix several neutron commands in
> python-openstackclient for queens and also to unbreak
> python-openstackclient's gate.
> 
> The release proposal patch is here:
> 
> https://review.openstack.org/540657
> 
> The issue at hand was:
> 
> The osc-functional-devstack-tips job, which tests master changes of
> openstackclient and openstacksdk against each other with
> openstackclient's functional tests was broken and was not testing
> master against master but rather master of openstackclient against
> released version of SDK. Therefore, the gate that was protecting us
> against breakages like these was incorrect and let us land a patch that made
> invalid query parameters raise errors instead of silently not filtering -
> without also adding missing but needed query parameters as valid.
> 
> The gate job has been fixed and SDK as of the proposed commit fixes the
> osc-functional-devstack-tips job. That can be seen in
> https://review.openstack.org/540554/ The osc-functional-devstack job, which
> checks OSC master against released SDK is broken with sdk 0.11.2 because of
> the bug fixed in the SDK patch.
> 
> We would want to bump the upper-constraints from 0.11.2 to 0.11.3 in both
> stable/queens and master upper-constraints files.
> 

As a UC bump you have my +2

It seems like these things require a gr bump even more now, which would
cause client re-releases iirc.  My question has more to do with having
this not happen again.  Do you cross gate with other projects (clients)?
That would allow you to check what's going into your master with what's
in the client master to ensure no breakage.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [trove] Retiring the trove-integration repository, final call

[Andreas Jaeger]

On 2018-01-26 22:22,  Manoj Kumar  wrote:
> Initial indication was provided in July last year, that the
> trove-integration repository was going away.
> All the elements have been merged into trove, and are being maintained
> there.
> 
> I do not believe anyone spoke up then. If anyone is depending on the
> separate repository, do speak up.

Please remove it completely from the CI system - follow
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

* abandon these two open reviews:
https://review.openstack.org/#/q/project:openstack/trove-integration+is:open

* Remove the project from project-config

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


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

[openstack-dev] [ironic] Not running for PTL this cycle

[Dmitry Tantsur]

Hi all,

I guess it's quite obvious already, but I won't be running for PTL position this 
time. It's been a challenging and interesting journey, I've learned a lot, and I 
believe we've achieved a lot together. Now I'd like to get back to calm waters 
and allow others to driver the project forward :) Of course I'm not going 
anywhere far, and I'm ready to help whoever gets this chair with their new 
challenge.


Now a small request: please leave me anonymous feedback at 
https://goo.gl/forms/810u3j8Yh2fymUMG2 that'll help me to improve further :)


Thank you all,
Dmitry

__
OpenStack Development Mailing 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] [sdk][release][requirements] FFE request for openstacksdk 0.11.3

[Monty Taylor]

Hi!

I'd like to request another FFE to fix several neutron commands in 
python-openstackclient for queens and also to unbreak 
python-openstackclient's gate.


The release proposal patch is here:

https://review.openstack.org/540657

The issue at hand was:

The osc-functional-devstack-tips job, which tests master changes of
openstackclient and openstacksdk against each other with
openstackclient's functional tests was broken and was not testing
master against master but rather master of openstackclient against
released version of SDK. Therefore, the gate that was protecting us
against breakages like these was incorrect and let us land a patch that 
made invalid query parameters raise errors instead of silently not 
filtering - without also adding missing but needed query parameters as 
valid.


The gate job has been fixed and SDK as of the proposed commit fixes the
osc-functional-devstack-tips job. That can be seen in 
https://review.openstack.org/540554/ The osc-functional-devstack job, 
which checks OSC master against released SDK is broken with sdk 0.11.2 
because of the bug fixed in the SDK patch.


We would want to bump the upper-constraints from 0.11.2 to 0.11.3 in 
both stable/queens and master upper-constraints files.


Thanks!
Monty

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

[openstack-dev] [cloudkitty] Rocky Cloudkitty PTL candidacy

[Christophe Sauthier]

Hello everyone,

I would like to announce my candidacy for PTL of Cloudkitty.

During the Queens cycle we have been able open relaunch our community 
with the integration of a few regular contributors and new core.
We also have been to change the way we configure Cloudkitty and the 
definition of metrics to be fetched in order to be more agile (and less 
hard-coded relationship). With that evolution we have been able to 
extend to spectrum of Cloudkitty to other projects (both within and 
outside OpenStack).


During the Rocky cycle the focus I am looking for is to continue the 
expand the spectrum of cloukitty integration with various services. We 
also have some work that we are planning our storage concepts. Finally 
we plan to improve the reports that can get fetched from cloudkitty 
(both graphical and outputs).


Finally I am decided also to continue to work to support the wider 
ecosystem adoption of Cloudkitty as the best solution for chargeback and 
rating.


I would also like to take this opportunity to thank all members of the 
OpenStack community who helped our team during the lasts cycles.


Thank you,

Christophe Sauthier


Christophe Sauthier
CEO

Objectif Libre : Au service de votre Cloud

+33 (0) 6 16 98 63 96 | christophe.sauth...@objectif-libre.com

www.objectif-libre.com | @objectiflibre | 
www.linkedin.com/company/objectif-libre

Recevez la Pause Cloud Et DevOps : olib.re/abo-pause

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