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] 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] [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.

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

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

Re: [openstack-dev] [tc][ptls][all] Potential Queens Goal: Migrate Off Paste

[Amrith Kumar]

OK, I'd assumed that from earlier conversations about py35 being a 
multi-release goal, that it would have been a shoe-in. But yes, if it is still 
a possibility that the community would do py1.75 in pike and not commit to the 
other py1.75 in queens, sure, there's only one committed goal for queens (which 
I still don't understand, I've been told).

-amrith

--
Amrith Kumar


> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Thursday, June 1, 2017 12:38 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc][ptls][all] Potential Queens Goal: Migrate
> Off Paste
> 
> Amrith Kumar wrote:
> > Thierry, isn't the py35 goal continuing for Queens?
> 
> That's an open question, which is discussed in its own thread:
> http://lists.openstack.org/pipermail/openstack-dev/2017-May/117746.html
> 
> --
> 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][ptls][all] Potential Queens Goal: Migrate Off Paste

[Amrith Kumar]

Thierry, isn't the py35 goal continuing for Queens?

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


> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Thursday, June 1, 2017 4:35 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc][ptls][all] Potential Queens Goal: Migrate
> Off Paste
> 
> Amrith Kumar wrote:
> > I agree, this would be a good thing to do and something which will
> definitely improve the overall ease of upgrades. We already have two Queens
> goals though; do we want to add a third?
> 
> Hmm, we only have one so far ?
> 
> https://governance.openstack.org/tc/goals/queens/index.html
> 
> --
> 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][ptls][all] Potential Queens Goal: Migrate Off Paste

[Amrith Kumar]

I agree, this would be a good thing to do and something which will definitely 
improve the overall ease of upgrades. We already have two Queens goals though; 
do we want to add a third?

-amrith

P.S. I'd happily volunteer doing this, with a real end user benefit, over the 
current tempest shuffle goal. My 2c worth.

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


> -Original Message-
> From: Mike [mailto:thin...@gmail.com]
> Sent: Wednesday, May 31, 2017 4:39 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Cc: Sean Dague <s...@dague.net>
> Subject: [openstack-dev] [tc][ptls][all] Potential Queens Goal: Migrate Off
> Paste
> 
> Hello everyone,
> 
> As part of our community wide goals process [1], we will discuss the
> potential goals that came out of the forum session in Boston [2].
> These discussions will aid the TC in making a final decision of what goals
> the community will work towards in the Queens release.
> 
> For this thread we will be discussing migrating off paste. This was suggested
> by Sean Dague. I’m not sure if he’s leading this effort, but here’s a excerpt
> from him to get us started:
> 
> A migration path off of paste would be a huge win. Paste deploy is
> unmaintained (as noted in the etherpad) and being in etc means it's another
> piece of gratuitous state that makes upgrading harder than it really should
> be. This is one of those that is going to require someone to commit to
> working out that migration path up front. But it would be a pretty good chunk
> of debt and upgrade ease.
> 
> 
> [1] - https://governance.openstack.org/tc/goals/index.html
> [2] - https://etherpad.openstack.org/p/BOS-forum-Queens-Goals
> 
> —
> 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] [qa][tc][all] Tempest to reject trademark tests

[Amrith Kumar]

I've been following this discussion from a safe distance on the mailing
list, and I just caught up on the IRC conversation as well.

It was my understanding that if a project had tests that were going to be
run for the purposes of determination whether something met the standards of
"OpenStack Powered Databases" (TBD), then those tests would reside in the
tempest repository. Any other tempest tests that the project would have for
any purpose (or purposes) should, I understand, be moved into an independent
repository per the Queens community goal[1].

I'm particularly interested in having this matter decided in an email thread
such as this one because of the comment in IRC about a verbal discussion at
the forum not being considered to be a 'binding decision' [2]. It had been
my understanding that the forum and the PTG were places where 'decisions'
were made, but if that is not the case, I'm hoping that one will be
documented as part of this thread and formalized (maybe) with a resolution
by the TC or the Interop/DefCore body?

-amrith


[1]
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.201
7-05-31.log.html#t2017-05-31T15:39:33

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


> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Wednesday, May 31, 2017 12:24 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
> 
> On 2017-05-31 17:18:54 +0100 (+0100), Graham Hayes wrote:
> [...]
> > Trademark programs are trademark programs - we should have a unified
> > process for all of them. Let's not make the same mistakes again by
> > creating classes of projects / programs. I do not want this to be a
> > distinction as we move forward.
> 
> This I agree with. However I'll be surprised if a majority of the QA team
> disagree on this point (logistic concerns with how to curate this over
time I
> can understand, but that just means they need to interest some people in
> working on a manageable solution).
> --
> 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

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

[Amrith Kumar]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Wednesday, May 31, 2017 12:00 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master
> 
> On 05/31/2017 02:14 AM, Clint Byrum wrote:
> > Either way, it should be much simpler to manage slave lag than to deal
> > with a Galera cluster that won't accept any writes at all because it
> > can't get quorum.
> 
> Would CockroachDB be any better at achieving quorum?
> 
> Genuinely curious. :)

[Amrith Kumar] Last I read about this was in [1] and it sounded like it would 
be no better, or worse.

[1] https://www.cockroachlabs.com/blog/consensus-made-thrive/

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


__
OpenStack Development Mailing 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] Changing project schemas in patches; upgrade implications

[Amrith Kumar]

Thx Monty, jroll, smcginnis, zzzeek_ ...


-amrith

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


On Wed, May 31, 2017 at 10:17 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 05/31/2017 08:51 AM, Amrith Kumar wrote:
>
>> This email thread relates to[1], a change that aims to improve cross-SQL
>> support in project schemas.
>>
>> I want to explicitly exclude the notion of getting rid of support for
>> PostgreSQL in the underlying project schemas, a topic that was discussed at
>> the summit[2].
>>
>> In this change, the author (Thomas Bechtold, copied on this thread) makes
>> the comment that the change "is not changing the schema. It just avoids
>> implicit type conversion".
>>
>> It has long been my understanding that changes like this are not upgrade
>> friendly as it could lead to two installations both with, say version 37 or
>> 38 of the schema, but different table structures. In effect, this change
>> breaks upgradability of systems.
>>
>> i.e. a deployment which had a schema from the install of Ocata would have
>> a v38 table modules table with a default of 0 and one installed with Pike
>> (should this change be accepted) would have a modules table with a default
>> of False.
>>
>
> I agree that if that was the case this would be bad. But I don't think
> it's the case here.
>
> The datatype in the model is already Boolean. So I believe that means this
> will be a tinyint in MySQL and likely a boolean in PG (I'm guessing) the
> only change here is to the SQLA layer in what is being used in code - and
> being more explicit seems good.
>
> So I think this is a win.
>
> I'm raising this issue on the ML because the author also claims (albeit
>> not verified by me) that other projects have accepted changes like this.
>>
>
> Thanks! I think this is an area we need to be careful in - and extra
> eyeballs are a good thing.
>
> I submit to you that the upgrade friendly way of making this change would
>> be to propose a new version of the schema which alters all of these tables
>> and includes the correct default value. On a fresh install, with no data,
>> the upgrade step with this new schema version would bring the table to the
>> right default value and any system with that version of the schema would
>> have an identical set of defaults. Similarly any system with v37 or 38 of
>> the schema would have identical defaults.
>>
>
> Yes - I agree - that would definitely be the right way to do this if there
> was a model change.
>
> What's the advice of the community on this change; I've explicitly added
>> stable-maint-core as reviewers on this change as it does have stable branch
>> upgrade implications.
>>
>> -amrith
>>
>> [1] https://review.openstack.org/#/c/467080/
>> ​[2]https://etherpad.openstack.org/p/BOS-postgresql
>> ​
>> ​​
>>
>> --
>> Amrith Kumar
>> Phone: +1-978-563-9590
>>
>>
>>
>> 
>> __
>> 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] Changing project schemas in patches; upgrade implications

[Amrith Kumar]

This email thread relates to[1], a change that aims to improve cross-SQL
support in project schemas.

I want to explicitly exclude the notion of getting rid of support for
PostgreSQL in the underlying project schemas, a topic that was discussed at
the summit[2].

In this change, the author (Thomas Bechtold, copied on this thread) makes
the comment that the change "is not changing the schema. It just avoids
implicit type conversion".

It has long been my understanding that changes like this are not upgrade
friendly as it could lead to two installations both with, say version 37 or
38 of the schema, but different table structures. In effect, this change
breaks upgradability of systems.

i.e. a deployment which had a schema from the install of Ocata would have a
v38 table modules table with a default of 0 and one installed with Pike
(should this change be accepted) would have a modules table with a default
of False.

I'm raising this issue on the ML because the author also claims (albeit not
verified by me) that other projects have accepted changes like this.

I submit to you that the upgrade friendly way of making this change would
be to propose a new version of the schema which alters all of these tables
and includes the correct default value. On a fresh install, with no data,
the upgrade step with this new schema version would bring the table to the
right default value and any system with that version of the schema would
have an identical set of defaults. Similarly any system with v37 or 38 of
the schema would have identical defaults.

What's the advice of the community on this change; I've explicitly added
stable-maint-core as reviewers on this change as it does have stable branch
upgrade implications.

-amrith

[1] https://review.openstack.org/#/c/467080/
​[2]https://etherpad.openstack.org/p/BOS-postgresql
​
​​

--
Amrith Kumar
Phone: +1-978-563-9590
__
OpenStack Development Mailing 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] Onboarding rooms postmortem, what did you do, what worked, lessons learned

[Amrith Kumar]

Kendall,

I would like to be the Trove liaison, and would like to participate in
Upstream University next time around.

With that said, the answers to Sean's original question.

I ran the room for the Trove team, I think it was a welcome addition.

What went well: I think it was a good opportunity for the project to get
new contributors (update: if you are interested in contributing to an
openstack project, trove is looking for new participants).

It would have been nice to have them video taped.

-amrith


-amrith

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


On Wed, May 24, 2017 at 6:20 PM, Kendall Nelson <kennelso...@gmail.com>
wrote:

