[openstack-dev] VM stalls with the console log "Exiting boot services and installing virtual address map"

[Srikanth Kumar Lingala]

Hi,

I am working with OpenStack stable/pike release in Ubuntu 18.04.

When I am trying to spawn VM, which is worked in the earlier OpenStack
releases, VM is stalled with the following log in the VM console logs:

EFI stub: Booting Linux Kernel...

EFI stub: Generating empty DTB

EFI stub: Exiting boot services and installing virtual address map...

I am observing that VM is in Running status, without any error logs. And,
VM is booting with UEFI support. But, I am not able to get VM Console.

Earlier I didn't observe this. How can I disable UEFI support, while
spawning VM's in OpenStack Nova-Compute.

My Libvirt version is 4.0.0.

Can someone help me to fix the issue.

Regards, Srikanth.

-- 

Srikanth.
__
OpenStack Development Mailing 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] puppet5 has broken the master gate

[Chandan kumar]

Hello Alex,

On Tue, Nov 13, 2018 at 9:53 AM Alex Schultz  wrote:
>
> Just a heads up but we recently updated to puppet5 in the master
> dependencies. It appears that this has completely hosed the master
> scenarios and containers-multinode jobs.  Please do recheck/approve
> anything until we get this resolved.
>
> See https://bugs.launchpad.net/tripleo/+bug/1803024
>
> I have a possible fix (https://review.openstack.org/#/c/617441/) but
> it's probably a better idea to roll back the puppet package if
> possible.
>

In RDO, we have reverted Revert "Stein: push puppet 5.5.6" ->
https://review.rdoproject.org/r/#/c/17333/1

Thanks for the heads up!

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][openstack-ansible] Updates on collaboration on os_tempest role

[Chandan kumar]

Hello,

During the starting of Denver 2018 PTG [1]., We started collaborating
towards using the
openstack-ansible-os_tempest role [2] as a unified tempest role in TripleO and
openstack-ansible project within OpenStack community.

It will help us to improve the testing strategies between two projects
which can be
further expanded to other OpenStack deployment tools.

We will be sharing bi-weekly updates through mailing lists.
We are tracking/planning all the work here:
Proposal doc: https://etherpad.openstack.org/p/ansible-tempest-role
Work item collaboration doc:
https://etherpad.openstack.org/p/openstack-ansible-tempest

Here is the update till now:
openstack-ansible-os_tempest project:

* Enable stackviz support - https://review.openstack.org/603100
* Added support for installing tempest from distro -
https://review.openstack.org/591424
* Fixed missing ; from if statement in tempest_run -
https://review.openstack.org/614521
* Added task to list tempest plugins - https://review.openstack.org/615837
* Remove apt_package_pinning dependency from os_tempest role -
https://review.openstack.org/609992
* Enable python-tempestconf support - https://review.openstack.org/612968

Support added to openstack/rpm-packaging project (will be consumed in
os_tempest role):
* Added spec file for stackviz - https://review.openstack.org/609337
* Add initial spec for python-tempestconf - https://review.openstack.org/598143

Upcoming improvements:
* Finish the integration of python-tempestconf in os_tempest role.

Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel.

Links:
[1.] http://lists.openstack.org/pipermail/openstack-dev/2018-August/133119.html
[2.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][ui][tempest][oooq] Refreshing plugins from git

[Chandan kumar]

Hello Honza,

On Thu, Oct 18, 2018 at 6:15 PM Bogdan Dobrelya  wrote:
>
> On 10/18/18 2:17 AM, Honza Pokorny wrote:
> > Hello folks,
> >
> > I'm working on the automated ui testing blueprint[1], and I think we
> > need to change the way we ship our tempest tests.
> >
> > Here is where things stand at the moment:
> >
> > * We have a kolla image for tempest
> > * This image contains the tempest rpm, and the openstack-tempest-all rpm
> > * The openstack-tempest-all package in turn contains all of the
> >openstack tempest plugins
> > * Each of the plugins is shipped as an rpm
> >
> > So, in order for a new test in tempest-tripleo-ui to appear in CI we
> > have to go through at least the following tests:
> >
> > * New tempest-tripleo-ui rpm
> > * New openstack-tempest-all rpm
> > * New tempest kolla image
> >
> > This could easily take a week, if not more.
> >
> > What I would like to build is something like the following:
> >
> > * Add an option to the tempest-setup.sh script in tripleo-quickstart to
> >refresh all tempest plugins from git before running any tests
> > * Optionally specify a zuul change for any of the plugins being
> >refreshed
> > * Hook up the test job to patches in tripleo-ui (which tests in
> >tempest-tripleo-ui are testing) so that I can run a fix and its test
> >in a single CI job

I have added a patch in TripleO Quickstart extras Validate-tempest
role: https://review.openstack.org/#/c/612377/ to install any tempest
plugin from git and zuul will pick
the specific change in the gates.
Here is the patch on how to test it with FS: https://review.openstack.org/612386
Basically in any FS, we can add following lines
tempest_format: venv
tempest_plugins_git:
   - 'https://git.openstack.org/openstack/tempest-tripleo-ui.git'
the respective FS related job will install the tempest plugin and we
can also use test_white_regex:  to
trigger the tempest tests.

I think it will solve the problem.

Thanks

Chandan Kumar

__
OpenStack Development Mailing 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] Regarding dropping Ocata related jobs from TripleO

[Chandan kumar]

Hello,

As Ocata release is already EOL on 27-08-2018 [1].
In TripleO, we are running Ocata jobs in TripleO CI and in promotion pipelines.
Can we drop it all the jobs related to Ocata or do we need to keep some jobs
to support upgrades in CI?

Links:
[1.] https://releases.openstack.org/

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][kolla-ansible][DevStack][Tempest][openstack-ansible] Collaborate towards creating a unified ansible tempest role in openstack-ansible project

[Chandan kumar]

Hello,

Few days back, Alex initiated the conversation about sharing ansible
roles [1] across different projects. It is a nice idea and it brings a
lot of collaboration
among different projects with in OpenStack Community.

Since Tempest provides the Integration test suite for validating any
deployed OpenStack cloud. We uses ansible roles for
installing/configuring/running Tempest
starting from DevStack Tempest Zuul based CI jobs to TripleO,
OpenStack-ansible spanning to kolla-ansible projects.

Across all these deployments tools have their own roles for
installing/configuring/running Tempest but doing similar tasks.
I think it's a good opportunity for us to collaborate towards creating
an unified ansible role in openstack-ansible project by re-using and
modifying the stuff
and then aggregating into openstack-ansible-os_tempest [2] project.

I have summarized the problem statement and requirements on this etherpad [3].
Feel free to add your requirements and questions for the same on the
etherpad so that we can shape the unified ansible role in a better
way.

Links:
1. http://lists.openstack.org/pipermail/openstack-dev/2018-August/133119.html
2. https://github.com/openstack/openstack-ansible-os_tempest
3. https://etherpad.openstack.org/p/ansible-tempest-role

Thanks,

Chandan Kumar

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

Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do

[Chandan kumar]

the os_nova role and pass in
> > > like install: false, service: false, config_dir:
> > > /my/special/location/, config_data: {...} and it spit out the configs.
> > > Then my roles would actually leverage these via containers/etc.  Of
> > > course most of this goes away if we had a unified (not file based)
> > > configuration method across all services (openstack and non-openstack)
> > > but we don't. :D
> > >
> >
> > I like your idea here Alex.
> > So having a role for each of these steps is too much management I agree,
> > however
> > establishing a pattern of using tasks for each step may be a really good
> > way to cleanly handle this.
> >
> > Are you saying something like the following?
> >
> > openstack-nova-role/
> > * * /tasks/
> > * * /tasks/install.yml
> > * * /tasks/service.yml
> > * */tasks/config.yml
> > * */taks/main.yml
> > ---
> > # main.yml
> >
> > include: install.yml
> > when: nova_install|bool
> >
> > include: service.yml
> > when: nova_service|bool
> >
> > include: config.yml
> > when: nova_config.yml
> > ------
> >
> > Interested in anything other than tags :)
> > Thanks
> >
> This is basically what I do with roles i write, allow the user to decide to 
> step
> over specific tasks. For example, I have created nodepool_task_manager 
> variable
> with the following:
>
> 
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/defaults/main.yaml#n16
> 
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/tasks/main.yaml
>
> Been using it for a few years now, works much better then tags for me.  The
> phases are pre, install, configure, service right now.


Thanks Alex for starting the conversation.
There are few other ansible roles for tempest and it's friends (stackviz)
https://github.com/redhat-openstack/infrared/tree/master/plugins/tempest
https://github.com/openstack/tempest/tree/master/roles

It would be a great idea to improve ansible-role-os_tempest role and
modify it such a way that it can be re-used by anyone.
I will start working on this.

Thanks,

Chandan Kumar

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

[openstack-dev] [cinder][security][api-wg] Adding http security headers

[Nishant Kumar E]

Hi,

I have registered a blueprint for adding http security headers - 
https://blueprints.launchpad.net/cinder/+spec/http-security-headers

Reason for introducing this change - I work for AT cloud project - Network 
Cloud (Earlier known as AT integrated Cloud). As part of working there we 
have introduced this change within all the services as kind of a downstream 
change but would like to see it a part of upstream community. While we did not 
face any major threats without this change but during our investigation process 
we found that if dealing with web services we should maximize the security as 
much as possible and came up with a list of HTTP security headers that we 
should include as part of the OpenStack services. I would like to introduce 
this change as part of cinder to start off and then propagate this to all the 
services.

Some reference links which might give more insight into this:

  *   https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers
  *   https://www.keycdn.com/blog/http-security-headers/
  *   
https://securityintelligence.com/an-introduction-to-http-response-headers-for-security/
Please let me know if this looks good and whether it can be included as part of 
Cinder followed by other services. More details on how the implementation will 
be done is mentioned as part of the blueprint but any better ideas for 
implementation is welcomed too !!

Thanks and Regards,
Nishant


Regards,
Nishant

__
OpenStack Development Mailing 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] [Summit][qa] Vancouver Summit 2018 QA Recap

[Chandan kumar]

in QA and we all agreed on below points:
> - QA will keep doing the same number of stable branches support as it is 
> doing now. Means support till "Maintained"  phase branches. EM branch will 
> not be in scope of guaranteed support of QA.
> - As Tempest is branchless, it should work for EM phase branches also but if 
> anything new changes break EM branch testing then we stopped testing master 
> Tempest on EM branches.
> Matt has already pushed the patch to document the above agreement [3]. Thanks 
> for doing good documentation always :),
>
> Eris
> ===
> Spec- https://review.openstack.org/#/c/443504/
> It came up in feedback sessions also and people really want to see some 
> progress on this. We have spec under review for that and need more volunteer 
> to drive this forward. I will also check with SamP on this. Other than that 
> there was not much discussion/progress on this in summit.
>
> ACTION ITEM:  gmann to push the spec review in QA team and more follow up 
> about progress.
>
>
> [1] https://etherpad.openstack.org/p/YVR-rocky-default-roles
> [2] https://etherpad.openstack.org/p/YVR-extended-maintenance
> [3] https://review.openstack.org/#/c/570620/

Thanks,

Chandan Kumar

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

Re: [openstack-dev] [nova] Refused to connect port 8774.

[manoj kumar]

I would check for:

1) Telnet to controller on port 8774.
2) check if controller service is listening on 8774 

Sent from my iPhone

> On 23-Mar-2018, at 1:07 PM, __ mango. <935540...@qq.com> wrote:
> 
> 
> I run the openstack compute service list with the following error:
> 
> # openstack compute service list
> Unable to establish connection to http://controller:8774/v2.1/os-services:
> HTTPConnectionPool(host='controller', port=8774): 
> Max retries exceeded with url: /v2.1/os-services (Caused by 
> NewConnectionError(' 0x7efdbbee9e50>: 
> Failed to establish a new connection: [Errno 111] 
> \xe6\x8b\x92\xe7\xbb\x9d\xe8\xbf\x9e\xe6\x8e\xa5',))
> 
> My port 8774 didn't work and restart the nova- API doesn't work.
> Is there any way to solve this problem?  thank you.  
> 
> 
> __
> OpenStack Development Mailing 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] [trove] PTG planning, weekly meeting for Trove

[Manoj Kumar]

 I would encourage everyone who is interested in providing input into the 
Rocky planning cycle for Trove to put their ideas into the etherpad at:

https://etherpad.openstack.org/p/trove-ptg-rocky

There are a good number of topics posted already. We would welcome input 
from operators as well.
We are planning to meet remotely using Skype. If you are interested in 
participating in the discussions do add your Skype ID as well.

As we prepare for the PTG, there will be no weekly meeting next week.

- Manoj




__
OpenStack Development Mailing 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] Office Hours Report 2018-02-01

[Chandan kumar]

Hello,

Thanks everyone for attending QA office hour. Since It's the starting
of the year so attendance is low. We managed to triaged some bugs
opened/changed in last 14 days.

The IRC report [0] and full log [1] are available through meetbot.

bug 1745871 in Patrole "RBAC tests for group type specs"
https://bugs.launchpad.net/patrole/+bug/1745871
Status: confirmed
Related Review: https://review.openstack.org/#/c/525589/

1743688 in congress "Tempest unable to detect service availability
properly, causing congress tests to fail"
https://bugs.launchpad.net/devstack/+bug/1743688
Status: In Progress

bug 1744096 in devstack "CentOS install fails with 'python3: command not found'"
https://bugs.launchpad.net/devstack/+bug/1744096
status: In Progress

bug 1746687 in tempest "tempest plugins should be loaded though configuration"
https://bugs.launchpad.net/tempest/+bug/1746687
Status: Invalid

Above bug leads to interesting discussion on how to ship tempest
plugins with kolla tempest containers
Below are the remarks:
* Bundle all the plugins in a single containers.
* User service_available config params to enable or disable a plugin
while using it
* In tempest we have blacklist or whitelist test params to play with tests.

bug 1745322 in tempest "stackviz folder does not show up in logs on
zuulv3 native jobs"
https://bugs.launchpad.net/tempest/+bug/1745322
Status: Fix committed
Review: https://review.openstack.org/#/c/539146/

bug 1745307 in tempest "Group related cases would fail if driver has
group spec check"
https://bugs.launchpad.net/tempest/+bug/1745307
Status: in-progress
Review: https://review.openstack.org/537784

https://bugs.launchpad.net/tempest/+bug/1660612
bug 1660612 in neutron "Tempest full jobs time out on execution"
status: New
Comments: related fix https://review.openstack.org/#/c/536598/ is not
ok. it changes existing tox envs which has an impact on existing jobs
it make it all scenario to run parallel, but tempest full deos not run
 scenario tests.

Links:
[0]. 
http://eavesdrop.openstack.org/meetings/qa_office_hour/2018/qa_office_hour.2018-02-01-09.05.txt
[1]. 
http://eavesdrop.openstack.org/meetings/qa_office_hour/2018/qa_office_hour.2018-02-01-09.05.log.html

Thanks for reading.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all] QA Office Hours on 01st Feb, 2018

[Chandan kumar]

Hello All,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

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

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

[Manoj Kumar]

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.

Cheers,
- Manoj

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

[openstack-dev] [trove] Not running for Trove PTL

[Manoj Kumar]

I have had the good fortune to be the PTL for Trove the last cycle. 
During this period, I was able to oversee a resurgence of community 
participation in Trove.
As the project continues to evolve, it could use some new leadership.
I wanted to clear the path for others to run. 
So I do not intend to nominate myself for the Rocky cycle.

Cheers,
- Manoj


__
OpenStack Development Mailing 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][all] QA Office Hours on 18th Jan, 2018

[Chandan kumar]

Hello All,

A kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] Community Goals for Rocky

[Chandan kumar]

Hello Em

On Tue, Jan 16, 2018 at 9:59 PM, Emilien Macchi <emil...@redhat.com> wrote:
> Here's an update so we can hopefully, as a community, take a decision
> in the next days or so.
>
>
> * Migration to StoryBoard
>
> Champion: Kendall Nelson
> https://review.openstack.org/#/c/513875/
> Some projects already migrated, some projects will migrate soon but
> there is still a gap of things that prevents some projects to not
> migrate.
> See 
> https://storyboard.openstack.org/#!/search?tags=blocking-storyboard-migration
> For that reason, we are postponing this goal to later but work needs
> to keep going to make that happen one day.
>
>
> * Remove mox
>

> Champion: Sean McGinnis (unless someone else steps up)
> https://review.openstack.org/#/c/532361/
> This goal is to clean some technical debt in the code.
> It remains a good candidate for Queens.
>

May I step up for this goal for Rocky release?
I am currently involved with Tempest plugin split goal in Queens
Release. I wanted to help on this one.

Thanks,

Chandan Kumar

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

[openstack-dev] [trove] Changes to the Trove core team

[Manoj Kumar]

I would like to announce the following changes to the Trove core 
reviewers:

-amrith
+maciej.jozefczyk
+fanzhang

Amrith's stewardship of Trove and active contributions over the last 
several cycles would be missed dearly.
Would like to welcome Fan and Maciej.

- Manoj

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

Re: [openstack-dev] [infra][tempest][devstack][congress] tempest.config.CONF.service_available changed on Jan 2/3?

[Chandan kumar]

Hello Eric,

On Sat, Jan 6, 2018 at 4:46 AM, Eric K <ekcs.openst...@gmail.com> wrote:
> Seems that sometime between 1/2 and 1/3 this year,
> tempest.config.CONF.service_available.aodh_plugin as well as
> ..service_available.mistral became unavailable in congress dsvm check/gate
> job. [1][2]
>
> I've checked the changes that went in to congress, tempest, devstack,
> devstack-gate, aodh, and mistral during that period but don't see obvious
> causes. Any suggestions on where to look next to fix the issue? Thanks
> very much!
>

The aodh tempest plugin [https://review.openstack.org/#/c/526299/] is
moved to telemetry-tempest-plugin
[https://github.com/openstack/telemetry-tempest-plugin].
I have sent a patch to Congress project to fix the issue:
https://review.openstack.org/#/c/531534/

The mistral bundled intree tempest plugin
[https://review.openstack.org/#/c/526918/] is also moved to
mistral-tempest-plugin repo
[https://github.com/openstack/mistral-tempest-plugin]

Tests are moved to a new repo as a part of Tempest Plugin Split goal
[https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html].
Feel free to consume the new tempest plugin and let me know if you
need any more help.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] Office Hours Report 2018-01-04

[Chandan kumar]

Hello,

Thanks everyone for attending QA office hour. Since It's the starting
of the year so attendance is low. We managed to triaged some bugs
opened/changed in last 14 days.

The IRC report [0] and full log [1] are available through meetbot.

**Bug Traiged Summary**
* Bug #1740194 in devstack: "Apache2 unable to start as 2 MPM modules
enabled on Fedora 27"
  Status: Confirmed, Related Review: https://review.openstack.org/#/c/527048/
  https://bugs.launchpad.net/devstack/+bug/1740194

* Bug #1740480 in devstack: "502 Proxy Error"
  Status: New, Action: Need help in traiging
  https://bugs.launchpad.net/devstack/+bug/1740480

* Bug #1740920 in devstack: "stable/newton branch does not work
because keystone does not have stable/newton branch"
  Status: Invalid
  https://bugs.launchpad.net/devstack/+bug/1740920

* Bug #1741097 in devstack: "Installing pip fails on RHEL 7.4 with SSL error"
  status: In Progress, Related Review: https://review.openstack.org/#/c/530991/
  https://bugs.launchpad.net/devstack/+bug/1741097

* Bug #1740544 in tempest: "Volume retype fails when migration occurs"
  Status: confirmed
  https://bugs.launchpad.net/tempest/+bug/1740544

* Bug #1739829 in tempest: "tempest-full job failing in stable/pike
with 404 from keystone during tempest verify-config"
  Status: Confirmed, Related Review:
https://review.openstack.org/#/c/530915/ (Needs to be backported for
stable branches)
  https://bugs.launchpad.net/tempest/+bug/1739829

* Bug #1740258 in tempest: "[scenario]/img_dir is deprecated but required"
  Status: Undecided, Action: Needs discussion
  https://bugs.launchpad.net/tempest/+bug/1740258


Links:

[0]. 
http://eavesdrop.openstack.org/meetings/qa_office_hours/2018/qa_office_hours.2018-01-04-09.02.html

[1]. 
http://eavesdrop.openstack.org/meetings/qa_office_hours/2018/qa_office_hours.2018-01-04-09.02.log.html

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all] QA Office Hours on 04th Jan, 2018

[Chandan kumar]

Hello All,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] Office Hours Report 2017-12-21

[Chandan kumar]

Hello,

Thanks everyone for attending QA office hour.
The IRC report [0] and full log [1] are available through meetbot.

We have triaged 3 bugs and talks about some reviews, As below is the report.
* Bug #1736988 in devstack: "using long-deprecated keystonemiddleware options"
  https://bugs.launchpad.net/devstack/+bug/1736988
  Status: Invalid, transferred to Keystone


* Bug #1738938 in devstack: ""[: ==: unary operator expected" when
running unstack.sh"
  https://bugs.launchpad.net/devstack/+bug/1738938
   Status: Fixed in progress.

*Bug #1737634 in tempest: "ImagesTestJSON.test_delete_saving_image can
wait for image status SAVING when the snapshot is already ACTIVE"
https://bugs.launchpad.net/tempest/+bug/1737634
 Status: Confirmed, Tagged as low-hanging-fruit

Discussions on review:

* Remove jobs from tempest-lib as repo is deprecated:
https://review.openstack.org/#/c/529524/

* Add profiler support into Tempest - https://review.openstack.org/#/c/523935/

Links:

[0] 
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-12-21-09.01.html

[1] 
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-12-21-09.01.log.html


Thanks for reading, Happy Holidays, see ya next year :-)


Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all] QA Office Hours on 21st Dec, 2017

[Chandan kumar]

Hello All,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] Office Hours report 2017-12-07

[Chandan kumar]

Hello,

Thanks everyone for attending QA office hour.
The IRC report [0] and full log [1] are available through meetbot.

Below is the list of 10 bugs traiged and discussed during office hour,
opened in last 14 days.

* Bug #1735667 in StackViz: "Use stestr instead of testrepository"
   https://bugs.launchpad.net/stackviz/+bug/1735667

* Bug #1733983 in os-testr: "Tempest reports 'missing Worker 1!'"
  https://bugs.launchpad.net/os-testr/+bug/1733983