> @Nikhil, we (the organizers of Upstream Institute) sent a few emails
> [1][2] out to the dev mailing list asking for help and representatives from
> various projects to attend and get involved. We are also working on
> building a network of project liaisons to direct newcomers to in each
> project. Would you be interested in being our Glance liaison?
>
> Let me know if you have any other Upstream Institute questions!
>
> - Kendall(diablo_rojo)
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> January/110788.html
> [2]  http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/108084.html
>
> On Wed, May 24, 2017 at 4:03 PM Nikhil Komawar <nik.koma...@gmail.com>
> wrote:
>
>> Project:  Glance
>>
>> Attendees: ~15
>>
>> What was done:
>>
>> We started by introducing the core team (or whatever existed then), did a
>> run down of Glance API documentation especially for developers, other
>> references like notes for ops, best practices. We went through the
>> architecture of the project. A few were interested in knowing more details
>> and going in depth so we discussed the design patterns that exist today,
>> scope of improvements and any blackholes therein, auxiliary services and
>> performance tradeoffs etc. A lot of the discussion was free form so people
>> asked questions and session was interactive.
>>
>>
>> What worked:
>>
>> 1. The projector worked!
>>
>> 2. Session was free form, there was good turnout and it was interactive.
>> (all the good things)
>>
>> 3. People were serious about contributing as per their
>> availability/capacity to do upstream and one person showed up asking to do
>> reviews.
>>
>>
>> Lessons:
>>
>> 1. Could have been advertised more at least the session description more
>> customized.
>>
>> 2. A representative from the team could have been officially invited to
>> the upstream institute training.
>>
>> 3. The community building sessions and on-boarding sessions seem to
>> overlap a bit so a representative from the team could be help in those
>> sessions for Q or more interaction. Probably more collaboration/prep
>> before the summit for such things. ($0.02)
>>
>>
>> Cheers
>>
>> On Wed, May 24, 2017 at 1:27 PM, Jay S Bryant <jungleb...@gmail.com>
>> wrote:
>>
>>> Project:  Cinder
>>>
>>> Attendees: Approximately 30
>>>
>>> I was really pleased by the number of people that attended the Cinder
>>> session and the fact that they people in the room seemed engaged with the
>>> presentation and asked good questions showing interest in the project.  I
>>> think having the on-boardings rooms was beneficial and hopefully something
>>> that we can continue.
>>>
>>> Given the number of people in the room we didn't go around and introduce
>>> everyone.  I did have the Sean McGinnis introduce himself as PTL and had
>>> the other Cinder Core members introduce themselves so that the attendees
>>> could put faces with our names.
>>>
>>> From there we kicked off the presentation [1] which covered the
>>> following high level topics:
>>>
>>>- Introduction of Cinder's Repos and components
>>>- Quick overview of Cinder's architecture/organization
>>>- Pointers to the Upstream Institute education (Might have done a
>>>bit of a sales pitch for the next session here ;-))
>>>- Expanded upon the Upstream Institute education to explain how what
>>>was taught there specifically applied to Cinder
>>>- Walked through the main Cinder code tree
>>>- Described how to test changes to Cinder
>>>
>>> My presentation was designed to assume that attendees had been through
>>> Upstream Institute.  I had coverage in the slides in case they had not been
>>> through the education.  Unfortunately most of the c

Re: [openstack-dev] [ptg] Strawman Queens PTG week slicing

[Amrith Kumar]

Thierry,

Thanks for doing this. Two specific points below.

1. You can schedule Trove for Wednesday and Thursday, skip the Friday.

2. Similar to the idea of splitting the project things from the cross
project/infra things, would it be possible to have projects try and keep
their project specific (non cross project) topics to one of the days and
give a preference to cross project things on another day. This may help
with scheduling cross project participation.

Thanks,

-amrith


-amrith

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


On Wed, May 24, 2017 at 10:44 AM, Thierry Carrez <thie...@openstack.org>
wrote:

> Doug Hellmann wrote:
> > Two questions about theme-based initiatives:
> >
> > I would like to have a discussion about the work to stop syncing
> > requirements and to see if we can make progress on the implementation
> > while we have the right people together. That seems like a topic
> > for Monday or Tuesday. Would I reserve one of the "last-minute WG"
> > rooms or extra rooms (it doesn't feel very last-minute if I know
> > about it now)?
>
> We have some flexibility there, depending on how much time we need. If
> it's an hour or two, I would go and book one of the "reservable rooms".
> If it's a day or two, I would assign one of the rooms reserved for
> upcoming workgroups/informal teams. "Last-minute" is confusing (just
> changed it on the spreadsheet), those rooms are more to cater for needs
> that are not represented in formal workgroups today.
>
> > I don't see a time on here for the Docs team to work together on
> > the major initiative they have going to change how publishing works.
> > I didn't have the impression that we could anticipate that work
> > being completed this cycle. Is the "helproom" going to be enough,
> > or do we need a separate session for that, too?
>
> Again, we should be pretty flexible on that. We can reuse the doc
> helproom, or we can say that the doc helproom is only on one day and the
> other day is dedicated to making the doc publishing work. And if the doc
> refactoring ends up being a release goal, it could use a release goal
> room instead.
>
> All in all, the idea is to show that on Mon-Tue we have a number of
> rooms set apart to cover for any inter-project need we may have (already
> identified or not). The room allocation is actually much tighter on
> Wed-Thu :)
>
> --
> 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] on the subject of when we should be deprecating API's in a release cycle

[Amrith Kumar]

> -Original Message-
> From: Matt Riedemann [mailto:mriede...@gmail.com]
> Sent: Tuesday, May 23, 2017 8:59 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] on the subject of when we should be deprecating
> API's in a release cycle
> 
> On 5/23/2017 7:50 PM, Amrith Kumar wrote:
> > TL;DR
> >
> > When IaaS projects in OpenStack deprecate their API's after milestone
> > 1, it puts PaaS projects in a pickle. I think it would be much better
> > for PaaS projects if the IaaS projects could please do their
> > deprecations well before
> > milestone-1
> >
> > The longer issue:
> >
> > OK, the guy from Trove is bitching again. The Trove gate is broken (again).
> > This time, it appears to be because Trove was using a deprecated Nova
> > Networking API call, and even though everyone and their brother knew
> > that Nova Networking was gone-gone, Trove never got the memo, and like
> > a few others got hit by it.
> >
> > But the fact of the matter is this, it happened. This has happened in
> > previous releases as well where at milestone 2 we are scrambling to
> > fix something because an IaaS project did a planned deprecation.
> >
> > I'm wondering whether we can get a consensus around doing these
> > earlier in the cycle, like before milestone-1, so other projects which
> > depend on the API have a chance to handle it with enough time to test and
> verify.
> >
> > Just to be explicitly clear, I AM NOT pointing fingers at Nova. I knew
> > that NN was gone, just that a couple of API's remained in use and we
> > got bit in the glueteus maximus. I asked Matt for help to find out
> > what API's had been deprecated, he almost immediately helped me with a
> > list and I'm working through getting them fixed (Thanks Matt).
> >
> > I'm merely raising the generic question of whether or not planned
> > deprecations should be done before Milestone 1.
> >
> > Thanks for reading the longer version ...
> >
> > --
> > Amrith Kumar
> > amrith.ku...@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
> >
> 
> The novaclient changes to deprecate the networking proxy CLIs and APIs was
> done in the Newton release. They were removed and released in 8.0.0 which was
> milestone 1 of the Pike release. So what are you specifically asking for
> here? Maybe Trove didn't get hit until recently because novaclient 8.0.0
> wasn't pulled into upper-constraints? That might have been why it seems
> recent for Trove. I think the u-c change was gating on Horizon fixing their
> stuff, but maybe u-c changes aren't gated on Trove unit tests?
> 
[Amrith Kumar] Hmm, trove's unit tests are gating against u-c, so that may have 
been the reason. You may be correct, u-c changes are not gated on Trove yet and 
I hesitate to request that given how flaky our gate currently is. The container 
stuff is coming along nicely and is much more reliable so I may be able to have 
a reliable containerized version that can be tested against before long and 
then I will request gating u-c changes on Trove as well.

> Admittedly the python API binding deprecations in novaclient weren't using
> the python warnings module with the DeprecationWarning, which we've been
> pretty consistent about with other API deprecations in the novaclient (like
> with the volume, image and baremetal proxy APIs). We dropped the ball on the
> networking ones though. We have docs in novaclient about how to deprecate
> things, but it's mostly CLI-focused so I'm going to update that to be
> explicit about deprecation warnings in the API bindings too.
> 

[Amrith Kumar] Yeah, but I won't try to hide behind that; we should have seen 
this coming. In fairness, looking at how the neutron stuff is implemented in 
Trove makes me believe that we have a refactoring project in the near future.

> --
> 
> 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] on the subject of when we should be deprecating API's in a release cycle

[Amrith Kumar]

TL;DR

When IaaS projects in OpenStack deprecate their API's after milestone 1, it
puts PaaS projects in a pickle. I think it would be much better for PaaS
projects if the IaaS projects could please do their deprecations well before
milestone-1

The longer issue:

OK, the guy from Trove is bitching again. The Trove gate is broken (again).
This time, it appears to be because Trove was using a deprecated Nova
Networking API call, and even though everyone and their brother knew that
Nova Networking was gone-gone, Trove never got the memo, and like a few
others got hit by it.

But the fact of the matter is this, it happened. This has happened in
previous releases as well where at milestone 2 we are scrambling to fix
something because an IaaS project did a planned deprecation.

I'm wondering whether we can get a consensus around doing these earlier in
the cycle, like before milestone-1, so other projects which depend on the
API have a chance to handle it with enough time to test and verify.

Just to be explicitly clear, I AM NOT pointing fingers at Nova. I knew that
NN was gone, just that a couple of API's remained in use and we got bit in
the glueteus maximus. I asked Matt for help to find out what API's had been
deprecated, he almost immediately helped me with a list and I'm working
through getting them fixed (Thanks Matt).

I'm merely raising the generic question of whether or not planned
deprecations should be done before Milestone 1.

Thanks for reading the longer version ...

--
Amrith Kumar
amrith.ku...@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-dev] [trove][all] Weekly meeting time change - 1500UTC #openstack-meeting-alt

[Amrith Kumar]

The Trove weekly meeting time has been changed from 1800UTC on Wednesdays to
1500UTC on Wednesdays[1]. Thanks to Trevor for following up on this action
item from the discussions we had in the summit in Boston.

This change has been made to accommodate some new participants to the
community from Europe and China, and advancing the meeting time by three
hours makes the time more convenient for them and not terrible for the rest
of us.

The first meeting at this new time[2] will be on this coming Wednesday,
24th. As always, the meeting agenda can be found at [3].

Thanks,

-amrith

[1] https://review.openstack.org/#/c/466381/
[2] http://eavesdrop.openstack.org/#Trove_(DBaaS)_Team_Meeting
[3] https://wiki.openstack.org/wiki/Meetings/TroveMeeting
--
Amrith Kumar
GPG: 0x5e48849a9d21a29b



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

Re: [openstack-dev] [tc][all] Do we need a #openstack-tc IRC channel

[Amrith Kumar]

In keeping with the brevity of the email below, 

YES

Enough others have opined on the why, I have nothing new to add and I am happy 
to just say +1 ...

-amrith

> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: Tuesday, May 16, 2017 9:39 AM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] [tc][all] Do we need a #openstack-tc IRC channel
> 
> Folks,
> 
> See $TITLE :)
> 
> Thanks,
> Dims
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] Trove meeting time update

[Amrith Kumar]

Thanks for doing this Trevor, I am hoping that this patch merges soon so we can 
do the new meeting time on Wednesday.

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


> -Original Message-
> From: MCCASLAND, TREVOR [mailto:tm2...@att.com]
> Sent: Friday, May 19, 2017 2:49 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] [trove] Trove meeting time update
> 
> I have submitted a patch for updating the regular trove meeting time to 1500
> UTC. This was decided during the trove project update meeting last week[1]
> 
> If you weren't able to make it and want to voice your opinion or If you feel
> like a better time is more suitable, feel free to make a suggestion here[2]
> 
> [1] https://youtu.be/g8tKXn_Axhs?t=23m50s
> [2] https://review.openstack.org/#/c/466381/
> 
> 
> __
> OpenStack Development Mailing 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] contribute to the travel assistance program

[Amrith Kumar]

That link again

https://www.eventbrite.com/e/openstack-summit-may-2017-boston-tickets-283756
75409

Sorry for the duplication.

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


> -Original Message-
> From: Amrith Kumar [mailto:amrith.ku...@gmail.com]
> Sent: Friday, May 5, 2017 11:56 AM
> To: 'OpenStack Development Mailing List (not for usage questions)'
> <openstack-dev@lists.openstack.org>; 'OpenStack Operators'  operat...@lists.openstack.org>
> Subject: contribute to the travel assistance program
> 
> Folks,
> 
> Summit is just a couple of days away and it is still not too late to
> participate in the foundation's travel assistance program. Every bit
counts,
> and if you are able to contribute to it, you may be able to help one of
your
> fellow openstackers attend the summit. As you all know, it is a major
hiring
> place for openstack talent and given the recent shake-up's, this could be
a
> significant difference for someone you know.
> 
> Anything you can contribute will be a plus, please point your browser at
> 
>
https://www.eventbrite.com/e/openstack-summit-may-2017-boston-tickets-283756
75409
> 
> and scroll down to the last ticket type.
> 
> Thanks,
> 
> -amrith
> 
> --
> Amrith Kumar
> amrith.ku...@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-dev] contribute to the travel assistance program

[Amrith Kumar]

Folks,

Summit is just a couple of days away and it is still not too late to
participate in the foundation's travel assistance program. Every bit counts,
and if you are able to contribute to it, you may be able to help one of your
fellow openstackers attend the summit. As you all know, it is a major hiring
place for openstack talent and given the recent shake-up's, this could be a
significant difference for someone you know.

Anything you can contribute will be a plus, please point your browser at

https://www.eventbrite.com/e/openstack-summit-may-2017-boston-tickets-283756
75409

and scroll down to the last ticket type.

Thanks,

-amrith

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




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

Re: [openstack-dev] [all][elections] Technical Committee Election Results

[Amrith Kumar]

And thanks to the election officials, Kendall, Tristan, and Tony.

-amrith 

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


> -Original Message-
> From: Tristan Cacqueray [mailto:tdeca...@redhat.com]
> Sent: Thursday, April 20, 2017 8:35 PM
> To: openstack-dev@lists.openstack.org; openstack-annou...@lists.openstack.org
> Subject: [openstack-dev] [all][elections] Technical Committee Election
> Results
> 
> Please join me in congratulating the 7 newly elected members of the Technical
> Committe (TC).
> 
> Chris Dent (cdent)
> Davanum Srinivas (dims)
> Dean Troyer (dtroyer)
> Flavio Percoco (flaper87)
> John Garbutt (johnthetubaguy)
> Sean McGinnis (smcginnis)
> Thierry Carrez (ttx)
> 
> Full results:
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5
> 
> Election process details and results are also available here:
> https://governance.openstack.org/election/
> 
> Thank you to all of the candidates, having a good group of candidates helps
> engage the community in our democratic process.
> 
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure your voice is heard.
> 
> Thank you for another great round.
> -Tristan


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

[openstack-dev] [nova][trove] deleted instances appearing in nova's server-group list

[Amrith Kumar]

TL;DR

Nova's v2 server group API list() call returns a list of members which
includes deleted instances. Is this valid behavior? Should requestors make
the determination that these are deleted instances and act accordingly, or
is this something that changed in Nova and that Nova will fix?

The whole story:

Trove's gate has begun to fail with a very repeatable and specific pattern
where a test finds that there are left-over members in a server group and
therefore does not delete the server group. See [1].

The tests in question create a server group (anti-affinity) and add multiple
instance to it. The instances are then deleted, and the tests wait to ensure
that the instances are in fact deleted. The tests then attempt to delete the
server group. The code (in trove) that determines whether or not to delete
the server group has contained (since its creation) a check to ensure that
the group is only deleted if it is empty (has no members) or has a single
instance (the last instance being deleted).

Now however, since the server groups membership shows deleted instances,
trove's code isn't deleting the server group and our tests are failing.

This is illustrated from the CLI based example (attached).

[1] https://bugs.launchpad.net/bugs/1682845

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


amrith@amrith-work:/opt/stack/trove$ openstack server group create 
affinity-policy --policy affinity
+--+--+
| Field| Value|
+--+--+
| id   | e74ce429-9f12-48f6-a156-6222930f733e |
| members  |  |
| name | affinity-policy  |
| policies | affinity |
+--+--+

amrith@amrith-work:/opt/stack/trove$ nova server-group-list
/usr/local/lib/python2.7/dist-packages/novaclient/client.py:278: UserWarning: 
The 'tenant_id' argument is deprecated in Ocata and its use may result in 
errors in future releases. As 'project_id' is provided, the 'tenant_id' 
argument will be ignored.
  warnings.warn(msg)
+--+-+--+--+---+-+--+
| Id   | Name| Project Id   
| User Id  | Policies  | Members | 
Metadata |
+--+-+--+--+---+-+--+
| e74ce429-9f12-48f6-a156-6222930f733e | affinity-policy | 
a2701e81c2214285b12f86921426d12b | ac9d7a717aa34456984ad2d0c9d21255 | 
[u'affinity'] | []  | {}   |
+--+-+--+--+---+-+--+

amrith@amrith-work:/opt/stack/trove$ nova boot --image 
2c5becd4-4d27-4567-b6c8-5d5cb984ee7b --flavor 1 --hint 
"group=e74ce429-9f12-48f6-a156-6222930f733e" instance-1

amrith@amrith-work:/opt/stack/trove$ nova boot --image 
2c5becd4-4d27-4567-b6c8-5d5cb984ee7b --flavor 1 --hint 
"group=e74ce429-9f12-48f6-a156-6222930f733e" instance-2


amrith@amrith-work:/opt/stack/trove$ nova server-group-get 
e74ce429-9f12-48f6-a156-6222930f733e  
/usr/local/lib/python2.7/dist-packages/novaclient/client.py:278: UserWarning: 
The 'tenant_id' argument is deprecated in Ocata and its use may result in 
errors in future releases. As 'project_id' is provided, the 'tenant_id' 
argument will be ignored.
  warnings.warn(msg)
+--+-+--+--+---++--+
| Id   | Name| Project Id   
| User Id  | Policies  | Members
| Metadata |
+--+-+--+--+---++--+
| e74ce429-9f12-48f6-a156-6222930f733e | affinity-policy | 
a2701e81c2214285b12f86921426d12b | ac9d7a717aa34456984ad2d0c9d21255 | 
[u'affinity'] | [u'b4d45181-030b-491d-8266-4be7f412c59a', 
u'7af84322-4d3f-4c11-9f86-a52d34f393c4'] | {}   |
+--+-+--+--+---++--+

amrith@amrith-work:/opt/stack/trove$ nova

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

[Amrith Kumar]

Hmm, all the cool kids didn’t receive the email but I did. Now I feel bad ☹

 

-amrith

 

From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] 
Sent: Wednesday, April 12, 2017 9:53 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] Emails for OpenStack R Release Name voting going 
out - please be patient

 

I also have not received a poll email.

 

On Apr 12, 2017 6:13 AM, "Neil Jerram"  
> wrote:

Nor me.

 

On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann  > wrote:

Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
> On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
> > On 04/06/2017 07:34 AM, Monty Taylor wrote:
> > >
> > > Hey all!
> > >
> > > I've started the R Release Name poll and currently am submitting
> > > everyone's email address to the system. In order to not make our fine
> > > friends at Carnegie Mellon (the folks who run the CIVS voting service)
> > > upset, I have a script that submits the emails one at a time with a
> > > half-second delay between each email. That means at best, since there
> > > are 40k people to process it'll take ~6 hours for them all to go out.
> > >
> > > Which is to say - emails are on their way - but if you haven't gotten
> > > yours yet, that's fine. I'll send another email when they've all gone
> > > out, so don't worry about not receiving one until I've sent that mail.
> > Well- that took longer than I expected. Because of some rate limiting, 
> > 1/2 second delay was not long enough...
> >
> > Anyway - all of the emails should have gone out now. Because that took 
> > so long, I'm going to hold the poll open until next Wednesday.
> >
> > Monty
>
> Not sure why, but I haven't received an email yet.
>
> Thanks,
> Michal