* Bug #1736385 in grenade: "placement is not being properly restarted
in grenade (pike to master)"
  https://bugs.launchpad.net/grenade/+bug/1736385

* Bug #1734510 in devstack: "devstack pike: Error: No sql_connection
parameter is established"
  https://bugs.launchpad.net/devstack/+bug/1734510

* Bug #1735097 in devstack: "Devstack depends on running mysql on ubuntu 16.04"
  https://bugs.launchpad.net/devstack/+bug/1735097

* Bug #1736385 in devstack: "placement is not being properly restarted
in grenade (pike to master)"
  https://bugs.launchpad.net/devstack/+bug/1736385

* Bug #1736776 in devstack: "DevStack in DevStack"
  https://bugs.launchpad.net/devstack/+bug/1736776

* Bug #1506215 in tempest: "--regex  and --blacklist_file does not
work together"
  https://bugs.launchpad.net/tempest/+bug/1506215

* Bug #1734636 in tempest: "test_get_service_by_volume_host_name
failed with "cinder-volume not found on host #DEFAULT"
error"
  https://bugs.launchpad.net/tempest/+bug/1734636

* Bug #1734776 in tempest: "Tempest volume tests hardcoded for tenant isolation"
  https://bugs.launchpad.net/tempest/+bug/1734776

Links:
[0] 
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-12-07-09.00.html

[1] 
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-12-07-09.00.log.html

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all] QA Office Hours on 07th Dec, 2017

[Chandan kumar]

Hello All,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

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

[openstack-dev] [all] [tc] Tempest Plugin Split Goal Queens-2 Update

[Chandan kumar]

Hello,

As Queens Milestone 2 approaches its end, here is the second iteration
of updates on Queens Tempest Plugin Split community goal [1].

**Not Started**
Congress
ec2-api
freezer
mistral
monasca
senlin
tacker
Telemetry
Trove
Vitrage

** In Progress **
Cinder
Heat
Ironic
magnum
manila
Neutron
murano
networking-l2gw
octavia

** Completed **
Barbican
CloudKitty
Designate
Horizon
Keystone
Kuryr
Sahara
Solum
Tripleo
Watcher
Winstackers
Zaqar
Zun

Here is the list of open reviews:
https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open

Here is the detailed report on Tempest Plugin split goal status for
different projects:
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html#project-teams

If you are willing to help on the **not started**, that would be great help.

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

Thanks,

Chandan Kumar

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

[openstack-dev] [trove] Changes to the Trove core team

[Manoj Kumar]

I would like to announce the following changes to the Trove core 
reviewers:

+jian.song 
-mariamj

Mariam has moved on to other projects and unfortunately has not been able 
to contribute recently.
Jian Song has been an active contributor/reviewer for the last few cycles.


- Manoj

__
OpenStack Development Mailing 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

[Amrith Kumar]

I don't see much of a point in an OpenStack Technical blog. After all,
those who want to blog likely already have blogs that are syndicated
through the OpenStack digest mechanism.

What problem or existing shortcoming is sought to be addressed by this
blog? And is there some reason that existing (individual) blogs can't be
used for this?

The issue may be centralization and longevity which, given the transient
nature of all of our involvement in OpenStack is a perfectly legitimate
concern. But, I'd like that this be articulated clearly if it is in fact
the issue.

-amrith


On Mon, Nov 27, 2017 at 9:16 AM, Dan Prince  wrote:

>
>
> On Mon, Nov 27, 2017 at 8:55 AM, Flavio Percoco  wrote:
>
>> Greetings,
>>
>> Last Thursday[0], at the TC office hours, we brainstormed a bit around
>> the idea
>> of having a tech blog. This idea came first from Joshua Harlow and it was
>> then
>> briefly discussed at the summit too.
>>
>> The idea, we have gathered, is to have a space where the community could
>> write
>> technical posts about OpenStack. The idea is not to have an aggregator
>> (that's
>> what our planet[1] is for) but a place to write original and curated
>> content.
>>
>
> Why not just write article's on existing blogs, link them into planet, and
> then if they are really good promote them at a higher level?
>
> Having a separate blog that is maintained by a few seems a bit elitist to
> me.
>
> Dan
>
>
>> During the conversation, we argued about what kind of content would be
>> acceptable for this platform. Here are some ideas of things we could have
>> there:
>>
>> - Posts that are dev-oriented (e.g: new functions on an oslo lib)
>> - Posts that facilitate upstream development (e.g: My awesome dev setup)
>> - Deep dive into libvirt internals
>>
>
> What is really missing in our current infrastructure setup that really
> prevents any of the above?
>
>
>> - ideas?
>>
>> As Chris Dent pointed out on that conversation, we should avoid making
>> this
>> place a replacement for things that would otherwise go on the mailing
>> list -
>> activity reports, for example. Having dev news in this platform, we would
>> overlap with things that go already on the mailing list and, arguably, we
>> would
>> be defeating the purpose of the platform. But, there might be room for
>> both(?)
>>
>> Ultimately, we should avoid topics promoting new features in services as
>> that's what
>> superuser[2] is for.
>>
>> So, what are your thoughts about this? What kind of content would you
>> rather
>> have posted here? Do you like the idea at all?
>>
>> [0] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23op
>> enstack-tc.2017-11-23.log.html#t2017-11-23T15:01:25
>> [1] http://planet.openstack.org/
>> [2] http://superuser.openstack.org/
>>
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ptl] Improving the process for release marketing

[Amrith Kumar]

Very cool, thanks Sean!


-amrith


On Mon, Nov 20, 2017 at 12:18 PM, Sean McGinnis 
wrote:

> Hello PTL's, release liaisons, and all those interested.
>
> The changes on our side to support a release cycle highlights page have
> been
> completed, and things have settled a bit from the Summit activies, so I
> think
> now is a good time to get things going again for this.
>
> See below for the background, but if you missed it or have forgotten by
> now, we
> plan to have an easier way to collect significant "highlights" for each
> release
> cycle in order to collect "key features" flagged by each team that
> marketing
> teams can use during release communication times. The goal is to reduce the
> number of times PTL's get asked by various groups to "tell us what changed
> in
> this release."
>
> The way we are approaching this is by adding a "cycle-highlights" key to
> the
> deliverable file for your project [1]. This field will take RST formatted
> text
> that will then be rendered into the highlights page we will share with
> marketing.
>
> Our goal is to have roughly three "highlights" per team for each release,
> but
> this will vary based on the needs of the team and the amount of work done
> during the cycle. If there is only one significant change to share, that is
> fine. If there are five, that's OK too. Just keep in mind that these
> should be
> limited to only the significant changes that you feel are worth
> communicating
> to the marketing, sales, and end users out there that need to know what to
> expect.
>
> We will want to start collecting this information as we near RC releases,
> but
> feel free to start adding items of interest with the upcoming Queens-2
> release
> if you already have changes worth noting.
>
> And please ask here or in the #openstack-release channel if you have any
> questions about how this works.
>
> Thanks,
> Sean
>
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466
>
> P.S. This is for cycle_* deliverables only. If you see a need for this
> with the
> independent releases, let me know and we can talk about how that might
> look.
>
>
> On Tue, Sep 26, 2017 at 02:33:09PM -0700, Anne Bertucio wrote:
> > Release marketing is a critical part of sharing what’s new in each
> release, and we want to rework how the marketing community and projects
> work together to make the release communications happen.
> >
> > Having multiple, repetetive demands to summarize "top features" during
> release time can be pestering and having to recollect the information each
> time isn't an effective use of time. Being asked to make polished,
> "press-friendly" messages out of release notes can feel too far outside of
> the PTL's focus areas or skills. At the same time, for technical content
> marketers, attempting to find the key features from release notes, ML
> posts, specs, Roadmap, etc., means interesting features are sometimes
> overlooked. Marketing teams don't have the latest on what features landed
> and with what caveats.
> >
> > To address this gap, the Release team and Foundation marketing team
> propose collecting information as part of the release tagging process.
> Similar to the existing (unused) "highlights" field for an individual tag,
> we will collect some text in the deliverable file to provide highlights for
> the series (about 3 items). That text will then be used to build a landing
> page on release.openstack.org that shows the "key features" flagged by
> PTLs that marketing teams should be looking at during release communication
> times. The page will link to the release notes, so marketers can start
> there to gather additional information, eliminating repetitive asks of
> PTLs. The "pre selection" of features means marketers can spend more time
> diving into release note details and less sifting through them.
> >
> > To supplement the written information, the marketing community is also
> going to work together to consolidate follow up questions and deliver them
> in "press corps" style (i.e. a single phone call to be asked questions from
> multiple parties vs. multiple phone calls from individuals).
> >
> > We will provide more details about the implementation for the highlights
> page when that is ready, but want to gather feedback about both aspects of
> the plan early.
> >
> > Thanks for your input,
> > Anne Bertucio and Sean McGinnis
> >
> >
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing 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
> 

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [QA] Proposal for a QA SIG

[Chandan kumar]

Hello,

On Sun, Nov 19, 2017 at 7:44 PM, Ghanshyam Mann <ghanshyamm...@gmail.com> wrote:
> On Sat, Nov 18, 2017 at 12:41 AM, Andrea Frittoli
> <andrea.fritt...@gmail.com> wrote:
>>
>>
>> On Fri, Nov 17, 2017 at 12:33 PM Thierry Carrez <thie...@openstack.org>
>> wrote:
>>>
>>> Andrea Frittoli wrote:
>>> > [...]
>>> > during the last summit in Sydney we discussed the possibility of
>>> > creating an
>>> > OpenStack quality assurance special interest group (OpenStack QA SIG).
>>> > The proposal was discussed during the QA feedback session [0] and it
>>> > received
>>> > positive feedback there; I would like to bring now the proposal to a
>>> > larger
>>> > audience via the SIG, dev and operators mailing lists.
>>> > [...]
>
> Yea, This will greatly help QA team to get more interest from
> downstream QA teams and sharing
> of QA practice, scenarios & tools. I am happy to volunteer for this effort.
>
>>>
>>> I think this goes with the current trends of re-centering upstream
>>> "project teams" on the production of software, while using SIGs as
>>> communities of practice (beyond the governance boundaries), even if they
>>> happen to produce (some) software as the result of their work.
>>>
>>> One question I have is whether we'd need to keep the "QA" project team
>>> at all. Personally I think it would create confusion to keep it around,
>>> for no gain. SIGs code contributors get voting rights for the TC anyway,
>>> and SIGs are free to ask for space at the PTG... so there is really no
>>> reason (imho) to keep a "QA" project team in parallel to the SIG ?
>>
>>
>> That is a possibility indeed, but I think co-existance will be the case for
>> a
>> bit at least - we may decide to drop the QA program eventually depending
>> on how the experience with the SIG goes.
>
> Yea, we can think of merging both based on progress and how this SIG
> provide us the practical benefits. Probably this idea might solve less
> contributors issue where more people from downstream start
> participating in QA but as of now I cannot say anything on this.
>
> In current situation, it will be difficult to not have QA project
> team. QA has around 15 projects
> and few of active projects like Tempest, Devstack, Grenade, Patrole,
> O-H need dedicated team to
> maintain and implement them. Grouping them under single SIG will be
> another challenge to get a dedicated
> attention to them.
>
> Currently I see the proposed QA SIG as a common platform for different
> entity like OpenStack upstream, downstream QA and
> other community like opnfv etc. to share best practice, tooling etc.
> For example, opnfv shown much interest in on-ongoing OpenStack
> "extreme testing" and this SIG can play important role to
> shape this project in good/efficient direction. But we need a
> dedicated set of people to lead/implement it.
>
> Another point/idea is to consider and run this QA SIG  as one of the
> effort under QA program along with project team which can be lead by
> common leader(QA PTL) to make sure both
> effort goes in smooth and syncing way.
>

Thanks Andreaf for starting it. I am happy to help.
It is a great idea to bring more people under QA as well as help to
share best practices
and tools with in OpenStack community.
I have one query, Are we also planning to collaborate with other
communities like Ansible, K8s and others for the same?

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] Building Openstack Trove Images

[Amrith Kumar]

I would start here:

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed for
port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs for
more information.


-amrith


On Mon, Nov 13, 2017 at 2:59 AM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amirth,
>
>
>
> Many thanks for your response coz of which I was able to build a MySQL
> image from Ubuntu Xenial.
>
> However, I am facing another obstacle now, we have added one compute node
> to our Openstack controller which is showing in the openstack dashboard
> however the when we launch any VM, the VM goes into error state. We have
> gone through most of the things available on the internet but nothing sorts
> it out. Below are the logs for the error:
>
>
>
> ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
> File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py",
> line 984, in _update_ports_for_instance
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] port_client, instance, port_id,
> port_req_body)
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8]   File "/usr/lib/python2.7/site-
> packages/nova/network/neutronv2/api.py", line 445, in _update_port
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_
> failure(port)
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8]   File "/usr/lib/python2.7/site-
> packages/nova/network/neutronv2/api.py", line 191, in
> _ensure_no_port_binding_failure
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] raise
> exception.PortBindingFailed(port_id=port['id'])
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed
> for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs
> for more information.
>
>
>
>
>
> Can you throw some light or give us some guidance on this as it has halted
> the implementation of our Production Openstack Pike.
>
> Your support and co-operation is highly appreciated.
>
>
> FYI: Controller and compute node are running CentOS7.
>
>
>
> Thanks and Regards,
>
> Ritesh
>
>
>
>
>
> On Thu, Nov 9, 2017 at 12:03 PM, Amrith Kumar <amrith.ku...@gmail.com>
> wrote:
>
>> Sorry, I should have been more clear.
>>
>> You shouldn't use redstack.
>>
>> And you should not be using trovestack with trusty.
>>
>> All of the gate moved to Xenial a while back and I don't know that anyone
>> is verifying trusty any longer. But, YMMV, set the force flag and try again
>> if you want. I am not able to verify with Trusty, don't have a trusty env.
>>
>> Apologies for the back and forth. It has been a long week at summit.
>>
>>
>>
>> -amrith
>>
>>
>> On Thu, Nov 9, 2017 at 1:24 AM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>> Hi Amrith,
>>>
>>> This time I followed the https://github.com/opensta
>>> ck/trove/tree/master/integration/ however, it still throws me the same
>>> error. Please find the log file attached.
>>>
>>>
>>> Regards,
>>> Ritesh
>>>
>>> On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar <amrith.ku...@gmail.com>
>>> wrote:
>>>
>>>> Please see inline below.
>>>>
>>>> -amrith
>>>>
>>>>
>>>> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
>>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>>
>>>>>
>>>>>
>>>>> Hi Amrith,
>>>>>
>>>>>
>>>>>
>>>>> Please find my response to your queries below:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 1.   What (exact) version of OpenStack are you using? Is it from
>>>>> upstream or a vendor, if it is the latter, which vendor?
>>>>>
>>>>> We are using Openstack Pike installed on CentOS7.
>>>>>
>>>>> 2.   What database (exact version) are you trying to create an
>>>>> image for?
>>>&g

Re: [openstack-dev] Building Openstack Trove Images

[Amrith Kumar]

Sorry, I should have been more clear.

You shouldn't use redstack.

And you should not be using trovestack with trusty.

All of the gate moved to Xenial a while back and I don't know that anyone
is verifying trusty any longer. But, YMMV, set the force flag and try again
if you want. I am not able to verify with Trusty, don't have a trusty env.

Apologies for the back and forth. It has been a long week at summit.



-amrith


On Thu, Nov 9, 2017 at 1:24 AM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amrith,
>
> This time I followed the https://github.com/openstack/trove/tree/master/
> integration/ however, it still throws me the same error. Please find the
> log file attached.
>
>
> Regards,
> Ritesh
>
> On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar <amrith.ku...@gmail.com>
> wrote:
>
>> Please see inline below.
>>
>> -amrith
>>
>>
>> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>>
>>>
>>> Hi Amrith,
>>>
>>>
>>>
>>> Please find my response to your queries below:
>>>
>>>
>>>
>>>
>>>
>>> 1.   What (exact) version of OpenStack are you using? Is it from
>>> upstream or a vendor, if it is the latter, which vendor?
>>>
>>> We are using Openstack Pike installed on CentOS7.
>>>
>>> 2.   What database (exact version) are you trying to create an
>>> image for?
>>>
>>> We want to build images for mysql5.7 as of now.
>>>
>>> 3.   What operating system (exact version) are you attempting to
>>> perform this   on?
>>>
>>> We have tried it from CentOS7 & Ubuntu 14.04.
>>>
>>> 4.   What command(s) are you executing?
>>>
>>> I am step-by-step following the 
>>> *https://github.com/openstack/trove-integration
>>> <https://github.com/openstack/trove-integration>* and the “./redstack
>>> install” command. Also, I want to confirm that as this code installs its
>>> own devstack cloud, will we be able to use the images created using it
>>> in our Openstack Pike trove environment.
>>>
>>
>>
>> ​The Trove Integration repository is dead and gone for a couple of
>> releases now and you should be using the stuff from the trove repository as
>> the documentation indicates.​
>>
>>
>>
>>> 5.   What exact error(s) are you receiving?
>>>
>>> I have attached the logs.
>>>
>>
>>
>> ​The end of your error log indicates
>>
>> +./stack.sh:main:225   echo 'WARNING: this script
>> has not been tested on trusty'
>> WARNING: this script has not been tested on trusty
>> +./stack.sh:main:226   [[ '' != \y\e\s ]]
>> +./stack.sh:main:227   die 227 'If you wish to run
>> this script anyway run with FORCE=yes'
>> +functions-common:die:187  local exitcode=0
>> +functions-common:die:188  set +o xtrace
>> [Call Trace]
>> ./stack.sh:227:die
>> [ERROR] ./stack.sh:227 If you wish to run this script anyway run with
>> FORCE=yes
>>
>>
>> That seems pretty clear to me. Don't do it, redstack is dead, gone,
>> bye-bye.
>>
>> Use the stuff in trove/integration/scripts
>>
>> The trove-integration repository should now have been deleted as well.​
>>
>>
>>
>>>
>>>
>>>
>>>
>>>   Please guide us where are going wrong on this.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ritesh
>>>
>>>
>>>
>>>Please guide us where are going wrong on this.
>>>
>>> On Wed, Nov 8, 2017 at 12:11 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
>>>> ++Looping my fellow engineer.
>>>>
>>>> On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar <amrith.ku...@gmail.com>
>>>> wrote:
>>>>
>>>>> Ritesh,
>>>>>
>>>>> Your answers don't help me understand the problems you are having. So
>>>>> let's try this instead.
>>>>>
>>>>> 1. What (exact) version of OpenStack are you using? Is it from
>>>>> upstream or a vendor, if it is the latter, which vendor?
>>>>> 2. What database (exact version) are you trying to create an image for?
>>>>> 3. What operatin

Re: [openstack-dev] Building Openstack Trove Images

[Amrith Kumar]

Please see inline below.

-amrith


On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

>
>
> Hi Amrith,
>
>
>
> Please find my response to your queries below:
>
>
>
>
>
> 1.   What (exact) version of OpenStack are you using? Is it from
> upstream or a vendor, if it is the latter, which vendor?
>
> We are using Openstack Pike installed on CentOS7.
>
> 2.   What database (exact version) are you trying to create an image
> for?
>
> We want to build images for mysql5.7 as of now.
>
> 3.   What operating system (exact version) are you attempting to
> perform this   on?
>
> We have tried it from CentOS7 & Ubuntu 14.04.
>
> 4.   What command(s) are you executing?
>
> I am step-by-step following the 
> *https://github.com/openstack/trove-integration
> <https://github.com/openstack/trove-integration>* and the “./redstack
> install” command. Also, I want to confirm that as this code installs its
> own devstack cloud, will we be able to use the images created using it in
> our Openstack Pike trove environment.
>


​The Trove Integration repository is dead and gone for a couple of releases
now and you should be using the stuff from the trove repository as the
documentation indicates.​



> 5.   What exact error(s) are you receiving?
>
> I have attached the logs.
>


​The end of your error log indicates

+./stack.sh:main:225   echo 'WARNING: this script has
not been tested on trusty'
WARNING: this script has not been tested on trusty
+./stack.sh:main:226   [[ '' != \y\e\s ]]
+./stack.sh:main:227   die 227 'If you wish to run this
script anyway run with FORCE=yes'
+functions-common:die:187  local exitcode=0
+functions-common:die:188  set +o xtrace
[Call Trace]
./stack.sh:227:die
[ERROR] ./stack.sh:227 If you wish to run this script anyway run with
FORCE=yes


That seems pretty clear to me. Don't do it, redstack is dead, gone, bye-bye.

Use the stuff in trove/integration/scripts

The trove-integration repository should now have been deleted as well.​



>
>
>
>
>   Please guide us where are going wrong on this.
>
>
>
> Regards,
>
> Ritesh
>
>
>
>Please guide us where are going wrong on this.
>
> On Wed, Nov 8, 2017 at 12:11 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> ++Looping my fellow engineer.
>>
>> On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar <amrith.ku...@gmail.com>
>> wrote:
>>
>>> Ritesh,
>>>
>>> Your answers don't help me understand the problems you are having. So
>>> let's try this instead.
>>>
>>> 1. What (exact) version of OpenStack are you using? Is it from upstream
>>> or a vendor, if it is the latter, which vendor?
>>> 2. What database (exact version) are you trying to create an image for?
>>> 3. What operating system (exact version) are you attempting to perform
>>> this on?
>>> 4. What command(s) are you executing?
>>> 5. What exact error(s) are you receiving?
>>>
>>> For #4 and #5 it would be ideal if you just cut/pasted a terminal
>>> session into an etherpad or gist or pastebuffer or some such thing and
>>> shared that link via email. If you have passwords and other sensitive
>>> stuff, make sure you redact it.
>>>
>>> Thanks.
>>>
>>> -amrith
>>>
>>>
>>>
>>> On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
>>>> Hi Amrith,
>>>>
>>>>
>>>> Many Thanks for your response. Hope you are doing well!
>>>>
>>>>
>>>> The confusing part here is that the OpenStack tutorial page itself not
>>>> seems to be updated https://docs.openstack.org/tro
>>>> ve/latest/admin/building_guest_images.html#build-guest-images
>>>>
>>>> as the *dib-lint* file is there instead of the mentioned *disk-image-create
>>>> *and when executed just verifies the other elements.
>>>>
>>>> I have also tried using https://github.com/denismakogo
>>>> n/trove-guest-image-elements but the error on which I got stuck is
>>>> “deltarpm not installed” (deltarpm is installed on the host machine).
>>>> Though yesterday, I came across the https://github.com/openstack/t
>>>> rove-integration which I am going to try out today, kindly let me know
>>>> if it is the right one or please share any relevant refe