Nor I.

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

__
OpenStack Development Mailing 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] weekly meeting canceled today

[Amrith Kumar]

I've not seen anything new on the agenda and I have a late scheduling
conflict today. Let's catch up on IRC if there is anything that needs
discussing. 

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




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

Re: [openstack-dev] [tc] [elections] Available time and top priority

[Amrith Kumar]

> -Original Message-
> From: Matt Riedemann [mailto:mriede...@gmail.com]
> Sent: Monday, April 10, 2017 4:41 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] [elections] Available time and top priority
> 
> On 4/10/2017 2:55 PM, Dean Troyer wrote:
> >
> > The TC meetings are held in IRC and that may somewhat mitigate the
> > issue for non-native English speakers, but I've had problems myself
> > keeping up at times with the flurry of comments.  In any case, I think
> > it would be good to include language in the pile of concerns over
> > world-wide participation
> 
> I don't attend many TC meetings, it's usually on accident, but yeah, when I
> do I always note the flurry of cross-talk chatter that just drowns everything
> out. I feel like there are usually at least 3 parallel conversations going on
> during a TC meeting and it's pretty frustrating to follow along, or get a
> thought in the mix. That has to be much worse for a non-native English
> speaker.
> 
> So yeah, slow down folks. :)

[Amrith Kumar] A huge +1000 to that. I have found it very hard to follow the 
conversations of the TC and some months back (may be over a year back) there 
was a meeting where someone had to explicitly ask for people to stop the 
wisecracking. Just unwinding the multiple conversations from last week's 
meeting where I was trying to have parallel conversations with several people 
on a proposal I had before the meeting was very challenging. The challenge this 
must face for people who don't natively think in English is something I can 
hardly imagine.

It may not be a bad idea to have TC meetings be moderated and where people who 
wish to speak must be recognized and the floor yielded to them. It will be 
different, but I think it can work.

> 
> I'm not advocating splitting the meetings though. It's possible to have your
> cake and eat it to if done properly. For example, Alex Xu runs the Nova API
> subteam meeting and we have people from China, India, Japan, UK and USA and
> get through it fine, but it does involve slowing down to get an
> acknowledgement from people that they are OK with any decisions being made.
> 

[Amrith Kumar] I think the answer lies more in having the discussions in mail, 
on the mailing list and reserving the TC meeting for the actual vote. By 
framing the meeting more as a procedural mechanism, one can even allow for 
offline voting and then the time of the meeting becomes less important.

To be truly welcoming of a distributed community, I think this approach would 
be way better.

> This might also tie back in with what cdent was mentioning, and if the flurry
> of conversation during a TC meeting throws people off, maybe the minutes
> should be digested after the meeting in the mailing list. I know the meeting
> is logged, but it can be hard to read through that without one's eyes glazing
> over due to the cross-talk and locker-room towel whipping going on.
> 
> --
> 
> 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

--
Amrith 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] [tc] [elections] Available time and top priority

[Amrith Kumar]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Monday, April 10, 2017 5:17 AM
> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [tc] [elections] Available time and top priority
> 
> Hi everyone,
> 
> New in this TC election round, we have a few days between nominations and
> actual voting to ask questions and get to know the candidates a bit better.
> I'd like to kick off this new "campaigning period" with a basic question on
> available time and top priority.
> 
> All the candidates are top community members with a lot of responsibilities
> on their shoulders already. My experience tells me that it is easy to
> overestimate the time we can dedicate to Technical Committee matters, and how
> much we can push and get done in six months or one year. At the same time,
> our most efficient way to make progress is always when someone "owns" a
> particular initiative and pushes it through the governance process.
> 
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing proposed
> changes and pushing your own) ? If there was ONE thing, one initiative, one
> change you will actively push in the six months between this election round
> and the next, what would it be ?
> 

[Amrith Kumar] I have the (somewhat) luxury of being able to devote a 
significant portion of my time to activities of OpenStack and the technical 
committee in the new role that I will be entering into. I will therefore be 
able to devote at least 20% of my time to activities related to the technical 
committee.

The one initiative that I would drive would be to build community for projects 
that (like Trove) face a declining participation, and are facing the same 
kind(s) of challenges when it comes to the mechanics of reviewing changes, 
keeping up with the rest of OpenStack, and continuing to make forward progress 
on their own deliverables.

It will be part of my new role to establish a core group of OpenStack talent 
who will participate in a number of projects (including, of course Trove). This 
initiative is not something new for me, I've been doing this for some time now. 
I gratefully acknowledge the help I've received in this area from many in the 
community, and most of all from dims (also candidate for election to the TC 
this cycle, please also vote for him) and want to build a larger group of 
motivated contributors who are willing to take time out of their schedules and 
participate in the effort of growing the community and the leadership. I've 
been participating in the activities of the SWG (since its inception) and I see 
this not so much as an 'election campaign' but rather a continuation of what 
I've been espousing for some time now.

The success of OpenStack in its mission to be the ubiquitous cloud computing 
platform depends in large part on the vibrant community in all of the projects 
that form part of OpenStack, not just the high profile ones. For this mission 
to be fulfilled, it will be essential that this community which has been 
weakened by recent corporate redirections be rebuilt through the introduction 
of new participants and participating companies.

> Thanks in advance for your answers !
> 

[Amrith Kumar] Thanks for the question.

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


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

[openstack-dev] amrith candidacy for OpenStack Technical Committee

[Amrith Kumar]

My name is Amrith Kumar, I've been around OpenStack since a little
before the IceHouse release (about 3 years ago). During this time,
I've worked mostly on Trove, and a little bit on other projects but
mostly in service of Trove. I've also served as a member of the
Stewardship Working Group, and have participated in other activities
that seek to foster and encourage participation in OpenStack
(mentorship, for example).

I submit my candidacy for election to the TC at what I believe we will
look back upon as a point of inflection in the OpenStack trajectory.

Trove, the project that I've been most closely associated with, and
some other projects that are not part of the 'core OpenStack' have
faced a decline in participation. To be clear, I don't intend to place
blame on the 'big tent' proposal; I think the approach proposed in the
big tent was rational and needed at the time. The old way of doing
things was unsustainable and the new model is much more
scalable. However, it is an observable fact that the non-core projects
have seen a decline in participation as more corporate focus is placed
on the few core projects.

At this point of inflection, I think the TC should focus more of its
attention on three specific things that I promise to champion if
elected to the TC. I describe each in turn below.

I would like to make it easier for newcomers to OpenStack to
participate in the project, and I will make this a priority on the
Technical Committee. I have over the past few years done several
things in this area including talks at universities, presentations at
meetups, blogging and other things that aim to simplify this and make
the 'newcomer experience' a lot better. This is something I promise to
continue if elected to the TC.

A significant part of my motivation for running for election for the
TC is based on what was discussed at a leadership training for TC
members that I attended in Ann Arbor last year.

I'm happy to see that the TC has taken a more assertive position on
defining a vision, something which was discussed at length, and I
believe long overdue. I have long advocated that the TC should take a
more assertive and prescriptive approach towards the technical
decisions that it makes, and this is something I promise to bring to
the TC if elected.

I'm a strong proponent of allowing projects to make the right
technical decisions for their own areas, but still see the value in a
central governance structure. A part of the evolution of OpenStack
that I welcome is the recent move to take positive action on the
Golang issue, and to get work going to allow projects to choose a
language other than Python.

Finally, I believe that the TC is in need of some 'new voices' and I
promise to bring a new and different perspective to the deliberations
of the TC.

Thanks,

-amrith

--
Amrith Kumar
amrith.ku...@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-dev] [trove] today weekly meeting canceled

[Amrith Kumar]

There's nothing to discuss on the agenda today so I'm canceling the meeting
for today.

-amrith

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




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

Re: [openstack-dev] [oslo]Introduction of new driver for oslo.messaging

[Amrith Kumar]

Great idea, happy to try it out for Trove. We love o.m.rpc :) But it needs to 
be secure; other comment has been posed in review, I'm doing a talk about o.m 
use by trove in Boston anyway, maybe we can get Melissa to join me for that?

-amrith


-Original Message-
From: Deja, Dawid [mailto:dawid.d...@intel.com] 
Sent: Friday, March 31, 2017 10:41 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [oslo]Introduction of new driver for oslo.messaging

Hi all,

To work around issues with rabbitMQ scalability we'd like to introduce new 
driver in oslo messaging that have nearly no scaling limits[1].
We'd like to have as much eyes on this as possible since we believe that this 
is the technology of the future. Thanks for all reviews.

Dawid Deja

[1] https://review.openstack.org/#/c/452219/
__
OpenStack Development Mailing 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] reminder, DST adjustment

[Amrith Kumar]

Just a reminder that the Trove weekly meeting[1] is at 1800 UTC and with the
DST correction, the meeting is now

1400EDT
1100PDT

Thanks,

-amrith 

[1] http://eavesdrop.openstack.org/#Trove_(DBaaS)_Team_Meeting

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




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

Re: [openstack-dev] [requirements] pycrypto is dead, long live pycryptodome... or cryptography...

[Amrith Kumar]

Sounds like a good candidate for a cross-project release goal.

A non-controversial situation, the work is a no-op for most, a specific
deliverable for a few, and a mechanism to close the loop and make sure it
gets done in a specific timeframe?

Thanks for surfacing it Matthew.

-amrith

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Wednesday, March 8, 2017 2:30 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [requirements] pycrypto is dead, long live
pycryptodome... or cryptography...

Ack thanks Matthew!