Re: [openstack-dev] Building Openstack Trove Images

[Amrith Kumar]

Ritesh,

Your answers don't help me understand the problems you are having. So let's
try this instead.

1. What (exact) version of OpenStack are you using? Is it from upstream or
a vendor, if it is the latter, which vendor?
2. What database (exact version) are you trying to create an image for?
3. What operating system (exact version) are you attempting to perform this
on?
4. What command(s) are you executing?
5. What exact error(s) are you receiving?

For #4 and #5 it would be ideal if you just cut/pasted a terminal session
into an etherpad or gist or pastebuffer or some such thing and shared that
link via email. If you have passwords and other sensitive stuff, make sure
you redact it.

Thanks.

-amrith


On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amrith,
>
>
> Many Thanks for your response. Hope you are doing well!
>
>
> The confusing part here is that the OpenStack tutorial page itself not
> seems to be updated https://docs.openstack.org/
> trove/latest/admin/building_guest_images.html#build-guest-images
>
> as the *dib-lint* file is there instead of the mentioned *disk-image-create
> *and when executed just verifies the other elements.
>
> I have also tried using https://github.com/denismakogon/trove-guest-
> image-elements but the error on which I got stuck is “deltarpm not
> installed” (deltarpm is installed on the host machine). Though yesterday, I
> came across the https://github.com/openstack/trove-integration which I am
> going to try out today, kindly let me know if it is the right one or please
> share any relevant reference on which we can work.
>
>
>
> Regards,
>
> Ritesh
>
> On Tue, Nov 7, 2017 at 8:16 AM, Amrith Kumar <amrith.ku...@gmail.com>
> wrote:
>
>> Ha, it isn't often that I get called out by name in a mailing list thread.
>>
>> What are the issues that you are facing? Currently there are complete
>> notes about how to build guest images but the issues you may be facing may
>> not relate to the images you are building.
>>
>> So please provide some more details so I can give you a more accurate
>> reply.
>> ​
>> ​Thanks,​
>>
>>
>> -amrith
>>
>>
>> On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>> Hi Team,
>>>
>>> We have installed Openstack Pike in our campus but despite of numerous
>>> attempts we are just unable to build trove images that we can use to launch
>>> database instances.We also came across a mail thread where Mr. Amrith
>>> updates that some review & update of the OpenStack Trove documents was
>>> going on, kindly provide us some reference document or link which we can
>>> follow.
>>>
>>> https://lists.gt.net/openstack/dev/58182
>>>
>>> We will be eagerly waiting for your response.
>>>
>>>
>>>
>>> Thanks  & Regards,
>>> Ritesh Vishwakarma
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Building Openstack Trove Images

[Amrith Kumar]

Ha, it isn't often that I get called out by name in a mailing list thread.

What are the issues that you are facing? Currently there are complete notes
about how to build guest images but the issues you may be facing may not
relate to the images you are building.

So please provide some more details so I can give you a more accurate reply.
​
​Thanks,​


-amrith


On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Team,
>
> We have installed Openstack Pike in our campus but despite of numerous
> attempts we are just unable to build trove images that we can use to launch
> database instances.We also came across a mail thread where Mr. Amrith
> updates that some review & update of the OpenStack Trove documents was
> going on, kindly provide us some reference document or link which we can
> follow.
>
> https://lists.gt.net/openstack/dev/58182
>
> We will be eagerly waiting for your response.
>
>
>
> Thanks  & Regards,
> Ritesh Vishwakarma
>
> __
> OpenStack Development Mailing 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] [trove] retiring trove-integration?

[Amrith Kumar]

Agreed, please also see[1].

-amrith

[1] https://review.openstack.org/515084


On Wed, Oct 25, 2017 at 3:28 AM, Andreas Jaeger  wrote:

> Trove team,
>
> with the retirement of stable/newton, you can now retire
> trove-integration AFAIU.
>
> For information on what to do, see:
> https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
>
> I just pushed out two changes for stable/newton retirement that also
> take care of step 1 of the retiring process, see:
>
> https://review.openstack.org/#/c/514916/
> https://review.openstack.org/#/c/514918/
>
> Will you take care of the other steps, please?
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Schedule Is Available

[Amrith Kumar]

Mike,

Thanks for sending this out. Long lines in descriptions of many events
are not being wrapped, take Rochelle's session "Refstack: OpenStack to
OPNFV, Vertical, Integrated, Interop" at 3:30pm on Wednesday.

Any chance the descriptions could be wrapped?

-amrith



On Mon, Oct 16, 2017 at 7:43 PM, Mike Perez  wrote:
> Hey all,
>
> Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's 
> the
> schedule posted on the Summit site filtering by forum related sessions:
>
> https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63
>
> Please reply to give corrections.
>
> I will be sending emails to listed moderators to verify there will be someone
> physically present at the Forum to moderate the session. Thank you!
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing 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][election] Question for all candidates in TC election: What will you do if you don't win?

[Amrith Kumar]

In a recent conversation on #openstack-tc where we bemoaned the ills
of Stackalytics and related management-by-objectives to Heisenberg's
uncertainty principle, the conversation (on 10-03, for example) veered
towards why people were interested in running for election to the
Technical Committee.

The observation was made that one motivation may be that an
individual's employer derives some benefit from having a member on the
technical committee. That would explain why some people (in the N-M,
the ones who don't get elected) do not remain actively involved in the
work of the TC if they are not elected. Some days later, I went and
eyeballed the people who have run for TC elections over the past four
cycles and then looked at what many of them did after the election, on
the mailing list, and on the governance repository, and I think there
is some truth to the observation.

I've never been elected to the TC, I have run for election several
times. Not winning the election has not in any way diminished my
desire or drive to participate in the governance of OpenStack. Not
winning has merely given me the (little more) luxury of not feeling so
bad if I don't make it to the TC meeting (RIP), or not making it to as
many of the office hours as I can. It has meant that I don't feel
compelled to attend the TC meeting that precedes the Summit, and where
possible I have made an effort to do so.

In my mind winning or not winning merely changes one thing; do you get
an actual vote that is counted towards a decision, on something that
is put before the TC.

Now, the question is this; does the vote really matter? I'm really
happy with one thing that the TC has done over the years I've known of
it; few (if any) decisions were actually made on a small margin of
votes. Whether you have a vote, or not, participation has always been
welcomed, and you get to say your piece. Never have I felt that not
having a vote has made my opinion second class in any way.

> If you are one of those (N-M) candidates, what then? What do you
> believe you can do if you are not elected to the TC, and what will you
> do? (concrete examples would be good)"

I will still attend the office hours, I will still give dims grief and
say that I preferred the regular TC meetings to office hours, I will
still make time to get involved in more activities like the SWG and in
the coming year if I have an opportunity to do that, I will. work to
revive the SWG as a SIG. All of these are things (including giving
dims a hard time) are things I've been doing already. I will continue
to live by the decisions of the TC and I will continue to work to make
OpenStack a better solution for me, a user of OpenStack.

> "If you are one of the M elected candidates, the N-M candidates who
> were not elected represent a resource?

One thing that I have suggested in the past was the notion of
alternates. For good reasons it was decided not to go this route but a
similar benefit could in fact be achieved if the TC was able to tap
these candidates to take on special projects, or drive specific
initiatives. It is here that the issue of time came up; would people
not elected be able to spare the time to do these kinds of things, and
would their employers permit them the time to do it. I submit to you
that while this is a reality, if in fact employers are not able to
permit people the time to do these kinds of things if not elected, I
submit to you that the motivations for running for election are flawed
in the first place.

Today, the responsibility to run too many of our "projects" are
falling back on members of the TC, I'm thinking of Doug, Sean, Monty,
... I would try and leverage the N-M if at all possible to make for a
stronger bench of leaders in the years to come.


-amrith



On Sun, Oct 15, 2017 at 2:17 PM, Paul Belanger <pabelan...@redhat.com> wrote:
> On Sun, Oct 15, 2017 at 08:15:51AM -0400, Amrith Kumar wrote:
>> Full disclosure, I'm running for election as well. I intend to also
>> provide an answer to the question I pose here, one that I've posed
>> before on #openstack-tc in an office hours session.
>>
>> Question 1:
>>
>> "There are M open slots for the TC and there are N (>>M) candidates
>> for those open slots. This is a good problem to have, no doubt.
>> Choice, is a good thing, enthusiasm and participation are good things.
>>
>> But clearly, (N-M) candidates will not be elected.
>>
>> If you are one of those (N-M) candidates, what then? What do you
>> believe you can do if you are not elected to the TC, and what will you
>> do? (concrete examples would be good)"
>>
> ++
>
> I'd like to see (N-M) candidates continue with TC by helping support M.
> Personally, I plan on participating more in TC office hours regardless of
> results. Or even reach out to TC and ask what non-TC members 

[openstack-dev] [tc][election] Question for all candidates in TC election: What will you do if you don't win?

[Amrith Kumar]

Full disclosure, I'm running for election as well. I intend to also
provide an answer to the question I pose here, one that I've posed
before on #openstack-tc in an office hours session.

Question 1:

"There are M open slots for the TC and there are N (>>M) candidates
for those open slots. This is a good problem to have, no doubt.
Choice, is a good thing, enthusiasm and participation are good things.

But clearly, (N-M) candidates will not be elected.

If you are one of those (N-M) candidates, what then? What do you
believe you can do if you are not elected to the TC, and what will you
do? (concrete examples would be good)"

Question 2:

"If you are one of the M elected candidates, the N-M candidates who
were not elected represent a resource?

Would you look to leverage/exploit that resource, and if so, how?
(concrete examples would be good)"

-amrith

__
OpenStack Development Mailing 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][election] Question for candidates: How do you think we can make our community more inclusive?

[Amrith Kumar]

Thanks Doug, I didn't know what caused the "Welcome New Contributor"
thing show up in reviews, but that is exactly what I used to look for.

-amrith



On Fri, Oct 13, 2017 at 1:52 PM, Doug Hellmann  wrote:
> Excerpts from Amrith Kumar's message of 2017-10-13 13:32:54 -0400:
>> Flavio,
>>
>> Some months back I looked at a slide that Thierry showed at a meeting;
>> it showed contributor statistics and it showed that there were a large
>> number of contributors who made exactly 1 commit which sometimes got
>> merged, but there was a huge drop off from 1 commit to 2 commits!
>>
>> So I got to thinking about what could cause that and how one could get
>> to the second commit (once you're hooked, you are hooked!).
>>
>> To that end, I tried to give priority to first time committers; if I
>> saw a commit that said "New Contributor", I try to not only thank them
>> for it, but also be much more responsive. I hope that helped at least
>> one contributor go from 1st commit to 2nd commit.
>
> This is a great point. It's easy to find new contributors because
> we have a bot that drops a welcome message on their patch, and
> gerrit can query by reviewer:
>
> https://review.openstack.org/#/q/reviewer:%22Welcome%252C+new+contributor!%22+status:open,n,z
>
>>
>> Other than that, working (with Dims) trying to take up a number of
>> initiatives that bring new contributors to OpenStack including
>>
>> - speaking to university students (a project I proposed a while back
>> called OpenStack in the classroom[1])
>> - making presentations at Summit(s) meetups, and any other place which
>> will have us to tell people about OpenStack[2].
>> - participate (as a mentor) in the OpenStack mentorship program, the
>> Women of OpenStack program, and a myriad of other non-OpenStack
>> community development programs
>>
>> Shameless plug for Dims & my presentation at Summit in Sydney about
>> contributing to OpenStack [2].
>>
>> Thanks for the question!
>>
>> -amrith
>>
>> [1] http://openstack.markmail.org/thread/qadfotwkoj6alivj
>> [2] 
>> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/19116/getting-started-with-contributing-to-openstack-dos-and-donts
>>
>> On Fri, Oct 13, 2017 at 8:45 AM, Flavio Percoco  wrote:
>> > Greetings,
>> >
>> > Some of you, TC candidates, expressed concerns about diversity and
>> > inclusiveness
>> > (or inclusivity, depending on your taste) in your candidacy. I believe this
>> > is a
>> > broad, and some times ill-used, topic so, I'd like to know, from y'all, how
>> > you
>> > think we could make our community more inclusive. What areas would you
>> > improve
>> > first?
>> >
>> > Thank you,
>> > Flavio
>> >
>> > --
>> > @flaper87
>> > Flavio Percoco
>> >
>> > __
>> > OpenStack Development Mailing 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][election] Question for candidates: How do you think we can make our community more inclusive?

[Amrith Kumar]

Flavio,

Some months back I looked at a slide that Thierry showed at a meeting;
it showed contributor statistics and it showed that there were a large
number of contributors who made exactly 1 commit which sometimes got
merged, but there was a huge drop off from 1 commit to 2 commits!

So I got to thinking about what could cause that and how one could get
to the second commit (once you're hooked, you are hooked!).

To that end, I tried to give priority to first time committers; if I
saw a commit that said "New Contributor", I try to not only thank them
for it, but also be much more responsive. I hope that helped at least
one contributor go from 1st commit to 2nd commit.

Other than that, working (with Dims) trying to take up a number of
initiatives that bring new contributors to OpenStack including

- speaking to university students (a project I proposed a while back
called OpenStack in the classroom[1])
- making presentations at Summit(s) meetups, and any other place which
will have us to tell people about OpenStack[2].
- participate (as a mentor) in the OpenStack mentorship program, the
Women of OpenStack program, and a myriad of other non-OpenStack
community development programs

Shameless plug for Dims & my presentation at Summit in Sydney about
contributing to OpenStack [2].

Thanks for the question!

-amrith

[1] http://openstack.markmail.org/thread/qadfotwkoj6alivj
[2] 
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/19116/getting-started-with-contributing-to-openstack-dos-and-donts

On Fri, Oct 13, 2017 at 8:45 AM, Flavio Percoco  wrote:
> Greetings,
>
> Some of you, TC candidates, expressed concerns about diversity and
> inclusiveness
> (or inclusivity, depending on your taste) in your candidacy. I believe this
> is a
> broad, and some times ill-used, topic so, I'd like to know, from y'all, how
> you
> think we could make our community more inclusive. What areas would you
> improve
> first?
>
> Thank you,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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] TC Candidates: what does an OpenStack user look like?

[Amrith Kumar]

Zane, thanks for the question.

Let me answer from the perspective of an OpenStack user (I work for
Verizon) and from a developer (both now, and in the past as part of
Tesora). OpenStack has multiple different users:

- Deployers:  People who deploy OpenStack and operate a cloud environment.

- Product Companies: This is a broad collective of things like
solutions providers, distribution providers; companies that don't
operate OpenStack but write and sell software that others can operate
in their OpenStack deployment, and are participants in the OpenStack
community/ecosystem.

- End Users: People who consume OpenStack services (offered by
deployers). This is particularly important in the case of PaaS
projects (like Trove which I work on).

To me, the first (Deployers) and the third (End Users) are top of mind
because that is who we should be building for. I work in a team that
represents these two constituencies, we operate OpenStack and consume
the services of OpenStack.

Thanks,

-amrith



On Thu, Oct 12, 2017 at 12:51 PM, Zane Bitter  wrote:
> (Reminder: we are in the TC election campaigning period, and we all have the
> opportunity to question the candidates. The campaigning period ends on
> Saturday, so make with the questions.)
>
>
> In my head, I have a mental picture of who I'm building OpenStack for. When
> I'm making design decisions I try to think about how it will affect these
> hypothetical near-future users. By 'users' here I mean end-users, the actual
> consumers of OpenStack APIs. What will it enable them to do? What will they
> have to work around? I think we probably all do this, at least
> subconsciously. (Free tip: try doing it consciously.)
>
> So my question to the TC candidates (and incumbent TC members, or anyone
> else, if they want to answer) is: what does the hypothetical OpenStack user
> that is top-of-mind in your head look like? Who are _you_ building OpenStack
> for?
>
> There's a description of mine in this email, as an example:
> http://lists.openstack.org/pipermail/openstack-dev/2017-October/123312.html
>
> To be clear, for me at least there's only one wrong answer ("person who
> needs somewhere to run their IRC bouncer"). What's important in my opinion
> is that we have a bunch of people with *different* answers on the TC,
> because I think that will lead to better discussion and hopefully better
> decisions.
>
> Discuss.
>
> cheers,
> Zane.
>
> __
> OpenStack Development Mailing 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][election] Question for the candidates

[Amrith Kumar]

Clay,

Great question and one that made me think quite a bit. I believe that
while the commits in the Governance repo represent the visible actions
of the TC, the real leadership ability of the TC is often in the
actions that it inspires in people in the community. The TC is a body
that has to lead without any real authority over the individuals that
they lead, which makes it a very interesting form of leadership.

To the specific reviews, I'll pick three [1], [2] and [3]. Let me explain.

The first is a commit that I authored for the governance repository to
formalize the creation of the Stewardship Working Group (SWG). This
group then drove the discussions around the TC Vision which is the
subject of the third review. I'm very thankful for the leadership and
drive that Collette Alexander brought in getting a number of us
together in Detroit to meet and discuss where the TC was and where it
should be going. I was lucky to be one of the non-TC participants at
that meeting and worked with the group that later created the TC
vision which was also well discussed in the community.

The second is another review that I proposed that relates to the
maintenance-mode tag for projects to reflect (accurately) to deployers
and users (collectively to customers) the state of projects that are
not actively being developed.

You explicitly said that "actions speak louder ...", so let me
highlight that the reviews that I cite are ones that I either authored
or participated actively in.

Thanks for the question.

-amrith

[1] https://review.openstack.org/#/c/337895/
[2] https://review.openstack.org/#/c/449925/
[3] https://review.openstack.org/#/c/453262/

On Thu, Oct 12, 2017 at 3:42 PM, Clay Gerrard  wrote:
> I like a representative democracy.  It mostly means I get a say in which
> other people I have to trust to think deeply about issues which effect me
> and make decisions which I agree (more or less) are of benefit to the social
> groups in which I participate.  When I vote IRL I like to consider voting
> records.  Actions speak louder blah blah.
>
> To candidates:
>
> Would you please self select a change (or changes) from
> https://github.com/openstack/governance/ in the past ~12 mo or so where they
> thought the outcome or the discussion/process was particular good and
> explain why you think so?
>
> It'd be super helpful to me, thanks!
>
> -Clay
>
> __
> OpenStack Development Mailing 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][election] TC non-candidacy

[Amrith Kumar]

On Tue, Oct 10, 2017 at 7:40 PM, Monty Taylor  wrote:
> Hey everybody!
>
> I have decided not to seek reelection for the TC.
>
> I have had the honor and privilege of serving you on the TC and it's
> predecessor the PPB since the fall of 2011 (with one six month absence that
> I blame on Jay Pipes)
>
> There are a wealth of amazing people running for the TC this cycle, many of
> whom have a different genetic, cultural or geographic background than I do.
> I look forward to seeing how they shepherd our amazing community.
>

Thank you Monty for all that you've done for OpenStack all these years. It has
been wonderful working with you and I look forward to continuing that.

> I am not going anywhere. We're just getting Zuul v3 rolled out, there's a
> pile of work to do to merge and rationalize shade and openstacksdk and I
> managed to sign myself up to implement application credentials in Keystone.
> I still haven't even managed to convince all of you that Floating IPs are a
> bad idea...
>
> Thank you, from the bottom of my heart, for the trust you have placed in me.
> I look forward to seeing as many of you as I can in Sydney, Vancouver,
> Berlin and who knows where else.
>
> 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 Development Mailing 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] [kolla] [PTL] who can start the official meeting?

[Amrith Kumar]

I agree with Jeremy that we shouldn't attempt to implement technical
solutions for non-technical problems. But to that end, I'd be curious
to know what the problem was with this. In my experience it has been
an asset to have the meeting start on time even if the regular chair
is for some reason delayed.

I've benefited from that in Trove, and on at least one occasion I've
started the oslo meeting and the regular chair came in and took over a
while later.

The short log that coolsvap provided doesn't exhibit a problem, as
best as I can tell; people without bouncers sometimes do lose their
internet connection :(

-amrith



On Wed, Oct 11, 2017 at 9:55 AM, Jeremy Stanley  wrote:
> On 2017-10-11 17:51:59 +0530 (+0530), Swapnil Kulkarni (coolsvap) wrote:
>> I was attending the weekly requirements meeting when I noticed
>> someone started the kolla meeting [1] on openstack-meeting-4
>> channel. I thought we had the restrictions on the chairs, but
>> apparently there's not. Can we think about having one such
>> restriction?
>
> We don't implement technical solutions to social problems of this
> nature. If you have an issue with the person who started the kolla
> meeting in your absence, please take it up with them.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing 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] Containerizing tempest

[Chandan kumar]

Hello,

I am planning to containerizing tempest for Tripleo.
Kolla project provides tempest kolla image [1.].
On a containerized Tripleo deployment, the Kolla tempest image will be
available on undercloud and the end user should able to run tempest
from there using tempest cli.

I need some help on how to proceed:
[1.] Where to make changes in Tripleo in order to make Kolla Tempest
image available on undercloud?
[2.] Since Tempest is not a service but an application, how to expose
tempest cli without tempest cli on undercloud without entering into
tempest kolla image?

Links:
[1.] https://github.com/openstack/kolla/tree/master/docker/tempest

Thanks,

Chandan Kumar

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

[openstack-dev] [all]Tempest plugin split community goals status update

[Chandan kumar]

Hello,

Since one month is about to pass after Denver PTG.
Here is the status update on the Tempest Plugin split community goals:

List of projects which have already completed the goal:
- Barbican
- Designate
- Horizon
- Keystone
- Kuryr
- Os-win
- Sahara
- Solum
- Watcher

List of projects which are working on the goal:
- Aodh
- Cinder
- Magnum
- Manila
- Murano
- Neutron
- Neutron L2GW
- Octavia
- Senlin
- Zaqar
- Zun

Here is the detailed report on Tempest Plugin split goal status for
different projects:
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html#project-teams