On Wed, Mar 8, 2017 at 2:24 PM, Matthew Thode 
wrote:
> I'm aware, iirc it was brought up when pysaml2 had to be fixed due to 
> a CVE.  This thread is more looking for a long term fix.
>
> On 03/08/2017 01:11 PM, Davanum Srinivas wrote:
>> Matthew,
>>
>> Please see the last time i took inventory:
>> https://review.openstack.org/#/q/pycryptodome+owner:dims-v
>>
>> Thanks,
>> Dims
>>
>> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode 
wrote:
>>> So, pycrypto upstream is dead and has been for a while, we should 
>>> look at moving off of it for both bugfix and security reasons.
>>>
>>> Currently it's used by the following.
>>>
>>> barbican, cinder, trove, glance, heat, keystoneauth, 
>>> keystonemiddleware, kolla, openstack-ansible, and a couple of other
smaller places.
>>>
>>> Development of it was forked into pycryptodome, which is supposed to 
>>> be a drop in replacement.  The problem is that due to 
>>> co-installability requirements we can't have half of packages out 
>>> there using pycrypto and the other half using pycryptodome.  We'd 
>>> need to hard switch everyone as both packages install into the same
namespace.
>>>
>>> Another alternative would be to use something like cryptography 
>>> instead, though it is not a drop in replacement, the migration would 
>>> be able to be done piecemeal.
>>>
>>> I'd be interested in hearing about migration plans, especially from 
>>> the affected projects.
>>>
>>> --
>>> Matthew Thode (prometheanfire)
>>>
>>>
>>> 
>>> __ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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


__
OpenStack Development Mailing 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] today weekly meeting

[Amrith Kumar]

While I try to schedule my life to not conflict with the weekly Trove
meeting, it appears that Wednesday afternoon at 1pm is a particularly
popular time for people to want to meet me.

 

This week, and next week are no exception. While I'd tried to avoid these
conflicts, I've managed to be unable to do it (again).

 

Nikhil (slicknik) has kindly agreed to run the meeting today, same place,
same time as always.

 

Thanks Nikhil.

 

-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] [trove] Weekly meeting today canceled

[Amrith Kumar]

My apologies for the short notice but I have a conflict at 1pm and since we
had the mid-cycle last week, things are still relatively fresh in everyone's
mind. So, I'm going to cancel this weeks meeting and resume regular weekly
meetings next week.

In the interim, if you need something Trove related, the #openstack-trove
channel is your best bet.

-amrith

--
Amrith Kumar
amrith.ku...@gmail.com
+1-978-563-9590
GPG: 0x5e48849a9d21a29b



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

[openstack-dev] [trove] session schedule for Pike PTG

[Amrith Kumar]

For those attending the Pike PTG and interested in the trove sessions,
please fill in your participation (and IRC nick) at the etherpad[1].

We will have a complete schedule by end of day on Tuesday. If you are
specifically interested in a session and have time constraints, please put
that into the etherpad. Let's plan to start on Wednesday morning at 9am in
the dedicated Trove room with a quick scheduling session; if you are able to
attend in person that's great, if you are not make sure that your interest
and constraints are in the etherpad.

Thanks,

-amrith

[1] https://etherpad.openstack.org/p/trove-pike-ptg-topics

--
Amrith Kumar
GPG: 0x5e48849a9d21a29b



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

[openstack-dev] [trove] Trove logo files

[Amrith Kumar]

Trove team members,

 

Please see email below from the Openstack Foundation with a link to the Trove 
logo files.

 

-amrith

 

 

From: Heidi Joy Tretheway [mailto:heidi...@openstack.org] 
Sent: Tuesday, February 14, 2017 4:53 AM
To: Amrith Kumar
Subject: Trove logo files

 

Hi Amrith, 

 

I’m excited to finally be able to share final project logo files with you. 
Inside this folder, you’ll find full-color and one-color versions of the logo, 
plus a mascot-only version, in EPS, JPG and PNG formats. You can use them on 
presentations and wherever else you’d like to add some team flair. 

 

https://www.dropbox.com/sh/v7l130m8ci4kmv7/AAA7dBhyjtTSaaQZvYOatmJga?dl=0

 

At the PWG, we’ll have stickers for your team of the mascot, plus signage on 
your room. I’m especially excited for the project teams to see all of the logos 
together as one group, because they work beautifully together stylistically 
while making each project’s mark distinctive. Feel free to share this with your 
team, and thanks to you and to them for the hard work they put into reaching an 
agreement on the mascot. Also feel free to direct any questions my way!

 


  
<https://s3.amazonaws.com/ucwebapp.wisestamp.com/09b84cf4-afd1-43b4-8aaa-af7d338680cb/HeidprofilephotoFeb2015SMALL.crop_360x372_15,17.preview.format_png.resize_200x.png#logo>
 

Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation

 <tel:503%20816%209769> 503 816 9769 | Skype:  
<https://webapp.wisestamp.com/sig_iframe?origin=mac-mail_id=5499768844845056=0.9726545857097719>
 heidi.tretheway

 <http://linkedin.com/in/heiditretheway>   <http://twitter.com/heiditretheway>  
 <http://www.openstack.org/> 

 

 

 



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

Re: [openstack-dev] [trove][Neutron] Towards better stability of gate jobs

[Amrith Kumar]

I'd like to add the same call-to-action for Trove as well.

When you see a gate failure, please don't simply recheck. Let's start
tracking failure patterns in Launchpad and fix them. I know this is a change
from what we've been doing a lot of in Trove of late so I realize that it
will take some time before we get used to it.

But, it is an improvement worth aspiring to.

Thanks,

-amrith

> -Original Message-
> From: Jakub Libosvar [mailto:jlibo...@redhat.com]
> Sent: Monday, January 30, 2017 11:37 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Neutron] Towards better stability of gate jobs
> 
> Hi all,
> 
> we've been struggling with functional and fullstack jobs for a while now
> and we'd like to bring a better stability to it as the failure rate is
> still quite high. This is getting annoying, specifically for voting
> functional job, which makes it sometimes harder to get some of our
> beautiful precious patches merged.
> 
> The very basic pillar on the way to improve the jobs is to understand what
> is wrong with them. Without having an overview of current failures it's
> very hard to make any improvement.
> 
> Hence I'd like to ask you for help. When you see a failed job, don't just
> 'recheck' with the best hope that your patch won't get hit by gate failure
> again. Take a minute, please, open the failure and eventually report a new
> bug.
> 
> Armando already sent similar email in the past [1], where he encouraged to
> have a look at the failure and report a bug. I have also sent a new policy
> to our docs with recommended steps [2]. Ideas on improvement are very
> welcome!
> 
> It's really crucial to get a better grasp of our job failures and I
> believe if we can make this a habit into our day to day work, it will
> really make a difference at the job stability.
> 
> Thank you.
> Jakub
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100801.html
> [2] https://review.openstack.org/#/c/426829/
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [trove] status of the gate

[Amrith Kumar]

The issues plaguing the gate have been addressed with the help of Andrey
Kurilin, Jian Song and Tin Lam. Thanks y'all for your patches which were
merged and helped unblock the gate[1].

As noted in the commit message there, this change includes some low quality
band-aid which needs to be redone before we get to Ocata. But for the
present, the gate is running again.

-amrith

[1] https://review.openstack.org/#/c/426535/

> -Original Message-
> From: Amrith Kumar [mailto:amrith.ku...@gmail.com]
> Sent: Sunday, January 29, 2017 12:06 PM
> To: 'OpenStack Development Mailing List (not for usage questions)'
> <openstack-dev@lists.openstack.org>
> Subject: [trove] status of the gate
> 
> All:
> 
> There are at least a couple of issues that are currently impacting the
> trove
> gate and I'm getting to the bottom of it. The currently known problems are
> being handled in a single commit[1].
> 
> This currently emcompasses the issues identified in three independent
> commits, none of which will be able to merge by themselves [2], [3], and
> [4].
> 
> There is at least one more issue that I have to wrestle to the ground and
> it
> appears to be some change to the structure of oslo_context that isn't
> immediately apparent (at least that's the current hunch).
> 
> In the meanwhile, rechecks and changes to trove, and python-troveclient
> will
> merely fail after taking up some useless time in the gate.
> 
> I'll try and get this resolved soon, sorry for the delay.
> 
> -amrith
> 
> [1] https://review.openstack.org/#/c/426535/
> [2] https://review.openstack.org/#/c/425857/
> [3] https://review.openstack.org/#/c/423086/
> [4] https://review.openstack.org/#/c/412497/
> 
> 
> --
> Amrith Kumar
> GPG: 0x5e48849a9d21a29b



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

[openstack-dev] [trove][tc][stable] trove core team coverage this week

[Amrith Kumar]

Over the next couple of days, some members of the trove core team will be
traveling and others have commitments that may cause brief periods when
there is no one around immediately to respond on IRC.

For anything that needs urgent attention, please email me directly and I
will try to get back to you as soon as I can. For something urgent, please
include a telephone number where I can call you. Thanks for understanding.

-amrith

--
Amrith Kumar
GPG: 0x5e48849a9d21a29b



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

[openstack-dev] [trove] status of the gate

[Amrith Kumar]

All:

There are at least a couple of issues that are currently impacting the trove
gate and I'm getting to the bottom of it. The currently known problems are
being handled in a single commit[1].

This currently emcompasses the issues identified in three independent
commits, none of which will be able to merge by themselves [2], [3], and
[4].

There is at least one more issue that I have to wrestle to the ground and it
appears to be some change to the structure of oslo_context that isn't
immediately apparent (at least that's the current hunch).

In the meanwhile, rechecks and changes to trove, and python-troveclient will
merely fail after taking up some useless time in the gate.

I'll try and get this resolved soon, sorry for the delay.

-amrith 

[1] https://review.openstack.org/#/c/426535/
[2] https://review.openstack.org/#/c/425857/
[3] https://review.openstack.org/#/c/423086/
[4] https://review.openstack.org/#/c/412497/


--
Amrith Kumar
GPG: 0x5e48849a9d21a29b



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

[openstack-dev] [trove] gate currently broken, rechecking is pointless

[Amrith Kumar]

The Trove gate appears to be currently broken and rechecking things on the
trove or trove-client projects is pointless. There was some speculation that
this current failure relates to some change in the nova client. I haven't
verified this myself but a fix[1] has been proposed to (ostensibly) fix the
gate but it hasn't worked. I also found that a change was pushed up some
time back[2] and it has successfully fallen through the cracks.

 

I'll be looking into this tomorrow and hopefully we can get the gate
unwedged again.

 

But in the meanwhile, please refrain from just rechecking stuff; it isn't
going to do any good to warm the planet faster than it is already.

 

-amrith

 

[1] https://review.openstack.org/#/c/423086/

[2] https://review.openstack.org/#/c/412497/

 

--

Amrith Kumar

GPG: 0x5e48849a9d21a29b

 



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

[openstack-dev] [trove] self-nomination for Trove PTL

[Amrith Kumar]

I am writing to submit my candidacy for re-election as the PTL for the
Trove project (Pike cycle). I have been an active technical
contributor to the Trove project since just before the Icehouse
release when Trove was integrated into OpenStack. I have also
contributed code[1] and reviews[2] to some other OpenStack projects,
and have been an active participant in the Stewardship Working Group
[3] (SWG) and a not-so active participant in the Delimiter project.

I believe that in the Pike release we should continue to move forward
with the Trove project and continue to build on the improvements that
we were able to accomplish (some are still work in progress) in the
Ocata release.

- paying down our technical debt, including specifically some long
  standing items that were listed by the TC at the time when Trove was
  integrated, and improving our testing, addressing some long standing
  issues with dependencies between the server and the client, and

- making it easier to use Trove by eliminating the trovestack tool and
  instead offering a set of tools that will serve the purposes of end
  users and deployers alike, and

- adding support for new datastores, capabilities and configurations,
  and

- expanding the community, adding new contributors, contributing
  companies, and end users interested in the project, and

- streamlining the API with the implementation of better versioning
  support.

I would also like to take this opportunity to thank all members of the
development community who helped the Trove project during the Ocata
cycle; those who contributed code and reviews to the project as well
as members of the infra, release, stable, oslo, docs, dib, and other
project teams who helped us on innumerable occasions.

Not to pick on them too much, but I'd especially like to thank Davanum
Srinivas (dims), and Doug Hellmann for all their help on the release
team, and for all the things that they've done to make branching so
much easier. My thanks to Joshua Harlow, the PTL for oslo for his help
and support in getting a particularly knarly set of issues relating to
oslo_messaging.rpc put to rest. Last but not the least, to everyone on
the infra team who helped us with a bunch of changes that helped
considerably in speeding up the Trove check/gate process. The jury is
still out on those changes, but thanks folks for allowing us the
freedom to try the experiment.

Thank you, and I appreciate your support in the election. I have
submitted this candidacy as review [4].

-amrith

[1] http://stackalytics.com/?user_id=amrith=all=commits
[2] http://stackalytics.com/?user_id=amrith=all=marks
[3] https://review.openstack.org/#/c/337895/
[4] https://review.openstack.org/422891


--
Amrith Kumar
GPG: 0x5e48849a9d21a29b



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

Re: [openstack-dev] [Trove] Resource not found when creating db instances.

[Amrith Kumar]

Sorry Wang Sen, why do you say Trove is not ready for Neutron"? It has
worked with Neutron for some releases now.

This does not appear to be at all related to Neutron.

-amrith

--
amrith.ku...@gmail.com
On Jan 18, 2017 10:56 PM, "Wang Sen"  wrote:

> Hi all,
>
> I met the resource not found error when I'm creating a database
> instance. The instance stays on build status and turns to error status
> after timeout.
>
> I know trove is not ready for neuton. Is there a work around for this
> issue ? Thanks in advance.
>
> Below is the detailed information.
>
> Error Log
> =
>
> /var/log/trove/trove-taskmanager.log:
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task [-] Error
> during Manager.publish_exists_event
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task Traceback
> (most recent call last):
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/oslo_service/periodic_task.py", line
> 220, in run_periodic_tasks
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  task(self, context)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/trove/taskmanager/manager.py", line
> 429, in publish_exists_event
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  self.admin_context)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/trove/extensions/mgmt/instances/models.py",
> line 178, in publish_exist_events
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  notifications = transformer()
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/trove/extensions/mgmt/instances/models.py",
> line 271, in __call__
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  client=self.nova_client)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/trove/extensions/mgmt/instances/models.py",
> line 40, in load_mgmt_instances
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  mgmt_servers = client.servers.list(search_opts={'all_tenants': 1})
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/v2/servers.py", line 835, in
> list
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  "servers")
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/base.py", line 249, in _list
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task resp,
> body = self.api.client.get(url)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 480, in get
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task return
> self._cs_request(url, 'GET', **kwargs)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 436, in
> _cs_request
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  self.authenticate()
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 619, in
> authenticate
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  self._v2_auth(auth_url)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 684, in
> _v2_auth
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task return
> self._authenticate(url, body)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 697, in
> _authenticate
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task
>  **kwargs)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 431, in
> _time_request
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task resp,
> body = self.request(url, method, **kwargs)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task   File
> "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 425, in
> request
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task raise
> exceptions.from_response(resp, body, url, method)
> 2017-01-19 11:27:31.666 22795 ERROR oslo_service.periodic_task NotFound:
> The resource could not be found. (HTTP 404)
>
> Openstack Cluster
> =
>
> openstack version: Neuton
> trove version: 2.5.0
> $ root@kvm-215:~# trove --version
> 2.5.0
> $ root@kvm-215:~# openstack --version
> openstack 3.2.0
>
> Controller Node: ubuntu 16.04, 9.181.129.215
> Compute Node: ubuntu 

Re: [openstack-dev] [ironic] [infra] Nested KVM + the gate

[Amrith Kumar]

Jay,

 

This is the Trove commit …  
 
I85364c6530058e964a8eba7fb515d7deadfd5d72

 

-amrith

 

From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] 
Sent: Wednesday, January 18, 2017 7:57 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [ironic] [infra] Nested KVM + the gate

 

On Tue, Jan 17, 2017 at 6:41 PM, Jay Faulkner  
> wrote:

Hi all,

Back in late October, Vasyl wrote support for devstack to auto detect, and when 
possible, use kvm to power Ironic gate jobs 
(0036d83b330d98e64d656b156001dd2209ab1903). This has lowered some job time when 
it works, but has caused failures — how many? It’s hard to quantify as the log 
messages that show the error don’t appear to be indexed by elastic search. It’s 
something seen often enough that the issue has become a permanent staple on our 
gate whiteboard, and doesn’t appear to be decreasing in quantity.

I pushed up a patch, https://review.openstack.org/#/c/421581, which keeps the 
auto detection behavior, but defaults devstack to use qemu emulation instead of 
kvm.

I have two questions:
1) Is there any way I’m not aware of we can quantify the number of failures 
this is causing? The key log message, "KVM: entry failed, hardware error 0x0”, 
shows up in logs/libvirt/qemu/node-*.txt.gz.
2) Are these failures avoidable or visible in any way?

IMO, if we can’t fix these failures, in my opinion, we have to do a change to 
avoid using nested KVM altogether. Lower reliability for our jobs is not worth 
a small decrease in job run time.

 

+2, especially this late in the cycle, we need our CI to be rock solid.

// jim

 

 



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

Re: [openstack-dev] [ironic] [infra] Nested KVM + the gate

[Amrith Kumar]

Clark is right, trove does detect and try to use kvm where possible. The
performance has been well worth the change (IMHO).

-amrith

On Jan 17, 2017 6:53 PM, "Clark Boylan"  wrote:

> On Tue, Jan 17, 2017, at 03:41 PM, Jay Faulkner wrote:
> > Hi all,
> >
> > Back in late October, Vasyl wrote support for devstack to auto detect,
> > and when possible, use kvm to power Ironic gate jobs
> > (0036d83b330d98e64d656b156001dd2209ab1903). This has lowered some job
> > time when it works, but has caused failures — how many? It’s hard to
> > quantify as the log messages that show the error don’t appear to be
> > indexed by elastic search. It’s something seen often enough that the
> > issue has become a permanent staple on our gate whiteboard, and doesn’t
> > appear to be decreasing in quantity.
> >
> > I pushed up a patch, https://review.openstack.org/#/c/421581, which
> keeps
> > the auto detection behavior, but defaults devstack to use qemu emulation
> > instead of kvm.
> >
> > I have two questions:
> > 1) Is there any way I’m not aware of we can quantify the number of
> > failures this is causing? The key log message, "KVM: entry failed,
> > hardware error 0x0”, shows up in logs/libvirt/qemu/node-*.txt.gz.
> > 2) Are these failures avoidable or visible in any way?
> >
> > IMO, if we can’t fix these failures, in my opinion, we have to do a
> > change to avoid using nested KVM altogether. Lower reliability for our
> > jobs is not worth a small decrease in job run time.
>
> Part of the problem with nested KVM failures is that in many cases they
> destroy the test nodes in unrecoverable ways. In which case you don't
> get any logs, and zuul will restart the job for you. I think that
> graphite will capture this as a job that resulted in a Null/None status
> though (rather than SUCCESS/FAILURE).
>
> As for collecting info when you do get logs, we don't index the libvirt
> instance logs currently and I am not sure we want to. We already
> struggle to keep up with the existing set of logs when we are busy.
> Instead we might have job cleanup do a quick grep for known nested virt
> problem indicators and then log that to the console log which will be
> indexed.
>
> I think trove has also seen kernel panic type errors in syslog that we
> hypothesized were a result of using nested virt.
>
> The infra team explicitly attempts to force qemu instead of kvm on jobs
> using devstack-gate for these reasons. We know it doesn't work reliably
> and not all clouds support it. Unfortunately my understanding of the
> situation is that base hypervisor cpu and kernel, second level
> hypervisor kernel, and nested guest kernel all come into play here. And
> there can be nasty interactions between them causing a variety of
> problems.
>
> Put another way:
>
> 2017-01-14T00:42:00   if we're talking nested kvm
> 2017-01-14T00:42:04   it's kindof a nightmare
> from
> http://eavesdrop.openstack.org/irclogs/%23openstack-
> infra/%23openstack-infra.2017-01-14.log
>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Amrith Kumar]

Ian,

This is a fascinating conversation. Let me offer two observations.

First, Trove has long debated the ideal solution for storing secrets. There
have been many conversations, and Barbican has been considered many times.
We sought input from people who were deploying and operating Trove at scale;
customers of Tesora, self described users of the upstream Trove, and some of
the (then) active contributors who were also operators.

The consensus was that installing and deploying OpenStack was hard enough
and requiring the installation of yet more services was problematic. This is
not something which singles out Barbican in any way. For example, Trove uses
Swift as the default object store where backups are stored, and in
implementing replication we leveraged the backup capability. This means that
to have replication, one needs to have Swift. Several deployers have
objected to this since they don't have swift. But that is a dependency which
we considered to be a hard dependency and offer no alternatives; you can
have Ceph if you so desire but we still access it as a swift store.
Similarly we needed some capabilities of job scheduling and opted to use
mistral for this; we didn't reimplement all of these capabilities in Trove.