Here is the list of open reviews:
https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open
Feel free to take a look.
If you have any queries related to the goal, Free to ping me on
#openstack-qa channel.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] [election] [tc] TC Candidacy

[Amrith Kumar]

I wish to submit my candidacy for election to the OpenStack Technical
Committee. I have never been elected to the Technical Committee before
but, I have never believed that being elected is a requirement to
participate in the deliberations. I have therefore been a frequent
participant and a consistent follower of the activities of the TC.

My focus on the TC would be (consistent with prior candidacies for the
TC) to make it easier for people to deploy and use OpenStack, and make
it easier for people to get involved in, participate, and contribute
to OpenStack.

I have been an active technical contributor to OpenStack for about
four years[1], involved in Trove for that entire period of time. I have
been the PTL for Trove for three cycles (Newton, Ocata and Pike). I
was reelected for Queen but at the PTG that position was transitioned
over to another member of the team[2] as I move my focus to a new DBaaS
implementation for OpenStack (tenantively named Hoard).

During these four years, I have been involved in a number of the
initiatives of the TC including most significantly the Stewardship
Working Group which began the process of writing the TC Vision
document. I attended the first of the Stewardship training sessions in
Michigan where the idea of the cross-project goals was conceived of
(by Doug Hellmann and others), an initiative that I am strongly
supportive of.

I have also been active in activities to improve the overall
participation in OpenStack, through mentorship, outreach to
educational institions. This is a key aspect of my current role,
employed at Verizon Wireless in the team that has built, and operates
one of the largest OpenStack deployments around. The team now includes
Brian Rosmaita, and Graham Hayes, and we are actively hiring more
contributors to the team.

I thank you for reading, and appreciate your vote.

[1] http://stackalytics.com/?release=all=commits_id=amrith
[2] http://openstack.markmail.org/thread/txurdd5bhbzsebtq

-amrith

__
OpenStack Development Mailing 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][election] non-candidacy for TC

[Amrith Kumar]

Steve, thanks for all you've done on the TC, and for OpenStack.

Looking forward to continuing to work with you,

-amrith


On Tue, Oct 3, 2017 at 11:05 PM, Steve Martinelli 
wrote:

> Folks, due to changes in my day job I will not be running in the next TC
> election. I still intend to contribute to OpenStack whenever possible. I
> look forward to seeing how the community continues to grow, change, and
> approach new challenges.
>
> I'd like to encourage others to step up to the challenge and run. It's an
> excellent experience to learn more about yourself, OpenStack, and
> governance of a large open source project.
>
> Thanks for your time,
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Disk Image Builder for redhat 7.4

[Amrith Kumar]

As Tony says, there's a base image that you can use for RHEL 7.4. Yes, you
can install Oracle onto the image using dib.

In saying that I only mean that it is possible. I make no statement about
the supportability of that solution by any vendors involved.

To do it, you would create elements (the basic unit of abstraction) in dib.

You would, for example have an element with an install.d phase that would
install the Oracle package just the same way you would if you did it by
hand.

Then you'd invoke a command like

disk-image-create rhel7 vm your-oracle-element -o oracle-image.qcow2 ...
maybe a couple of other options for good measure ...




-amrith


On Tue, Sep 26, 2017 at 6:43 PM, Tony Breeds 
wrote:

> On Tue, Sep 26, 2017 at 10:19:45PM +0530, Amit Singla wrote:
> > Hi,
> >
> > Could you tell me how I can create qcow2 image for rhel 7.4 by disk image
> > builder and I want also to install oracle 12.2 on that image with DIB. Is
> > it possible?
>
> For the RHEL 7.4 side of things there is a rhel7 dib target, that starts
> with a guest image supplied by Red Hat and customises it for your needs.
>
> No idea about oracle 12.2.
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] patches for simple typo fixes

[Amrith Kumar]

Sean,

Each fix is a valid change, in and of itself. But what kind of lazy person
would fix (in three patches) the exact same thing, in three places in a
single project?

Or which person would submit the exact same kind of patch multiple times to
change URL's from http:// to https:// in places which are (literally)
comments in the code?

Or submit multiple changes to fix something that is a python stylistic
thing, not enforced by pep8 or some project wide checks for style?
Typically, when I see changes like this, I ask the submitter to make a
corresponding change to the accepted tests (enable an otherwise disabled
change, and show that the tests pass for the whole project). Well, that's
real work and the change gets abandoned.

Those are the kinds of (for lack of a PC word) bad behavior that I think we
should, as a community, reject.




-amrith


On Mon, Sep 25, 2017 at 8:24 AM, Sean Dague  wrote:

> On 09/25/2017 07:56 AM, Chris Dent wrote:
> > On Fri, 22 Sep 2017, Paul Belanger wrote:
> >
> >> This is not a good example of encouraging anybody to contribute to the
> >> project.
> >
> > Yes. This entire thread was a bit disturbing to read. Yes, I totally
> > agree that mass patches that do very little are a big cost to
> > reviewer and CI time but a lot of the responses sound like: "go away
> > you people who don't understand our special culture and our
> > important work".
> >
> > That's not a good look.
> >
> > Matt's original comment is good in and of itself: I saw a thing,
> > let's remember to curtail this stuff and do it in a nice way.
> >
> > But then we generate a long thread about it. It's odd to me that
> > these threads sometimes draw more people out then discussions about
> > actually improving the projects.
> >
> > It's also odd that if OpenStack were small and differently
> > structured, any self-respecting maintainer would be happy to see
> > a few typo fixes and generic cleanups. Anything to push the quality
> > forward is nice. But because of the way we do review and because of
> > the way we do CI these things are seen as expensive distractions[1].
> > We're old and entrenched enough now that our tooling enforces our
> > culture and our culture enforces our tooling.
> >
> > [1] Note that I'm not denying they are expensive distractions nor
> > that they need to be managed as such. They are, but a lot of that
> > is on us.
>
> I was trying to ignore the thread in the hopes it would die out quick.
> But torches and pitchforks all came out from the far corners, so I'm
> going to push back on that a bit.
>
> I'm not super clear why there is always so much outrage about these
> patches. They are fixing real things. When I encounter them, I just
> approve them to get them merged quickly and not backing up the review
> queue, using more CI later if they need rebasing. They are fixing real
> things. Maybe there is a CI cost, but the faster they are merged the
> less likely someone else is to propose it in the future, which keeps
> down the CI cost. And if we have a culture of just fixing typos later,
> then we spend less CI time on patches the first time around with 2 or 3
> iterations catching typos.
>
> I think the concern is the ascribed motive for why people are putting
> these up. That's fine to feel that people are stat padding (and that too
> many things are driven off metrics). But, honestly, that's only
> important if we make it important. Contributor stats are always going to
> be pretty much junk stats. They are counting things to be the same which
> are wildly variable in meaning (number of patches, number of Lines of
> Code).
>
> My personal view is just merge things that fix things that are wrong,
> don't care why people are doing it. If it gets someone a discounted
> ticket somewhere, so be it. It's really not any skin off our back in the
> process.
>
> If people are deeply concerned about CI resources, step one is to get
> some better accounting into the existing system to see where resources
> are currently spent, and how we could ensure that time is fairly spread
> around to ensure maximum productivity by all developers.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] patches for simple typo fixes

[Amrith Kumar]

Sean, I quantified it in 2016 for some of the patches that came in to
Trove; approximately 130 hours of CI time per patch given the number of
hacks that the person took before even getting pep8 to run.

Close to a release boundary, that had very bad results on an already
fragile Trove gate.


-amrith


On Mon, Sep 25, 2017 at 9:42 AM, Sean Dague  wrote:

> On 09/25/2017 09:28 AM, Doug Hellmann wrote:
> 
> > I'm less concerned with the motivation of someone submitting the
> > patches than I am with their effect. Just like the situation we had
> > with the bug squash days a year or so ago, if we had a poorly timed
> > set of these trivial patches coming in at our feature freeze deadline,
> > it would be extremely disruptive. So to me the fact that we're
> > seeing them in large batches means we have people who are not fully
> > engaged with the community and don't understand the impact they're
> > having. My goal is to reach out and try to improve that engagement,
> > and try to help them become more fully constructive contributors.
>
> I think that quantifying how big that impact is would be good before
> deciding it needs to be a priority to act upon. There are lots of things
> that currently swamp our system, and on my back of the envelope math and
> spot checking on resources used, these really aren't a big concern.
>
> But it's harder to see that until we really start accounting for CI time
> by project / person, and what kinds of things really do consume the system.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[Amrith Kumar]

Thanks Matt for highlighting this (again). Please also see

http://openstack.markmail.org/thread/iaqsha7hbiitwqe2
http://markmail.org/thread/k62gcehxg6gv5ep4
http://markmail.org/thread/n753w3wljii67yug

When can we take some concrete action to stop these same kinds of things
from coming up again and again?



-amrith


On Fri, Sep 22, 2017 at 8:10 AM, Tom Barron  wrote:

>
>
> On 09/21/2017 10:21 PM, Matt Riedemann wrote:
> > I just wanted to highlight to people that there seems to be a series of
> > garbage patches in various projects [1] which are basically doing things
> > like fixing a single typo in a code comment, or very narrowly changing
> > http to https in links within docs.
> >
> > Also +1ing ones own changes.
> >
> > I've been trying to snuff these out in nova, but I see it's basically a
> > pattern widespread across several projects.
> >
> > This is the boilerplate comment I give with my -1, feel free to employ
> > it yourself.
> >
> > "Sorry but this isn't really a useful change. Fixing typos in code
> > comments when the context is still clear doesn't really help us, and
> > mostly seems like looking for padding stats on stackalytics. It's also a
> > drain on our CI environment.
> >
> > If you fixed all of the typos in a single module, or in user-facing
> > documentation, or error messages, or something in the logs, or something
> > that actually doesn't make sense in code comments, then maybe, but this
> > isn't one of those things."
> >
> > I'm not trying to be a jerk here, but this is annoying to the point I
> > felt the need to say something publicly.
> >
> > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> >
>
> The boilerplate is helpful but have we considered putting something
> along these lines in official documentation so that reviewers can just
> point to it? It should then be clear to all that negative reviews on
> these grounds are not simply a function of the individual reviewer's
> judgment or personality.
>
> FWIW I think it is better not to attribute motivation in these cases.
> Perhaps the code submitter is trying to pad stats, but perhaps they are
> just a new contributor trying to learn the process with a "harmless"
> patch, or just a compulsive clean-upper who hasn't thought through the
> costs in reviewer time and CI resources.
>
>
>
>
> __
> OpenStack Development Mailing 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] [trove] Please welcome Samuel Matzek, Luke Browning and Manoj Kumar to the Trove core team

[Amrith Kumar]

​Pl​
ease join me in welcoming Samuel Matzek, Luke Browning and Manoj Kumar to
the Trove core team.


-amrith
__
OpenStack Development Mailing 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]how to save time of creating instance?

[Amrith Kumar]

The amount of time taken to create a trove instance (or cluster) is largely
related to how long it takes to create a nova instance of the same size.
So, how long does it take to create a nova instance of the same size on
your system?

Does your trove image install the database statically into the image, or
will it install the database on the fly?


-amrith


2017-09-06 0:01 GMT-07:00 王俊 :

> Hi:
>
> it will take 8 minutes to create a mysql instance, and will take 16
> minutes to create mysql cluster, which have one master and one slave
>
> 保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
>
> __
> OpenStack Development Mailing 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] [trove][tc][all] Trove restart - next steps

[Amrith Kumar]

Tim,

 

Sorry for the delay getting back to you.

 

Different database vendors give you different levels of isolation within your 
database itself, and making a database truly multi-tenant was something that we 
did not want to get into. The discussion centered around the benefits of such a 
use-case and thing that drove the decision to not go down the path of 
multi-tenancy was that if Trove provided a VM per database instance, 
implementing multi-tenancy is something that a trove user can in fact do for 
themselves.

 

At the time when we thought about this, the critical things on the horizon were 
to implement replication and clustering, and add support for more capabilities 
and databases. Therefore multi-tenancy did not rise very far on the list. 

 

Looking at it again, I like the idea but again think there are higher priority 
things I’d like to focus on first. In digging us out of the current ditch that 
we are in, multi-tenancy may not be the thing that would materially benefit the 
project.

 

But, we shall discuss in a week or so at PTG.

 

--

Amrith Kumar
amrith.ku...@gmail.com <mailto:amrith.ku...@gmail.com> 



 

From: Tim Bell [mailto:tim.b...@cern.ch] 
Sent: Wednesday, August 16, 2017 1:45 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

 

 

Thanks for the info.

 

Can you give a summary for reasons for why this was not a viable approach?

 

Tim

 

From: Amrith Kumar <amrith.ku...@gmail.com <mailto:amrith.ku...@gmail.com> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 15 August 2017 at 23:09
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

 

Tim,

This is an idea that was discussed at a trove midcycle a long time back (Juno 
midcycle, 2014). It came up briefly in the Kilo midcycle as well but was 
quickly rejected again.

I've added it to the list of topics for discussion at the PTG. If others want 
to add topics to that list, the etherpad is at 
https://etherpad.openstack.org/p/trove-queens-ptg​

 

Thanks!


-amrith

 

On Tue, Aug 15, 2017 at 12:43 PM, Tim Bell <tim.b...@cern.ch 
<mailto:tim.b...@cern.ch> > wrote:

One idea I found interesting from the past discussion was the approach that the 
user need is a database with a connection string.

 

How feasible is the approach where we are provisioning access to a multi-tenant 
database infrastructure rather than deploying a VM with storage and installing 
a database?

 

This would make the service delivery (monitoring, backup, upgrades) in the 
responsibility of the cloud provider rather than the end user. Some 
quota/telemetry would be needed to allocate costs to the project.

 

Tim

 

From: Amrith Kumar <amrith.ku...@gmail.com <mailto:amrith.ku...@gmail.com> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 15 August 2017 at 17:44
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org> >
Subject: [openstack-dev] [trove][tc][all] Trove restart - next steps

 

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

   - Fix the gate

   - Update currently failing jobs, create xenial based images
   - Fix gate jobs that have gone stale (non-voting, no one paying
 attention)

   - Bug triage

   - Bugs in launchpad are really out of date, assignments to
 people who are no longer active, bugs that are really support
 requests, etc.,
   - Prioritize fixes for Queens and beyond

   - Get more active rev

Re: [openstack-dev] Future Trove development

[Amrith Kumar]

Luke, please see inline below.

--
Amrith Kumar
mailto:amrith.ku...@gmail.com


>From: Luke Browning [mailto:lukebrown...@us.ibm.com] 
>Sent: Thursday, August 31, 2017 1:00 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] Future Trove development
>
>Amrith, 
>
>See answers to your questions below.
>
>Cheers,
>Luke  
>
>>>
>>> I understand that the Trove project will be going into maintenance mode
>>> soon. I have a number of Trove related enhancements and bug fixes that I
>>> would like to submit to the community, but I don't know if they would be
>>> considered given that the project is going into maintenance mode. Please
>>> elaborate on what you mean by maintenance mode.
>>>
>>
>> See: https://review.openstack.org/#/c/488947/
>>
>> It is not a foregone conclusion that the project will go into maintenance
>> mode. Thierry and I (for example) are not convinced that this is the right
>> course of action, but if there are no offers to contribute to the project,
>> it may be a decision by default.
>>
>> Do you subscribe to the OpenStack-dev mailing list. Please also see
>> http://openstack.markmail.org/thread/4p6gp263fei4mbru
>>
>> Finally, for a description of what maintenance mode means, please refer:
>> https://governance.openstack.org/tc/reference/tags/status_ma
>> intenance-mode.html
>>
>>>
>>>
>>> Would Trove be updated to support new OpenStack versions?
>>>
>> Would support be provided for Trove gate testing?
>>>
>> Would elements be enhanced to support Xenial and newer versions of
>>> databases?
>>>
>> Is there a time limit associated with maintenance mode? For example, would
>>> it remain in effect for a year or two after the new stuff is released?
>>>
>>> For the four questions above, I direct your attention to the definition
>> of the maintenance-mode tag (https://governance.openstack/.
>> org/tc/reference/tags/status_maintenance-mode.html) and remind you that
>> support for different versions from the community, for gate testing and for
>> elements is dependent on people participating (and their employers allowing
>> them to do this). At this point, I have no one who has stepped up to do
>> this in any significant way. There are a couple of people from China Mobile
>> who want to help but who are largely in the weeds, trying to fix this and
>> that bug but have no idea what Trove is all about. IBM has a core reviewer
>> on the project (Mariam is copied on this email). I am happy that she's
>> able to devote what time she can to the project but absent competent
>> reviewers, whether your changes ever get merged or not remains an
>> interesting question. Since you will be contributing elements and propose
>> to contribute a tool, will you be (or will IBM be) offering to support it?
>>
>>  Let me provide some back ground on my code changes, so you will have a
>> better idea of what might be submitted in a patch.
>>
>>>
>>> I have written a fully automated command that creates a virtual guest
>>> image based on Ubuntu 16.04 containing a user specified version of a
>>> database. The user's selection is validated against an internal list of
>>> databases built into the tool. Once validated, the tool creates the image,
>>> registers it with Glance, and then creates a Trove Datastore definition for
>>> it. This is done in a single command invocation that typically takes about
>>> 25 minutes to complete. For some of the databases, it takes considerably
>>> longer (2 hours for mongodb) as I have to compile source code. The guest
>>> image that is produced is complete from a Trove perspective. It includes
>>> the Cloud specific trove-guestagent.conf file and SSH public keys for the
>>> DBA and OpenStack controller nodes.
>>>
>>> What mechanism does it use to develop the image? is it diskimage-builder
>> or some other?
>
>Yes, diskimage-builder and Trove elements
>
>>
>>
>> Is there something the matter with the existing tool that exists, it
>> already works, it does more than just build an image, and it is already
>> integrated in the gate. Why not use that?
>


I should have said this before (like in the last reply) and I may not have, but 
I am broadly in favor of the approach you proposed (I did look briefly at the 
repository that you provided). The place(s) where I had reservations relate 
primarily to how this new tool would interface/interact with the existing 
Trove. More details about that below.

[openstack-dev] [all] Queens Goal for Tempest Plugin Split

[Chandan kumar]

Hello,

Since Tempest Plugin Split[0] is added as Queen Goal and most of the
projects have already started the work.
It is just a heads up. If you are going to Denver PTG.
Andreaf is doing a walkthrough on migrating a plugin from in-tree to
own repo [1]. Do not forget to attend this.
The OpenStack-QA team will be also hosting sprints in order to help on
splitting tempest plugins. If you are volunteering for the
same, take some time to participate in that.
If you have any queries or any help you need on this, I will be
available on #openstack-qa channel, Feel free to ping me.
My IRC nick is chandankumar.

After PTG, I will start sneaking in project's weekly meeting to help
the project team to achieve this goal.
One last thing, if you are volunteering for this goal, don't forgot to
update the tempest plugin split wiki page[2].

Links:
[0]. https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[1]. https://etherpad.openstack.org/p/qa-queens-ptg
[2]. https://wiki.openstack.org/wiki/Tempest_plugin_split_status

Thanks,

Chandan Kumar

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

Re: [openstack-dev] [openstack][oslo][all] Clean up oslo deprecated stuff !

[Amrith Kumar]

GCB, Ken, thanks for doing this. It will help immensely.


-amrith



On Wed, Aug 23, 2017 at 9:32 AM, Ken Giusti  wrote:

>
>
> On Tue, Aug 22, 2017 at 3:24 AM, ChangBo Guo  wrote:
>
>> Hi ALL,
>>
>> We discussed a little about how to avoid breaking consuming projects'
>> gate in oslo weekly meeting last week.  The easy improvement is that clean
>> up deprecated stuff in oslo at the beginning of Queens.  I collected
>> deprecated stuff  in [1].  This need Oslo team and other team work
>> toghether. I think we can start the work when cycle Queens is open. I
>> also reserved a room in PTG
>> for 2 hours to do hacking.[2]
>>
>>
>> [1] https://etherpad.openstack.org/p/oslo-queens-tasks
>> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>>
>> --
>> ChangBo Guo(gcb)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> I've gone through oslo.messaging and have updated the etherpad [1] with a
> few more entries.  I've opened launchpad bugs where appropriate, adding the
> oslo-debt-cleanup tag to each for good measure.
>
> The original list included a few items that as best I can tell were not
> tagged as deprecated via debtcollector until Pike. IIUC we can't remove
> those in Queens, correct?
>
> --
> Ken Giusti  (kgiu...@gmail.com)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Future Trove development

[Amrith Kumar]

​The email thread below is an one that I have been having with Luke and
some others at IBM who have been working on Trove.

I feel that these kind(s) of conversations are better had in the mailing
list, and in replying to this email, I let the participants know that
absent any objections, I would like to continue this conversation on the
ML. Hearing nothing in the past two days, I am forwarding this to the ML.

-amrith
​