However, when it comes to secret storage, the consensus of opinion is
Yet another service.

Here is the second observation. This conversation reminds me of many
conversations from years past "Why do you want to use a NoSQL database, we
have a  database already". I've sat in on heated arguments
amongst architects who implemented "lightweight key-value storage based on
" and didn't use the corporate standard RDBMS.

One size doesn't fit all. And today, ten years on, it is clear that there
are legitimate situations where one would be silly to require an architect
to use a RDBMS; we talk of polyglot persistence as a matter of course.

The thing is this; Barbican may be a fine project with a ton of capabilities
that I don't even know of nor have the ability to comprehend. But there's a
minimum threshold of requirements that I need to have before the benefit of
the new dependency becomes valuable. From Trove's perspective, I don't
believe we have crossed that threshold (yet). If Barbican were a library not
a project, it may be a much easier sell for deployers.

Finally, it is my personal belief that making software pluggable such that
"if it discovers Barbican, it uses it, if it discovers XYZ it uses it, if it
discovers PQR it uses that ..." is a very expensive design paradigm.  Unless
Barbican, PQR, XYZ and any other implementation provide such material value
to the consumer, and there is significant deployment and usage of each, the
cost of maintaining the transparent pluggability of these, the cost of
testing, and development all add up very quickly.

Which is why when some project wants to store a secret, it ciphers it using
some one way hash and stuffs that in a database (if that's all it needs).

My 2c is that requiring projects to use Barbican as the secret store is the
equivalent of requiring developers (10 years ago) to use an RDBMS. One size
doesn't fit all ... Barbican is a "one size" secret store, I don't need all
of the bells and whistles just as the guy who wants a key value store
doesn't mind eventual consistency, lost writes, but can't take the cost of a
traditional RDBMS.

Thanks,

-amrith



> -Original Message-
> From: Ian Cordasco [mailto:sigmaviru...@gmail.com]
> Sent: Monday, January 16, 2017 8:36 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [all] [barbican] [security] Why are projects
trying to
> avoid Barbican, still?
> 
> Hi everyone,
> 
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
> 
> I've been struggling to understand the reasoning behind this and I'm
> wondering if there are more people around who can help me understand.
> 
> To help others help me, let me provide my point of view. Barbican's been
> around for a few years already and has been deployed by several companies
> which have probably audited it for security purposes. Most of the
technology
> involved in Barbican is proven to be secure and the way the project has
> strung those pieces together has been analyzed by the OSSP (OpenStack's
> own security group). It doesn't have a requirement on a hardware TPM
> which means there's no hardware upgrade cost. Furthermore, several
> services already provide the option of using Barbican (but won't place a
hard
> requirement on it). It stands to reason (in my opinion) that if new
services
> have a need for secrets and other services already support using Barbican
as
> secret storage, then those new services should be using Barbican. It seems
a
> 

Re: [openstack-dev] [oslo] Not running for Oslo PTL for Pike

[Amrith Kumar]

Josh,

It has been great working with you as the PTL of Oslo. Thanks for your
leadership.

-amrith

> -Original Message-
> From: Joshua Harlow [mailto:harlo...@fastmail.com]
> Sent: Tuesday, January 3, 2017 3:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
 d...@lists.openstack.org>
> Subject: [openstack-dev] [oslo] Not running for Oslo PTL for Pike
> 
> Hi Oslo folks (and others),
> 
> Happy new year!
> 
> After serving for about a year I think it's a good opportunity for myself
to let
> another qualified individual run for Oslo PTL (seems common to only go for
two
> terms and hand-off to another).
> 
> So I just wanted to let folks know that I will be doing this, so that we
can grow
> others in the community that wish to try out being a PTL.
> 
> I don't plan on leaving the Oslo community btw, just want to make sure we
> spread the knowledge (and the fun!) of being a PTL.
> 
> Hopefully I've been a decent PTL (with  room to improve) during this
time :-
> )
> 
> -Josh
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [trove] A question for the user survey

[Amrith Kumar]

We have the opportunity to ask one question on the upcoming user survey and
we get to decide the audience to which we serve the question.

 

Your options (for audience target) are: USING, TESTING, or INTERESTED in
Trove

 

The question can take one of several forms; multiple choice (select one or
more), or short answer.

 

Please send suggestions before Wednesday so I can respond to the team
assembling the survey in sufficient time.

 

Thanks,

 

-amrith

 

--

Amrith Kumar

 <mailto:amr...@amrith.org> amr...@tesora.com

+1-978-563-9590

GPG: 0x5e48849a9d21a29b

 



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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Amrith Kumar]

So Jeremy, that's great. so all someone has to do is pick this file and
blast it out to 150 projects :)

Merry Christmas, Happy Hanukah, Happy Festivus and best wishes for the feats
of strenght, Happy Holidays, Have a good weekend ... (pick as many as you'd
like)

-amrith

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Saturday, December 24, 2016 9:58 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
projects
> 
> On 2016-12-22 09:52:21 -0600 (-0600), Anne Gentle wrote:
> [...]
> > Does anyone have a "perfect" CONTRIBUTING.rst (or does it need to be
> > .md for github, Ian?) for all projects? Is it similar to the nova 2012
> > version or is there a more modern take?
> 
> The reference example is maintained at
> http://git.openstack.org/cgit/openstack-
> dev/cookiecutter/tree/%7b%7bcookiecutter.repo_name%7d%7d/CONTRIB
> UTING.rst
> (or at least that's the closest we have to one that's supposed to be kept
> "modern").
> --
> 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


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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Amrith Kumar]

For those who would like to know exactly what this set of changes cost in the 
CI, the answer is approximately 1050 jobs which consumed 190 compute hours of 
CI time.

-amrith

-Original Message-
From: Amrith Kumar [mailto:amr...@tesora.com] 
Sent: Wednesday, December 21, 2016 11:13 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

Ian, Andreas, Emilien,

My sentiments on the subject of these kinds of "production line" changes is 
unchanged from [1] and [2]. A complete list of these changes is at [3].

I've updated all of the changes in this thread with a block comment and a -1. 
My apologies to other reviewers (and active contributors in those projects) for 
this automated comment across 131 commits. 

It is high time we eliminated these kinds of changes which do little to improve 
the overall quality of the product and serve merely to generate a huge amount 
of pointless work on the CI systems, and boost some meaningless statistics that 
someone wants to put on a slide someplace.

-amrith

[1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
[2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
[3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

-Original Message-
From: Andreas Jaeger [mailto:a...@suse.com]
Sent: Wednesday, December 21, 2016 10:47 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

On 2016-12-21 16:22, Ian Cordasco wrote:
> [...]
> That said, I think there are two better places for this information 
> that are already standards in OpenStack:
> 
> * README.rst
> * HACKING.rst
> 
> Most projects include links to the contributing documentation in at 
> least one of these files. I think the effort here is to standardize, 
> albeit in a brand new file, and that's admirable.

If that's the goal - to standardize - then I would expect that we move all the 
documentation out of those files in one place.

Right now, the changes duplicate information that exists - and the new 
information is often wrong. It points to place that do not exist or where 
better places exist. ;(


I'm fine with the status quo - of using the two files that you mention.
Having contribution information is important,

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


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


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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Amrith Kumar]

Ian, Andreas, Emilien,

My sentiments on the subject of these kinds of "production line" changes is 
unchanged from [1] and [2]. A complete list of these changes is at [3].

I've updated all of the changes in this thread with a block comment and a -1. 
My apologies to other reviewers (and active contributors in those projects) for 
this automated comment across 131 commits. 

It is high time we eliminated these kinds of changes which do little to improve 
the overall quality of the product and serve merely to generate a huge amount 
of pointless work on the CI systems, and boost some meaningless statistics that 
someone wants to put on a slide someplace.

-amrith

[1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
[2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
[3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

-Original Message-
From: Andreas Jaeger [mailto:a...@suse.com] 
Sent: Wednesday, December 21, 2016 10:47 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

On 2016-12-21 16:22, Ian Cordasco wrote:
> [...]
> That said, I think there are two better places for this information
> that are already standards in OpenStack:
> 
> * README.rst
> * HACKING.rst
> 
> Most projects include links to the contributing documentation in at
> least one of these files. I think the effort here is to standardize,
> albeit in a brand new file, and that's admirable.

If that's the goal - to standardize - then I would expect that we move
all the documentation out of those files in one place.

Right now, the changes duplicate information that exists - and the new
information is often wrong. It points to place that do not exist or
where better places exist. ;(


I'm fine with the status quo - of using the two files that you mention.
Having contribution information is important,

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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] Finish test job transition to Ubuntu Xenial

[Amrith Kumar]

Clark, for Trove, I'm in the process of finishing this and there is a change
[1] that is currently up for review (I have to incorporate changes to
reflect Andreas' comments).

If you find something amiss with the Trove jobs (trove, trove client,
trove-integration or dashboard), please let me know and I'll fix it up
pronto.

Thanks,

-amrith

[1] https://review.openstack.org/#/c/405018/

> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org]
> Sent: Monday, December 5, 2016 4:53 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [All] Finish test job transition to Ubuntu
Xenial
> 
> On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:
> > Hello everyone,
> >
> > The infra team would really like to get the Ubuntu Xenial for testing
> > transition completed early this cycle. We are planning to switch any
> > jobs that remain on Ubuntu Trusty but should be on Ubuntu Xenial on
> > December 6, 2016. That gives us about a month from today to more
> > gracefully migrate jobs while still getting it done early enough in
> > the cycle to fix any issues and put it behind us. Would be great for
> > project teams to test if their jobs run on Xenial and propose updates
> > to openstack-infra/project-config as necessary to switch to Ubuntu
Xenial.
> 
> As a heads up the Infra team has begun pushing changes to start this work.
> The vast majority of them likely won't start merging until tomorrow,
however
> you may start to see changes going in particularly for experimental and
non
> voting jobs.
> 
> Thank you to all the teams that got ahead of this and worked to make the
> transition earlier.
> 
> One thing that pops out at me as we go through this work is that we have a
> lot of experimental and non voting jobs that need to be updated.
> Considering that experimental jobs in particular and often non voting jobs
> are supposed to be works in progress to get to voting, does the lack of
> interest in updating these from the projects themselves imply the jobs are
> dead and not needed? Maybe we should be doing cleanup of old forgotten
> experimental and non voting jobs that aren't being used?
> 
> Thank you,
> Clark
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

[Amrith Kumar]

Thierry, when we were adding the #openstack-swg group, we had this
conversation and I observed that my own preference would be for a project's
meetings to be in that projects room. It makes it easier to then search for
logs for something (say SWG related) in the SWG room, and I do this
regularly for Trove but I have to store text logs of the trove meetings (in
#openstack-meeting-alt) with the logs of the trove room #openstack-trove.

While I understand the simplicity of just hanging around in four or five
conference rooms and being available for pings I submit to you that if
someone wants to ping you and you are not in that projects room, they know
where to go find you if you are a person who hangs around.

So I submit to you that rather than creating #openstack-meeting-5, let's
outlaw the meeting rooms altogether and allow projects to meet in their own
rooms. And people who are interested in projects can hang out in those rooms
(which people do quite a bit anyway), and others who just hangout in
#openstack or #openstack-dev or #openstack-infra.

-amrith

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Friday, December 2, 2016 7:52 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] Creating a new IRC meeting room ?
> 
> Daniel P. Berrange wrote:
> > Do we have any real data on just how many contributors really do lurk
> > in the meeting rooms permanently, as opposed to merely joining rooms
> > at start of the meeting & leaving immediately thereafter ?
> 
> There are currently 488 permanent residents on #openstack-meeting, 270 on
> #openstack-meeting-4 (while no meeting is going on). So I'd say that most
> people stay around permanently.
> 
> > Likewise any data on how many contributors are actively participate in
> > meetings across different projects, vs silod just in their own one
> > project ?
> 
> That is harder to get numbers on.
> 
> > If the latter is in the clear majority, then you might as well just
> > have #openstack-meeting-$PROJECT and thus mostly avoid the problem of
> > conflicting demands for a limited set of channels.
> 
> Since there are between 300 and 500 people who find it interesting to lurk
in
> meeting channels, I'm pretty sure that would be a bad choice...
> 
> --
> 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


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

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Amrith Kumar]

Thanks Flavio,

I've logged https://bugs.launchpad.net/trove/+bug/1644851 for this and I 
assume that other projects which want to do this kind of manual cleanup can 
either use this bug or create their own.

-amrith

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Friday, November 25, 2016 9:00 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in
> README files
>
> On 25/11/16 13:46 +, Amrith Kumar wrote:
> >Flavio,
> >
> >I see a number of patches[1] which have been landed on this project but
> >I find that at least the ones that were landed for Trove, and a random
> >sampling of the others all to be different from what you proposed
> >below[2] in one important aspect.
> >
> >In [2] you proposed a structure where the title of the document; or the
> >first, and most prominent heading, would be the existing heading of the
> >document, and the tags would be below that. In [2] for example, that was:
> >
> >"kombu - Messaging library for Python"
> >
> >and the tags would be in smaller font below that.
>
> Hey Amrith,
>
> One reason it's different from Kombu is because Kombu uses shields as a
> backend for this SVGs, whereas we don't. We generate the badges
> ourselves[0], which probably ended up in some differences.
>
> The other main difference in the kombu case, there are multiple images in
> the README, wherease in our case there's one SVG containing multiple svgs.
> The motivation behind this is being able to update the badges without
> sending patches to projects everytime the governance repo is modified.
>
> This layout and format can of couse be modified, the font size and family 
> can
> be changed, etc. See[1].
>
> >What I see in [3] the patch for Trove and the proposed example [4] is:
> >
> >"Team and repository tags" as the first, and most conspicuous header,
> >and the header "Trove" below that.
> >
> >In some cases the second header is the same font as the "Team and
> >repository tags" header.
>
> I explained this a bit here[2]. The reason for prepending these secion to 
> the
> README's instead of finding a good place in it is that READMEs throughout
> OpenStack are quite different from each other and putting this at the top
> helped in making the process of adding the badges simpler.
>
> >I think this change (these 124 changes) as proposed are not consistent
> >with the proposal you made below, and certainly seem to be less
> >suitable than that proposal. The end product for the four trove
> >repositories [4], [5], [6], and [7]
> >
> >I think we should have a discussion on the ML whether we feel that this
> >new structure is the appropriate one, and before some projects approve
> >these changes and others don't that these be all marked WF-1.
>
> I honestly don't think the current proposal is bad, it's different from 
> Kombu
> for the reasons I mentioned above but it can be improved. Not that
> improving the badges and their layout doesn't require submitting these
> patches again. It'll be enough to modify the governance repo that generates
> these images.
>
> Hope this helps,
> Flavio
>
>
> [0]
> http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts
> /badges.py
> [1] https://review.openstack.org/#/c/399278/
> [2] http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/107969.html
>
> >Thanks,
> >
> >-amrith
> >
> >[1] https://review.openstack.org/#/q/topic:project-badges
> >[2] https://github.com/celery/kombu/blob/master/README.rst
> >[3] https://review.openstack.org/#/c/402547/
> >[4]
> https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
> >[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
> >[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
> >[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258
> >
> >
> >
> >
> >> -Original Message-
> >> From: Flavio Percoco [mailto:fla...@redhat.com]
> >> Sent: Thursday, October 13, 2016 7:07 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev@lists.openstack.org>
> >> Subject: Re: [openstack-dev] [all][tc] Exposing project team's
> >> metadata in README files
> >>
> >> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
> >> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
> >

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Amrith Kumar]

Flavio,

I see a number of patches[1] which have been landed on this project but I find 
that at least the ones that were landed for Trove, and a random sampling of 
the others all to be different from what you proposed below[2] in one 
important aspect.

In [2] you proposed a structure where the title of the document; or the first, 
and most prominent heading, would be the existing heading of the document, and 
the tags would be below that. In [2] for example, that was:

"kombu - Messaging library for Python"

and the tags would be in smaller font below that.

What I see in [3] the patch for Trove and the proposed example [4] is:

"Team and repository tags" as the first, and most conspicuous header, and the 
header "Trove" below that.

In some cases the second header is the same font as the "Team and repository 
tags" header.

I think this change (these 124 changes) as proposed are not consistent with 
the proposal you made below, and certainly seem to be less suitable than that 
proposal. The end product for the four trove repositories [4], [5], [6], and 
[7]

I think we should have a discussion on the ML whether we feel that this new 
structure is the appropriate one, and before some projects approve these 
changes and others don't that these be all marked WF-1.

Thanks,

-amrith

[1] https://review.openstack.org/#/q/topic:project-badges
[2] https://github.com/celery/kombu/blob/master/README.rst
[3] https://review.openstack.org/#/c/402547/
[4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258




> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Thursday, October 13, 2016 7:07 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in
> README files
>
> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
> >> Greetings,
> >>
> >> One of the common complains about the existing project organization
> >> in the big tent is that it's difficult to wrap our heads around the
> >> many projects there are, their current state (in/out the big tent), their
> tags, etc.
> >>
> >> This information is available on the governance website[0]. Each
> >> official project team has a page there containing the information
> >> related to the deliverables managed by that team. Unfortunately, I
> >> don't think this page is checked often enough and I believe it's not 
> >> known
> by everyone.
> >>
> >> In the hope that we can make this information clearer to people
> >> browsing the many repos (most likely on github), I'd like to propose
> >> that we include the information of each deliverable in the readme
> >> file. This information would be rendered along with the rest of the
> >> readme (at least on Github, which might not be our main repo but it's the
> place most humans go to to check our projects).
> >>
> >> Rather than duplicating this information, I'd like to find a way to
> >> just "include it" in the Readme file. As far as showing the
> >> "official" badge goes, I believe it'd be quite simple. We can do it
> >> the same way CI tags are exposed when using travis (just include an
> >> image). As for the rest of the tags, it might require some extra hacking.
> >>
> >> So, before I start digging more into this, I wanted to get other
> >> opinions/ideas on this topic and how we can make this information
> >> more evident to the rest of the community (and people not as familiar
> with our processes as some of us are).
> >>
> >> Thanks in advance,
> >> Flavio
> >>
> >> [0] http://governance.openstack.org/reference/projects/index.html
> >>
> >
> >Is your proposal that a tag like release:cycle-with-milestones would
> >result in a badge being added when the README.rst is rendered on
> >github.com? Would that work for git.openstack.org, too?
>
> I don't think it'd work for git.openstack.org because it doesn't render the
> README's[0] like github does. One thing I'd like to avoid is for this
> information to result in new changes to the README file everytime the tags
> are updated because I'd like for this information to not be duplicated and 
> to
> make it clear that this information is not meant to be updated manually.
>
> Here's[1] an example of what it would look like (or kinda).
>
> [0] http://git.openstack.org/cgit/openstack/glance/tree/README.rst
> [1] https://github.com/celery/kombu/blob/master/README.rst
>
>
> >I agree that the governance site is not the best place to put the info
> >to make it discoverable. Do users look first at the source repository,
> >or at some other documentation?
>
> The feedback* I've gotten is that users normally look at repos first and 
> they
> go from there to docs 

[openstack-dev] [all][ptls] A request: using the cross-project release goals process for openstack wide change

[Amrith Kumar]

In the last week I've been dealing with two [1][2] cross project efforts
that I believe would have been great candidates for the cross-project goals
process. I think the cross project goals process is lightweight, and it is a
closed-loop process which ensures that we don't have escapes. The use of the
mailing list to communicate these has proved to be problematic in the past
given the sheer volume of mail on the mailing list and the fact that it is
hard to establish server side filters, or for that matter client side
filters to try and only see the emails that are likely of interest without
any possibility that emails that are important get filtered out.

 

So, what's my request . If you see something like this which you believe is
a cross-project, OpenStack wide effort being discussed on the mailing list,
please:

 

(a)Add [all] to the subject line if it isn't already there, and

(b)   Suggest to the sender that they should consider using the
cross-project release goals process.

 

Thanks,

 

-amrith

 

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html

[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086272.html

 



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