> On Thu, Aug 17, 2017 at 4:24 PM, Luke Browning 
> wrote:
>
>> Hi Amrith,
>>
>> I understand that the Trove project will be going into maintenance mode
>> soon. I have a number of Trove related enhancements and bug fixes that I
>> would like to submit to the community, but I don't know if they would be
>> considered given that the project is going into maintenance mode. Please
>> elaborate on what you mean by maintenance mode.
>>
>
> ​See: https://review.openstack.org/#/c/488947/
>
> It is not a foregone conclusion that the project will go into maintenance
> mode. Thierry and I (for example) are not convinced that this is the right
> course of action, but if there are no offers to contribute to the project,
> it may be a decision by default.
>
> Do you subscribe to the OpenStack-dev mailing list​. Please also see
> http://openstack.markmail.org/thread/4p6gp263fei4mbru
>
> Finally, for a description of what maintenance mode means, please refer:
> https://governance.openstack.org/tc/reference/tags/status_ma
> intenance-mode.html
>
>>
>>
>> Would Trove be updated to support new OpenStack versions?
>>
> Would support be provided for Trove gate testing?
>>
> Would elements be enhanced to support Xenial and newer versions of
>> databases?
>>
> Is there a time limit associated with maintenance mode? For example, would
>> it remain in effect for a year or two after the new stuff is released?
>>
>> ​For the four questions above, I direct your attention to the definition
> of the maintenance-mode tag (https://governance.openstack.
> org/tc/reference/tags/status_maintenance-mode.html) and remind you that
> support for different versions from the community, for gate testing and for
> elements is dependent on people participating (and their employers allowing
> them to do this). At this point, I have no one who has stepped up to do
> this in any significant way. There are a couple of people from China Mobile
> who want to help but who are largely in the weeds, trying to fix this and
> that bug but have no idea what Trove is all about. IBM has a core reviewer
> on the project ​(Mariam is copied on this email). I am happy that she's
> able to devote what time she can to the project but absent competent
> reviewers, whether your changes ever get merged or not remains an
> interesting question. Since you will be contributing elements and propose
> to contribute a tool, will you be (or will IBM be) offering to support it?
>
>  Let me provide some back ground on my code changes, so you will have a
> better idea of what might be submitted in a patch.
>
>>
>> I have written a fully automated command that creates a virtual guest
>> image based on Ubuntu 16.04 containing a user specified version of a
>> database. The user's selection is validated against an internal list of
>> databases built into the tool. Once validated, the tool creates the image,
>> registers it with Glance, and then creates a Trove Datastore definition for
>> it. This is done in a single command invocation that typically takes about
>> 25 minutes to complete. For some of the databases, it takes considerably
>> longer (2 hours for mongodb) as I have to compile source code. The guest
>> image that is produced is complete from a Trove perspective. It includes
>> the Cloud specific trove-guestagent.conf file and SSH public keys for the
>> DBA and OpenStack controller nodes.
>>
>> ​What mechanism does it use to develop the image? is it diskimage-builder
> or some other?
>
>
> Is there something the matter with the existing tool that exists, it
> already works, it does more than just build an image, and it is already
> integrated in the gate. Why not use that?​
>
> ​
> This approach is nice (having a full guest image with the guest agent and
> all that but as you observe, it takes about 2 hours per build and from a
> developers perspective, this is a pain.
>
> I assume that the tool is therefore for production use cases.
>
> Could the elements that you have developed be used with the existing tool
> or is your tool a complete replacement for the one that already exists?​
>
> ​Is there some reason that this tool was not developed in the open, using
> the normal open development process?
>
> There are ways to accelerate the compiling of source code and such through
> the use of image layers (if you are using DIB). I have elements and code
> that will build most of the trove elements in minutes and I'm waiting to
> see whether there is any point in contributing them to the upstream or not,
> at this point. I could show 

Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

[Amrith Kumar]

Tim,

This is an idea that was discussed at a trove midcycle a long time back
(Juno midcycle, 2014). It came up briefly in the Kilo midcycle as well but
was quickly rejected again.

I've added it to the list of topics for discussion at the PTG. If others
want to add topics to that list, the etherpad is at
https://etherpad.openstack.org/p/trove-queens-ptg​

Thanks!

-amrith



On Tue, Aug 15, 2017 at 12:43 PM, Tim Bell <tim.b...@cern.ch> wrote:

> One idea I found interesting from the past discussion was the approach
> that the user need is a database with a connection string.
>
>
>
> How feasible is the approach where we are provisioning access to a
> multi-tenant database infrastructure rather than deploying a VM with
> storage and installing a database?
>
>
>
> This would make the service delivery (monitoring, backup, upgrades) in the
> responsibility of the cloud provider rather than the end user. Some
> quota/telemetry would be needed to allocate costs to the project.
>
>
>
> Tim
>
>
>
> *From: *Amrith Kumar <amrith.ku...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Tuesday, 15 August 2017 at 17:44
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [trove][tc][all] Trove restart - next steps
>
>
>
> Now that we have successfully navigated the Pike release and branched
> the tree, I would like to restart the conversation about how to revive
> and restart the Trove project.
>
> Feedback from the last go around on this subject[1] resulted in a
> lively discussion which I summarized in [2]. The very quick summary is
> this, there is interest in Trove, there is a strong desire to maintain
> a migration path, there is much that remains to be done to get there.
>
> What didn't come out of the email discussion was any concrete and
> tangible uptick in the participation in the project, promises
> notwithstanding.
>
> There have however been some new contributors who have been submitting
> patches and to help channel their efforts, and any additional
> assistance that we may receive, I have created the (below) list of
> priorities for the project. These will also be the subject of
> discussion at the PTG in Denver.
>
>- Fix the gate
>
>- Update currently failing jobs, create xenial based images
>- Fix gate jobs that have gone stale (non-voting, no one paying
>  attention)
>
>- Bug triage
>
>- Bugs in launchpad are really out of date, assignments to
>  people who are no longer active, bugs that are really support
>  requests, etc.,
>- Prioritize fixes for Queens and beyond
>
>- Get more active reviewers
>
>- There seems to still be a belief that 'contributing' means
>  'fixing bugs'. There is much more value in actually doing
>  reviews.
>- Get at least a three member active core review team by the
>  end of the year.
>
>- Complete Python 3 support
>
>   - Currently not complete; especially on the guest side
>
>- Community Goal, migrate to oslo.policy
>
>- Anything related to new features
>
> This is clearly an opinionated list, and is open to change but I'd
> like to do that based on the Agile 'stand up' meeting rules. You know, the
> chicken and pigs thing :)
>
> So, if you'd like to get on board, offer suggestions to change this
> list, and then go on to actually implement those changes, c'mon over.
>
> -amrith
>
>
>
> [1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
> [2] http://markmail.org/message/gfqext34xh5y37ir
>
>
> __
> OpenStack Development Mailing 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] [trove][tc][all] Trove restart - next steps

[Amrith Kumar]

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

   - Fix the gate

   - Update currently failing jobs, create xenial based images
   - Fix gate jobs that have gone stale (non-voting, no one paying
 attention)

   - Bug triage

   - Bugs in launchpad are really out of date, assignments to
 people who are no longer active, bugs that are really support
 requests, etc.,
   - Prioritize fixes for Queens and beyond

   - Get more active reviewers

   - There seems to still be a belief that 'contributing' means
 'fixing bugs'. There is much more value in actually doing
 reviews.
   - Get at least a three member active core review team by the
 end of the year.

   - Complete Python 3 support

  - Currently not complete; especially on the guest side

   - Community Goal, migrate to oslo.policy

   - Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the
chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.

-amrith



[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir
__
OpenStack Development Mailing 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] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

[Mohan Kumar]

Hi Rajeev,

No , We haven't started any design .

Let me know If I can help you anywhere . We can collaborate on this :)

Thanks.,
Mohankumar.N



On Tue, Aug 8, 2017 at 12:15 PM, rajeev.satyanaray...@wipro.com <
rajeev.satyanaray...@wipro.com> wrote:

> Hi MohanKumar,
>
>
>
> Thanks for the reply.
>
>
>
> Is the design part for the “OAM Operation Manager for SFC” done? What is
> the approach being used to monitor the SFC? If the design is already done,
> I would like to contribute in implementing it. Please provide your comments.
>
>
>
> Thanks and Regards,
>
> Rajeev
>
>
>
> *From:* Mohan Kumar [mailto:nmohankumar1...@gmail.com]
> *Sent:* Friday, July 28, 2017 1:32 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Cc:* Rajeev Satyanarayana (MFG & Tech) <rajeev.satyanaray...@wipro.com>
> *Subject:* ** Newsletter/Marketing email** Re: [openstack-dev]
> [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC
>
>
>
> ** This mail has been sent from an external source. Treat hyperlinks and
> attachments in this email with caution**
>
> Hi Rajeev,
>
>
>
> The Chain Monitoring is the missing piece in networking-sfc . Vikram and
> myself were discussed to introduce "SFC Manager" [1] (basically OAM tool )
> few cycle before.
>
>
>
> It'll continuously monitor an existing SFC chain,  when any SF VM goes
> down or any packet drop. It'll trigger alert and capture corresponding logs
> . But we haven't started any implementation on this. Feel free to discuss
> with community, IMO  this feature will be great addition to networking-sfc
>
>
>
> [1]  https://bugs.launchpad.net/networking-sfc/+bug/1513368
>
> <https://clicktime.symantec.com/a/1/oyvdp2ozE_Pe2sKTM51_kVGy1ODcQYS_L50v9C-IyKo=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D=https%3A%2F%2Fbugs.launchpad.net%2Fnetworking-sfc%2F%2Bbug%2F1513368>
>
>
>
> IRC: #networking-sfc
>
> Weekly Meeting:  https://wiki.openstack.org/wiki/Meetings/
> ServiceFunctionChainingMeeting
> <https://clicktime.symantec.com/a/1/6dNKaHpOkefxWGyCJEXAIE-cQCSPzu0gOs-V_OdWGO4=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FMeetings%2FServiceFunctionChainingMeeting>
>
>
>
> Thanks.,
>
> Mohankumar.N
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jul 27, 2017 at 11:30 AM, rajeev.satyanaray...@wipro.com <
> rajeev.satyanaray...@wipro.com> wrote:
>
> Hi Igor/Cathy/Gord,
>
>
>
> Sorry for the delay in replying.
>
>
>
> As part of monitoring the SFC, I think maintaining the details of “Number
> of flows assigned to a given SFC”, “Number of packets/bytes dropped/hit due
> to the policies at each Service Function entry/exit points or for the
> entire SFC” would be good to start with. I feel based on some of these
> details, an operator can know how much the virtual switch is loaded and
> take a call on whether to add a new SFC, or it could even help during
> debugging which service function has exactly caused the disruption to SFC.
>
> As a first step, I think it would be good to add meters to provide “number
> of packets/bytes hit due to policy at the ingress and egress of the entire
> SFC” and to realize that, we would need to add specific pollsters. We can
> use neutron_client API to fetch the ingress and egress port details and
> fetch the corresponding flows for those specific ports(also get flow_infos
> from flow_classifier and then use them to dump_flows matching those
> flow_infos) and fetch the no.of packets hit due to policy from them.
>
>
>
> I have just mentioned my idea on this. Can I please know your opinion on
> this and provide your comments?
>
>
>
> Thanks and Regards,
>
> Rajeev.
>
> The information contain

[openstack-dev] [networking-sfc] Add extension to DB UT

[Vikash Kumar]

Hi All,

 I have added tap extension for https://blueprints.launchpad.
net/networking-sfc/+spec/sfc-tap-port-pair.

 I wanted to add extension for DB validation. Where should i add the
extension ? I tried adding extension here:

https://github.com/openstack/networking-sfc/blob/master/
networking_sfc/tests/unit/db/test_sfc_db.py#L281

  but seems thats not working.


I have validated the extension on devstack setup and it works as
expected.

   Any pointers ?

Regards,
Vikash
__
OpenStack Development Mailing 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][performance] Proposing tail-based sampling in OSProfiler

[Rajul Kumar]

>As far as I understand the idea of continuous tracing is to collect as few
as possible metrics to get insights of the request (not all tracepoints).
>If you keep only API, RPC and Driver calls it is going to
drastically reduce amount of metrics collected.

Exactly, this is also one of the goals to have continuous tracing in place
i.e. to have minimal tracepoints active and increase the granularity to
learn more information or pin down the problem.

>I'll try to elaborate my points. For monitoring perspective it's going to
be super beneficial to have continuous tracing and I fully support the
effort. However, it won't help community too much to fix the real problems
in architecture (in my opinion it's too late), for example creating VM
performs ~400 DB requests... and yep this is going to be slow, and now
what? how can you fix that?..

Thanks. Monitoring is the major goal here. It's more focused on the user
and operational experience than the developer community.
Integrating this with services like rally may help the operations people
identify the hot spots and bottlenecks in the system. Automating this may
help with finding the anomalies in the system as one of many other usages.
Developers may get to know the impact the changes will make on the current
system across various services that interact. However, I totally agree that
it won't make any changes to the current architecture. It will just help to
set the baseline to further changes.

Thanks
Rajul


On Fri, Aug 4, 2017 at 4:24 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:

> Ilya,
>
> Continuous tracing is a cool story, but before proceeding it would be good
>> to estimate the overhead. There will be an additional delay introduced by
>> OSProfiler library itself and delay caused by events transfer to consumer.
>> OSProfiler overhead is critical to minimize. E.g. VM creation produces >1k
>> events, which gives almost 2 times performance penalty in DevStack. Would
>> be definitely nice to have the same test run on real environment --
>> something that Performance Team could help with.
>
>
> As far as I understand the idea of continuous tracing is to collect as few
> as possible metrics to get insights of the request (not all tracepoints).
> If you keep only API, RPC and Driver calls it is going to
> drastically reduce amount of metrics collected.
>
> As well, one of the things that should be done is sending the metrics in
> bulk after the request in async way, that way we won't slow down UX and
> won't add too much load on underlaying infrastructure.
>
>
> Rajul,
>
> ICYMI, Boris is father of OSprofiler in OpenStack [1]
>>
>>> This is why I was excited to get the first response from him and curious
>>> on his stand. Really looking forward to get more on this from him. Also,
>>> Josh's response on other Tracing thread peeked my curiosity further.
>>
>>
> I'll try to elaborate my points. For monitoring perspective it's going to
> be super beneficial to have continuous tracing and I fully support the
> effort. However, it won't help community too much to fix the real problems
> in architecture (in my opinion it's too late), for example creating VM
> performs ~400 DB requests... and yep this is going to be slow, and now
> what? how can you fix that?..
>
> Best regards,
> Boris Pavlovic
>
>
>
> On Fri, Aug 4, 2017 at 1:12 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
> wrote:
>
>> Hi Vinh
>>
>> For the `agent idea`, I think it is very good.
>>
>> However, in OpenStack, that idea may be really hard for us.
>>
>> The reason is the same with what Boris think.
>>
>>
>> Thanks. We did a poc and working to integrate it with OSProfiler without
>> affecting any of the services.
>> I understand this will be difficult.
>>
>> For tail-based and adaptive sampling, it is another story.
>>
>> Exactly. This needs some major changes. We will need this if we look to
>> have an effective tracing and any kind of automated analysis of the system.
>>
>> However, in naïve way, we can use sampling abilities from other
>> OpenTracing compatible tracers
>>
>> such as Uber Jaeger, Appdash, Zipkin (has an open pull request), LighStep
>> … by making OSprofiler
>>
>> compatible with OpenTracing API.
>>
>> I agree. Initially, this can be done.
>> However, the limitations of traces they generate is another story and
>> working to come up with another blueprint on that.
>>
>> ICYMI, Boris is father of OSprofiler in OpenStack [1]
>>
>> This is why I was excited to get the first response from him and curious
>> on his stand. Really looking forward to get more on this from him. 

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

[Rajul Kumar]

Hi Vinh

For the `agent idea`, I think it is very good.

However, in OpenStack, that idea may be really hard for us.

The reason is the same with what Boris think.


Thanks. We did a poc and working to integrate it with OSProfiler without
affecting any of the services.
I understand this will be difficult.

For tail-based and adaptive sampling, it is another story.

Exactly. This needs some major changes. We will need this if we look to
have an effective tracing and any kind of automated analysis of the system.

However, in naïve way, we can use sampling abilities from other OpenTracing
compatible tracers

such as Uber Jaeger, Appdash, Zipkin (has an open pull request), LighStep …
by making OSprofiler

compatible with OpenTracing API.

I agree. Initially, this can be done.
However, the limitations of traces they generate is another story and
working to come up with another blueprint on that.

ICYMI, Boris is father of OSprofiler in OpenStack [1]

This is why I was excited to get the first response from him and curious on
his stand. Really looking forward to get more on this from him. Also,
Josh's response on other Tracing thread peeked my curiosity further.

Thanks
Rajul




On Thu, Aug 3, 2017 at 10:04 PM, vin...@vn.fujitsu.com <
vin...@vn.fujitsu.com> wrote:

> Hi Rajul,
>
>
>
> For the `agent idea`, I think it is very good.
>
> However, in OpenStack, that idea may be really hard for us.
>
> The reason is the same with what Boris think.
>
>
>
> For the sampling part, head-based sampling can be implemented in
> OSprofiler.
>
> For tail-based and adaptive sampling, it is another story.
>
> However, in naïve way, we can use sampling abilities from other
> OpenTracing compatible tracers
>
> such as Uber Jaeger, Appdash, Zipkin (has an open pull request), LighStep
> … by making OSprofiler
>
> compatible with OpenTracing API.
>
>
>
> ICYMI, Boris is father of OSprofiler in OpenStack [1]
>
>
>
> [1] https://specs.openstack.org/openstack/oslo-specs/specs/
> mitaka/osprofiler-cross-service-project-profiling.html
>
>
>
> Best regards,
>
>
>
> Vinh Nguyen Trong
>
> PODC – Fujitsu Vietnam Ltd.
>
>
>
> *From:* Rajul Kumar [mailto:kumar.r...@husky.neu.edu]
> *Sent:* Friday, 04 August, 2017 03:49
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [oslo][performance] Proposing tail-based
> sampling in OSProfiler
>
>
>
> Hi Boris
>
>
>
> That is a point of concern.
>
> Can you please direct to any of those?
>
>
>
> Anyways, we don't have anything in place for OpenStack yet.
>
> Now, either we pick another tracing solution like Zipkin, Jaeger etc.
> which have their own limitations OR enhance OSProfiler.
>
> We pick the later as it's most native and better coupled with OpenStack as
> of now.
>
> I understand that we may be blocked by these issues. However, I feel it'll
> be better to fight with OSProfiler than anything else till we come up with
> something better :)
>
>
>
> Thanks
>
> Rajul
>
>
>
>
>
>
>
> On Thu, Aug 3, 2017 at 4:01 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
>
> Rajul,
>
>
>
> May I ask why you think so?
>
>
>
> Exposed by OSprofiler issues are going to be really hard to fix in current
> OpenStack architecture.
>
>
>
> Best regards,
>
> Boris Pavlovic
>
>
>
> On Thu, Aug 3, 2017 at 12:56 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
> wrote:
>
> Hi Boris
>
>
>
> Good to hear from you.
>
> May I ask why you think so?
>
>
>
> We do see some potential with OSProfiler for this and further objectives.
>
>
>
> Thanks
>
> Rajul
>
>
>
> On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
>
> Rajul,
>
>
>
> It makes sense! However, maybe it's a bit too late... ;)
>
>
>
> Best regards,
>
> Boris Pavlovic
>
>
>
> On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
> wrote:
>
> Hello everyone
>
>
>
> I have added a blueprint on having tail-based sampling as a sampling
> option for continuous tracing in OSProfiler. It would be really helpful to
> have some thoughts, ideas, comments on this from the community.
>
>
>
> Continuous tracing provides a good insight on how various transactions
> behave across in a distributed system. Currently, OpenStack doesn't have a
> defined solution for continuous tracing. Though, it has OSProfiler that
> does generates selective traces, it may not capture the occurrence. Even if
> we have OSProfiler running continuously [1], we 

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

[Rajul Kumar]

Hi Boris

That is a point of concern.
Can you please direct to any of those?

Anyways, we don't have anything in place for OpenStack yet.
Now, either we pick another tracing solution like Zipkin, Jaeger etc. which
have their own limitations OR enhance OSProfiler.
We pick the later as it's most native and better coupled with OpenStack as
of now.
I understand that we may be blocked by these issues. However, I feel it'll
be better to fight with OSProfiler than anything else till we come up with
something better :)

Thanks
Rajul



On Thu, Aug 3, 2017 at 4:01 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:

> Rajul,
>
> May I ask why you think so?
>
>
> Exposed by OSprofiler issues are going to be really hard to fix in current
> OpenStack architecture.
>
> Best regards,
> Boris Pavlovic
>
> On Thu, Aug 3, 2017 at 12:56 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
> wrote:
>
>> Hi Boris
>>
>> Good to hear from you.
>> May I ask why you think so?
>>
>> We do see some potential with OSProfiler for this and further objectives.
>>
>> Thanks
>> Rajul
>>
>> On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
>>
>>> Rajul,
>>>
>>> It makes sense! However, maybe it's a bit too late... ;)
>>>
>>> Best regards,
>>> Boris Pavlovic
>>>
>>> On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
>>> wrote:
>>>
>>>> Hello everyone
>>>>
>>>> I have added a blueprint on having tail-based sampling as a sampling
>>>> option for continuous tracing in OSProfiler. It would be really helpful to
>>>> have some thoughts, ideas, comments on this from the community.
>>>>
>>>> Continuous tracing provides a good insight on how various transactions
>>>> behave across in a distributed system. Currently, OpenStack doesn't have a
>>>> defined solution for continuous tracing. Though, it has OSProfiler that
>>>> does generates selective traces, it may not capture the occurrence. Even if
>>>> we have OSProfiler running continuously [1], we need to sample the traces
>>>> so as to cut down the data generated and still keep the useful info.
>>>>
>>>> Head based sampling can be applied that decides initially whether a
>>>> trace should be saved or not. However, it may miss out on some useful
>>>> traces. I propose to have tail-based sampling [2] mechanism that makes the
>>>> decision at the end of the transaction and tends to keep all the useful
>>>> traces. This may require a lot of changes depending on what all type of
>>>> info is required and the solution that we pick to implement it [2]. This
>>>> may not affect the current working of any of the services on OpenStack as
>>>> it will be off the critical path [3].
>>>>
>>>> Please share your thoughts on this and what solution should be
>>>> preferred in a broader OpenStack's perspective.
>>>> This is a step in the process of having an automated diagnostic
>>>> solution for OpenStack cluster.
>>>>
>>>> [1] https://blueprints.launchpad.net/osprofiler/+spec/osprof
>>>> iler-overhead-control
>>>> [2] https://blueprints.launchpad.net/osprofiler/+spec/tail-b
>>>> ased-coherent-sampling
>>>> [3] https://blueprints.launchpad.net/osprofiler/+spec/asynch
>>>> ronous-trace-collection
>>>>
>>>> Thanks
>>>> Rajul Kumar
>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

[Rajul Kumar]

Hi Boris

Good to hear from you.
May I ask why you think so?

We do see some potential with OSProfiler for this and further objectives.

Thanks
Rajul

On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:

> Rajul,
>
> It makes sense! However, maybe it's a bit too late... ;)
>
> Best regards,
> Boris Pavlovic
>
> On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
> wrote:
>
>> Hello everyone
>>
>> I have added a blueprint on having tail-based sampling as a sampling
>> option for continuous tracing in OSProfiler. It would be really helpful to
>> have some thoughts, ideas, comments on this from the community.
>>
>> Continuous tracing provides a good insight on how various transactions
>> behave across in a distributed system. Currently, OpenStack doesn't have a
>> defined solution for continuous tracing. Though, it has OSProfiler that
>> does generates selective traces, it may not capture the occurrence. Even if
>> we have OSProfiler running continuously [1], we need to sample the traces
>> so as to cut down the data generated and still keep the useful info.
>>
>> Head based sampling can be applied that decides initially whether a trace
>> should be saved or not. However, it may miss out on some useful traces. I
>> propose to have tail-based sampling [2] mechanism that makes the decision
>> at the end of the transaction and tends to keep all the useful traces. This
>> may require a lot of changes depending on what all type of info is required
>> and the solution that we pick to implement it [2]. This may not affect the
>> current working of any of the services on OpenStack as it will be off the
>> critical path [3].
>>
>> Please share your thoughts on this and what solution should be preferred
>> in a broader OpenStack's perspective.
>> This is a step in the process of having an automated diagnostic solution
>> for OpenStack cluster.
>>
>> [1] https://blueprints.launchpad.net/osprofiler/+spec/
>> osprofiler-overhead-control
>> [2] https://blueprints.launchpad.net/osprofiler/+spec/tail-
>> based-coherent-sampling
>> [3] https://blueprints.launchpad.net/osprofiler/+spec/
>> asynchronous-trace-collection
>>
>> Thanks
>> Rajul Kumar
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

[Rajul Kumar]

Hello everyone

I have added a blueprint on having tail-based sampling as a sampling option
for continuous tracing in OSProfiler. It would be really helpful to have
some thoughts, ideas, comments on this from the community.

Continuous tracing provides a good insight on how various transactions
behave across in a distributed system. Currently, OpenStack doesn't have a
defined solution for continuous tracing. Though, it has OSProfiler that
does generates selective traces, it may not capture the occurrence. Even if
we have OSProfiler running continuously [1], we need to sample the traces
so as to cut down the data generated and still keep the useful info.

Head based sampling can be applied that decides initially whether a trace
should be saved or not. However, it may miss out on some useful traces. I
propose to have tail-based sampling [2] mechanism that makes the decision
at the end of the transaction and tends to keep all the useful traces. This
may require a lot of changes depending on what all type of info is required
and the solution that we pick to implement it [2]. This may not affect the
current working of any of the services on OpenStack as it will be off the
critical path [3].

Please share your thoughts on this and what solution should be preferred in
a broader OpenStack's perspective.
This is a step in the process of having an automated diagnostic solution
for OpenStack cluster.

[1]
https://blueprints.launchpad.net/osprofiler/+spec/osprofiler-overhead-control
[2]
https://blueprints.launchpad.net/osprofiler/+spec/tail-based-coherent-sampling
[3]
https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-collection

Thanks
Rajul Kumar
__
OpenStack Development Mailing 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] Can we move some non-voting broken jobs to the experimental queue?

[Amrith Kumar]

Matt, we're trying our best to and the reason they were (recently) moved
back to NON-experimental is that in moving them to experimental, no one
monitored them.

Yes, I am trying to get them to voting and like everything else in Trove,
we could use some help.

Yes, I realize that there are no elements, and yes, they are failing.

​I would recommend against moving them to the experimental queue. But, if
someone else wants to propose the change, I'll leave it up to infra to
decide; that's not my decision.​

-amrith



On Wed, Aug 2, 2017 at 10:27 AM, Matt Riedemann  wrote:

> I don't dabble in Trove-land often but today I pushed a change and was
> watching it in zuul, and noticed that the change runs 26 jobs in the check
> queue. Several of those (cassandra, couch, mongo, percona) all failed
> nearly immediately with something in the diskimage builder, like this:
>
> http://logs.openstack.org/42/490042/1/check/gate-trove-scena
> rio-dsvm-cassandra-single-ubuntu-xenial-nv/d38a8c1/logs/
> devstack-gate-post_test_hook.txt.gz#_2017-08-02_14_58_16_953
>
> diskimage_builder.element_dependencies.MissingElementException: Element
> 'ubuntu-xenial-cassandra' not found
>
> Is anyone maintaining these jobs? If not, they should be moved to the
> experimental queue so they can be run on demand, not in the check queue for
> every patch set proposed to Trove. These are also single and multi-node
> jobs, so they are needlessly eating up node pool resources.
>
> --
>
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [All][Trove] Adding Amrith candidacy for Trove.Queens

[Amrith Kumar]

This email is to announce my candidacy for the PTL of Trove for the
Queens cycle. My candidacy has been formally submitted in[1].

I have been the PTL for the Trove project since the Trove release (in
March 2016). During this time, we've seen significant improvements
during the Newton and Ocata releases but faced a setback with the
departure of several companies from the community in the Pike release.

Trove faces many of the same challenges faced by projects that are not
part of the 'core' of OpenStack. Even though the last two user
surveys[2,3] show that Trove is one of the popular projects that
people want to adopt, this has not translated into an increase in
active participation.

The challenges facing Trove in the Queens release are broadly to:

1. improve active participation and contribution in code reviews and
   stabilize the core reviewer team.
2. keep up with changes in the rest of OpenStack
3. stabilize and maintain the existing code base

Two important aspects of my candidacy that are worth highlighting
here.

The first is that I am in favor of taking a serious look at the
current Trove architecture and revisiting whether we should
reimplement the project as a layered platform project that better
leverages underlying infrastructure (IaaS) projects. A good discussion
on the mailing list [4] surfaced a number of ideas which I intend to
discuss in depth at the PTG in Denver with other members of the
team. The hope is that we can come out of the PTG with a clear action
plan, and more importantly a commitment from participants to work on
the project and implement that plan.

The second is that at least in the Queens release, and until we can
get to the point where we have more active participation in the
project, I intend to place the project in 'maintenance-mode'. A change
has been proposed in the governance repository[5] to make this
happen. I expect however that the TC will respect the wishes of
whoever is elected PTL of the project in this election cycle.

I highlight both of these aspects (above) because they are not
universally accepted. I am aware that at least one other person wishes
to also run for election to the position of Trove PTL in the Queens
cycle, and we differ in our views on these two subjects. As I write
this, he has not yet announced his candidacy, and I will likely be
submitting this before he does so I will merely note that we differ on
how to approach the issue of rearchitecting Trove (he would prefer we
continue down the current path and stabilize/enhance it rather than
rearchitect it), and does not favor the notion of attaching the
maintenance-mode tag to the project.

While we differ on these two issues, I intend to remain an active
participant in the project, and support the PTL's lead if I am not
re-elected.

[1] https://review.openstack.org/48962
[2] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[3] https://www.openstack.org/assets/survey/October2016SurveyReport.pdf
[4] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[5] https://review.openstack.org/#/c/488947/

-amrith
__
OpenStack Development Mailing 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] [tc][dev][trove] Request to consider applying the status:maintenance-mode tag to the Trove project for the Queens cycle

[Amrith Kumar]

TC, Trove folks,

I've submitted [1] a request to the TC to consider applying the
status:maintenance-mode tag to the Trove project for the Queens cycle. If
you would like to comment on this, I suggest that you do it on the review
rather than this email thread.

Thanks

-amrith

[1] https://review.openstack.org/#/c/488947/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

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

[Mohan Kumar]

Hi Rajeev,

The Chain Monitoring is the missing piece in networking-sfc . Vikram and
myself were discussed to introduce "SFC Manager" [1] (basically OAM tool )
few cycle before.

It'll continuously monitor an existing SFC chain,  when any SF VM goes down
or any packet drop. It'll trigger alert and capture corresponding logs .
But we haven't started any implementation on this. Feel free to discuss
with community, IMO  this feature will be great addition to networking-sfc

[1]  https://bugs.launchpad.net/networking-sfc/+bug/1513368


IRC: #networking-sfc
Weekly Meeting:
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting

Thanks.,
Mohankumar.N







On Thu, Jul 27, 2017 at 11:30 AM, rajeev.satyanaray...@wipro.com <
rajeev.satyanaray...@wipro.com> wrote:

> Hi Igor/Cathy/Gord,
>
>
>
> Sorry for the delay in replying.
>
>
>
> As part of monitoring the SFC, I think maintaining the details of “Number
> of flows assigned to a given SFC”, “Number of packets/bytes dropped/hit due
> to the policies at each Service Function entry/exit points or for the
> entire SFC” would be good to start with. I feel based on some of these
> details, an operator can know how much the virtual switch is loaded and
> take a call on whether to add a new SFC, or it could even help during
> debugging which service function has exactly caused the disruption to SFC.
>
> As a first step, I think it would be good to add meters to provide “number
> of packets/bytes hit due to policy at the ingress and egress of the entire
> SFC” and to realize that, we would need to add specific pollsters. We can
> use neutron_client API to fetch the ingress and egress port details and
> fetch the corresponding flows for those specific ports(also get flow_infos
> from flow_classifier and then use them to dump_flows matching those
> flow_infos) and fetch the no.of packets hit due to policy from them.
>
>
>
> I have just mentioned my idea on this. Can I please know your opinion on
> this and provide your comments?
>
>
>
> Thanks and Regards,
>
> Rajeev.
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [rpm-packaging][karbor]

[Chandan kumar]

Hello Chen,

On Mon, Jul 17, 2017 at 12:41 PM, Chen Ying <chenyin...@gmail.com> wrote:
> Hi Chandan,
>
>Thank your work about  packaging abclient  .
>

Both the packages are now available in cbs.
https://review.rdoproject.org/r/#/c/7711/ got merged in RDO.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

;
> > 
> >
> > Clint makes a distinction between a database cluster within an
> > OpenStack deployment and an uber database cluster spanning clouds,
> > recommending that the latter is best left to a tertiary
> > orchestrator. Further, these are two distinct things, pick one and do
> > it well.
> >
> > Amrith: A valid approach and one that will allow Trove to focus on the
> > high value single OpenStack deployment of a db cluster (and to Jay's
> > point, do it well).
> >
> > 
> >
> > Consensus:
> >
> > Trove should expose (what Matt Fischer calls) BlackBox DB, not storage +
> > compute.
> >
> > Address rabbitmq security concerns differently; move guest agent off
> > instance.
> >
> > Don't reinvent the orchestration piece.
> >
> > Fewer DB's better support
> >
> > Clusters are first class citizens, not an afterthought
> >
> > Clusters spanning regions and openstack deployments
> >
> > Restart the service VM's discussion:
> > https://review.openstack.org/#/c/438134/
> >
> > 
> >
> > Several people emailed me privately and said they (or their companies)
> > would like to invest resources in Trove. Some indicated that they (or
> > their companies) would like to invest resources in Trove if the
> > commitment was towards a certain direction or technology choice.
> > Others have offered resources if the direction would be to provide
> > an AWS compatible API.
> >
> > To anyone who wants to contribute resources to a project, please do
> > it. Big companies considering contributing one or two people to a
> > project and making it seem like a big decision is really an indication
> > of a lack of seriousness. If the project is really valuable to you,
> > you'd have put people on it already. The fact that you haven't speaks
> > volumes.
> >
> > To those who want to place pre-conditions on technology choice, I have
> > no (good) words for you.
> >
> > Thanks to all who participated, I appreciate all the input. I will be
> > setting up a session at the Denver PTG to specifically continue this
> > conversation and hope you will all be able to attend. As soon as time
> > slots for PTG are announced, I will try and pick this slot and request
> > that you please attend.
> >
> > Thanks,
> >
> > -amrith
> >
> >
> >
> >
> > On Sun, Jun 18, 2017 at 6:35 AM, Amrith Kumar <amrith.ku...@gmail.com>
> > wrote:
> >
> > > Trove has evolved rapidly over the past several years, since
> integration
> > > in IceHouse when it only supported single instances of a few databases.
> > > Today it supports a dozen databases including clusters and replication.
> > >
> > > The user survey [1] indicates that while there is strong interest in
> the
> > > project, there are few large production deployments that are known of
> (by
> > > the development team).
> > >
> > > Recent changes in the OpenStack community at large (company
> realignments,
> > > acquisitions, layoffs) and the Trove community in particular, coupled
> with
> > > a mounting burden of technical debt have prompted me to make this
> proposal
> > > to re-architect Trove.
> > >
> > > This email summarizes several of the issues that face the project, both
> > > structurally and architecturally. This email does not claim to include
> a
> > > detailed specification for what the new Trove would look like, merely
> the
> > > recommendation that the community should come together and develop one
> so
> > > that the project can be sustainable and useful to those who wish to
> use it
> > > in the future.
> > >
> > > TL;DR
> > >
> > > Trove, with support for a dozen or so databases today, finds itself in
> a
> > > bind because there are few developers, and a code-base with a
> significant
> > > amount of technical debt.
> > >
> > > Some architectural choices which the team made over the years have
> > > consequences which make the project less than ideal for deployers.
> > >
> > > Given that there are no major production deployments of Trove at
> present,
> > > this provides us an opportunity to reset the project, learn from our
> v1 and
> > > come up with a strong v2.
> > >
> > > An important aspect of making this proposal work is that we seek to
> > > eliminate the effort (planning, and coding) involved in migrating
> 

[openstack-dev] [all][trove] Retiring the openstack/trove-integration repository

[Amrith Kumar]

This is an early warning that the openstack/trove-integration repository
was last used for Trove in the Newton release. Ocata, and now Pike use
elements and things that are in the trove repository.

This is a heads-up that when Newton goes EOL, the trove-integration
repository will be retired.

If you have anything which depends on this repository, or things that are
generated from this repository, speak sometime between now and early
November this year, or forever hold your peace.

Honestly, I think there will be wild partying in the streets when
trove-integration is finally retired but as I learned from the mysql.qcow2
fiasco (sorry folks) it is unwise to assume that something is unused.

Thanks,

-amrith
__
OpenStack Development Mailing 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] [rpm-packaging][karbor]

[Chandan kumar]

On Fri, Jul 14, 2017 at 12:10 PM, Chandan kumar <chkumar...@gmail.com> wrote:
> Hello Jiong,
>
> Thank you for packaging karbor.
>
> On Fri, Jul 14, 2017 at 11:49 AM, Jiong Liu <liuji...@gohighsec.com> wrote:
>> Hello rpm-packaging team and folks,
>>
>>
>>
>> I got trouble with packaging OpenStack project(karbor), which depends on two
>> packages: icalendar and abclient.
>>
>> icalendar has pip package and RPM package, but RPM package can not be found
>> by RDO CI.
>
> python-icalender is available in fedora:
> https://koji.fedoraproject.org/koji/packageinfo?packageID=10783
> We can pull it soon in RDO.
>
>>
>> While abclient only has pip package but no RPM package.
>>
>
> abclient is not available in Fedora or RDO. I am packaging it. It will
> be soon available in RDO.

I have filed a python-abclient package review for Fedora :
https://bugzilla.redhat.com/show_bug.cgi?id=1470980

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] [rpm-packaging][karbor]

[Chandan kumar]

Hello Jiong,

Thank you for packaging karbor.

On Fri, Jul 14, 2017 at 11:49 AM, Jiong Liu <liuji...@gohighsec.com> wrote:
> Hello rpm-packaging team and folks,
>
>
>
> I got trouble with packaging OpenStack project(karbor), which depends on two
> packages: icalendar and abclient.
>
> icalendar has pip package and RPM package, but RPM package can not be found
> by RDO CI.

python-icalender is available in fedora:
https://koji.fedoraproject.org/koji/packageinfo?packageID=10783
We can pull it soon in RDO.

>
> While abclient only has pip package but no RPM package.
>

abclient is not available in Fedora or RDO. I am packaging it. It will
be soon available in RDO.

>
>
> So in this case, what should I do to make sure these two packages can be
> installed via RPM when packaing karbor?
>
>
>
> My patch is uploaded to rpm-package review list, as you can find here
> https://review.openstack.org/#/c/480806/
>

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

Kevin,

In interests of 'keeping it simple', I'm going to try and prioritize the
use-cases and pick implementation strategies which target the higher
priority ones without needlessly excluding other (lower priority) ones.

Thanks,

-amrith

--
Amrith Kumar
​
P.S. Verizon is hiring ​OpenStack engineers nationwide. If you are
interested, please contact me or visit https://t.co/gGoUzYvqbE


On Wed, Jul 12, 2017 at 5:46 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> There is a use case where some sites have folks buy whole bricks of
> compute nodes that get added to the overarching cloud, but using AZ's or
> HostAggregates/Flavors to dedicate the hardware to the users.
>
> You might want to land the db vm on the hardware for that project and one
> would expect the normal quota would be dinged for it rather then a special
> trove quota. Otherwise they may have more quota then the hosts can actually
> handle.
>
> Thanks,
> Kevin
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Wednesday, July 12, 2017 6:57 AM
> To: openstack-dev
> Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect
> Trove
>
> Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500:
> > All:
> >
> > First, let me thank all of you who responded and provided feedback
> > on what I wrote. I've summarized what I heard below and am posting
> > it as one consolidated response rather than responding to each
> > of your messages and making this thread even deeper.
> >
> > As I say at the end of this email, I will be setting up a session at
> > the Denver PTG to specifically continue this conversation and hope
> > you will all be able to attend. As soon as time slots for PTG are
> > announced, I will try and pick this slot and request that you please
> > attend.
> >
> > 
> >
> > Thierry: naming issue; call it Hoard if it does not have a migration
> > path.
> >
> > 
> >
> > Kevin: use a container approach with k8s as the orchestration
> > mechanism, addresses multiple issues including performance. Trove to
> > provide containers for multiple components which cooperate to provide
> > a single instance of a database or cluster. Don't put all components
> > (agent, monitoring, database) in a single VM, decoupling makes
> > migraiton and upgrades easier and allows trove to reuse database
> > vendor supplied containers. Performance of databases in VM's poor
> > compared to databases on bare-metal.
> >
> > 
> >
> > Doug Hellmann:
> >
> > > Does "service VM" need to be a first-class thing?  Akanda creates
> > > them, using a service user. The VMs are tied to a "router" which is
> > > the billable resource that the user understands and interacts with
> > > through the API.
> >
> > Amrith: Doug, yes because we're looking not just for service VM's but all
> > resources provisioned by a service. So, to Matt's comment about a
> > blackbox DBaaS, the VM's, storage, snapshots, ... they should all be
> > owned by the service, charged to a users quota but not visible to the
> > user directly.
>
> I still don't understand. If you have entities that represent the
> DBaaS "host" or "database" or "database backup" or whatever, then
> you put a quota on those entities and you bill for them. If the
> database actually runs in a VM or the backup is a snapshot, those
> are implementation details. You don't want to have to rewrite your
> quota management or billing integration if those details change.
>
> Doug
>
> >
> > 
> >
> > Jay:
> >
> > > Frankly, I believe all of these types of services should be built
> > > as applications that run on OpenStack (or other)
> > > infrastructure. In other words, they should not be part of the
> > > infrastructure itself.
> > >
> > > There's really no need for a user of a DBaaS to have access to the
> > > host or hosts the DB is running on. If the user really wanted
> > > that, they would just spin up a VM/baremetal server and install
> > > the thing themselves.
> >
> > and subsequently in follow-up with Zane:
> >
> > > Think only in terms of what a user of a DBaaS really wants. At the
> > > end of the day, all they want is an address in the cloud where they
> > > can point their application to write and read data from.
> > > ...
> > > At the end of the day, I think Trove is best implemented as a hosted
> > > application that exposes an API to its users that i

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

 dependencies
> between OpenStack projects.
> ...
> I understand it's a hard trade-off: you want to reuse functionality
> rather than reinvent it in every project... we just need to
> recognize the cost of doing that.

Amrith: Yes, this is part of my concern re: Mistral, and earlier in
trove's life on depending on Manila for Oracle RAC. Clint raised a
similar concern about the dependency on Heat.

In response, Kevin:

> That view of dependencies is why Kubernetes development is outpacing
> OpenStacks and some users are leaving IMO. Not trying to be mean
> here but trying to shine some light on this issue.

I disagree, but that's a topic for another email thread and maybe not
even an email thread but an in-person conversation with suitable
beverages. It is a religious discussion which is best handled in a
different forum; such as the emacs-vi forum.



I wrote:

> - A guest agent running on a tenant instance, with connectivity to a
> shared management message bus is a security loophole; encrypting
> traffic, per-tenant-passwords, and any other scheme is merely
> lipstick on a security hole

Clint asks:

 This is a broad statement, and I'm not sure I understand the actual
 risk you're presenting here as "a security loophole".

 How else would you administer a database server than through some
 kind of agent? Whether that agent is a python daemon of our making,
 sshd, or whatever kubernetes component lets you change things,
 they're all administrative pieces that sit next to the resource.

Amrith: The issue is that the guest agent (currently) running in a
tenants context needs to establish a connection to a shared rabbitmq
server running in the service (control plane) context. I am fine with
a guest agent running in the control plan establishing a connection
into a guest VM if required, not the other way around.



Clint makes a distinction between a database cluster within an
OpenStack deployment and an uber database cluster spanning clouds,
recommending that the latter is best left to a tertiary
orchestrator. Further, these are two distinct things, pick one and do
it well.

Amrith: A valid approach and one that will allow Trove to focus on the
high value single OpenStack deployment of a db cluster (and to Jay's
point, do it well).



Consensus:

Trove should expose (what Matt Fischer calls) BlackBox DB, not storage +
compute.

Address rabbitmq security concerns differently; move guest agent off
instance.

Don't reinvent the orchestration piece.

Fewer DB's better support

Clusters are first class citizens, not an afterthought

Clusters spanning regions and openstack deployments

Restart the service VM's discussion:
https://review.openstack.org/#/c/438134/



Several people emailed me privately and said they (or their companies)
would like to invest resources in Trove. Some indicated that they (or
their companies) would like to invest resources in Trove if the
commitment was towards a certain direction or technology choice.
Others have offered resources if the direction would be to provide
an AWS compatible API.

To anyone who wants to contribute resources to a project, please do
it. Big companies considering contributing one or two people to a
project and making it seem like a big decision is really an indication
of a lack of seriousness. If the project is really valuable to you,
you'd have put people on it already. The fact that you haven't speaks
volumes.

To those who want to place pre-conditions on technology choice, I have
no (good) words for you.

Thanks to all who participated, I appreciate all the input. I will be
setting up a session at the Denver PTG to specifically continue this
conversation and hope you will all be able to attend. As soon as time
slots for PTG are announced, I will try and pick this slot and request
that you please attend.

Thanks,

-amrith




On Sun, Jun 18, 2017 at 6:35 AM, Amrith Kumar <amrith.ku...@gmail.com>
wrote:

> Trove has evolved rapidly over the past several years, since integration
> in IceHouse when it only supported single instances of a few databases.
> Today it supports a dozen databases including clusters and replication.
>
> The user survey [1] indicates that while there is strong interest in the
> project, there are few large production deployments that are known of (by
> the development team).
>
> Recent changes in the OpenStack community at large (company realignments,
> acquisitions, layoffs) and the Trove community in particular, coupled with
> a mounting burden of technical debt have prompted me to make this proposal
> to re-architect Trove.
>
> This email summarizes several of the issues that face the project, both
> structurally and architecturally. This email does not claim to include a
> detailed specification for what the new Trove would look like, merely the
> recommendation that the community should come together and develop one so
&

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

[Chandan kumar]

On Fri, Jun 30, 2017 at 3:08 PM, Thierry Carrez <thie...@openstack.org> wrote:
> Mike Perez wrote:
>> [...]
>> What do people think before we bikeshed on the name? Would having a
>> champion volunteer to each goal to help?
>
> It feels like most agree that having champions would help. Do we have
> any volunteer for the currently-proposed Pike goals ? As a reminder,
> those are:
>
> * Split Tempest plugins into separate repos/projects [1]

I would like to volunteer for Split Tempest plugins into separate
repos/projects .

> * Move policy and policy docs into code [2]
>
> [1]
> https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
> [2] https://review.openstack.org/#/c/469954/
>

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

Manoj,

It would be great if these teams were brought into this conversation. I am
not averse to the evolutionary approach, merely observing that in the
absence of commitment and contributors who wish to participate in this
evolution, we will be unable to sustain the project.

Regarding your view that it is feasible and rational to evolve Trove, I
would to understand the rationale behind those judgements and the resources
that you believe that it will take to make those possible, and a clear
statement of what your/IBM's commitment of resources to the project would
be.

Thanks,

-amrith


On Thu, Jun 29, 2017 at 9:33 AM, Manoj Kumar <kuma...@us.ibm.com> wrote:

> Amrith: Some comments regarding the scarcity of deployments, and the
> proposed approach.
>
> We know of multiple teams that are now independently charging down and
> investing in a Trove path.  They are at various stages of deployment and
> are beyond tire-kicking. They are beginning to build dev/test environments,
> some are building commercial products, and we fully expect some people to
> be in production with Trove by the end of the year.  Collectively, we need
> to start bridging and engaging these people into the Trove community.
>
> We also strongly believe that we need an evolutionary approach to moving
> Trove forward vs. the revolutionary approach that is being proposed.  Our
> deeply held view is that it is feasible and rationale to evolve Trove as it
> exists today.  We agree that there are architectural issues that have to be
> addressed.   Let's start working on addressing these issues as well as the
> current currency issues but in a evolutionary way.  The revolutionary
> approach will halt all progress and set a bad precedent, and we believe
> that it will cause people to walk away from the community and likely
> OpenStack as well.
>
> - Manoj
>
>
>
> From:Amrith Kumar <amrith.ku...@gmail.com>
> To:"OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date:06/18/2017 06:41 AM
> Subject:[openstack-dev] [trove][all][tc] A proposal to
> rearchitect Trove
> --
>
>
>
> Trove has evolved rapidly over the past several years, since integration
> in IceHouse when it only supported single instances of a few databases.
> Today it supports a dozen databases including clusters and replication.
>
> The user survey [1] indicates that while there is strong interest in the
> project, there are few large production deployments that are known of (by
> the development team).
>
> Recent changes in the OpenStack community at large (company realignments,
> acquisitions, layoffs) and the Trove community in particular, coupled with
> a mounting burden of technical debt have prompted me to make this proposal
> to re-architect Trove.
>
> This email summarizes several of the issues that face the project, both
> structurally and architecturally. This email does not claim to include a
> detailed specification for what the new Trove would look like, merely the
> recommendation that the community should come together and develop one so
> that the project can be sustainable and useful to those who wish to use it
> in the future.
>
> TL;DR
>
> Trove, with support for a dozen or so databases today, finds itself in a
> bind because there are few developers, and a code-base with a significant
> amount of technical debt.
>
> Some architectural choices which the team made over the years have
> consequences which make the project less than ideal for deployers.
>
> Given that there are no major production deployments of Trove at present,
> this provides us an opportunity to reset the project, learn from our v1 and
> come up with a strong v2.
>
> An important aspect of making this proposal work is that we seek to
> eliminate the effort (planning, and coding) involved in migrating existing
> Trove v1 deployments to the proposed Trove v2. Effectively, with work
> beginning on Trove v2 as proposed here, Trove v1 as released with Pike will
> be marked as deprecated and users will have to migrate to Trove v2 when it
> becomes available.
>
> While I would very much like to continue to support the users on Trove v1
> through this transition, the simple fact is that absent community
> participation this will be impossible. Furthermore, given that there are no
> production deployments of Trove at this time, it seems pointless to build
> that upgrade path from Trove v1 to Trove v2; it would be the proverbial
> bridge from nowhere.
>
> This (previous) statement is, I realize, contentious. There are those who
> have told me that an upgrade path must be provided, and there are those who
> have told

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

[Manoj Kumar]

Amrith: Some comments regarding the scarcity of deployments, and the 
proposed approach.

We know of multiple teams that are now independently charging down and 
investing in a Trove path.  They are at various stages of deployment and 
are beyond tire-kicking. They are beginning to build dev/test 
environments, some are building commercial products, and we fully expect 
some people to be in production with Trove by the end of the year. 
Collectively, we need to start bridging and engaging these people into the 
Trove community. 

We also strongly believe that we need an evolutionary approach to moving 
Trove forward vs. the revolutionary approach that is being proposed.  Our 
deeply held view is that it is feasible and rationale to evolve Trove as 
it exists today.  We agree that there are architectural issues that have 
to be addressed.   Let's start working on addressing these issues as well 
as the current currency issues but in a evolutionary way.  The 
revolutionary approach will halt all progress and set a bad precedent, and 
we believe that it will cause people to walk away from the community and 
likely OpenStack as well. 

- Manoj



From:   Amrith Kumar <amrith.ku...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date:   06/18/2017 06:41 AM
Subject:[openstack-dev] [trove][all][tc] A proposal to rearchitect 
Trove



Trove has evolved rapidly over the past several years, since integration 
in IceHouse when it only supported single instances of a few databases. 
Today it supports a dozen databases including clusters and replication.

The user survey [1] indicates that while there is strong interest in the 
project, there are few large production deployments that are known of (by 
the development team).

Recent changes in the OpenStack community at large (company realignments, 
acquisitions, layoffs) and the Trove community in particular, coupled with 
a mounting burden of technical debt have prompted me to make this proposal 
to re-architect Trove.

This email summarizes several of the issues that face the project, both 
structurally and architecturally. This email does not claim to include a 
detailed specification for what the new Trove would look like, merely the 
recommendation that the community should come together and develop one so 
that the project can be sustainable and useful to those who wish to use it 
in the future.

TL;DR

Trove, with support for a dozen or so databases today, finds itself in a 
bind because there are few developers, and a code-base with a significant 
amount of technical debt.

Some architectural choices which the team made over the years have 
consequences which make the project less than ideal for deployers.

Given that there are no major production deployments of Trove at present, 
this provides us an opportunity to reset the project, learn from our v1 
and come up with a strong v2.

An important aspect of making this proposal work is that we seek to 
eliminate the effort (planning, and coding) involved in migrating existing 
Trove v1 deployments to the proposed Trove v2. Effectively, with work 
beginning on Trove v2 as proposed here, Trove v1 as released with Pike 
will be marked as deprecated and users will have to migrate to Trove v2 
when it becomes available.

While I would very much like to continue to support the users on Trove v1 
through this transition, the simple fact is that absent community 
participation this will be impossible. Furthermore, given that there are 
no production deployments of Trove at this time, it seems pointless to 
build that upgrade path from Trove v1 to Trove v2; it would be the 
proverbial bridge from nowhere.

This (previous) statement is, I realize, contentious. There are those who 
have told me that an upgrade path must be provided, and there are those 
who have told me of unnamed deployments of Trove that would suffer. To 
this, all I can say is that if an upgrade path is of value to you, then 
please commit the development resources to participate in the community to 
make that possible. But equally, preventing a v2 of Trove or delaying it 
will only make the v1 that we have today less valuable.

We have learned a lot from v1, and the hope is that we can address that in 
v2. Some of the more significant things that I have learned are:

- We should adopt a versioned front-end API from the very beginning; 
making the REST API versioned is not a ‘v2 feature’

- A guest agent running on a tenant instance, with connectivity to a 
shared management message bus is a security loophole; encrypting traffic, 
per-tenant-passwords, and any other scheme is merely lipstick on a 
security hole

- Reliance on Nova for compute resources is fine, but dependence on Nova 
VM specific capabilities (like instance rebuild) is not; it makes things 
like containers or bare-metal second class citizens

- A fair portion of what Trove does is 

Re: [openstack-dev] [tc][swg] The future of the Stewardship Working Group

[Amrith Kumar]

Colette,

First of all, thank you for all that you have done in leading the charge
around the SWG (since long before it got that name). I had the good fortune
of being able to work with the first group of members of the TC who
attended the training in Michigan at Zing Train and I think the discussions
we had there, and the changes that you were able to drive as part of the
SWG were very useful.

Thanks, and all the very best at Spotify,

-amrith




On Wed, Jun 28, 2017 at 4:08 PM, Colette Alexander <
colettealexan...@gmail.com> wrote:

> Hello Stackers,
>
> As many of you know, I recently took a job with Spotify in New York City.
> I spoke with many folks about the transition plans when I was at the Boston
> Forum, and we all decided that it would make sense for me to get settled
> into the new position before deciding what amounts of time I had to tend to
> SWG work, and therefore what my future in the community would look like.
>
> My new job has become a lot busier a lot sooner than expected. I think
> I'll have a little bit more time in my schedule in the next month or so to
> do OpenStack related work, but after summer holidays, I expect things to
> pick back up again.
>
> Because of all of the unknowns around my availability for working on SWG
> things, I think now is a good time to start discussing a potential
> replacement for me as the chair of the group. I have loved working with
> OpenStack and I plan on sticking around in the IRC channel and monitoring
> mailing list work, but I don't think it's fair to the SWG, TC or the entire
> community for me to stay on as chair when I can't devote as much time as
> I'd like to spearheading efforts in the community.
>
> So - that means I'd love to hear from folks about who might be a good
> replacement. I have spoken to a few people behind the scenes to gauge
> interest, but I'd like to open it up the community as a whole at this point
> to start a discussion.
>
> For those of you who don't know what the Stewardship Working Group is:
> https://wiki.openstack.org/wiki/Stewardship_Working_Group is a good place
> to start
>
> Some of the workstreams going on:
> a) Follow up on project ideas from leadership training
> https://etherpad.openstack.org/p/pathtocontribution
> https://etherpad.openstack.org/p/communication-vision
>
> b) Any more poking/helping along of the TC with their current vision
>
> c) An actual vision for the SWG and their next batch of work (this would
> be based on feedback from the training sessions above, and from the
> community, collected at the Atlanta PTG - https://etherpad.openstack.
> org/p/AtlantaPTG-SWG
>
> d) The future of leadership training (more to schedule? break it up into
> smaller groups? who knows?)
>
> I'd be happy to onboard anyone who's interested in terms of getting them
> up to speed on these items.
>
> If anyone wants to discuss any of this with me directly I'm gothicmindfood
> on IRC.
>
> Thanks so much for being such an amazing community to be in - you all
> continue to be some of my favorite humans and I'm so lucky to have gotten a
> chance to work with you.
>
> Sincerely,
>
> -colette/gothicmindfood
>
> __
> OpenStack Development Mailing 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][ALL] What tempest tests will go under tempest plugin for a Project?

[Chandan kumar]

++ openstack-dev

On Tue, Jun 27, 2017 at 3:57 PM, Ghanshyam Mann <ghanshyamm...@gmail.com> wrote:
> On Tue, Jun 27, 2017 at 3:52 PM, Chandan kumar <chkumar...@gmail.com> wrote:
>> Hello Ghanshyam,
>>
>> On Sat, Jun 24, 2017 at 3:48 PM, Ghanshyam Mann <ghanshyamm...@gmail.com> 
>> wrote:
>>> On Fri, Jun 23, 2017 at 4:51 PM, Chandan kumar <chkumar...@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> In Queen OpenStack release, We have a community goal to split In-Tree
>>>> tempest plugin to a separate repo[1.].
>>>>
>>>> I have a couple question regarding the tempest tests movement within
>>>> tempest plugins.
>>>>
>>>> [1.] Since some of the core OpenStack projects like Nova, Glance and
>>>> Swift does have tempest plugin currently.
>>>>  Their Tempest tests reside under tempest project repo.
>>>>  are we going to create tempest plugin for the same?
>>>>  If yes, what are the tempest tests (API/Scenario) tests moving
>>>> under tempest plugins?
>>>>
>>>> [2.] And, like other core projects like neutron and cinder have their
>>>> in-tree tempest plugins also.
>>>>  And those are also moving to a separate repo and currently, their
>>>> tests also resides under tempest repo.
>>>>  How can we avoid the duplication of the tempest tests?
>>>
>>> Its same answer for 1 and 2. Tempest is a place to have integration
>>> tests and future tests also falls in same scope.
>>> Yes, we do have API tests negative as well as positive which are there
>>> because of defcore. Defcore need those for interop certification.
>>> Those will reside in Tempest as of now and so new tests can be added
>>> in Tempest if defcore require them.
>>>
>>> New or existing Tempest plugin for 6 core projects whose tests are
>>> present in Tempest, will target their functional/API/negative testing
>>> etc which are/should be out of scope of Tempest.
>>>
>>> Regarding the duplication of tests, we do take care of those while
>>> review of new tests addition. If there is any new tests proposed in
>>> Tempest, reviewers need to check whether same coverage is there on
>>> project side or not (either functional tests or in tempest plugin).
>>> Also if those are more appropriate to reside on project side. We will
>>> be continuing with the same process to avoid duplicate tests.
>>>
>>
>> Thanks got it, So basically if any tests needed by DefCore as well as
>> integration tests
>> needed for Core  Projects will go under Tempest.
>>
>>>
>>>>
>>>> [3.] For other projects while moving tests to a separate repo how we
>>>> are going to collaborate together to avoid
>>>>  duplication and move common tests to Tempest?
>>>
>>> You mean tests in projects tree as functional tests etc and their
>>> tempest plugin ?
>>
>> Yes, For example, Swift have lots of functional tests with in tests
>> folder of swift project tree.
>> Does it go under tempest plugin?
>> This part i am confused.
>
> That depends on project to project. If they want to implement tempest
> like tests and does not fall under Tempest scope, then those tests
> goes in tempest plugin like done by Cinder. But it does not mean that
> all existing functional tests of projects needs to be moved/converted
> to tempest like tests.
> That's all depends on project team decision.
>
> -gmann
>
>>
Thanks, I got all the answers.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][ALL] What tempest tests will go under tempest plugin for a Project?

[Chandan kumar]

Hello Ghanshyam,

On Sat, Jun 24, 2017 at 3:48 PM, Ghanshyam Mann <ghanshyamm...@gmail.com> wrote:
> On Fri, Jun 23, 2017 at 4:51 PM, Chandan kumar <chkumar...@gmail.com> wrote:
>> Hello,
>>
>> In Queen OpenStack release, We have a community goal to split In-Tree
>> tempest plugin to a separate repo[1.].
>>
>> I have a couple question regarding the tempest tests movement within
>> tempest plugins.
>>
>> [1.] Since some of the core OpenStack projects like Nova, Glance and
>> Swift does have tempest plugin currently.
>>  Their Tempest tests reside under tempest project repo.
>>  are we going to create tempest plugin for the same?
>>  If yes, what are the tempest tests (API/Scenario) tests moving
>> under tempest plugins?
>>
>> [2.] And, like other core projects like neutron and cinder have their
>> in-tree tempest plugins also.
>>  And those are also moving to a separate repo and currently, their
>> tests also resides under tempest repo.
>>  How can we avoid the duplication of the tempest tests?
>
> Its same answer for 1 and 2. Tempest is a place to have integration
> tests and future tests also falls in same scope.
> Yes, we do have API tests negative as well as positive which are there
> because of defcore. Defcore need those for interop certification.
> Those will reside in Tempest as of now and so new tests can be added
> in Tempest if defcore require them.
>
> New or existing Tempest plugin for 6 core projects whose tests are
> present in Tempest, will target their functional/API/negative testing
> etc which are/should be out of scope of Tempest.
>
> Regarding the duplication of tests, we do take care of those while
> review of new tests addition. If there is any new tests proposed in
> Tempest, reviewers need to check whether same coverage is there on
> project side or not (either functional tests or in tempest plugin).
> Also if those are more appropriate to reside on project side. We will
> be continuing with the same process to avoid duplicate tests.
>

Thanks got it, So basically if any tests needed by DefCore as well as
integration tests
needed for Core  Projects will go under Tempest.

>
>>
>> [3.] For other projects while moving tests to a separate repo how we
>> are going to collaborate together to avoid
>>  duplication and move common tests to Tempest?
>
> You mean tests in projects tree as functional tests etc and their
> tempest plugin ?

Yes, For example, Swift have lots of functional tests with in tests
folder of swift project tree.
Does it go under tempest plugin?
This part i am confused.

>  If so, then same process as done in Tempest. When
> adding new tests in tempest plugin, reviewers need to check the
> duplicate coverage of those tests.
>

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

On Thu, Jun 22, 2017 at 4:38 PM, Zane Bitter  wrote:

> (Top posting. Deal with it ;)
>
>
​Yes, please keep the conversation going; top posting is fine, the k8s
issue isn't 'off topic'.
​


> You're both right!
>
> Making OpenStack monolithic is not the answer. In fact, rearranging Git
> repos has nothing to do with the answer.
>
> But back in the day we had a process (incubation) for adding stuff to
> OpenStack that it made sense to depend on being there. It was a highly
> imperfect process. We got rid of that process with the big tent reform, but
> didn't really replace it with anything at all. Tags never evolved into a
> replacement as I hoped they would.
>
> So now we have a bunch of things that are integral to building a
> "Kubernetes-like experience for application developers" - secret storage,
> DNS, load balancing, asynchronous messaging - that exist but are not in
> most clouds. (Not to mention others like fine-grained authorisation control
> that are completely MIA.)
>
> Instead of trying to drive adoption of all of that stuff, we are either
> just giving up or reinventing bits of it, badly, in multiple places. The
> biggest enemy of "do one thing and do it well" is when a thing that you
> need to do was chosen by a project in another silo as their "one thing",
> but you don't want to just depend on that project because it's not widely
> adopted.
>
> I'm not saying this is an easy problem. It's something that the
> proprietary public cloud providers don't face: if you have only one cloud
> then you can just design everything to be as tightly integrated as it needs
> to be. When you have multiple clouds and the components are optional you
> have to do a bit more work. But if those components are rarely used at all
> then you lose the feedback loop that helps create a single polished
> implementation and everything else has to choose between not integrating,
> or implementing just the bits it needs itself so that whatever smaller
> feedback loop does manage to form, the benefits are contained entirely
> within the silo. OpenStack is arguably the only cloud project that has to
> deal with this. (Azure is also going into the same market, but they already
> have the feedback loop set up because they run their own public cloud built
> from the components.) Figuring out how to empower the community to solve
> this problem is our #1 governance concern IMHO.
>
> In my view, one of the keys is to stop thinking of OpenStack as an
> abstraction layer over a bunch of vendor technologies. If you think of Nova
> as an abstraction layer over libvirt/Xen/HyperV, and Keystone as an
> abstraction layer over LDAP/ActiveDirectory, and Cinder/Neutron as an
> abstraction layer over a bunch of storage/network vendors, then two things
> will happen. The first is unrelenting "pressure from vendors to add
> yet-another-specialized-feature to the codebase" that you won't be able
> to push back against because you can't point to a competing vision. And the
> second is that you will never build a integrated, application-centric
> cloud, because the integration bit needs to happen at the layer above the
> backends we are abstracting.
>
> We need to think of those things as the compute, authn, block storage and
> networking components of an integrated, application-centric cloud. And to
> remember that *by no means* are those the only components it will need -
> "The mission of Kubernetes is much smaller than OpenStack"; there's a lot
> we need to do.
>
> So no, the strength of k8s isn't in having a monolithic git repo (and I
> don't think that's what Kevin was suggesting). That's actually a
> slow-motion train-wreck waiting to happen. Its strength is being able to do
> all of this stuff and still be easy enough to install, so that there's no
> question of trying to build bits of it without relying on shared primitives.
>
> cheers,
> Zane.
>
> On 22/06/17 13:05, Jay Pipes wrote:
>
>> On 06/22/2017 11:59 AM, Fox, Kevin M wrote:
>>
>>> My $0.02.
>>>
>>> That view of dependencies is why Kubernetes development is outpacing
>>> OpenStacks and some users are leaving IMO. Not trying to be mean here but
>>> trying to shine some light on this issue.
>>>
>>> Kubernetes at its core has essentially something kind of equivalent to
>>> keystone (k8s rbac), nova (container mgmt), cinder (pv/pvc/storageclasses),
>>> heat with convergence (deployments/daemonsets/etc), barbican (secrets),
>>> designate (kube-dns), and octavia (kube-proxy,svc,ingress) in one unit. Ops
>>> dont have to work hard to get all of it, users can assume its all there,
>>> and devs don't have many silo's to cross to implement features that touch
>>> multiple pieces.
>>>
>>
>> I think it's kind of hysterical that you're advocating a monolithic
>> approach when the thing you're advocating (k8s) is all about enabling
>> non-monolithic microservices architectures.
>>
>> Look, the fact of the matter is that OpenStack's mission is larger than
>> that of 

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

​Kevin, just one comment inline below.
​
​
On Thu, Jun 22, 2017 at 3:33 PM, Fox, Kevin M  wrote:

> No, I'm not necessarily advocating a monolithic approach.
>
> I'm saying that they have decided to start with functionality and accept
> whats needed to get the task done. Theres not really such strong walls
> between the various functionality, rbac/secrets/kublet/etc. They don't
> spawn off a whole new project just to add functionality. they do so only
> when needed. They also don't balk at one feature depending on another.
>
> rbac's important, so they implemented it. ssl cert management was
> important. so they added that. adding a feature that restricts secret
> downloads only to the physical nodes need them, could then reuse the rbac
> system and ssl cert management.
>
> Their sigs are more oriented to features/functionality (or catagories
> there of), not as much specific components. We need to do X. X may involve
> changes to components A and B.
>
> OpenStack now tends to start with A and B and we try and work backwards
> towards implementing X, which is hard due to the strong walls and unclear
> ownership of the feature. And the general solution has been to try and make
> C but not commit to C being in the core so users cant depend on it which
> hasn't proven to be a very successful pattern.
>
> Your right, they are breaking up their code base as needed, like nova did.
> I'm coming around to that being a pretty good approach to some things.
> starting things is simpler, and if it ends up not needing its own whole
> project, then it doesn't get one. if it needs one, then it gets one.  Its
> not by default, start whole new project with db user, db schema, api,
> scheduler, etc. And the project might not end up with daemons split up in
> exactly the way you would expect if you prepoptomized breaking off a
> project not knowing exactly how it might integrate with everything else.
>
> Maybe the porcelain api that's been discussed for a while is part of the
> solution. initial stuff can prototyped/start there and break off as needed
> to separate projects and moved around without the user needing to know
> where it ends up.
>
> Your right that OpenStack's scope is much grater. and think that the
> commons are even more important in that case. If it doesn't have a solid
> base, every project has to re-implement its own base. That takes a huge
> amount of manpower all around. Its not sustainable.
>
> I guess we've gotten pretty far away from discussing Trove at this point.
>

​Please keep the conversation going.
​


>
> Thanks,
> Kevin
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Thursday, June 22, 2017 10:05 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect
> Trove
>
> On 06/22/2017 11:59 AM, Fox, Kevin M wrote:
> > My $0.02.
> >
> > That view of dependencies is why Kubernetes development is outpacing
> OpenStacks and some users are leaving IMO. Not trying to be mean here but
> trying to shine some light on this issue.
> >
> > Kubernetes at its core has essentially something kind of equivalent to
> keystone (k8s rbac), nova (container mgmt), cinder (pv/pvc/storageclasses),
> heat with convergence (deployments/daemonsets/etc), barbican (secrets),
> designate (kube-dns), and octavia (kube-proxy,svc,ingress) in one unit. Ops
> dont have to work hard to get all of it, users can assume its all there,
> and devs don't have many silo's to cross to implement features that touch
> multiple pieces.
>
> I think it's kind of hysterical that you're advocating a monolithic
> approach when the thing you're advocating (k8s) is all about enabling
> non-monolithic microservices architectures.
>
> Look, the fact of the matter is that OpenStack's mission is larger than
> that of Kubernetes. And to say that "Ops don't have to work hard" to get
> and maintain a Kubernetes deployment (which, frankly, tends to be dozens
> of Kubernetes deployments, one for each tenant/project/namespace) is
> completely glossing over the fact that by abstracting away the
> infrastructure (k8s' "cloud provider" concept), Kubernetes developers
> simply get to ignore some of the hardest and trickiest parts of operations.
>
> So, let's try to compare apples to apples, shall we?
>
> It sounds like the end goal that you're advocating -- more than anything
> else -- is an easy-to-install package of OpenStack services that
> provides a Kubernetes-like experience for application developers.
>
> I 100% agree with that goal. 100%.
>
> But pulling Neutron, Cinder, Keystone, Designate, Barbican, and Octavia
> back into Nova is not the way to do that. You're trying to solve a
> packaging and installation problem with a code structure solution.
>
> In fact, if you look at the Kubernetes development community, you see
> the *opposite* direction being taken: they have broken out and are
> actively breaking out large pieces of the 

[openstack-dev] [QA][ALL] What tempest tests will go under tempest plugin for a Project?

[Chandan kumar]

Hello,

In Queen OpenStack release, We have a community goal to split In-Tree
tempest plugin to a separate repo[1.].

I have a couple question regarding the tempest tests movement within
tempest plugins.

[1.] Since some of the core OpenStack projects like Nova, Glance and
Swift does have tempest plugin currently.
 Their Tempest tests reside under tempest project repo.
 are we going to create tempest plugin for the same?
 If yes, what are the tempest tests (API/Scenario) tests moving
under tempest plugins?

[2.] And, like other core projects like neutron and cinder have their
in-tree tempest plugins also.
 And those are also moving to a separate repo and currently, their
tests also resides under tempest repo.
 How can we avoid the duplication of the tempest tests?

[3.] For other projects while moving tests to a separate repo how we
are going to collaborate together to avoid
 duplication and move common tests to Tempest?

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

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

Thank you Kevin. Lots of container (specific?) goodness here.

-amrith


-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Mon, Jun 19, 2017 at 2:34 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> Thanks for starting this difficult discussion.
>
> I think I agree with all the lessons learned except  the nova one. while
> you can treat containers and vm's the same, after years of using both, I
> really don't think its a good idea to treat them equally. Containers can't
> work properly if used as a vm. (really, really.)
>
> I agree whole heartedly with your statement that its mostly an
> orchestration problem and should reuse stuff now that there are options.
>
> I would propose the following that I think meets your goals and could
> widen your contributor base substantially:
>
> Look at the Kubernetes (k8s) concept of Operator ->
> https://coreos.com/blog/introducing-operators.html
>
> They allow application specific logic to be added to Kubernetes while
> reusing the rest of k8s to do what its good at. Container Orchestration.
> etcd is just a clustered database and if the operator concept works for it,
> it should also work for other databases such as Gallera.
>
> Where I think the containers/vm thing is incompatible is the thing I think
> will make Trove's life easier. You can think of a member of the database as
> few different components, such as:
>  * main database process
>  * metrics gatherer (such as https://github.com/prometheus/mysqld_exporter
> )
>  * trove_guest_agent
>
> With the current approach, all are mixed into the same vm image, making it
> very difficult to update the trove_guest_agent without touching the main
> database process. (needed when you upgrade the trove controllers). With the
> k8s sidecar concept, each would be a separate container loaded into the
> same pod.
>
> So rather then needing to maintain a trove image for every possible
> combination of db version, trove version, etc, you can reuse upstream
> database containers along with trove provided guest agents.
>
> There's a secure channel between kube-apiserver and kubelet so you can
> reuse it for secure communications. No need to add anything for secure
> communication. trove engine -> kubectl exec x-db -c guest_agent some
> command.
>
> There is k8s federation, so if the operator was started at the federation
> level, it can cross multiple OpenStack regions.
>
> Another big feature I that hasn't been mentioned yet that I think is
> critical. In our performance tests, databases in VM's have never performed
> particularly well. Using k8s as a base, bare metal nodes could be pulled in
> easily, with dedicated disk or ssd's that the pods land on that are very
> very close to the database. This should give native performance.
>
> So, my suggestion would be to strongly consider basing Trove v2 on
> Kubernetes. It can provide a huge bang for the buck, simplifying the Trove
> architecture substantially while gaining the new features your list as
> being important. The Trove v2 OpenStack api can be exposed as a very thin
> wrapper over k8s Third Party Resources (TPR) and would make Trove entirely
> stateless. k8s maintains all state for everything in etcd.
>
> Please consider this architecture.
>
> Thanks,
> Kevin
>
> --
> *From:* Amrith Kumar [amrith.ku...@gmail.com]
> *Sent:* Sunday, June 18, 2017 4:35 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [trove][all][tc] A proposal to rearchitect
> Trove
>
> Trove has evolved rapidly over the past several years, since integration
> in IceHouse when it only supported single instances of a few databases.
> Today it supports a dozen databases including clusters and replication.
>
> The user survey [1] indicates that while there is strong interest in the
> project, there are few large production deployments that are known of (by
> the development team).
>
> Recent changes in the OpenStack community at large (company realignments,
> acquisitions, layoffs) and the Trove community in particular, coupled with
> a mounting burden of technical debt have prompted me to make this proposal
> to re-architect Trove.
>
> This email summarizes several of the issues that face the project, both
> structurally and architecturally. This email does not claim to include a
> detailed specification for what the new Trove would look like, merely the
> recommendation that the community should come together and develop one so
> that the project can be sustainable and useful to those who wish to use it
> in the future.
>
> TL;DR
>
> Trove, with support for a dozen or so databases today, finds itself in a
> bind because there

[openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

Trove has evolved rapidly over the past several years, since integration in
IceHouse when it only supported single instances of a few databases. Today
it supports a dozen databases including clusters and replication.

The user survey [1] indicates that while there is strong interest in the
project, there are few large production deployments that are known of (by
the development team).

Recent changes in the OpenStack community at large (company realignments,
acquisitions, layoffs) and the Trove community in particular, coupled with
a mounting burden of technical debt have prompted me to make this proposal
to re-architect Trove.

This email summarizes several of the issues that face the project, both
structurally and architecturally. This email does not claim to include a
detailed specification for what the new Trove would look like, merely the
recommendation that the community should come together and develop one so
that the project can be sustainable and useful to those who wish to use it
in the future.

TL;DR

Trove, with support for a dozen or so databases today, finds itself in a
bind because there are few developers, and a code-base with a significant
amount of technical debt.

Some architectural choices which the team made over the years have
consequences which make the project less than ideal for deployers.

Given that there are no major production deployments of Trove at present,
this provides us an opportunity to reset the project, learn from our v1 and
come up with a strong v2.

An important aspect of making this proposal work is that we seek to
eliminate the effort (planning, and coding) involved in migrating existing
Trove v1 deployments to the proposed Trove v2. Effectively, with work
beginning on Trove v2 as proposed here, Trove v1 as released with Pike will
be marked as deprecated and users will have to migrate to Trove v2 when it
becomes available.

While I would very much like to continue to support the users on Trove v1
through this transition, the simple fact is that absent community
participation this will be impossible. Furthermore, given that there are no
production deployments of Trove at this time, it seems pointless to build
that upgrade path from Trove v1 to Trove v2; it would be the proverbial
bridge from nowhere.

This (previous) statement is, I realize, contentious. There are those who
have told me that an upgrade path must be provided, and there are those who
have told me of unnamed deployments of Trove that would suffer. To this,
all I can say is that if an upgrade path is of value to you, then please
commit the development resources to participate in the community to make
that possible. But equally, preventing a v2 of Trove or delaying it will
only make the v1 that we have today less valuable.

We have learned a lot from v1, and the hope is that we can address that in
v2. Some of the more significant things that I have learned are:

- We should adopt a versioned front-end API from the very beginning; making
the REST API versioned is not a ‘v2 feature’

- A guest agent running on a tenant instance, with connectivity to a shared
management message bus is a security loophole; encrypting traffic,
per-tenant-passwords, and any other scheme is merely lipstick on a security
hole

- Reliance on Nova for compute resources is fine, but dependence on Nova VM
specific capabilities (like instance rebuild) is not; it makes things like
containers or bare-metal second class citizens

- A fair portion of what Trove does is resource orchestration; don’t
reinvent the wheel, there’s Heat for that. Admittedly, Heat wasn’t as far
along when Trove got started but that’s not the case today and we have an
opportunity to fix that now

- A similarly significant portion of what Trove does is to implement a
state-machine that will perform specific workflows involved in implementing
database specific operations. This makes the Trove taskmanager a stateful
entity. Some of the operations could take a fair amount of time. This is a
serious architectural flaw

- Tenants should not ever be able to directly interact with the underlying
storage and compute used by database instances; that should be the default
configuration, not an untested deployment alternative

- The CI should test all databases that are considered to be ‘supported’
without excessive use of resources in the gate; better code modularization
will help determine the tests which can safely be skipped in testing changes

- Clusters should be first class citizens not an afterthought, single
instance databases may be the ‘special case’, not the other way around

- The project must provide guest images (or at least complete tooling for
deployers to build these); while the project can’t distribute operating
systems and database software, the current deployment model merely impedes
adoption

- Clusters spanning OpenStack deployments are a real thing that must be
supported

This might sound harsh, that isn’t the intent. Each of these is the

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

[Vikash Kumar]

On Fri, Jun 16, 2017 at 3:39 PM, Thierry Carrez 
wrote:

> Shake Chen wrote:
> > HI Vikash
> >
> > I think Kolla is suitable for official project for deployment
>
> Deployment tooling is, by nature, opinionated. You just can't enable
> everything and keep it manageable. As long as people will have differing
> opinions on how OpenStack pieces should be deployed, which drivers or
> components should actually be made available, or the level of
> fine-tuning that should be exposed, you will have different deployment
> tools.
>
> "Picking one" won't magically make everyone else stop working on their
> specific vision for it, and suddenly force everyone to focus on a single
> solution. It will, however, hamper open collaboration between
> organizations on alternative approaches.
>

​"Picking one" is not, but having the minimal one (core components) is
what I see in the best interest of Openstack. ​I agree that the
deployment is very opinionated but before some one go for deployment
they need to evaluate few things, get some confidence. Right now,
the only option is either turn to vendors or get the experts to do. Or Am i
missing something and Openstack can be evaluated by any organization
without any hassle ?
Having a minimal deployment software will ease this process and kind of
increase
the audience. I don't see having this will create any conflict or hinder any
collaboration.


> My personal view is that it's a space where we need to let flowers bloom
> and encourage open collaboration. We just need to clean up the garden
> when those flowers don't go anywhere.
>
> --
> 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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

[Vikash Kumar]

I strongly believe Openstack must have any one official project for
deployment whether its Fuel or anything else. Cutting it short, talking to
number of people across industry/academic/government institutions, got a
sense that its necessary that there should be a official tool more than
Devstack for deployment.

Regards,
Vikash

On Fri, Jun 16, 2017 at 2:20 AM, Dean Troyer  wrote:

> On Thu, Jun 15, 2017 at 10:33 AM, Jay Pipes  wrote:
> > I'd fully support the removal of all deployment projects from the
> "official
> > OpenStack projects list".
>
> Nice to hear Jay! :)
>
> It was intentional from the beginning to not be in the deployment
> space, we allowed those projects in (not unanimously IIRC) and most of
> them did not evolve as expected.
>
> I would not mind picking one winner and spending effort making an
> extremely easy, smooth, upgradable install that is The OneTrue
> OpenStack, I do not expect us to ever agree what that will look like
> so it is effectively never going to happen.  We've seen how far
> single-vendor projects have gone, and none of them reached that level.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Moving away from "big tent" terminology

[Amrith Kumar]

I'm confused by the proposal; you've made a 1-1 substitution of "big tent"
with "openstack project" and then there are some "openstack hosted
projects".

How does that clarify the situation?

It does not help me answer the question "Is Trove part of OpenStack?" with
any more clarity than before.

So I'm missing something and judging by the follow-up's I'm not the only
one.

And yes, "friends of OpenStack" only begs the question who are not friends
of OpenStack :)

-amrith


-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Thu, Jun 15, 2017 at 8:57 AM, Thierry Carrez <thie...@openstack.org>
wrote:

> Sean Dague wrote:
> > [...]
> > I think those are all fine. The other term that popped into my head was
> > "Friends of OpenStack" as a way to describe the openstack-hosted efforts
> > that aren't official projects. It may be too informal, but I do think
> > the OpenStack-Hosted vs. OpenStack might still mix up in people's head.
>
> My original thinking was to call them "hosted projects" or "host
> projects", but then it felt a bit incomplete. I kinda like the "Friends
> of OpenStack" name, although it seems to imply some kind of vetting that
> we don't actually do.
>
> An alternative would be to give "the OpenStack project infrastructure"
> some kind of a brand name (say, "Opium", for OpenStack project
> infrastructure ultimate madness) and then call the hosted projects
> "Opium projects". Rename the Infra team to Opium team, and voilà!
>
> --
> 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

Re: [openstack-dev] [all] Call for check: is your project ready for pylint 1.7.1?

[Amrith Kumar]

I guess this mail thread and the questions asked here fell on deaf ears because 
I see https://review.openstack.org/#/c/472891/1 marching its way to merging.

--
Amrith Kumar
amrith.ku...@gmail.com


> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Friday, June 9, 2017 12:34 PM
> To: openstack-dev <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [all] Call for check: is your project ready for
> pylint 1.7.1?
> 
> Excerpts from Akihiro Motoki's message of 2017-06-09 03:53:34 +0900:
> > Hi all,
> >
> > Is your project ready for pylint 1.7.1?
> > If you use pylint in your pep8 job, it is worth checked.
> >
> > Our current version of pylint is 1.4.5 but it is not safe in python 3.5.
> > The global-requirements update was merged once [1], However, some
> > projects (at least neutron) are not ready for pylint
> > 1.7.1 and it was reverted [2].
> > it is reasonable to give individual projects time to cope with pylint
> 1.7.1.
> >
> > I believe bumping pylint version to 1.7.1 (or later) is the right
> > direction in long term.
> > I would suggest to make your project ready for pylint 1.7.1 soon (two
> > weeks or some?) You can disable new rules in pylint 1.7.1 temporarily
> > and clean up your code later as neutron does [3]. As far as I checked,
> > most rules are reasonable and worth enabled.
> >
> > Thanks,
> > Akihiro Motoki
> >
> > [1] https://review.openstack.org/#/c/470800/
> > [2] https://review.openstack.org/#/c/471756/
> > [3] https://review.openstack.org/#/c/471763/
> >
> 
> I thought we had linters in a list that didn't require the versions to be
> synced across projects, to allow projects to update at their own pace. Did we
> undo that work?
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] Call for check: is your project ready for pylint 1.7.1?

[Amrith Kumar]

Thanks, Sean.

I will heartily second that request/proposal.

-amrith


-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Fri, Jun 9, 2017 at 11:07 AM, Sean Dague <s...@dague.net> wrote:

> On 06/08/2017 02:53 PM, Akihiro Motoki wrote:
> > Hi all,
> >
> > Is your project ready for pylint 1.7.1?
> > If you use pylint in your pep8 job, it is worth checked.
> >
> > Our current version of pylint is 1.4.5 but it is not safe in python 3.5.
> > The global-requirements update was merged once [1],
> > However, some projects (at least neutron) are not ready for pylint
> > 1.7.1 and it was reverted [2].
> > it is reasonable to give individual projects time to cope with pylint
> 1.7.1.
> >
> > I believe bumping pylint version to 1.7.1 (or later) is the right
> > direction in long term.
> > I would suggest to make your project ready for pylint 1.7.1 soon (two
> > weeks or some?)
> > You can disable new rules in pylint 1.7.1 temporarily and clean up
> > your code later
> > as neutron does [3]. As far as I checked, most rules are reasonable
> > and worth enabled.
> >
> > Thanks,
> > Akihiro Motoki
> >
> > [1] https://review.openstack.org/#/c/470800/
> > [2] https://review.openstack.org/#/c/471756/
> > [3] https://review.openstack.org/#/c/471763/
>
> Please only make changes like this in the first milestone of the cycle.
> Lint requirements changes are distracting, and definitely shouldn't be
> happening during the final milestone.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Call for check: is your project ready for pylint 1.7.1?

[Amrith Kumar]

​Is there a driving reason why this has to be done in the Pike cycle? The
requirements freeze is coincident with Pike-3 and your two week deadline
puts it pretty close to that date so I'm going to assume that you will have
to make this change before p3.

Trove is another of the projects that went down in flames with the new
pylint and I'm wondering what benefit this has for projects in general. The
notion of accumulating more technical debt (enable pylint 1.7.1 and disable
the new tests, cleanup code later) strikes me as less than ideal.

Thanks,

-amrith​



-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Thu, Jun 8, 2017 at 1:53 PM, Akihiro Motoki <amot...@gmail.com> wrote:

> Hi all,
>
> Is your project ready for pylint 1.7.1?
> If you use pylint in your pep8 job, it is worth checked.
>
> Our current version of pylint is 1.4.5 but it is not safe in python 3.5.
> The global-requirements update was merged once [1],
> However, some projects (at least neutron) are not ready for pylint
> 1.7.1 and it was reverted [2].
> it is reasonable to give individual projects time to cope with pylint
> 1.7.1.
>
> I believe bumping pylint version to 1.7.1 (or later) is the right
> direction in long term.
> I would suggest to make your project ready for pylint 1.7.1 soon (two
> weeks or some?)
> You can disable new rules in pylint 1.7.1 temporarily and clean up
> your code later
> as neutron does [3]. As far as I checked, most rules are reasonable
> and worth enabled.
>
> Thanks,
> Akihiro Motoki
>
> [1] https://review.openstack.org/#/c/470800/
> [2] https://review.openstack.org/#/c/471756/
> [3] https://review.openstack.org/#/c/471763/
>
> __
> OpenStack Development Mailing 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] Proposed changes to the team meeting time

[Chandan kumar]

On Thu, Jun 8, 2017 at 4:04 PM, Andrea Frittoli
<andrea.fritt...@gmail.com> wrote:
> I proposed a change to irc-meetings [1] to move the meeting to 8:00 UTC.
> The first 8:00 UTC meeting will be next week June 15th.
>
> [1] https://review.openstack.org/472194
>

It will be helpful.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] [reno] we need help reviewing patches to reno

[Vikash Kumar]

Hi Doug,

 Will participate in reno reviews.

Regards,
Vikash

*"Without requirements or design, programming is the art of adding bugs to
an empty text file."- Louis Srygley*

On Tue, Jun 6, 2017 at 8:41 PM, Julien Danjou  wrote:

> On Tue, Jun 06 2017, Doug Hellmann wrote:
>
> > I am looking for one or two people interested in learning about how reno
> > works to help with reviews. If you like graph traversal algorithms
> > and/or text processing, have a look at the code in the openstack/reno
> > repository and let me know if you're interested in helping out.
>
> I've added it to my list of watched projects. I'll try to review patches
> as they come in. I use reno and I like it. :)
>
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
>
> __
> OpenStack Development Mailing 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][tc][all] Tempest to reject trademark tests

[Amrith Kumar]

> -Original Message-
> From: Sean McGinnis [mailto:sean.mcgin...@gmx.com]
> Sent: Thursday, June 1, 2017 4:48 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [qa][tc][all] Tempest to reject trademark tests
> 
> >
> > And yes, I agree with the argument that we should be fair and treat
> > all projects the same way. If we're going to move tests out of the
> > tempest repository, we should move all of them. The QA team can still
> > help maintain the test suites for whatever projects they want, even if
> > those tests are in plugins.
> >
> > Doug
> >
> 
> +1

+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