Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Matthew Treinish]

On Wed, May 03, 2017 at 11:09:32PM -0400, Monty Taylor wrote:
> On 05/02/2017 11:49 AM, Sean McGinnis wrote:
> > On Tue, May 02, 2017 at 03:36:20PM +0200, Jordan Pittier wrote:
> > > On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann 
> > > wrote:
> > > 
> > > > In Cinder, there are many features/APIs which are backend specific and
> > > > will return 405 or 501 if same is not implemented on any backend [1].
> > > > If such tests are implemented in Tempest, then it will break some gate
> > > > where that backend job is voting. like ceph job in glance_store gate.
> > > > 
> > > > There been many such cases recently where ceph jobs were broken due to
> > > > such tests and recently it is for force-delete backup feature[2].
> > > > Reverting force-delete tests in [3]. To resolve such cases at some
> > > > extend, Jon is going to add a white/black list of tests which can run
> > > > on ceph job [4] depends on what all feature ceph implemented. But this
> > > > does not resolve it completely due to many reason like
> > > > 1. External use of Tempest become difficult where user needs to know
> > > > what all tests to skip for which backend
> > > > 2. Tempest tests become too specific to backend.
> > > > 
> > > > Now there are few options to resolve this:
> > > > 1. Tempest should not tests such API/feature which are backend
> > > > specific like mentioned by api-ref like[1].
> > > > 
> > > So basically, if one of the 50 Cinder driver doesn't support a feature, we
> > > should never test that feature ? What about the 49 other drivers ? If a
> > > feature exists and can be tested in the Gate (with whatever default
> > > config/driver is shipped) then I think we should test it.
> > > 
> > 50? Over 100 as of Ocata.
> > 
> > Well, is tempest's purpose in life to provide complete gate test coverage,
> > or is tempest's purpose in life to give operators a tool to validate that
> > their deployment is working as expected?
> 
> I'd actually like to suggest that such a scenario actually points out a
> thing that is ultimately potential pain passed to the end user in the real
> world, so this question about what/how to test this in tempest is a good one
> to have.
> 
> If there is a feature which is only provisionally available depending on the
> backend driver such that it's hard to test in tempest without an out of band
> config - then it's a feature that a user will have no clue whether it works
> on a given cloud.
> 
> As we find these, I'd love it if we could expose discovery in the API for
> viability of the feature. Like:
> 
> GET /capabilities
> 
> {
>   "capabilities": {
> "has_force_delete": true
>   }
> }
> 
> (I know we've talked about that concept generally, but this is a specific
> example)
> 
> If such a thing existed, then the user can know whether they can use a thing
> .. and so can tempest. A tempest test to validate force_delete working could
> check the capability reported by the API and validate that if the API says
> "true" that the feature work as expected, and if it says "false" validate
> that attempting to call it returns a 405 (or whatever is appropriate)
> 
> Ultimately, every config we need to feed to tempest is potentially a place
> where an end user is unable to know whether or not to expect a call to work
> - and an opportunity for us to provide our API consumers with a richer
> experience.

Heh, well I've been saying all of these things for years. In fact I got so tired
of repeating it all the time I just put it in the tempest configuration guide:
(although I remember it being a lot snarkier)

https://docs.openstack.org/developer/tempest/configuration.html#service-feature-configuration

So, I'll be very happy when the capabilities work actually becomes a thing you
can use. But, it feels like we've been talking about around the problem for a
very long time...

-Matt Treinish


> 
> > In attempting to do things in the past, I've received push back based on
> > the argument that it was the latter. For this reason, in-tree tempest tests
> > were added to Cinder to give us a way to get better test coverage for our
> > own sake.
> > 
> > Now that this is all in place, I think it's working well and I would like
> > to see it continue that way. IMO, tempest proper should not have anything
> > that isn't universally applicable to real world deployments. Not just for
> > things like Ceph, but things like the manage/unmanage backend specific
> > tests that were added and broke a large majority of third party CI.
> > 
> > Backend specific things should not be part of tempest in my opinion. We
> > should cover those things through in-tree tempest plugins and our own
> > testing.
> > > 
> > > > 2. Tempest test can be disabled/skip based on backend. - This is not
> > > > good idea as it increase config options and overhead of setting those.
> > > > 
> > > Using regex and blacklist, any 3rd party CI can skip any test based on the
> > > test ID. Without introducing a config flag. 

[openstack-dev] [Openstack-operators][heat]desire your feedback and join! And welcome on board!

[Rico Lin]

Hi all,

Boston Summit is near, and we need your help and feedback! We really hope
to improve your orchestration experiences,
so *if you're a User, Operator, or Developer,* please join us on
*`Large Orchestration Stacks
`
*Forum
session *(Wednesday, May 10, 5:20pm-6:00pm)*:
To discuss large stacks works and plan and we welcome any users/ops/devs to
join and give out your feedback or thoughts to help on improving
orchestration experiences.
*Here is the etherpad link so please share your opinions whether you're
coming to the summit or not.
**https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks
*


If you wish to learn more detail on heat from beginner
welcome join our *`Heat- Project Onboarding
`
*
Forum session *(Tuesday, May 9, 2:00pm-3:30pm)*
Feel free to contact me and share what you would like to learn from this
session, which I will try my best to put something in.


And if you're interested in overall project update
welcome, join our *`Project Update - Heat
`
session (Monday, May 8, 5:30pm-6:10pm)*



Also, there are a lot of heat relative talks
,
so feel free to walk around and discover it out

May The Force of OpenStack Be With You,
Rico Lin (irc: ricolin)
__
OpenStack Development Mailing 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][heat][murano][daisycloud] Removing Heat support from Tempest

[Matthew Treinish]

On Wed, May 03, 2017 at 11:51:13AM +, Andrea Frittoli wrote:
> On Tue, May 2, 2017 at 5:33 PM Matthew Treinish 
> wrote:
> 
> > On Tue, May 02, 2017 at 09:49:14AM +0530, Rabi Mishra wrote:
> > > On Fri, Apr 28, 2017 at 2:17 PM, Andrea Frittoli <
> > andrea.fritt...@gmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra 
> > wrote:
> > > >
> > > >> On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli <
> > > >> andrea.fritt...@gmail.com> wrote:
> > > >>
> > > >>> Dear stackers,
> > > >>>
> > > >>> starting in the Liberty cycle Tempest has defined a set of projects
> > > >>> which are in scope for direct
> > > >>> testing in Tempest [0]. The current list includes keystone, nova,
> > > >>> glance, swift, cinder and neutron.
> > > >>> All other projects can use the same Tempest testing infrastructure
> > (or
> > > >>> parts of it) by taking advantage
> > > >>> the Tempest plugin and stable interfaces.
> > > >>>
> > > >>> Tempest currently hosts a set of API tests as well as a service
> > client
> > > >>> for the Heat project.
> > > >>> The Heat service client is used by the tests in Tempest, which run in
> > > >>> Heat gate as part of the grenade
> > > >>> job, as well as in the Tempest gate (check pipeline) as part of the
> > > >>> layer4 job.
> > > >>> According to code search [3] the Heat service client is also used by
> > > >>> Murano and Daisycore.
> > > >>>
> > > >>
> > > >> For the heat grenade job, I've proposed two patches.
> > > >>
> > > >> 1. To run heat tree gabbi api tests as part of grenade 'post-upgrade'
> > > >> phase
> > > >>
> > > >> https://review.openstack.org/#/c/460542/
> > > >>
> > > >> 2. To remove tempest tests from the grenade job
> > > >>
> > > >> https://review.openstack.org/#/c/460810/
> > > >>
> > > >>
> > > >>
> > > >>> I proposed a patch to Tempest to start the deprecation counter for
> > Heat
> > > >>> / orchestration related
> > > >>> configuration items in Tempest [4], and I would like to make sure
> > that
> > > >>> all tests and the service client
> > > >>> either find a new home outside of Tempest, or are removed, by the end
> > > >>> the Pike cycle at the latest.
> > > >>>
> > > >>> Heat has in-tree integration tests and Gabbi based API tests, but I
> > > >>> don't know if those provide
> > > >>> enough coverage to replace the tests on Tempest side.
> > > >>>
> > > >>>
> > > >> Yes, the heat gabbi api tests do not yet have the same coverage as the
> > > >> tempest tree api tests (lacks tests using nova, neutron and swift
> > > >> resources),  but I think that should not stop us from *not* running
> > the
> > > >> tempest tests in the grenade job.
> > > >>
> > > >> I also don't know if the tempest tree heat tests are used by any other
> > > >> upstream/downstream jobs. We could surely add more tests to bridge
> > the gap.
> > > >>
> > > >> Also, It's possible to run the heat integration tests (we've enough
> > > >> coverage there) with tempest plugin after doing some initial setup,
> > as we
> > > >> do in all our dsvm gate jobs.
> > > >>
> > > >> It would propose to move tests and client to a Tempest plugin owned /
> > > >>> maintained by
> > > >>> the Heat team, so that the Heat team can have full flexibility in
> > > >>> consolidating their integration
> > > >>> tests. For Murano and Daisycloud - and any other team that may want
> > to
> > > >>> use the Heat service
> > > >>> client in their tests, even if the client is removed from Tempest, it
> > > >>> would still be available via
> > > >>> the Heat Tempest plugin. As long as the plugin implements the service
> > > >>> client interface,
> > > >>> the Heat service client will register automatically in the service
> > > >>> client manager and be available
> > > >>> for use as today.
> > > >>>
> > > >>>
> > > >> if I understand correctly, you're proposing moving the existing
> > tempest
> > > >> tests and service clients to a separate repo managed by heat team.
> > Though
> > > >> that would be collective decision, I'm not sure that's something I
> > would
> > > >> like to do. To start with we may look at adding some of the missing
> > pieces
> > > >> in heat tree itself.
> > > >>
> > > >
> > > > I'm proposing to move tests and the service client outside of tempest
> > to a
> > > > new home.
> > > >
> > > > I also suggested that the new home could be a dedicate repo, since that
> > > > would allow you to maintain the
> > > > current branchless nature of those tests. A more detailed discussion
> > about
> > > > the topic can be found
> > > > in the corresponding proposed queens goal [5],
> > > >
> > > > Using a dedicated repo *is not* a precondition for moving tests and
> > > > service client out of Tempest.
> > > >
> > > >
> > > We probably are mixing two different things here.
> > >
> > > 1. Moving in-tree heat templest plugn and tests to a dedicated repo
> > >
> > > Though we don't have any plans for it now, we may have to do it 

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Monty Taylor]

On 05/03/2017 03:47 AM, Thierry Carrez wrote:

Monty Taylor wrote:

On 05/01/2017 10:44 AM, Ben Swartzlander wrote:

On 04/28/2017 06:26 PM, Monty Taylor wrote:

[...]
Thoughts? Anyone violently opposed?


I don't have any problems with this idea. My main concern would be for
backwards-compatibility and it sounds like that's pretty well sorted out.

I do think it's important that if we make this improvement that all the
projects really do get it done at around the same time, because if we
only implement it 80% of projects, it will look pretty weird.


I could not possibly agree more strongly with both points.


"All the projects [should] really [...] get it done at around the same
time, because if we only implement it 80% of projects, it will look
pretty weird" sounds pretty much like the definition of a good
cross-community goal. Can we afford to wait for Queens to implement this
? If yes it feels like this would make a great goal.



We could - and I agree with you ... but there is actually not work that 
needs to be done in all of the projects. To support this from the 
openstack side - we mostly need to land a patch to keystoneauth. (patch 
already written) I will go check the other clientlibs, but I'm pretty 
sure everyone has been updated to use keystoneauth at this point- except 
swiftclient, but there is a patch up already to handle that. (also, nova 
is working on consuming services via the catalog, but that patch is also 
in flight and that work already has a local version of this done)


We also want to add support both for consuming this and testing it in 
tempest - but that probably wants a deeper conversation with the tempest 
team about the right way to do it.


In any case - I think the hardest part is ensuring consensus that it's a 
good path forward, and a few logisitical concerns Sean and Morgan 
brought up over in the service-types-authority and keystoneauth repos. 
Once we find agreement, I can basically have this implemented on the 
consume side in OpenStack in a few days.


That's a super long response - sorry - I ramble. I'd be more than happy 
to make it a cross-project goal if we think that's the right way to get 
it done - but I worry that if we do it'll steal a valuable slot since 
there's not much of an ask from the projects on this one.


__
OpenStack Development Mailing 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][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

[Adrian Turjak]

On 04/05/17 03:32, Dean Troyer wrote:
> On Tue, May 2, 2017 at 7:32 PM, Adrian Turjak  wrote:
>> Shade in this context is both really easy, and harder since I can't just
>> give it the same session so it can reuse the same token. I've tried
>> seeing if I can pilfer the OpenStackCloudConfig from OSC but passing
>> that to shade seemed to break. If you run that interpreter command you
>> can explore the OSC objects too. "self.app.cloud_config" or
>> "self.app.cloud" appears to be close to what we want, but I can't get it
>> to play nice with shade as it appears to be a OSC extension of the
>> os-client-config class.
> With last week's release of os-client-config 1.27.0 and osc-lib 1.5.1
> and the addition of these to global-requirements minimums for today's
> OSC 3.10.0 release we are in a place to move most of the special-case
> code back in to osc-lib and os-client-config.  Much of this is due to
> backward-compatibility issues that OSC needed to handle.
>
>> If the interpreter is started from envvars you can do "cloud =
>> openstack_cloud()" and shade does the right thing. If it was started
>> with --os-cloud then you can also do "cloud =
>> openstack_cloud(cloud=self.app.cloud.config.get('cloud'))". The latter
>> also works with envvars as "self.app.cloud.config.get('cloud')" returns
>> an empty string so shade looks at envvars. I can easily make a function
>> that just returns shade with a new token, just kind of sucks that there
>> is no way to pass it a valid session/token for it to reuse. Would be
>> fantastic if you can take a gander at that as I don't know that much
>> about Shade. I'd prefer to have this thing use a single shared session
>> or token as much as possible.
> Both OSC and Shade use ksa Sessions, that bit should be directly
> sharable and includes the token handling.  OSC's auth stuff changed a
> bit in the 3.10.0 release in the first step of simplifying it and
> actually being able to use os-client-config as intended.  There are a
> bunch of timing issues regarding _when_ auth plugins get loaded that
> differ between Shade and OSC's usage.  once we complete resolving that
> the level of reuse should be able to go up substantially.
>
> dt
With the newest release, the following seems to work without errors:
In [1]: import shade

In [2]: cloud = shade.openstack_cloud(config=self.app.cloud_config)

In [3]: cloud.list_servers()

I'm not sure it reuses the same session, but *shrug* at least it is
easily piping through the same auth and profile values you used to setup
the openstackclient to shade. I'll add a basic factory for shade (not
that it really needs much of one), and then one for OpenStackSDK soon
and publish a new version of the interpreter command.


__
OpenStack Development Mailing 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] [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

[Adrian Turjak]

On 04/05/17 03:20, Dean Troyer wrote:
> On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak  
> wrote:
>> As part of my dev work I recently put together a cool little tool which
>> lets me have much easier access to the various OpenStack python clients
>> in the scope of a python interpreter session. The first version was a
>> little rough and without os-client-config support. The current version
>> is now a plugin for the openstackclient and introduces a command that
>> simply authenticates you, sets up the environment and helper tools, and
>> then drops you into an ipython interactive session. The helper stuff is
>> fairly simple, but combined with the features of ipython it really lets
>> you start playing with the tools quickly, and by piggybacking onto
>> openstackclient I get access to a lot of the niceties and inbuilt auth
>> mechanisms.
>>
>> It is useful for learning, testing, or development against the various
>> openstack client libraries, and even as an ops tool to quickly run some
>> basic actions without having to resort to weird or silly bash command
>> combinations.
> This is at the other end of the spectrum of client usage from the CLI
> in that it takes a very developer-like view of the APIs.  OSC has its
> interactive mode (using cmd2) that is just a command loop without even
> the ability to change global settings.  My hunch is that something in
> between would be really useful, but I am not interested in creating
> yet another DSL for this to include flow control and branching.
>
> You mentioned Shade, which falls somewhere in between as it implements
> a lot of logic to hide differences in clouds and ease dealing with
> some of our API warts.  What would you think about producing a Python
> mirror of the CLI interface with resource names, option names,
> everything, but in Python.  I have not thought all the way through
> this yet, but think we could take advantage of using the cliff command
> classes and be able to re-use all of the bits already written.
>
> This also magnifies the things we need to add to (or factor out of)
> OSC to make it truly useful, such as manipulation of the global
> options, maintaining multiple client contexts, etc.
>
> Thanks for sharing!
> dt
A new DSL is probably a terrible idea for obvious reasons:
https://xkcd.com/927/

A good interpreter like ipython combined with a reasonably easy way to
access the existing myriad of client libraries gets us most of the way.
While making yet another wrapper layer to simplify everything could
work, I feel that we have enough libraries already, and no one really
knows them all that well, and a lot of them are seriously lacking good
docs outside of the code itself. While the idea of making a interpreter
specific layer for the APIs would be interesting, I feel like it would
be wasted effort that could go towards promoting better consistency and
quality among the various existing python tools.

The project specific python libraries have a fairly similar command
structure to OSC as is, but it is interesting to compare them all:

OSC:   openstack  
vs
clients:   ..
vs
SDK:  .._
vs
shade:   ._

There are of course differences between some of the
python-clients structurally but a lot of them tend to follow
the same pattern. Then there is minor but annoying stuff like some
list() commands return lists, while others return generators.

I don't think writing yet another python library is a good idea even if
specific to python interpreter interactions. I think we just need to
document and educate about all the existing client options really well,
and have tools like this that promote them.

Including non-python libraries, because often those feel like second
class citizen, and often we forget about them entirely. I had to
recommend a good java library to a client recently and after testing a
bunch I found that only openstack4j was actually easy to use, and had
proper identity v3 support. The most recommended javaSDK is jclouds and
it was so very confusing and badly documented at a glance and from a new
user perspective.

My goal with this tool was mainly to promote better literacy for the
existing python libraries among our team here at Catalyst and give our
cloud customers a place to start prototyping interactions when building
applications that talk to the APIs. Well... and build something I myself
wanted to use!

Less new libraries and standards unless we actually deprecate old stuff!
More docs, polish for existing libraries, and better ways to use them! :P



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

Re: [openstack-dev] [all] Yakumo: Pythonic, unified OpenStack client library

[Akira Yoshiyama]

Hi Markus,

2017-05-03 15:59 GMT+09:00 Markus Zoeller :
> On 03.05.2017 04:46, Akira Yoshiyama wrote:
>> Hello all,
>>
>> I'm pleased to announce Yakumo, yet another unified OpenStack client
>> library with an interactive shell. You can find Yakumo below:
>>
>>PyPI: https://pypi.python.org/pypi/yakumo/
>>Github: https://github.com/yosshy/python-yakumo/
>>
>> Yakumo development focuses to:
>>
>> * Pythonic: handles each cloud resource as an object in the same manner
>> * Unified: handles all OpenStack APIs at once
>> * Less dependency: no import of other OpenStack client libraries
>>
>> Why do we have to specify IDs of cloud resources in Python
>> programming? Python is an object-oriented programming language. IMO,
>> we should use objects to represent cloud resources, including method
>> arguments. It's one of the reasons I've started Yakumo project.
>>
>> Yakumo 0.11.0 suports OpenStack APIs below:
>>
>> * Identity API v2/v3
>> * Compute API v2
>> * Networking v2
>> * Image Service API v1/v2
>> * Block Storage v1/v2
>> * Object Storage v1
>>
>> Yakumo has 23 sample smoke tests below for the APIs now. It's useful
>> to test your cloud and learn usage of Yakumo.
>>
>>https://github.com/yosshy/python-yakumo/tree/master/yakumo/smoketests
(snip)
> The interface looks nice! The docs too! I like the openstack-client for
> CLI stuff, but I think I will give your client a shot when I have to
> hack functional tests in python scripts which don't need to be in Tempest.

Oh, thank you. I hope you like it.

Regards,
Akira

>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> __
> OpenStack Development Mailing 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][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

[Adrian Turjak]

On 04/05/17 03:20, Dean Troyer wrote:
> On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak  
> wrote:
>> As part of my dev work I recently put together a cool little tool which
>> lets me have much easier access to the various OpenStack python clients
>> in the scope of a python interpreter session. The first version was a
>> little rough and without os-client-config support. The current version
>> is now a plugin for the openstackclient and introduces a command that
>> simply authenticates you, sets up the environment and helper tools, and
>> then drops you into an ipython interactive session. The helper stuff is
>> fairly simple, but combined with the features of ipython it really lets
>> you start playing with the tools quickly, and by piggybacking onto
>> openstackclient I get access to a lot of the niceties and inbuilt auth
>> mechanisms.
>>
>> It is useful for learning, testing, or development against the various
>> openstack client libraries, and even as an ops tool to quickly run some
>> basic actions without having to resort to weird or silly bash command
>> combinations.
> This is at the other end of the spectrum of client usage from the CLI
> in that it takes a very developer-like view of the APIs.  OSC has its
> interactive mode (using cmd2) that is just a command loop without even
> the ability to change global settings.  My hunch is that something in
> between would be really useful, but I am not interested in creating
> yet another DSL for this to include flow control and branching.
>
> You mentioned Shade, which falls somewhere in between as it implements
> a lot of logic to hide differences in clouds and ease dealing with
> some of our API warts.  What would you think about producing a Python
> mirror of the CLI interface with resource names, option names,
> everything, but in Python.  I have not thought all the way through
> this yet, but think we could take advantage of using the cliff command
> classes and be able to re-use all of the bits already written.
>
> This also magnifies the things we need to add to (or factor out of)
> OSC to make it truly useful, such as manipulation of the global
> options, maintaining multiple client contexts, etc.
>
> Thanks for sharing!
> dt
A new DSL is probably a terrible idea for obvious reasons:
https://xkcd.com/927/

A good interpreter like ipython combined with a reasonably easy way to
access the existing myriad of client libraries gets us most of the way.
While making yet another wrapper layer to simplify everything could
work, I feel that we have enough libraries already, and no one really
knows them all that well, and a lot of them are seriously lacking good
docs outside of the code itself. While the idea of making a interpreter
specific layer for the APIs would be interesting, I feel like it would
be wasted effort that could go towards promoting better consistency and
quality among the various existing python tools.

The project specific python libraries have a fairly similar command
structure to OSC as is, but it is interesting to compare them all:

OSC:   openstack  
vs
clients:   ..
vs
SDK:  .._
vs
shade:   ._

There are of course differences between some of the
python-clients structurally but a lot of them tend to follow
the same pattern. Then there is minor but annoying stuff like some
list() commands return lists, while others return generators.

I don't think writing yet another python library is a good idea even if
specific to python interpreter interactions. I think we just need to
document and educate about all the existing client options really well,
and have tools like this that promote them.

Including non-python libraries, because often those feel like second
class citizen, and often we forget about them entirely. I had to
recommend a good java library to a client recently and after testing a
bunch I found that only openstack4j was actually easy to use, and had
proper identity v3 support. The most recommended javaSDK is jclouds and
it was so very confusing and badly documented at a glance and from a new
user perspective.

My goal with this tool was mainly to promote better literacy for the
existing python libraries among our team here at Catalyst and give our
cloud customers a place to start prototyping interactions when building
applications that talk to the APIs. Well... and build something I myself
wanted to use!

Less new libraries and standards unless we actually deprecate old stuff!
More docs, polish for existing libraries, and better ways to use them! :P



__
OpenStack Development Mailing 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][cinder][ceph] should Tempest tests the backend specific feature?

[Fei Long Wang]

On 04/05/17 15:01, Ghanshyam Mann wrote:
>
> On Wed, May 3, 2017 at 21:57 Andrea Frittoli
> > wrote:
>
> On Tue, May 2, 2017 at 2:41 PM Jordan Pittier
> >
> wrote:
>
> On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann
> > wrote:
>
> In Cinder, there are many features/APIs which are backend
> specific and
> will return 405 or 501 if same is not implemented on any
> backend [1].
> If such tests are implemented in Tempest, then it will
> break some gate
> where that backend job is voting. like ceph job in
> glance_store gate.
>
> There been many such cases recently where ceph jobs were
> broken due to
> such tests and recently it is for force-delete backup
> feature[2].
> Reverting force-delete tests in [3]. To resolve such cases
> at some
> extend, Jon is going to add a white/black list of tests
> which can run
> on ceph job [4] depends on what all feature ceph
> implemented. But this
> does not resolve it completely due to many reason like
> 1. External use of Tempest become difficult where user
> needs to know
> what all tests to skip for which backend
> 2. Tempest tests become too specific to backend.
>
> Now there are few options to resolve this:
> 1. Tempest should not tests such API/feature which are backend
> specific like mentioned by api-ref like[1].
>
> So basically, if one of the 50 Cinder driver doesn't support a
> feature, we should never test that feature ? What about the 49
> other drivers ? If a feature exists and can be tested in the
> Gate (with whatever default config/driver is shipped) then I
> think we should test it.
>  
>
> 2. Tempest test can be disabled/skip based on backend. -
> This is not
> good idea as it increase config options and overhead of
> setting those.
>
> Using regex and blacklist, any 3rd party CI can skip any test
> based on the test ID. Without introducing a config flag.
> See: 
> https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871
>
>
> This way each 3rd party system has to maintain its own list, which
> has the advantage that
> different teams maintain their own list (which is nice from an
> ownership and scale pov).
>
> However I think such list of tests are not as re-usable as having
> a devstack plugin (or an
> ansible or puppet module) changing a few tempest config options. 
>
>
> Humm, I am little bit hesitate to go that way. For gate and CI it
> might be good solution but for production cloud testing it makes
> Tenpest difficult to use.
>
> If I use Tempest to test my cloud, few tests going to fail as those
> were not supported by cinder driver my cloud has or going to have. 
> I do not have any way to configure something so that test can be
> disabled. Instead I need to maintain list of tests to run or skip. And
> that list is not static, it grows dynamically. 
> This makes Tempest difficult to use. 
>
>

Agree. We (Catalyst Cloud based in NZ) are using Tempest as the
monitoring tool and CI/CD gate for our cloud. But we do have to maintain
a white list of test cases because there are some cases are not fitting
our cloud.

>
>
>  
>
> 3. Tempest test can verify behavior with if else condition
> as per
> backend. This is bad idea and lose the test strength.
>
> Yeah, that's bad. 
>
>
> IMO options 1 is better options. More feedback are welcome. 
>
>
> ..1
> 
> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
> ..2 https://bugs.launchpad.net/glance/+bug/1687538
> ..3 https://review.openstack.org/#/c/461625/
> ..4
> 
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>
> -gmann
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> 
> 

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Ghanshyam Mann]

On Wed, May 3, 2017 at 22:35 Sean McGinnis  wrote:

> On Wed, May 03, 2017 at 01:14:18PM +, Andrea Frittoli wrote:
> >
> > > >
> >
> > > Now that this is all in place, I think it's working well and I would
> like
> > > to see it continue that way. IMO, tempest proper should not have
> anything
> > > that isn't universally applicable to real world deployments. Not just
> for
> > > things like Ceph, but things like the manage/unmanage backend specific
> > > tests that were added and broke a large majority of third party CI.
> > >
> >
> > Is there a policy in Cinder that a backend must implement a certain set
> of
> > APIs? If so we could think of testing only that set of APIs in Tempest,
> so
> > that
> > any app developer knows that he/she can rely on that minimum set of APIs.
> >


+1.


>
> Yes, there is a minimum feature set that all backend drivers must support.
> That base functionality can be found here [0] and here [1].
>
> [0]
> https://docs.openstack.org/developer/cinder/devref/drivers.html#core-functionality
> [1]
> https://github.com/openstack/cinder/blob/master/cinder/interface/volume_driver.py
>
> The issue we've had with some of the tempest tests isn't actually around
> whether the given backend supports the API. It's the way the API is used
> that becomes a challenge.


This is good way to solve the most part of issue. Tempest can test the
cinder MUST list Features. This provides the consistent way of testing the
basic and consistent features.



>
> I'll use the manage/unmanage snapshot one as an example. This is not one
> of the required APIs, but many backends do support it. But the way this
> API works is you are basically saying "manage this snapshot that you
> identify as X", where "X" can be different things depending on the volume
> driver being used. It's the storage device's native way of identifying
> a snapshot, which may or may not be our Cinder snapshot ID.
>
> So that test was added based on the way the LVM driver works for this.
> That part is great, we get some more code coverage in the gate. But then
> each volume driver that uses a different ID had to first a) start failing
> CI, b) troubleshoot what happened to cause this new failure, c) reconfig
> their CI to skip this test. Repeat cycle for each test added that does
> something specific to how one or a small subset of backends work.


Yea, we should test the consistent part of behavior. I agree snapshot
manage test needs to be modified to work for all backends. We welcome if
you or someone from cinder team can suggest the generic way to identify the
managed snapshot.

For all cinder MUST features in all backend we should avoid the
storage/backend specific logic in tests.



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

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Monty Taylor]

On 05/02/2017 11:49 AM, Sean McGinnis wrote:

On Tue, May 02, 2017 at 03:36:20PM +0200, Jordan Pittier wrote:

On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann 
wrote:


In Cinder, there are many features/APIs which are backend specific and
will return 405 or 501 if same is not implemented on any backend [1].
If such tests are implemented in Tempest, then it will break some gate
where that backend job is voting. like ceph job in glance_store gate.

There been many such cases recently where ceph jobs were broken due to
such tests and recently it is for force-delete backup feature[2].
Reverting force-delete tests in [3]. To resolve such cases at some
extend, Jon is going to add a white/black list of tests which can run
on ceph job [4] depends on what all feature ceph implemented. But this
does not resolve it completely due to many reason like
1. External use of Tempest become difficult where user needs to know
what all tests to skip for which backend
2. Tempest tests become too specific to backend.

Now there are few options to resolve this:
1. Tempest should not tests such API/feature which are backend
specific like mentioned by api-ref like[1].


So basically, if one of the 50 Cinder driver doesn't support a feature, we
should never test that feature ? What about the 49 other drivers ? If a
feature exists and can be tested in the Gate (with whatever default
config/driver is shipped) then I think we should test it.


50? Over 100 as of Ocata.

Well, is tempest's purpose in life to provide complete gate test coverage,
or is tempest's purpose in life to give operators a tool to validate that
their deployment is working as expected?


I'd actually like to suggest that such a scenario actually points out a 
thing that is ultimately potential pain passed to the end user in the 
real world, so this question about what/how to test this in tempest is a 
good one to have.


If there is a feature which is only provisionally available depending on 
the backend driver such that it's hard to test in tempest without an out 
of band config - then it's a feature that a user will have no clue 
whether it works on a given cloud.


As we find these, I'd love it if we could expose discovery in the API 
for viability of the feature. Like:


GET /capabilities

{
  "capabilities": {
"has_force_delete": true
  }
}

(I know we've talked about that concept generally, but this is a 
specific example)


If such a thing existed, then the user can know whether they can use a 
thing .. and so can tempest. A tempest test to validate force_delete 
working could check the capability reported by the API and validate that 
if the API says "true" that the feature work as expected, and if it says 
"false" validate that attempting to call it returns a 405 (or whatever 
is appropriate)


Ultimately, every config we need to feed to tempest is potentially a 
place where an end user is unable to know whether or not to expect a 
call to work - and an opportunity for us to provide our API consumers 
with a richer experience.



In attempting to do things in the past, I've received push back based on
the argument that it was the latter. For this reason, in-tree tempest tests
were added to Cinder to give us a way to get better test coverage for our
own sake.

Now that this is all in place, I think it's working well and I would like
to see it continue that way. IMO, tempest proper should not have anything
that isn't universally applicable to real world deployments. Not just for
things like Ceph, but things like the manage/unmanage backend specific
tests that were added and broke a large majority of third party CI.

Backend specific things should not be part of tempest in my opinion. We
should cover those things through in-tree tempest plugins and our own
testing.



2. Tempest test can be disabled/skip based on backend. - This is not
good idea as it increase config options and overhead of setting those.


Using regex and blacklist, any 3rd party CI can skip any test based on the
test ID. Without introducing a config flag. See:
https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871



3. Tempest test can verify behavior with if else condition as per
backend. This is bad idea and lose the test strength.


Yeah, that's bad.



IMO options 1 is better options. More feedback are welcome.




..1 https://developer.openstack.org/api-ref/block-storage/v3/?
expanded=force-delete-a-backup-detail#force-delete-a-backup
..2 https://bugs.launchpad.net/glance/+bug/1687538
..3 https://review.openstack.org/#/c/461625/
..4 http://lists.openstack.org/pipermail/openstack-dev/2017-
April/115229.html

-gmann


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

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Ghanshyam Mann]

On Wed, May 3, 2017 at 21:57 Andrea Frittoli 
wrote:

> On Tue, May 2, 2017 at 2:41 PM Jordan Pittier 
> wrote:
>
>> On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann 
>> wrote:
>>
>>> In Cinder, there are many features/APIs which are backend specific and
>>> will return 405 or 501 if same is not implemented on any backend [1].
>>> If such tests are implemented in Tempest, then it will break some gate
>>> where that backend job is voting. like ceph job in glance_store gate.
>>>
>>> There been many such cases recently where ceph jobs were broken due to
>>> such tests and recently it is for force-delete backup feature[2].
>>> Reverting force-delete tests in [3]. To resolve such cases at some
>>> extend, Jon is going to add a white/black list of tests which can run
>>> on ceph job [4] depends on what all feature ceph implemented. But this
>>> does not resolve it completely due to many reason like
>>> 1. External use of Tempest become difficult where user needs to know
>>> what all tests to skip for which backend
>>> 2. Tempest tests become too specific to backend.
>>>
>>> Now there are few options to resolve this:
>>> 1. Tempest should not tests such API/feature which are backend
>>> specific like mentioned by api-ref like[1].
>>>
>> So basically, if one of the 50 Cinder driver doesn't support a feature,
>> we should never test that feature ? What about the 49 other drivers ? If a
>> feature exists and can be tested in the Gate (with whatever default
>> config/driver is shipped) then I think we should test it.
>>
>>
>>> 2. Tempest test can be disabled/skip based on backend. - This is not
>>> good idea as it increase config options and overhead of setting those.
>>>
>> Using regex and blacklist, any 3rd party CI can skip any test based on
>> the test ID. Without introducing a config flag. See:
>> https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871
>>
>
> This way each 3rd party system has to maintain its own list, which has the
> advantage that
> different teams maintain their own list (which is nice from an ownership
> and scale pov).
>
> However I think such list of tests are not as re-usable as having a
> devstack plugin (or an
> ansible or puppet module) changing a few tempest config options.
>

Humm, I am little bit hesitate to go that way. For gate and CI it might be
good solution but for production cloud testing it makes Tenpest difficult
to use.

If I use Tempest to test my cloud, few tests going to fail as those were
not supported by cinder driver my cloud has or going to have.
I do not have any way to configure something so that test can be disabled.
Instead I need to maintain list of tests to run or skip. And that list is
not static, it grows dynamically.
This makes Tempest difficult to use.




>
>>
>>> 3. Tempest test can verify behavior with if else condition as per
>>> backend. This is bad idea and lose the test strength.
>>>
>> Yeah, that's bad.
>>
>>>
>>> IMO options 1 is better options. More feedback are welcome.
>>
>>
>>> ..1
>>> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
>>> ..2 https://bugs.launchpad.net/glance/+bug/1687538
>>> ..3 https://review.openstack.org/#/c/461625/
>>> ..4
>>> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>>>
>>> -gmann
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> __
>> OpenStack Development Mailing 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
>
-- 
-gmann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Ghanshyam Mann]

On Wed, May 3, 2017 at 21:49 Andrea Frittoli 
wrote:

> On Tue, May 2, 2017 at 6:46 AM Ghanshyam Mann 
> wrote:
>
>> In Cinder, there are many features/APIs which are backend specific and
>> will return 405 or 501 if same is not implemented on any backend [1].
>> If such tests are implemented in Tempest, then it will break some gate
>> where that backend job is voting. like ceph job in glance_store gate.
>>
>
> Having a test in Tempest is important for interoperability and API
> backward compatibility.
> As long as available features are discoverable and reported in a
> consistent way, it
> is possible for app developer to write application that will work fine
> against
> different backends.
>

But in this case, features are not discoverable. From API status code only
we can get to know whether it is implemented in particular backend or not.
It has same issue for interoperability as Tempest facing now.


>
>>
>> There been many such cases recently where ceph jobs were broken due to
>> such tests and recently it is for force-delete backup feature[2].
>> Reverting force-delete tests in [3]. To resolve such cases at some
>> extend, Jon is going to add a white/black list of tests which can run
>> on ceph job [4] depends on what all feature ceph implemented. But this
>> does not resolve it completely due to many reason like
>> 1. External use of Tempest become difficult where user needs to know
>> what all tests to skip for which backend
>> 2. Tempest tests become too specific to backend.
>>
>> Now there are few options to resolve this:
>> 1. Tempest should not tests such API/feature which are backend
>> specific like mentioned by api-ref like[1].
>> 2. Tempest test can be disabled/skip based on backend. - This is not
>> good idea as it increase config options and overhead of setting those.
>>
>
> Tempest has many options because we decide not to rely on discovery, i.e.
> we configure what we expect to find in the target cloud. I don't think we
> can use
> this as a factor to influence the decision in this case.
>

>
>> 3. Tempest test can verify behavior with if else condition as per
>> backend. This is bad idea and lose the test strength.
>>
>> IMO options 1 is better options. More feedback are welcome.
>>
>> ..1
>> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
>> ..2 https://bugs.launchpad.net/glance/+bug/1687538
>> ..3 https://review.openstack.org/#/c/461625/
>> ..4
>> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>>
>> -gmann
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
-gmann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] [all] systemd in devstack by default

[Monty Taylor]

On 05/03/2017 06:45 PM, James Slagle wrote:

On Tue, May 2, 2017 at 9:19 AM, Monty Taylor  wrote:

I absolutely cannot believe I'm saying this given what the change implements
and my general steaming hatred associated with it ... but this is awesome
work and a definite improvement over what existed before it. If we're going
to be stuck sharing the Bad Trip that is Lennart's projected consciousness,
this is a pleasant surprise of a positive outcome.


In my opinion, these comments about Lennart are quite out of line.
Regardless of whether or not that individual is a member of the
OpenStack community, there are constructive ways to voice your
opinions about systemd without resorting to these types of personal
comments.


Totally fair, and I apologize.


systemd is an open source driven community project. I'd suggest
directing your energy at those technology choices and working towards
what you see as improvements in those choices instead of making
comments such as what you've done here.

While minor (with some thinly veiled praise sprinkled in), I'm a bit
shocked no one else has called attention to your response. It is not
friendly, considerate, and above all else -- it is not respectful.


You are totally right. It is an unacceptable way for me to have 
expressed myself. I will endeavor to do better in the future - and 
although I doubt he's reading this list at the moment, I do earnestly 
apologize to Lennart as well. Personally directed statements such as 
that are, in fact, totally inappropriate.


Monty


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

[openstack-dev] [keystone] No policy meeting next week (2017-05-10)

[Lance Bragstad]

Next week is the Forum, so we'll forego the the policy meeting in favor of
some face-to-face discussions.

Let's pick back up with policy recaps on the 17th of May.

Thanks,


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

Re: [openstack-dev] OpenStack moving both too fast and too slow at the same time

[Chris Friesen]

On 05/03/2017 02:00 PM, Drew Fisher wrote:


Reading the user survey [2], I see the same issues time and time again.
Pages 18-19 of the survey are especially common points.
Things move too fast, no LTS release, upgrades are terrifying for
anything that isn't N-1 -> N.
These come up time and time again
How is the TC working with the dev teams to address these critical issues?


With my upstream nova developer hat on, it'd be painful to try to enable 
upgrades for anything other than N-1 -> N.  (Heck, it's sometimes painful to 
even ensure that N-1 -> N works properly.)


The team I work for made the decision to skip Liberty and upgrade directly from 
Kilo to Mitaka.  We made it work, but the RPC and object versioning issues were 
a bit finicky.



I asked this because on page 18 is this comment:

"Most large customers move slowly and thus are running older versions,
which are EOL upstream sometimes before they even deploy them."

This is exactly what we're seeing with some of our customers and I
wanted to ask the TC about it.


Us too.  I'm not sure there is a simple solution.  To some extent I suppose 
that's what distro folks get paid for...to do stuff that upstream can't (or 
won't) do.


Chris


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

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests thebackend specific feature?

[zhu.fanglei]

Yea, the situation described below is imagable.




And all things seem to be a measure and tradeoff, i.e.,  if the feature is 
supported by a big part of the backends and can be deemed as something like 
"main trend", then we should test it in Tempest, though inevitably we will 
suffer the procedure of fail-＞troubleshoot-＞skip in some third party CI, but 
not everything can be perfect in the world, again, it's a tradeoff.




And as to how to decide what feature is "main trend" feature, maybe we can have 
a mechanism of voting, just as how we decide the core-functionality set.






Original Mail



Sender:  ＜sean.mcgin...@gmx.com＞
To:  ＜openstack-dev@lists.openstack.org＞
Date: 2017/05/03 21:35
Subject: Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests thebackend 
specific feature?





On Wed, May 03, 2017 at 01:14:18PM +, Andrea Frittoli wrote:
＞ 
＞ ＞ ＞
＞ 
＞ ＞ Now that this is all in place, I think it's working well and I would like
＞ ＞ to see it continue that way. IMO, tempest proper should not have anything
＞ ＞ that isn't universally applicable to real world deployments. Not just for
＞ ＞ things like Ceph, but things like the manage/unmanage backend specific
＞ ＞ tests that were added and broke a large majority of third party CI.
＞ ＞
＞ 
＞ Is there a policy in Cinder that a backend must implement a certain set of
＞ APIs? If so we could think of testing only that set of APIs in Tempest, so
＞ that
＞ any app developer knows that he/she can rely on that minimum set of APIs.
＞ 

Yes, there is a minimum feature set that all backend drivers must support.
That base functionality can be found here [0] and here [1].

[0] 
https://docs.openstack.org/developer/cinder/devref/drivers.html#core-functionality
[1] 
https://github.com/openstack/cinder/blob/master/cinder/interface/volume_driver.py

The issue we've had with some of the tempest tests isn't actually around
whether the given backend supports the API. It's the way the API is used
that becomes a challenge.

I'll use the manage/unmanage snapshot one as an example. This is not one
of the required APIs, but many backends do support it. But the way this
API works is you are basically saying "manage this snapshot that you
identify as X", where "X" can be different things depending on the volume
driver being used. It's the storage device's native way of identifying
a snapshot, which may or may not be our Cinder snapshot ID.

So that test was added based on the way the LVM driver works for this.
That part is great, we get some more code coverage in the gate. But then
each volume driver that uses a different ID had to first a) start failing
CI, b) troubleshoot what happened to cause this new failure, c) reconfig
their CI to skip this test. Repeat cycle for each test added that does
something specific to how one or a small subset of backends work.


__
OpenStack Development Mailing 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] Deployment for production

[Paras pradhan]

It is going to be a lot of work to make high availablity work with the
deployment you do with packstack or rdo.  Tripleo provides HA . One good
reason to deploy triplo over rdo / packstack

-Paras.

On Wed, May 3, 2017 at 7:08 PM, Mike Smith  wrote:

> At Overstock.com we use RDO on CentOS for our production clouds.   Works
> great for us.
>
> We do the install straight from the openstack docs but do our own puppet
> modules since we use puppet for everything we do.
>
> Mike
>
> > On May 3, 2017, at 1:01 AM, Satish Patel  wrote:
> >
> > We did POC on RDO and we are happy with product but now question is,
> should we use RDO for production deployment or other open source flavor
> available to deploy on prod. Not sure what is the best method of production
> deployment?
> >
> > Sent from my iPhone
> > ___
> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [tripleo] pingtest vs tempest

[Dan Prince]

On Wed, 2017-05-03 at 17:53 -0400, Emilien Macchi wrote:
> (cross-posting)
> 
> I've seen a bunch of interesting thoughts here.
> The most relevant feedback I've seen so far:
> 
> - TripleO folks want to keep testing fast and efficient.
> - Tempest folks understand this problematic and is willing to
> collaborate.
> 
> I propose that we move forward and experiment the usage of Tempest in
> TripleO CI for one job that could be experimental or non-voting to
> start.

Experimental or periodic at first please.

> Instead of running the Pingtest, we would execute a Tempest Scenario
> that boot an instance from volume (like Pingstest is already doing)
> and see how it goes (in term of coverage and runtime).
> I volunteer to kick-off the work with someone more expert than I am
> with quickstart (Arx maybe?).
> 
> Another iteration could be to start building an easy interface to
> select which Tempest tests we want a TripleO CI job to run and plug
> it
> to our CI tooling (tripleo-quickstart I presume).

Running a subset of Tempest tests isn't the same thing as designing
(and owning) your own test suite that targets the things that mean the
most to our community (namely speed and coverage). Even giving up 5-10
minutes of runtime...just to be able to run Tempest isn't something
that some of us would be willing to do.

> I also hear some feedback about keeping the pingtest alive for some
> uses cases, and I agree we could keep some CI jobs to run the
> pingtest
> when it makes more sense (when we want to test Heat for example, or
> just maintain it for developers who used it).



> 
> How does it sounds? Please bring feedback.
> 
> 
> On Tue, Apr 18, 2017 at 7:41 AM, Attila Fazekas 
> wrote:
> > 
> > 
> > On Tue, Apr 18, 2017 at 11:04 AM, Arx Cruz 
> > wrote:
> > > 
> > > 
> > > 
> > > On Tue, Apr 18, 2017 at 10:42 AM, Steven Hardy  > > > wrote:
> > > > 
> > > > On Mon, Apr 17, 2017 at 12:48:32PM -0400, Justin Kilpatrick
> > > > wrote:
> > > > > On Mon, Apr 17, 2017 at 12:28 PM, Ben Nemec  > > > > an.com>
> > > > > wrote:
> > > > > > Tempest isn't really either of those things.  According to
> > > > > > another
> > > > > > message
> > > > > > in this thread it takes around 15 minutes to run just the
> > > > > > smoke
> > > > > > tests.
> > > > > > That's unacceptable for a lot of our CI jobs.
> > > 
> > > 
> > > I rather spend 15 minutes running tempest than add a regression
> > > or a new
> > > bug, which already happen in the past.
> > > 
> > 
> > The smoke tests might not be the best test selection anyway, you
> > should pick
> > some scenario which does
> > for example snapshot of images and volumes. yes, these are the slow
> > ones,
> > but they can run in parallel.
> > 
> > Very likely you do not really want to run all tempest test, but
> > 10~20 minute
> > time,
> > sounds reasonable for a sanity test.
> > 
> > The tempest config utility also should be extended by some parallel
> > capability,
> > and should be able to use already downloaded (part of the image)
> > resources.
> > 
> > Tempest/testr/subunit worker balance is not always the best,
> > technically would be possible to do dynamic balancing, but it would
> > require
> > a lot of work.
> > Let me know when it becomes the main concern, I can check what
> > can/cannot be
> > done.
> > 
> > 
> > > 
> > > > 
> > > > > Ben, is the issue merely the time it takes? Is it the affect
> > > > > that time
> > > > > taken has on hardware availability?
> > > > 
> > > > It's both, but the main constraint is the infra job timeout,
> > > > which is
> > > > about
> > > > 2.5hrs - if you look at our current jobs many regularly get
> > > > close to (and
> > > > sometimes exceed this), so we just don't have the time budget
> > > > available
> > > > to
> > > > run exhasutive tests every commit.
> > > 
> > > 
> > > We have green light from infra to increase the job timeout to 5
> > > hours, we
> > > do that in our periodic full tempest job.
> > 
> > 
> > Sounds good, but I am afraid it could hurt more than helping, it
> > could delay
> > other things get fixed by lot
> > especially if we got some extra flakiness, because of foobar.
> > 
> > You cannot have all possible tripleo configs on the gate anyway,
> > so something will pass which will require a quick fix.
> > 
> > IMHO the only real solution, is making the before test-run steps
> > faster or
> > shorter.
> > 
> > Do you have any option to start the tempest running jobs in a more
> > developed
> > state ?
> > I mean, having more things already done at the start
> > time  (images/snapshot)
> > and just do a fast upgrade at the beginning of the job.
> > 
> > Openstack installation can be completed in a `fast` way (~minute)
> > on
> > RHEL/Fedora systems
> > after the yum steps, also if you are able to aggregate all yum step
> > to
> > single
> > command execution (transaction) you generally able to save a lot of
> > time.
> > 
> > There 

Re: [Openstack] Deployment for production

[Mike Smith]

At Overstock.com we use RDO on CentOS for our production clouds.   Works great 
for us.

We do the install straight from the openstack docs but do our own puppet 
modules since we use puppet for everything we do.

Mike

> On May 3, 2017, at 1:01 AM, Satish Patel  wrote:
> 
> We did POC on RDO and we are happy with product but now question is, should 
> we use RDO for production deployment or other open source flavor available to 
> deploy on prod. Not sure what is the best method of production deployment?
> 
> Sent from my iPhone
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

Re: [Openstack] Deployment for production

[Satish Patel]

So let me get this straight you used RDO repo but use your puppet module to 
deploy application right? 

Also do you guys using DVR distributes virtual router or central network node?

Sent from my iPhone

> On May 3, 2017, at 12:31 PM, Tim Bell  wrote:
> 
> We use packstack when we need an all-in-one environment such as people 
> wanting to try out some new ideas 
> (http://clouddocs.web.cern.ch/clouddocs/advanced_topics/installing_your_own_openstack.html).
> 
> Puppet gives us lots of additional abilities to customise parts of the cloud 
> for different purposes such as compute optimised. Details are at 
> http://openstack-in-production.blogspot.fr
> 
> Managing 220K cores with packstack would be adventurous.
> 
> Tim
> 
> On 03.05.17, 18:25, "Satish Patel"  wrote:
> 
>so at CERN you are not using packstack. You are using RDO and done
>your puppet work to deploy stuff right?
> 
>I found packstack very easy and handy to deploy stuff, why people hate
>it? what could go wrong if we deploy using packstack?
> 
>>On Wed, May 3, 2017 at 12:18 PM, Tim Bell  wrote:
>> You also need to assess the skills of your administration team, will they 
>> need help to set things up, consulting, formal support contract etc.
>> 
>> At CERN, we’re running packages and puppet configuration derived from RDO in 
>> production.
>> 
>> Tim
>> 
>> On 03.05.17, 17:56, "Satish Patel"  wrote:
>> 
>>Problem is there are many tools available but hard to pick which one
>>is reliable and provide long term community support, also we are
>>looking something we can easily deploy compute node, upgrade software
>>time to time without breaking any code etc.
>> 
>>On Wed, May 3, 2017 at 5:41 AM, Christian Berendt
>> wrote:
>>> Hello Satish.
>>> 
>>> You have to differentiate.
>>> 
>>> You probably used the packages provided by the RDO project for 
>>> CentOS/RedHat to deploy an OpenStack environment by hand (maybe using the 
>>> official OpenStack install guide). This way is not recommended for a 
>>> production. The packages provided itself are production ready, the way you 
>>> have deployed them is not production ready.
>>> 
>>> For a production you want to use one of the existing deployment frameworks 
>>> or a distribution provided by a vendor (normally based on one of the 
>>> existing deployment frameworks). Some of the deployment frameworks are able 
>>> to use the packages provided by the RDO project.
>>> 
>>> As a core member of the Kolla project I recommend to use Kolla 
>>> (https://github.com/openstack/kolla). Our product is based on Kolla.
>>> 
>>> There are other deployment frameworks as well: Fuel, OpenStack Ansible, 
>>> OpenStack Chef, OpenStack Puppet, TripleO.
>>> 
>>> The “best method” depends on the person you ask for the best method.
>>> 
>>> If you need further details about Kolla drop me line line, I am happy to 
>>> help you with this.
>>> 
>>> Christian.
>>> 
 On 3. May 2017, at 08:48, Satish Patel  wrote:
 
 We did POC on RDO and we are happy with product but now question is, 
 should we use RDO for production deployment or other open source flavor 
 available to deploy on prod. Not sure what is the best method of 
 production deployment?
>>> 
>>> --
>>> Christian Berendt
>>> Chief Executive Officer (CEO)
>>> 
>>> Telefon: +49 711 21957003
>>> Mobil: +49 171 5542175
>>> Mail: bere...@betacloud-solutions.de
>>> Web: https://www.betacloud-solutions.de
>>> 
>>> Betacloud Solutions GmbH
>>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>> 
>>> Geschäftsführer: Christian Berendt
>>> Unternehmenssitz: Stuttgart
>>> Amtsgericht: Stuttgart, HRB 756139
>>> 
>> 
>>___
>>Mailing list: 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>Post to : openstack@lists.openstack.org
>>Unsubscribe : 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> 
>> 
> 
> 

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

Re: [openstack-dev] [devstack] [all] systemd in devstack by default

[Sean Dague]

On 05/03/2017 07:08 PM, Doug Hellmann wrote:

Excerpts from Sean Dague's message of 2017-05-03 16:16:29 -0400:

Screen is going away in Queens.

Making the dev / test runtimes as similar as possible is really
important. And there is so much weird debt around trying to make screen
launch things reliably (like random sleeps) because screen has funny
races in it.

It does mean some tricks people figured out in screen are going away.


It sounds like maybe we should start building a shared repository of new
tips & tricks for systemd/journald.


Agreed, the devstack docs have the following beginnings of that:

https://docs.openstack.org/developer/devstack/development.html - for 
basic flow


which also links to a systemd primer - 
https://docs.openstack.org/developer/devstack/systemd.html


But more contributions are welcomed for sure.

(These docs exist in the devstack tree under doc/source)

-Sean

--
Sean Dague
http://dague.net

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

Re: [openstack-dev] [devstack] [all] systemd in devstack by default

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-05-03 16:16:29 -0400:
> Screen is going away in Queens.
> 
> Making the dev / test runtimes as similar as possible is really
> important. And there is so much weird debt around trying to make screen
> launch things reliably (like random sleeps) because screen has funny
> races in it.
> 
> It does mean some tricks people figured out in screen are going away.

It sounds like maybe we should start building a shared repository of new
tips & tricks for systemd/journald.

Doug

> 
> Journalctl provides some pretty serious improvements in querying logs
> https://www.freedesktop.org/software/systemd/man/journalctl.html - you
> can search in time ranges, filter by units (one or more of them), and if
> we get to the bottom of the eventlet interaction, we'll be able to
> search by things like REQUEST_ID as well.
> 
> Plus every modern Linux system uses systemd now, so skills learned
> around systemd and journalctl are transferable both from OpenStack to
> other systems, as well as for new people coming in that understand how
> this works outside of OpenStack. So it helps remove a difference from
> the way we do things from the rest of the world.
> 
> -Sean
> 
> On 05/03/2017 04:02 PM, Hongbin Lu wrote:
> > Hi Sean,
> > 
> > I tried the new systemd devstack and frankly I don't like it. There are 
> > several handy operations in screen that seems to be impossible after 
> > switching to systemd. For example, freeze a process by "Ctrl + a + [". In 
> > addition, navigating though the logs seems difficult (perhaps I am not 
> > familiar with journalctl).
> > 
> > From my understanding, the plan is dropping screen entirely in devstack? I 
> > would argue that it is better to keep both screen and systemd, and let 
> > users choose one of them based on their preference.
> > 
> > Best regards,
> > Hongbin
> > 
> >> -Original Message-
> >> From: Sean Dague [mailto:s...@dague.net]
> >> Sent: May-03-17 6:10 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [devstack] [all] systemd in devstack by
> >> default
> >>
> >> On 05/02/2017 08:30 AM, Sean Dague wrote:
> >>> We started running systemd for devstack in the gate yesterday, so far
> >>> so good.
> >>>
> >>> The following patch (which will hopefully land soon), will convert
> >> the
> >>> default local use of devstack to systemd as well -
> >>> https://review.openstack.org/#/c/461716/. It also includes
> >>> substantially updated documentation.
> >>>
> >>> Once you take this patch, a "./clean.sh" is recommended. Flipping
> >>> modes can cause some cruft to build up, and ./clean.sh should be
> >>> pretty good at eliminating them.
> >>>
> >>> https://review.openstack.org/#/c/461716/2/doc/source/development.rst
> >>> is probably specifically interesting / useful for people to read, as
> >>> it shows how the standard development workflows will change (for the
> >>> better) with systemd.
> >>>
> >>> -Sean
> >>
> >> As a follow up, there are definitely a few edge conditions we've hit
> >> with some jobs, so the following is provided as information in case you
> >> have a job that seems to fail in one of these ways.
> >>
> >> Doing process stop / start
> >> ==
> >>
> >> The nova live migration job is special, it was restarting services
> >> manually, however it was doing so with some copy / pasted devstack code,
> >> which means it didn't evolve with the rest of devstack. So the stop
> >> code stopped working (and wasn't robust enough to make it clear that
> >> was the issue).
> >>
> >> https://review.openstack.org/#/c/461803/ is the fix (merged)
> >>
> >> run_process limitations
> >> ===
> >>
> >> When doing the systemd conversion I looked for a path forward which was
> >> going to make 90% of everything just work. The key trick here was that
> >> services start as the "stack" user, and aren't daemonizing away from
> >> the console. We can take the run_process command and make that the
> >> ExecStart in a unit file.
> >>
> >> *Except* that only works if the command is specified by an *absolute
> >> path*.
> >>
> >> So things like this in kuryr-libnetwork become an issue
> >> https://github.com/openstack/kuryr-
> >> libnetwork/blob/3e2891d6fc5d55b3712258c932a5a8b9b323f6c2/devstack/plugi
> >> n.sh#L148
> >>
> >> There is also a second issue there, which is calling sudo in the
> >> run_process line. If you need to run as a user/group different than the
> >> default, you need to specify that directly.
> >>
> >> The run_process command now supports that -
> >> https://github.com/openstack-
> >> dev/devstack/blob/803acffcf9254e328426ad67380a99f4f5b164ec/functions-
> >> common#L1531-L1535
> >>
> >> And lastly, run_process really always did expect that the thing you
> >> started remained attached to the console. These are run as "simple"
> >> services in systemd. If you are running a thing which already
> >> daemonizes systemd is going to assume (correctly 

Re: [openstack-dev] [vitrage] trouble installing Nagios on devstack on ubuntu 16.04 ...

[Yujun Zhang (ZTE)]

One easy way could be writing a scenario to raise deduced alarm based on a
simple rule, e.g. when a host is discovered, raise an alarm saying host is
up.

Waines, Greg 于2017年5月4日 周四04:35写道：

> I don’t think I saw any responses to this.
>
>
>
> Alternative question ... so I’ve got vitrage up and running fine ...
>
>
>
> What’s the easiest way to generate an alarm against a host ?   ( OTHER
> than NAGIOS, due to problem in original email ) ???
>
>
>
> let me know any ideas,
>
> Greg.
>
>
>
>
>
> *From: *Greg Waines 
> *Date: *Tuesday, May 2, 2017 at 9:03 AM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [vitrage] trouble installing Nagios on
> devstack on ubuntu 16.04 ...
>
>
>
> Hey ... I’m working thru the ‘Vitrage - Getting Started Guide’
>
>
>
> https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html
>
>
>
> Was able to get vitrage up and running and enabled in horizon ... on
> ubuntu 16.04 .
>
>  ( I tried on ubuntu 14.04 and ‘./stack.sh’ warned that it had not
> been tested on trusty (14.04), I FORCE=yes it ... but it failed. )
>
>
>
>
>
> Now trying to install Nagios in devstack
>
>
> https://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html
>
>
>
> BUT it doesn’t seem like there is an OMD package available for ubuntu
> 16.04 ... and the trusty (14.04) package won’t install due to dependency
> issues.
>
>
>
>
>
>
>
> Any suggestions ?
>
>
>
> Greg.
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Yujun Zhang
__
OpenStack Development Mailing 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] [devstack] [all] systemd in devstack by default

[James Slagle]

On Tue, May 2, 2017 at 9:19 AM, Monty Taylor  wrote:
> I absolutely cannot believe I'm saying this given what the change implements
> and my general steaming hatred associated with it ... but this is awesome
> work and a definite improvement over what existed before it. If we're going
> to be stuck sharing the Bad Trip that is Lennart's projected consciousness,
> this is a pleasant surprise of a positive outcome.

In my opinion, these comments about Lennart are quite out of line.
Regardless of whether or not that individual is a member of the
OpenStack community, there are constructive ways to voice your
opinions about systemd without resorting to these types of personal
comments.

systemd is an open source driven community project. I'd suggest
directing your energy at those technology choices and working towards
what you see as improvements in those choices instead of making
comments such as what you've done here.

While minor (with some thinly veiled praise sprinkled in), I'm a bit
shocked no one else has called attention to your response. It is not
friendly, considerate, and above all else -- it is not respectful.

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] VMware Voting CI

[Tracy Jones]

Hi Sean – this was done in error and we have just fixed it.  Sorry for the 
confusion.

Tracy


Begin forwarded message:
From: Sean McGinnis >
Subject: [openstack-dev] VMware Voting CI
Date: May 3, 2017 at 7:06:55 AM PDT
To: 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Hey everyone,
I'm looking for some background on the VMware NSX CI. Specifically,
why this CI is enabled for voting.
We had discussed whether to have "stable" CI's vote in the Cinder
project a while back, and other than potentially some benefit in
doing scripted reporting, we couldn't really think of a good
reason to have third party CI voting.
This CI account, however, appears to be used for multiple projects.
I think it got voting rights via a different project. I'm just
wondering if there is still a valid reason for that.
I think this has come up before, and to be clear, it does not block
anything when there ends up a -1 from this CI. The issue I have
with it is when looking in a summary list of patches, even if Jenkins
has voted +1, if the VMware NSX CI has failed, it ends up with a big
ol' red -1 in the Verified column, making it look like there is an
issue with the patch. Which likely means unless someone is
specifically interested in that patch, they will see the red -1 and
move on.
Does anyone have the background as to why this CI has voting rights,
and whether it should still have them?
Thanks,
Sean (smcginnis)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [tripleo] pingtest vs tempest

[Emilien Macchi]

(cross-posting)

I've seen a bunch of interesting thoughts here.
The most relevant feedback I've seen so far:

- TripleO folks want to keep testing fast and efficient.
- Tempest folks understand this problematic and is willing to collaborate.

I propose that we move forward and experiment the usage of Tempest in
TripleO CI for one job that could be experimental or non-voting to
start.
Instead of running the Pingtest, we would execute a Tempest Scenario
that boot an instance from volume (like Pingstest is already doing)
and see how it goes (in term of coverage and runtime).
I volunteer to kick-off the work with someone more expert than I am
with quickstart (Arx maybe?).

Another iteration could be to start building an easy interface to
select which Tempest tests we want a TripleO CI job to run and plug it
to our CI tooling (tripleo-quickstart I presume).
I also hear some feedback about keeping the pingtest alive for some
uses cases, and I agree we could keep some CI jobs to run the pingtest
when it makes more sense (when we want to test Heat for example, or
just maintain it for developers who used it).

How does it sounds? Please bring feedback.


On Tue, Apr 18, 2017 at 7:41 AM, Attila Fazekas  wrote:
>
>
> On Tue, Apr 18, 2017 at 11:04 AM, Arx Cruz  wrote:
>>
>>
>>
>> On Tue, Apr 18, 2017 at 10:42 AM, Steven Hardy  wrote:
>>>
>>> On Mon, Apr 17, 2017 at 12:48:32PM -0400, Justin Kilpatrick wrote:
>>> > On Mon, Apr 17, 2017 at 12:28 PM, Ben Nemec 
>>> > wrote:
>>> > > Tempest isn't really either of those things.  According to another
>>> > > message
>>> > > in this thread it takes around 15 minutes to run just the smoke
>>> > > tests.
>>> > > That's unacceptable for a lot of our CI jobs.
>>> >
>>
>>
>> I rather spend 15 minutes running tempest than add a regression or a new
>> bug, which already happen in the past.
>>
> The smoke tests might not be the best test selection anyway, you should pick
> some scenario which does
> for example snapshot of images and volumes. yes, these are the slow ones,
> but they can run in parallel.
>
> Very likely you do not really want to run all tempest test, but 10~20 minute
> time,
> sounds reasonable for a sanity test.
>
> The tempest config utility also should be extended by some parallel
> capability,
> and should be able to use already downloaded (part of the image) resources.
>
> Tempest/testr/subunit worker balance is not always the best,
> technically would be possible to do dynamic balancing, but it would require
> a lot of work.
> Let me know when it becomes the main concern, I can check what can/cannot be
> done.
>
>
>>
>>>
>>> > Ben, is the issue merely the time it takes? Is it the affect that time
>>> > taken has on hardware availability?
>>>
>>> It's both, but the main constraint is the infra job timeout, which is
>>> about
>>> 2.5hrs - if you look at our current jobs many regularly get close to (and
>>> sometimes exceed this), so we just don't have the time budget available
>>> to
>>> run exhasutive tests every commit.
>>
>>
>> We have green light from infra to increase the job timeout to 5 hours, we
>> do that in our periodic full tempest job.
>
>
> Sounds good, but I am afraid it could hurt more than helping, it could delay
> other things get fixed by lot
> especially if we got some extra flakiness, because of foobar.
>
> You cannot have all possible tripleo configs on the gate anyway,
> so something will pass which will require a quick fix.
>
> IMHO the only real solution, is making the before test-run steps faster or
> shorter.
>
> Do you have any option to start the tempest running jobs in a more developed
> state ?
> I mean, having more things already done at the start time  (images/snapshot)
> and just do a fast upgrade at the beginning of the job.
>
> Openstack installation can be completed in a `fast` way (~minute) on
> RHEL/Fedora systems
> after the yum steps, also if you are able to aggregate all yum step to
> single
> command execution (transaction) you generally able to save a lot of time.
>
> There is plenty of things what can be made more efficient before the test
> run,
> when you start considering everything evil which can be accounted for more
> than 30 sec
> of time, this can happen soon.
>
> For example just executing the cpython interpreter for the openstack
> commands is above 30 sec,
> the work what they are doing can be done in much much faster way.
>
> Lot of install steps actually does not depends on each other,
> it allows more things to be done in parallel, we generally can have more
> core than Ghz.
>
>
>>
>>>
>>>
>>> > Should we focus on how much testing we can get into N time period?
>>> > Then how do we decide an optimal N
>>> > for our constraints?
>>>
>>> Well yeah, but that's pretty much how/why we ended up with pingtest, it's
>>> simple, fast, and provides an efficient way to do smoke tests, e.g
>>> creating
>>> just one heat resource is 

Re: [openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

[Boden Russell]

On 5/3/17 8:55 AM, Eric Fried wrote:
> Can you please point to the change(s) that move the constants?  Or
> provide some other way to figure out which are affected?
>
This Hound search [1] provides an overall picture and can be honed to
specific projects as needed. The search will identify all modules that
import the constants, but the respective source will need to be inspected
to determine which constants are applicable to neutron-lib.

Also, feel free to reach out to me ('boden') on #openstack-neutron if
there's questions/comments/etc..

[1] 
http://codesearch.openstack.org/?q=from%20neutron%5C.plugins%5C.common%20import%20constants

__
OpenStack Development Mailing 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] [LBaaS][octavia] Weekly IRC meeting cancelled for three weeks

[Michael Johnson]

Hi Octavia team,

At today's weekly LBaaS/Octavia IRC meeting we decided to cancel the next
three meetings due to the OpenStack summit, other conflicts, and vacations.
We just won't have quorum these weeks.

Safe travels for those attending the OpenStack summit and we will meet again
5/31/17.

Michael



__
OpenStack Development Mailing 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] [vitrage] trouble installing Nagios on devstack on ubuntu 16.04 ...

[Waines, Greg]

I don’t think I saw any responses to this.

Alternative question ... so I’ve got vitrage up and running fine ...

What’s the easiest way to generate an alarm against a host ?   ( OTHER than 
NAGIOS, due to problem in original email ) ???

let me know any ideas,
Greg.


From: Greg Waines 
Date: Tuesday, May 2, 2017 at 9:03 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] trouble installing Nagios on devstack on 
ubuntu 16.04 ...

Hey ... I’m working thru the ‘Vitrage - Getting Started Guide’

https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html

Was able to get vitrage up and running and enabled in horizon ... on ubuntu 
16.04 .
 ( I tried on ubuntu 14.04 and ‘./stack.sh’ warned that it had not been 
tested on trusty (14.04), I FORCE=yes it ... but it failed. )


Now trying to install Nagios in devstack
https://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html

BUT it doesn’t seem like there is an OMD package available for ubuntu 16.04 ... 
and the trusty (14.04) package won’t install due to dependency issues.



Any suggestions ?

Greg.



__
OpenStack Development Mailing 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] [devstack] [all] systemd in devstack by default

[Sean Dague]

Screen is going away in Queens.

Making the dev / test runtimes as similar as possible is really
important. And there is so much weird debt around trying to make screen
launch things reliably (like random sleeps) because screen has funny
races in it.

It does mean some tricks people figured out in screen are going away.

Journalctl provides some pretty serious improvements in querying logs
https://www.freedesktop.org/software/systemd/man/journalctl.html - you
can search in time ranges, filter by units (one or more of them), and if
we get to the bottom of the eventlet interaction, we'll be able to
search by things like REQUEST_ID as well.

Plus every modern Linux system uses systemd now, so skills learned
around systemd and journalctl are transferable both from OpenStack to
other systems, as well as for new people coming in that understand how
this works outside of OpenStack. So it helps remove a difference from
the way we do things from the rest of the world.

-Sean

On 05/03/2017 04:02 PM, Hongbin Lu wrote:
> Hi Sean,
> 
> I tried the new systemd devstack and frankly I don't like it. There are 
> several handy operations in screen that seems to be impossible after 
> switching to systemd. For example, freeze a process by "Ctrl + a + [". In 
> addition, navigating though the logs seems difficult (perhaps I am not 
> familiar with journalctl).
> 
> From my understanding, the plan is dropping screen entirely in devstack? I 
> would argue that it is better to keep both screen and systemd, and let users 
> choose one of them based on their preference.
> 
> Best regards,
> Hongbin
> 
>> -Original Message-
>> From: Sean Dague [mailto:s...@dague.net]
>> Sent: May-03-17 6:10 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [devstack] [all] systemd in devstack by
>> default
>>
>> On 05/02/2017 08:30 AM, Sean Dague wrote:
>>> We started running systemd for devstack in the gate yesterday, so far
>>> so good.
>>>
>>> The following patch (which will hopefully land soon), will convert
>> the
>>> default local use of devstack to systemd as well -
>>> https://review.openstack.org/#/c/461716/. It also includes
>>> substantially updated documentation.
>>>
>>> Once you take this patch, a "./clean.sh" is recommended. Flipping
>>> modes can cause some cruft to build up, and ./clean.sh should be
>>> pretty good at eliminating them.
>>>
>>> https://review.openstack.org/#/c/461716/2/doc/source/development.rst
>>> is probably specifically interesting / useful for people to read, as
>>> it shows how the standard development workflows will change (for the
>>> better) with systemd.
>>>
>>> -Sean
>>
>> As a follow up, there are definitely a few edge conditions we've hit
>> with some jobs, so the following is provided as information in case you
>> have a job that seems to fail in one of these ways.
>>
>> Doing process stop / start
>> ==
>>
>> The nova live migration job is special, it was restarting services
>> manually, however it was doing so with some copy / pasted devstack code,
>> which means it didn't evolve with the rest of devstack. So the stop
>> code stopped working (and wasn't robust enough to make it clear that
>> was the issue).
>>
>> https://review.openstack.org/#/c/461803/ is the fix (merged)
>>
>> run_process limitations
>> ===
>>
>> When doing the systemd conversion I looked for a path forward which was
>> going to make 90% of everything just work. The key trick here was that
>> services start as the "stack" user, and aren't daemonizing away from
>> the console. We can take the run_process command and make that the
>> ExecStart in a unit file.
>>
>> *Except* that only works if the command is specified by an *absolute
>> path*.
>>
>> So things like this in kuryr-libnetwork become an issue
>> https://github.com/openstack/kuryr-
>> libnetwork/blob/3e2891d6fc5d55b3712258c932a5a8b9b323f6c2/devstack/plugi
>> n.sh#L148
>>
>> There is also a second issue there, which is calling sudo in the
>> run_process line. If you need to run as a user/group different than the
>> default, you need to specify that directly.
>>
>> The run_process command now supports that -
>> https://github.com/openstack-
>> dev/devstack/blob/803acffcf9254e328426ad67380a99f4f5b164ec/functions-
>> common#L1531-L1535
>>
>> And lastly, run_process really always did expect that the thing you
>> started remained attached to the console. These are run as "simple"
>> services in systemd. If you are running a thing which already
>> daemonizes systemd is going to assume (correctly in this simple mode)
>> the fact that the process detatched from it means it died, and kill and
>> clean it up.
>>
>> This is the issue the OpenDaylight plugin ran into.
>> https://review.openstack.org/#/c/461889/ is the proposed fix.
>>
>>
>>
>> If you run into any other issues please pop into #openstack-qa (or
>> respond to this email) and we'll try to work through them.
>>
>>  -Sean
>>
>> --

[openstack-dev] [glance] no meeting this week

[Brian Rosmaita]

Hello Glancers,

The weekly Glance IRC meeting is cancelled for tomorrow (May 4) and
the summit week (May 11).  We'll resume our regular weekly meeting
cadence on Thursday, May 18.

If you'll be at the summit/forum in Boston, you may find some fellow
glance people at these sessions:

Mon 8 , 12:45pm-2:00pm
Hynes Convention Center - Level One - MR 101
Glance - Project Onboarding

Mon 8 , 4:40pm-5:20pm
Hynes Convention Center - Level Two - MR 203
Project Update - Glance

Mon 8 , 5:30pm-6:10pm
Hynes Convention Center - Level One - MR 103
How do you use Glance?


cheers,
brian

__
OpenStack Development Mailing 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] [devstack] [all] systemd in devstack by default

[Hongbin Lu]

Hi Sean,

I tried the new systemd devstack and frankly I don't like it. There are several 
handy operations in screen that seems to be impossible after switching to 
systemd. For example, freeze a process by "Ctrl + a + [". In addition, 
navigating though the logs seems difficult (perhaps I am not familiar with 
journalctl).

From my understanding, the plan is dropping screen entirely in devstack? I 
would argue that it is better to keep both screen and systemd, and let users 
choose one of them based on their preference.

Best regards,
Hongbin

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: May-03-17 6:10 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [devstack] [all] systemd in devstack by
> default
> 
> On 05/02/2017 08:30 AM, Sean Dague wrote:
> > We started running systemd for devstack in the gate yesterday, so far
> > so good.
> >
> > The following patch (which will hopefully land soon), will convert
> the
> > default local use of devstack to systemd as well -
> > https://review.openstack.org/#/c/461716/. It also includes
> > substantially updated documentation.
> >
> > Once you take this patch, a "./clean.sh" is recommended. Flipping
> > modes can cause some cruft to build up, and ./clean.sh should be
> > pretty good at eliminating them.
> >
> > https://review.openstack.org/#/c/461716/2/doc/source/development.rst
> > is probably specifically interesting / useful for people to read, as
> > it shows how the standard development workflows will change (for the
> > better) with systemd.
> >
> > -Sean
> 
> As a follow up, there are definitely a few edge conditions we've hit
> with some jobs, so the following is provided as information in case you
> have a job that seems to fail in one of these ways.
> 
> Doing process stop / start
> ==
> 
> The nova live migration job is special, it was restarting services
> manually, however it was doing so with some copy / pasted devstack code,
> which means it didn't evolve with the rest of devstack. So the stop
> code stopped working (and wasn't robust enough to make it clear that
> was the issue).
> 
> https://review.openstack.org/#/c/461803/ is the fix (merged)
> 
> run_process limitations
> ===
> 
> When doing the systemd conversion I looked for a path forward which was
> going to make 90% of everything just work. The key trick here was that
> services start as the "stack" user, and aren't daemonizing away from
> the console. We can take the run_process command and make that the
> ExecStart in a unit file.
> 
> *Except* that only works if the command is specified by an *absolute
> path*.
> 
> So things like this in kuryr-libnetwork become an issue
> https://github.com/openstack/kuryr-
> libnetwork/blob/3e2891d6fc5d55b3712258c932a5a8b9b323f6c2/devstack/plugi
> n.sh#L148
> 
> There is also a second issue there, which is calling sudo in the
> run_process line. If you need to run as a user/group different than the
> default, you need to specify that directly.
> 
> The run_process command now supports that -
> https://github.com/openstack-
> dev/devstack/blob/803acffcf9254e328426ad67380a99f4f5b164ec/functions-
> common#L1531-L1535
> 
> And lastly, run_process really always did expect that the thing you
> started remained attached to the console. These are run as "simple"
> services in systemd. If you are running a thing which already
> daemonizes systemd is going to assume (correctly in this simple mode)
> the fact that the process detatched from it means it died, and kill and
> clean it up.
> 
> This is the issue the OpenDaylight plugin ran into.
> https://review.openstack.org/#/c/461889/ is the proposed fix.
> 
> 
> 
> If you run into any other issues please pop into #openstack-qa (or
> respond to this email) and we'll try to work through them.
> 
>   -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

[openstack-dev] OpenStack moving both too fast and too slow at the same time

[Drew Fisher]

This email is meant to be the ML discussion of a question I brought up
during the TC meeting on April 25th.; [1]

The TL;DR version is:


Reading the user survey [2], I see the same issues time and time again.
Pages 18-19 of the survey are especially common points.
Things move too fast, no LTS release, upgrades are terrifying for
anything that isn't N-1 -> N.
These come up time and time again
How is the TC working with the dev teams to address these critical issues?


I asked this because on page 18 is this comment:

"Most large customers move slowly and thus are running older versions,
which are EOL upstream sometimes before they even deploy them."

This is exactly what we're seeing with some of our customers and I
wanted to ask the TC about it.

Thanks,

-Drew




[1]
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-177
[2] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf


__
OpenStack Development Mailing 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] Neutron unable to create VLAN network

[Timothy Geier]

On May 2, 2017, at 2:53 PM, Kaustubh Kelkar 
> 
wrote:

VLAN 1 might be treated as the “default” VLAN by your switch.

-Kaustubh

The issue turned out to be old configuration in the database..after stracing 
neutron-server, I saw that it was running “SELECT from ml2_vlan_allocations” 
just after I tried to create the network..after finding that table in the 
neutron database, it was incorrectly showing that VLANs 1 and 2 were allocated, 
so that was an easy fix with:

mysql> update ml2_vlan_allocations set allocated = '0' where vlan_id = ‘1’;
mysql> update ml2_vlan_allocations set allocated = '0' where vlan_id = ‘2';

And now I can create the networks as intended.


From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Tuesday, May 2, 2017 3:19 PM
To: Timothy Geier >
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Neutron unable to create VLAN network

That means vlan 1 is in use by one of the other networks.

On May 2, 2017 14:59, "Timothy Geier" 
> wrote:
I’m doing some testing/PoC on an RDO Ocata CentOS7 setup and everything has 
gone well with the exception of configuring multiple VLANs.

After following the configuration detailed at 
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/networking_guide/sec-connect-instance#Using-VLAN-Provider-Networks
 , neutron errors out with the following:

$ neutron net-create 1_network \
--provider:network_type vlan \
--router:external true \
--provider:physical_network extnet \
--provider:segmentation_id 1 --shared
Unable to create the network. The VLAN 1 on physical network extnet is in use.

extnet is mapped to the OVSbridge br-ex, which has a physical interface that’s 
trunked to all of the available VLANs..trying this command on the other 
available VLANs works, but 1 and 2 (the ones I want to test on) always fails.  
Is there anything obvious to try on the system itself or is this more likely a 
network issue?

Thanks much,


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


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

[Openstack-operators] migrating instances from one NFS-share to another.

[Tobias Schön]

Hi,

We are a hosting company that use openstack as a public cloud service for our 
customers and have a stack built based on redhat director. We are using NFS for 
both cinder and nova ephemeral storage and are going to migrate all of our data 
from one physical storage to another. Using NFS with openstack is not that 
common nowadays but I've checked with the support if multiple ephemeral 
mountpoints are possible but it's not.

How do we solve this the easiest way without downtime. I understand if there's 
no solution for doing this without downtime. even possible to do?
Do we have to take down all our services during this migration? We would like 
to be able to continue using the director ofcourse.

Would appreciate all advices on how to solve this or get forward to a "good" 
solution.
It's a quite small environment so far, around 6-7 TB so it shouldn't take that 
long time to migrate it as we have a 10G backend. But I'm still concerned that 
it might take a lot of time to get complete and preserve the permissions and so 
forth.
We do have cinder-volumes as well not sure how to solve that migration.

MVH/Best regards,
Tobias Schön
Sysadmin/Drifttekniker AreaX
VCP6-DCV

[VMW-LGO-CERT-PRO-6-DATA-CTR-VIRT]
[cid:image001.png@01CEED18.59C12030]

Kvarnkroken 7, 805 92  GÄVLE
Box 6027, 800 06 GÄVLE
www.areax.se
www.fiberdata.se

Överväg miljöpåverkan innan du skriver ut detta e-postmeddelande

This communication and any attachment(s) to it are only for the use of the 
intended recipient. The information in it may be confidential and subject to 
legal privilege. Reading or dissemination of it by anyone other than the 
intended recipient is strictly prohibited. If you are not the intended 
recipient please contact the sender by reply e-mail and delete all copies of 
this message and any attachments from any drives or storage media and destroy 
any printouts.

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

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

[Chris Friesen]

On 05/03/2017 03:08 AM, Giuseppe Di Lena wrote:

Thank you a lot for the help!

I think that the problem can be solved using the anti-affinity filter, but we want 
a regular user can choose an instance and set the property(image, flavour, 
network, etc.) and a parameter Robustness >= 1(that is the number of copies of 
this particular instance).


I'm pretty sure a regular user can create a server group and specify the 
anti-affinity filter.  And a regular user can certainly specify --min-count and 
--max-count to specify the number of copies.



After that, we put every copy of this instance in a different compute, but we 
need to track where we put every copy of the instance (we need to know it for 
the algorithm that we would implement);


Normally only admin-level users are allowed to know which compute nodes a given 
instance is placed on.  Why do you need to track which compute nodes the 
instances are on?


Chris

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

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

[Jeremy Stanley]

On 2017-05-03 14:04:40 -0400 (-0400), Doug Hellmann wrote:
> Excerpts from Sean Dague's message of 2017-05-03 13:23:11 -0400:
> > On 05/03/2017 01:02 PM, Doug Hellmann wrote:
> > > Excerpts from Thierry Carrez's message of 2017-05-03 18:16:29 +0200:
[...]
> > > Knowing what will be discussed in advanced also helps everyone
> > > collect their thoughts and be ready to contribute.
> > 
> > What about ensuring that every agenda topic is more than a line,
> > but includes a full paragraph about what the agenda topic
> > proposer expects it will cover. A lot of times the agenda items
> > are cryptic enough unless you are knee deep in things.
> > 
> > That would help people collect their thoughts even more and
> > break away from the few minutes of delay in introducing the
> > subject (the introduction of the subject would be in the
> > agenda).
> 
> If the goal is to move most of the discussion onto the mailing
> list, we could link to the thread(s) there, too.

This seems like a great idea to me. Granted in many cases we already
have a change proposed in Gerrit containing a (potentially) lengthy
explanation, but duplicating some of that on the agenda can't hurt.
-- 
Jeremy Stanley


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

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

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-05-03 13:23:11 -0400:
> On 05/03/2017 01:02 PM, Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2017-05-03 18:16:29 +0200:
> >> Ed Leafe wrote:
> >>> On May 3, 2017, at 2:41 AM, Thierry Carrez  wrote:
> >>>
>  In the current
>  system, TC members (or really, anyone in the community) can add to the
>  "Open discussion" section of the meeting agenda, but that happens
>  extremely rarely. I suspect that the 5 minutes per week that we end up
>  dedicating to open discussion in the meetings does not encourage people
>  to load large topics of discussions in it.
> >>>
> >>> Simple: *start* the meeting with Open Discussion.
> >>
> >> I don't really see how that would solve the agenda problem.
> >>
> >> I think it's better for everyone if people post topics they want to
> >> discuss in advance. Europeans who want to attend need to stay up late,
> >> People in the APAC zone need to get up very early. Knowing up-front what
> >> will be discussed might (might) give people in those zones the extra
> >> incentive they need to attend.
> >>
> > 
> > Knowing what will be discussed in advanced also helps everyone collect
> > their thoughts and be ready to contribute.
> 
> What about ensuring that every agenda topic is more than a line, but
> includes a full paragraph about what the agenda topic proposer expects
> it will cover. A lot of times the agenda items are cryptic enough unless
> you are knee deep in things.
> 
> That would help people collect their thoughts even more and break away
> from the few minutes of delay in introducing the subject (the
> introduction of the subject would be in the agenda).
> 
> -Sean
> 

If the goal is to move most of the discussion onto the mailing list, we
could link to the thread(s) there, too.

Doug

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

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

[Sean Dague]

On 05/03/2017 01:02 PM, Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2017-05-03 18:16:29 +0200:
>> Ed Leafe wrote:
>>> On May 3, 2017, at 2:41 AM, Thierry Carrez  wrote:
>>>
 In the current
 system, TC members (or really, anyone in the community) can add to the
 "Open discussion" section of the meeting agenda, but that happens
 extremely rarely. I suspect that the 5 minutes per week that we end up
 dedicating to open discussion in the meetings does not encourage people
 to load large topics of discussions in it.
>>>
>>> Simple: *start* the meeting with Open Discussion.
>>
>> I don't really see how that would solve the agenda problem.
>>
>> I think it's better for everyone if people post topics they want to
>> discuss in advance. Europeans who want to attend need to stay up late,
>> People in the APAC zone need to get up very early. Knowing up-front what
>> will be discussed might (might) give people in those zones the extra
>> incentive they need to attend.
>>
> 
> Knowing what will be discussed in advanced also helps everyone collect
> their thoughts and be ready to contribute.

What about ensuring that every agenda topic is more than a line, but
includes a full paragraph about what the agenda topic proposer expects
it will cover. A lot of times the agenda items are cryptic enough unless
you are knee deep in things.

That would help people collect their thoughts even more and break away
from the few minutes of delay in introducing the subject (the
introduction of the subject would be in the agenda).

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [barbican] [security] Project Onboarding in Boston

[Dave McCowan (dmccowan)]

Greetings!

If you are interested in learning more about Barbican with a goal to 
contribute, please come to the Barbican Project Onboarding session on Tuesday, 
May 9, at 2pm in Room MR101.

We'll be sharing the time slot with the Security project for those interested 
in becoming an OpenStack Security contributor.

Please RSVP here and indicate your preference on topics to cover and the 
methods of learning.

https://etherpad.openstack.org/p/BOS-forum-barbican-onboarding

We'll optimize the session based on interest and number of expected attendees.

Thanks!
--Dave McCowan

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

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

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-05-03 18:16:29 +0200:
> Ed Leafe wrote:
> > On May 3, 2017, at 2:41 AM, Thierry Carrez  wrote:
> > 
> >> In the current
> >> system, TC members (or really, anyone in the community) can add to the
> >> "Open discussion" section of the meeting agenda, but that happens
> >> extremely rarely. I suspect that the 5 minutes per week that we end up
> >> dedicating to open discussion in the meetings does not encourage people
> >> to load large topics of discussions in it.
> > 
> > Simple: *start* the meeting with Open Discussion.
> 
> I don't really see how that would solve the agenda problem.
> 
> I think it's better for everyone if people post topics they want to
> discuss in advance. Europeans who want to attend need to stay up late,
> People in the APAC zone need to get up very early. Knowing up-front what
> will be discussed might (might) give people in those zones the extra
> incentive they need to attend.
> 

Knowing what will be discussed in advanced also helps everyone collect
their thoughts and be ready to contribute.

Doug

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

Re: [Openstack] Deployment for production

[Tim Bell]

We use packstack when we need an all-in-one environment such as people wanting 
to try out some new ideas 
(http://clouddocs.web.cern.ch/clouddocs/advanced_topics/installing_your_own_openstack.html).

Puppet gives us lots of additional abilities to customise parts of the cloud 
for different purposes such as compute optimised. Details are at 
http://openstack-in-production.blogspot.fr

Managing 220K cores with packstack would be adventurous.

Tim

On 03.05.17, 18:25, "Satish Patel"  wrote:

so at CERN you are not using packstack. You are using RDO and done
your puppet work to deploy stuff right?

I found packstack very easy and handy to deploy stuff, why people hate
it? what could go wrong if we deploy using packstack?

On Wed, May 3, 2017 at 12:18 PM, Tim Bell  wrote:
> You also need to assess the skills of your administration team, will they 
need help to set things up, consulting, formal support contract etc.
>
> At CERN, we’re running packages and puppet configuration derived from RDO 
in production.
>
> Tim
>
> On 03.05.17, 17:56, "Satish Patel"  wrote:
>
> Problem is there are many tools available but hard to pick which one
> is reliable and provide long term community support, also we are
> looking something we can easily deploy compute node, upgrade software
> time to time without breaking any code etc.
>
> On Wed, May 3, 2017 at 5:41 AM, Christian Berendt
>  wrote:
> > Hello Satish.
> >
> > You have to differentiate.
> >
> > You probably used the packages provided by the RDO project for 
CentOS/RedHat to deploy an OpenStack environment by hand (maybe using the 
official OpenStack install guide). This way is not recommended for a 
production. The packages provided itself are production ready, the way you have 
deployed them is not production ready.
> >
> > For a production you want to use one of the existing deployment 
frameworks or a distribution provided by a vendor (normally based on one of the 
existing deployment frameworks). Some of the deployment frameworks are able to 
use the packages provided by the RDO project.
> >
> > As a core member of the Kolla project I recommend to use Kolla 
(https://github.com/openstack/kolla). Our product is based on Kolla.
> >
> > There are other deployment frameworks as well: Fuel, OpenStack 
Ansible, OpenStack Chef, OpenStack Puppet, TripleO.
> >
> > The “best method” depends on the person you ask for the best method.
> >
> > If you need further details about Kolla drop me line line, I am 
happy to help you with this.
> >
> > Christian.
> >
> >> On 3. May 2017, at 08:48, Satish Patel  
wrote:
> >>
> >> We did POC on RDO and we are happy with product but now question 
is, should we use RDO for production deployment or other open source flavor 
available to deploy on prod. Not sure what is the best method of production 
deployment?
> >
> > --
> > Christian Berendt
> > Chief Executive Officer (CEO)
> >
> > Telefon: +49 711 21957003
> > Mobil: +49 171 5542175
> > Mail: bere...@betacloud-solutions.de
> > Web: https://www.betacloud-solutions.de
> >
> > Betacloud Solutions GmbH
> > Teckstrasse 62 / 70190 Stuttgart / Deutschland
> >
> > Geschäftsführer: Christian Berendt
> > Unternehmenssitz: Stuttgart
> > Amtsgericht: Stuttgart, HRB 756139
> >
>
> ___
> Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>


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

Re: [Openstack] Deployment for production

[Satish Patel]

so at CERN you are not using packstack. You are using RDO and done
your puppet work to deploy stuff right?

I found packstack very easy and handy to deploy stuff, why people hate
it? what could go wrong if we deploy using packstack?

On Wed, May 3, 2017 at 12:18 PM, Tim Bell  wrote:
> You also need to assess the skills of your administration team, will they 
> need help to set things up, consulting, formal support contract etc.
>
> At CERN, we’re running packages and puppet configuration derived from RDO in 
> production.
>
> Tim
>
> On 03.05.17, 17:56, "Satish Patel"  wrote:
>
> Problem is there are many tools available but hard to pick which one
> is reliable and provide long term community support, also we are
> looking something we can easily deploy compute node, upgrade software
> time to time without breaking any code etc.
>
> On Wed, May 3, 2017 at 5:41 AM, Christian Berendt
>  wrote:
> > Hello Satish.
> >
> > You have to differentiate.
> >
> > You probably used the packages provided by the RDO project for 
> CentOS/RedHat to deploy an OpenStack environment by hand (maybe using the 
> official OpenStack install guide). This way is not recommended for a 
> production. The packages provided itself are production ready, the way you 
> have deployed them is not production ready.
> >
> > For a production you want to use one of the existing deployment 
> frameworks or a distribution provided by a vendor (normally based on one of 
> the existing deployment frameworks). Some of the deployment frameworks are 
> able to use the packages provided by the RDO project.
> >
> > As a core member of the Kolla project I recommend to use Kolla 
> (https://github.com/openstack/kolla). Our product is based on Kolla.
> >
> > There are other deployment frameworks as well: Fuel, OpenStack Ansible, 
> OpenStack Chef, OpenStack Puppet, TripleO.
> >
> > The “best method” depends on the person you ask for the best method.
> >
> > If you need further details about Kolla drop me line line, I am happy 
> to help you with this.
> >
> > Christian.
> >
> >> On 3. May 2017, at 08:48, Satish Patel  wrote:
> >>
> >> We did POC on RDO and we are happy with product but now question is, 
> should we use RDO for production deployment or other open source flavor 
> available to deploy on prod. Not sure what is the best method of production 
> deployment?
> >
> > --
> > Christian Berendt
> > Chief Executive Officer (CEO)
> >
> > Telefon: +49 711 21957003
> > Mobil: +49 171 5542175
> > Mail: bere...@betacloud-solutions.de
> > Web: https://www.betacloud-solutions.de
> >
> > Betacloud Solutions GmbH
> > Teckstrasse 62 / 70190 Stuttgart / Deutschland
> >
> > Geschäftsführer: Christian Berendt
> > Unternehmenssitz: Stuttgart
> > Amtsgericht: Stuttgart, HRB 756139
> >
>
> ___
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>

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

Re: [Openstack] Deployment for production

[Tim Bell]

You also need to assess the skills of your administration team, will they need 
help to set things up, consulting, formal support contract etc.

At CERN, we’re running packages and puppet configuration derived from RDO in 
production.

Tim

On 03.05.17, 17:56, "Satish Patel"  wrote:

Problem is there are many tools available but hard to pick which one
is reliable and provide long term community support, also we are
looking something we can easily deploy compute node, upgrade software
time to time without breaking any code etc.

On Wed, May 3, 2017 at 5:41 AM, Christian Berendt
 wrote:
> Hello Satish.
>
> You have to differentiate.
>
> You probably used the packages provided by the RDO project for 
CentOS/RedHat to deploy an OpenStack environment by hand (maybe using the 
official OpenStack install guide). This way is not recommended for a 
production. The packages provided itself are production ready, the way you have 
deployed them is not production ready.
>
> For a production you want to use one of the existing deployment 
frameworks or a distribution provided by a vendor (normally based on one of the 
existing deployment frameworks). Some of the deployment frameworks are able to 
use the packages provided by the RDO project.
>
> As a core member of the Kolla project I recommend to use Kolla 
(https://github.com/openstack/kolla). Our product is based on Kolla.
>
> There are other deployment frameworks as well: Fuel, OpenStack Ansible, 
OpenStack Chef, OpenStack Puppet, TripleO.
>
> The “best method” depends on the person you ask for the best method.
>
> If you need further details about Kolla drop me line line, I am happy to 
help you with this.
>
> Christian.
>
>> On 3. May 2017, at 08:48, Satish Patel  wrote:
>>
>> We did POC on RDO and we are happy with product but now question is, 
should we use RDO for production deployment or other open source flavor 
available to deploy on prod. Not sure what is the best method of production 
deployment?
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Telefon: +49 711 21957003
> Mobil: +49 171 5542175
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>

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


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

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

[Anne Gentle]

On Wed, May 3, 2017 at 2:41 AM, Thierry Carrez 
wrote:

> Chris Dent wrote:
> >
> > # Intro
> >
> > Feedback from last week's first attempt at a weekly overview of TC
> > activity was positive enough to continue. Suggestions on how to make
> > it more useful welcome. Main change this time is that I've added
> > some information on stuff happened outside the meeting, a link to
> > the meeting minutes, and a section on stuff we talked about last
> > week that we said we'd pick up later but haven't yet.
> > [...]
>
> Thanks again for publishing your notes!
>
> That reminded me of an issue that has been bothering me for a while. We
> have one area that the current reviews+meeting system fails to capture
> well: issues that are raised somewhere in the community but do not take
> the shape of a formal resolution or governance change. In the current
> system, TC members (or really, anyone in the community) can add to the
> "Open discussion" section of the meeting agenda, but that happens
> extremely rarely. I suspect that the 5 minutes per week that we end up
> dedicating to open discussion in the meetings does not encourage people
> to load large topics of discussions in it. But it's a bit of a
> chicken-and-egg: I only keep a couple minutes of open discussion because
> nobody posts topics to discuss there on the agenda...
>

Would office hours work for this case? Might bring up random topics, but at
least the conversation could be real-time. Seems worth trying.

Thanks Chris for writing up notes! It's a tough job to summarize and this
is well-done.

Anne


>
> As we look toward evolving the meeting format, I feel like moving to a
> more free-form, less timeboxed forum for discussing TC topics (like a
> specific IRC channel or office hours in #openstack-dev) will allow us to
> raise such hot topics more easily.
>
> --
> 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
>



-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.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] [all] TC Report 18

[Thierry Carrez]

Ed Leafe wrote:
> On May 3, 2017, at 2:41 AM, Thierry Carrez  wrote:
> 
>> In the current
>> system, TC members (or really, anyone in the community) can add to the
>> "Open discussion" section of the meeting agenda, but that happens
>> extremely rarely. I suspect that the 5 minutes per week that we end up
>> dedicating to open discussion in the meetings does not encourage people
>> to load large topics of discussions in it.
> 
> Simple: *start* the meeting with Open Discussion.

I don't really see how that would solve the agenda problem.

I think it's better for everyone if people post topics they want to
discuss in advance. Europeans who want to attend need to stay up late,
People in the APAC zone need to get up very early. Knowing up-front what
will be discussed might (might) give people in those zones the extra
incentive they need to attend.

-- 
Thierry Carrez (ttx)



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

Re: [openstack-dev] [all] Yakumo: Pythonic, unified OpenStack client library

[Akira Yoshiyama]

Hi Andrea,

2017-05-03 21:00 GMT+09:00 Andrea Frittoli :
>
>
> On Wed, May 3, 2017 at 12:44 PM Brian Curtin  wrote:
>>
>> On Tue, May 2, 2017 at 10:46 PM, Akira Yoshiyama
>>  wrote:
>>>
>>> Hello all,
>>>
>>> I'm pleased to announce Yakumo, yet another unified OpenStack client
>>> library with an interactive shell. You can find Yakumo below:
>>>
>>>PyPI: https://pypi.python.org/pypi/yakumo/
>>>Github: https://github.com/yosshy/python-yakumo/
>>>
>>> Yakumo development focuses to:
>>>
>>> * Pythonic: handles each cloud resource as an object in the same manner
>>> * Unified: handles all OpenStack APIs at once
>
>
> Does Yakumo provide some plugin mechanism, or do you plan to include and
> support
> all OpenStack services in Yakumo?

Yakumo have no plugin mechanism now, but it sounds great. I'll support
another OpenStack APIs like below:

* Block Storage API v3
* Orchestration API

Yakumo (八雲) is a Japanese proper noun, it means "eightfold clouds" or
"multifold clouds". So the development goal of Yakumo is supporting 8+
OpenStack APIs.

>>> * Less dependency: no import of other OpenStack client libraries
>>>
>>> Why do we have to specify IDs of cloud resources in Python
>>> programming? Python is an object-oriented programming language. IMO,
>>> we should use objects to represent cloud resources, including method
>>> arguments. It's one of the reasons I've started Yakumo project.
>>>
>>> Yakumo 0.11.0 suports OpenStack APIs below:
>>>
>>> * Identity API v2/v3
>>> * Compute API v2
>>> * Networking v2
>>> * Image Service API v1/v2
>>> * Block Storage v1/v2
>>> * Object Storage v1
>>>
>>> Yakumo has 23 sample smoke tests below for the APIs now. It's useful
>>> to test your cloud and learn usage of Yakumo.
>>>
>>>https://github.com/yosshy/python-yakumo/tree/master/yakumo/smoketests
>>>
>>> And also you can use 'ossh', an interactive python shell in Yakumo.
>>> It's a good example.
(snip)
>>> See README for more usage and details:
>>>
>>>https://github.com/yosshy/python-yakumo/blob/master/README.md
>>>
>>> Feedback is welcome!
>
>
> It's not clear to me what is the specific use case this library aims to
> cover.
> Is it meant for application development or testing or both?

Good question. Yakumo is developed for OpenStack Ops; system health
checker, smoke tests, ops tools like creating/deleting tenants and
users, and so on.

> What are its benefit compared to openstacksdk and tempest clients?

I don't know the API of openstacksdk and tempest clients very well, so
it's hard to answer it for me. I think with-statement of resources in
Yakumo looks unique but other clients may have it. See examples like
below for more details:

   
https://github.com/yosshy/python-yakumo/blob/master/yakumo/smoketests/st30_network_subnet_port.py

Regards,
Akira Yoshiyama


>>> Cheers,
>>> Akira Yoshiyama
>>
>>
>> Looks almost exactly like openstacksdk. Why duplicate that and pollute an
>> already crowded space as there are already far too many existing libraries
>> to work with OpenStack?
>>
>> __
>> OpenStack Development Mailing 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] VMware Voting CI

[Sean McGinnis]

On Wed, May 03, 2017 at 02:42:34PM +, Jeremy Stanley wrote:
> On 2017-05-03 09:06:55 -0500 (-0500), Sean McGinnis wrote:
> [...]
> > This CI account, however, appears to be used for multiple projects.
> > I think it got voting rights via a different project.
> [...]
> 
> Doesn't work like that; there are project-specific "-ci" groups in
> our Gerrit which your ACLs are configured independently to allow for
> Verify+/-1 permission. In the case of openstack/cinder changes, this
> is controlled in the cinder-ci group:
> https://review.openstack.org/#/admin/groups/cinder-ci,members
> 
> Any member of the cinder-release group (the "owner" configured for
> cinder-ci) can update the membership there at any time. I _thought_
> we had this better documented, but couldn't find it so have proposed
> a new subsection for the Infra Manual:
> https://review.openstack.org/462176
> 
> Hope that helps!
> -- 
> Jeremy Stanley
> 
Thanks, I was not aware of that. I've "fixed the glitch" now.

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

[openstack-dev] [sahara] Project Onboarding in Boston

[Telles Nobrega]

Hi folks,

If you are interested in learning more about Sahara or meet the expert
developers, we organized a Sahara - Project Onboarding on Tue, May 9,
5:30pm -- 6:10pm Level One MR 1015.

I've put together an etherpad to list folks from Sahara who will be there,
please add yourself, and also to list attendees so we know how many people
we can expect.
https://etherpad.openstack.org/p/BOS-forum-sahara-onboarding

Thanks,
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
OpenStack Development Mailing 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] Deployment for production

[Satish Patel]

Problem is there are many tools available but hard to pick which one
is reliable and provide long term community support, also we are
looking something we can easily deploy compute node, upgrade software
time to time without breaking any code etc.

On Wed, May 3, 2017 at 5:41 AM, Christian Berendt
 wrote:
> Hello Satish.
>
> You have to differentiate.
>
> You probably used the packages provided by the RDO project for CentOS/RedHat 
> to deploy an OpenStack environment by hand (maybe using the official 
> OpenStack install guide). This way is not recommended for a production. The 
> packages provided itself are production ready, the way you have deployed them 
> is not production ready.
>
> For a production you want to use one of the existing deployment frameworks or 
> a distribution provided by a vendor (normally based on one of the existing 
> deployment frameworks). Some of the deployment frameworks are able to use the 
> packages provided by the RDO project.
>
> As a core member of the Kolla project I recommend to use Kolla 
> (https://github.com/openstack/kolla). Our product is based on Kolla.
>
> There are other deployment frameworks as well: Fuel, OpenStack Ansible, 
> OpenStack Chef, OpenStack Puppet, TripleO.
>
> The “best method” depends on the person you ask for the best method.
>
> If you need further details about Kolla drop me line line, I am happy to help 
> you with this.
>
> Christian.
>
>> On 3. May 2017, at 08:48, Satish Patel  wrote:
>>
>> We did POC on RDO and we are happy with product but now question is, should 
>> we use RDO for production deployment or other open source flavor available 
>> to deploy on prod. Not sure what is the best method of production deployment?
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Telefon: +49 711 21957003
> Mobil: +49 171 5542175
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>

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

Re: [openstack-dev] [keystone] Colleen Murphy for core

[Mike Perez]

On 13:15 May 02, Lance Bragstad wrote:
> Hey folks,
> 
> During today's keystone meeting we added another member to keystone's core
> team. For several releases, Colleen's had a profound impact on keystone.
> Her reviews are meticulous and of incredible quality. She has no hesitation
> to jump into keystone's most confusing realms and as a result has become an
> expert on several identity topics like federation and LDAP integration.
> 
> I'd like to thank Colleen for all her hard work and upholding the stability
> and usability of the project.
> 
> 
> Congratulations, Colleen!

Congratulations Colleen!!!

-- 
Mike Perez


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

Re: [Openstack] Deployment for production

[Satish Patel]

I used packstack

I am still not clear what is the difference between packstack vs
triple O  they both used RDP repo in backend.

On Wed, May 3, 2017 at 10:03 AM, Remo Mattei  wrote:
> Did you build it with packstack or triple o?
>
> Inviato da iPhone
>
> Il giorno 03 mag 2017, alle ore 01:41, Fawaz Mohammed
>  ha scritto:
>
> Hi Satish,
>
> I believe RDO is not meant to be for production. I prefer to use the
> original upstream project "TripleO" as they have better documentation.
>
> Other production grade deployment tools are:
> Fuel:
> https://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide.html
> Support CentOS and Ubuntu as hosts.
>
> Charm:
> https://docs.openstack.org/developer/charm-guide/
> Support Ubuntu only.
>
>
> On May 3, 2017 11:00 AM, "Satish Patel"  wrote:
>>
>> We did POC on RDO and we are happy with product but now question is,
>> should we use RDO for production deployment or other open source flavor
>> available to deploy on prod. Not sure what is the best method of production
>> deployment?
>>
>> Sent from my iPhone
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
> !DSPAM:1,5909980a99391285818740!
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
> !DSPAM:1,5909980a99391285818740!

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

[openstack-dev] [keystone][forum] BM/VM session conflict with project workshop

[Lance Bragstad]

Looking through the schedule of keystone-tagged sessions, it appears we
have a conflict between one of the BM/VM sessions [0] and keystone's
project on-boarding session [1].

I wouldn't be opposed to shuffling, but I assume it's too late for that? If
we can get a good idea of who is going to show up for the project
on-boarding session and set a schedule, we might just be able to start it
at 11:45 AM instead of 11:00. This would avoid the conflict, not requiring
late shuffling of sessions. It might also allow the team scheduled before
keystone to run over in their on-boarding session if needed.

I'd be fine doing that if we can get a rough idea of attendance, what
people want information on, and plan accordingly.

Let's use this thread to air some of that out. Thoughts?


Thanks,

Lance

[0]
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18794/operating-the-vm-and-baremetal-platform-22
[1]
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18712/keystone-project-onboarding
__
OpenStack Development Mailing 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] Deployment for production

[James Fleet]

We are using RDO in production ? But we have done some other things to
custom to our builds. If you use RedHat, Canonical Linux they provide you
with subscription support.

James R. Fleet
Innovative Solutions Technology
484 Williamsport Pike  #135
Martinsburg, WV 25404
 888.809.0223 ext.702

On Wed, May 3, 2017 at 10:03 AM, Remo Mattei  wrote:

> Did you build it with packstack or triple o?
>
> Inviato da iPhone
>
> Il giorno 03 mag 2017, alle ore 01:41, Fawaz Mohammed <
> fawaz.moh.ibrah...@gmail.com> ha scritto:
>
> Hi Satish,
>
> I believe RDO is not meant to be for production. I prefer to use the
> original upstream project "TripleO" as they have better documentation.
>
> Other production grade deployment tools are:
> Fuel:
> https://docs.openstack.org/developer/fuel-docs/userdocs/fuel
> -install-guide.html
> Support CentOS and Ubuntu as hosts.
>
> Charm:
> https://docs.openstack.org/developer/charm-guide/
> Support Ubuntu only.
>
>
> On May 3, 2017 11:00 AM, "Satish Patel"  wrote:
>
>> We did POC on RDO and we are happy with product but now question is,
>> should we use RDO for production deployment or other open source flavor
>> available to deploy on prod. Not sure what is the best method of production
>> deployment?
>>
>> Sent from my iPhone
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
> !DSPAM:1,5909980a99391285818740!
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
> !DSPAM:1,5909980a99391285818740!
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [murano] Weekly meeting today is cancelled

[MONTEIRO, FELIPE C]

Hi,

I'm going to cancel this week's IRC meeting, because here's not much on the 
agenda for today and few are likely to make it anyway. Next meeting is 5/9/2017.

Thank You,
Felipe Monteiro

__
OpenStack Development Mailing 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] [swift] Adding our developments to Assosciated projects list

[John Dickinson]

Nejc,

Great to see stuff being built on and around Swift. There's no special process 
for adding stuff to that page. It's a .rst file in the Swift code repo 
(https://github.com/openstack/swift/blob/master/doc/source/associated_projects.rst)
 and you can submit a patch for it via the normal patch submission process. As 
soon as the patch lands, the docs are rebuilt and you'll see the update 
reflected in the live page 
(https://docs.openstack.org/developer/swift/associated_projects.html)

Please feel free to stop by the #openstack-swift IRC channel and tell us about 
iostack and crystal.

--John




On 3 May 2017, at 6:48, Nejc Bat wrote:

> Greetings,
>
> Since I haven't found any appropriate guideline on the webpages and
> wiki I have decided to contact the lists. I apologize in
> advance if I'm spamming a bit.
>
> As part of the IOStack project (http://iostack.eu/) we developed a
> really promising feature for Swift that we called Crystal
> (http://crystal-sds.org/)
>
> I'm interested what is the official process of getting our results
> featured in the "Associated Projects"
> (https://docs.openstack.org/developer/swift/associated_projects.html)
> part of the documentation.
>
> Any help will be greatly appreciated. Thank you in advance.
>
> -- 
>
> *Best regards, / Lep pozdrav,
>
> Nejc Bat
> /Project Manager / Vodja projektov/*
> --
> E-mail: nejc@arctur.si
>
> Arctur d.o.o.
> Industrijska cesta 1a, Kromberk
> SI-5000 Nova Gorica
> Slovenija / EU
>
> Phone: (+386) 5 3029 070
> GSM: (+386) 41 400 987
> Telefax: (+386) 5 3022 042
> Internet: http://www.arctur.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


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

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

[Ed Leafe]

On May 3, 2017, at 2:41 AM, Thierry Carrez  wrote:

> In the current
> system, TC members (or really, anyone in the community) can add to the
> "Open discussion" section of the meeting agenda, but that happens
> extremely rarely. I suspect that the 5 minutes per week that we end up
> dedicating to open discussion in the meetings does not encourage people
> to load large topics of discussions in it.

Simple: *start* the meeting with Open Discussion.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] cloud-init not start ini ubuntu 17.04

[Adhi Priharmanto]

hi all,

I just created ubuntu 17.04 custom image for working with openstack
xenserver, after installing & update+upgrade ubuntu 17.04 base OS, I
installed cloud-init, then reboot it to test cloud-init, but I can't see
cloud-init process during the ubuntu 17.04 OS boot.

Is there anyone can help or give a suggest for me ?

-- 
Cheers,



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

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

Re: [openstack-dev] [all] Yakumo: Pythonic, unified OpenStack client library

[Akira Yoshiyama]

Hi Brian,

2017-05-03 20:42 GMT+09:00 Brian Curtin :
> On Tue, May 2, 2017 at 10:46 PM, Akira Yoshiyama 
> wrote:
>>
>> Hello all,
>>
>> I'm pleased to announce Yakumo, yet another unified OpenStack client
>> library with an interactive shell. You can find Yakumo below:
>>
>>PyPI: https://pypi.python.org/pypi/yakumo/
>>Github: https://github.com/yosshy/python-yakumo/
>>
>> Yakumo development focuses to:
>>
>> * Pythonic: handles each cloud resource as an object in the same manner
>> * Unified: handles all OpenStack APIs at once
>> * Less dependency: no import of other OpenStack client libraries
>>
>> Why do we have to specify IDs of cloud resources in Python
>> programming? Python is an object-oriented programming language. IMO,
>> we should use objects to represent cloud resources, including method
>> arguments. It's one of the reasons I've started Yakumo project.
(snip)
> Looks almost exactly like openstacksdk. Why duplicate that and pollute an
> already crowded space as there are already far too many existing libraries
> to work with OpenStack?

Because there were no unified OpenStack client when I started the development.

The first commit of openstacksdk was on Jan 22, 2014[1]. Yakumo was
originally named "osclient2"[2] and it had the previous version named
"osclient"[3]. The first commit of osclient was on Jul 4, 2013[4].
Moreover, it had another original idea on Jan 17, 2013[5]. The name,
repository and design were altered twice but its basic concept wasn't.

[1]https://github.com/openstack/python-openstacksdk/commit/4c86ed4fea60eb66f52bd0a2e40622d1fe4432dc
[2]https://github.com/yosshy/osclient2
[3]https://github.com/yosshy/osclient
[4]https://github.com/yosshy/osclient/commits/master
[5]https://github.com/yosshy/wiki/wiki/OpenStack_shell

Regards,
Akira Yoshiyama

__
OpenStack Development Mailing 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][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

[Dean Troyer]

On Tue, May 2, 2017 at 7:32 PM, Adrian Turjak  wrote:
> Shade in this context is both really easy, and harder since I can't just
> give it the same session so it can reuse the same token. I've tried
> seeing if I can pilfer the OpenStackCloudConfig from OSC but passing
> that to shade seemed to break. If you run that interpreter command you
> can explore the OSC objects too. "self.app.cloud_config" or
> "self.app.cloud" appears to be close to what we want, but I can't get it
> to play nice with shade as it appears to be a OSC extension of the
> os-client-config class.

With last week's release of os-client-config 1.27.0 and osc-lib 1.5.1
and the addition of these to global-requirements minimums for today's
OSC 3.10.0 release we are in a place to move most of the special-case
code back in to osc-lib and os-client-config.  Much of this is due to
backward-compatibility issues that OSC needed to handle.

> If the interpreter is started from envvars you can do "cloud =
> openstack_cloud()" and shade does the right thing. If it was started
> with --os-cloud then you can also do "cloud =
> openstack_cloud(cloud=self.app.cloud.config.get('cloud'))". The latter
> also works with envvars as "self.app.cloud.config.get('cloud')" returns
> an empty string so shade looks at envvars. I can easily make a function
> that just returns shade with a new token, just kind of sucks that there
> is no way to pass it a valid session/token for it to reuse. Would be
> fantastic if you can take a gander at that as I don't know that much
> about Shade. I'd prefer to have this thing use a single shared session
> or token as much as possible.

Both OSC and Shade use ksa Sessions, that bit should be directly
sharable and includes the token handling.  OSC's auth stuff changed a
bit in the 3.10.0 release in the first step of simplifying it and
actually being able to use os-client-config as intended.  There are a
bunch of timing issues regarding _when_ auth plugins get loaded that
differ between Shade and OSC's usage.  once we complete resolving that
the level of reuse should be able to go up substantially.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [kolla][kolla-ansible] Proposing Bertrand Lallau for kolla and kolla-ansible core

[Martin André]

+1

On Wed, May 3, 2017 at 3:10 PM, Mauricio Lima  wrote:
> +1
>
> 2017-05-03 1:43 GMT-03:00 Christian Berendt
> :
>>
>> +1
>>
>> > On 2. May 2017, at 17:30, Michał Jastrzębski  wrote:
>> >
>> > Hello,
>> >
>> > It's my pleasure to start another core reviewer vote. Today it's
>> > Bertrand (blallau). Consider this mail my +1 vote. Members of
>> > kolla-ansible and kolla core team, please cast your votes:) Voting
>> > will be open for 2 weeks (until 16th of May).
>> >
>> > I also wanted to say that Bertrand went through our core mentorship
>> > program (if only for few weeks because he did awesome job before too)
>> > :)
>> >
>> > Thank you,
>> > Michal
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>> Christian Berendt
>> Chief Executive Officer (CEO)
>>
>> Mail: bere...@betacloud-solutions.de
>> Web: https://www.betacloud-solutions.de
>>
>> Betacloud Solutions GmbH
>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>
>> Geschäftsführer: Christian Berendt
>> Unternehmenssitz: Stuttgart
>> Amtsgericht: Stuttgart, HRB 756139
>>
>>
>> __
>> OpenStack Development Mailing 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] [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

[Dean Troyer]

On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak  wrote:
> As part of my dev work I recently put together a cool little tool which
> lets me have much easier access to the various OpenStack python clients
> in the scope of a python interpreter session. The first version was a
> little rough and without os-client-config support. The current version
> is now a plugin for the openstackclient and introduces a command that
> simply authenticates you, sets up the environment and helper tools, and
> then drops you into an ipython interactive session. The helper stuff is
> fairly simple, but combined with the features of ipython it really lets
> you start playing with the tools quickly, and by piggybacking onto
> openstackclient I get access to a lot of the niceties and inbuilt auth
> mechanisms.
>
> It is useful for learning, testing, or development against the various
> openstack client libraries, and even as an ops tool to quickly run some
> basic actions without having to resort to weird or silly bash command
> combinations.

This is at the other end of the spectrum of client usage from the CLI
in that it takes a very developer-like view of the APIs.  OSC has its
interactive mode (using cmd2) that is just a command loop without even
the ability to change global settings.  My hunch is that something in
between would be really useful, but I am not interested in creating
yet another DSL for this to include flow control and branching.

You mentioned Shade, which falls somewhere in between as it implements
a lot of logic to hide differences in clouds and ease dealing with
some of our API warts.  What would you think about producing a Python
mirror of the CLI interface with resource names, option names,
everything, but in Python.  I have not thought all the way through
this yet, but think we could take advantage of using the cliff command
classes and be able to re-use all of the bits already written.

This also magnifies the things we need to add to (or factor out of)
OSC to make it truly useful, such as manipulation of the global
options, maintaining multiple client contexts, etc.

Thanks for sharing!
dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

[Dean Troyer]

On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak  wrote:
> As part of my dev work I recently put together a cool little tool which
> lets me have much easier access to the various OpenStack python clients
> in the scope of a python interpreter session. The first version was a
> little rough and without os-client-config support. The current version
> is now a plugin for the openstackclient and introduces a command that
> simply authenticates you, sets up the environment and helper tools, and
> then drops you into an ipython interactive session. The helper stuff is
> fairly simple, but combined with the features of ipython it really lets
> you start playing with the tools quickly, and by piggybacking onto
> openstackclient I get access to a lot of the niceties and inbuilt auth
> mechanisms.
>
> It is useful for learning, testing, or development against the various
> openstack client libraries, and even as an ops tool to quickly run some
> basic actions without having to resort to weird or silly bash command
> combinations.

This is at the other end of the spectrum of client usage from the CLI
in that it takes a very developer-like view of the APIs.  OSC has its
interactive mode (using cmd2) that is just a command loop without even
the ability to change global settings.  My hunch is that something in
between would be really useful, but I am not interested in creating
yet another DSL for this to include flow control and branching.

You mentioned Shade, which falls somewhere in between as it implements
a lot of logic to hide differences in clouds and ease dealing with
some of our API warts.  What would you think about producing a Python
mirror of the CLI interface with resource names, option names,
everything, but in Python.  I have not thought all the way through
this yet, but think we could take advantage of using the cliff command
classes and be able to re-use all of the bits already written.

This also magnifies the things we need to add to (or factor out of)
OSC to make it truly useful, such as manipulation of the global
options, maintaining multiple client contexts, etc.

Thanks for sharing!
dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [nova] Degradation of performance on master

[Anastasia Kravets]

Hi, 

No sorry but we haven’t run this with os-profiler (and don’t have plans to run).

Thank you,
Anastasia

> From: Matt Riedemann >
> Sent: Thursday, April 27, 2017 9:20 PM
> To: openstack-dev@lists.openstack.org 
> 
> Subject: Re: [openstack-dev] [nova] Degradation of performance on master
>  
> Thanks for the information. Have you run this with os-profiler to get an 
> idea of where it's taking the most time? The virt driver, fake or not, 
> shouldn't make a difference when listing instances as that's just a 
> database operation.
> 
> -- 
> 
> 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-dev mailing list 
> 
> lists.openstack.org 
> This list for the developers of OpenStack to discuss development issues and 
> roadmap. It is focused on the next release of OpenStack: you should post on 
> this list if ...

__
OpenStack Development Mailing 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] [OSC] OpenStackClient release and core team and meetings

[Dean Troyer]

First of all, I would like to say how glad I am to have seen the two
recent messages regarding other OpenStack client-side projects.  More
projects like this raise the visibility of all of the client-side work
as it illustrates the importance of the consumer side of OpenStack
APIs in the minds of those watching what we do (/me waves at project
managers and other corporate resource deciders).

## Meetings

OSC has a split meeting schedule in an attempt to accommodate our
diverse time zones.  Part of the problem with that is keeping track of
odd or even weeks and as a result we've been missing a couple of
meetings.  I do not plan to change the schedule[0], but I _do_ plan to
start sending meeting reminders to the ML as that seems to work well
for other teams with a split schedule.  So here is the first:

The next OpenStackClient meeting is set for Thursday May 4 at 1300 UTC
in #openstack-meeting-3.

## 3.10.0 Release

OpenStackClient 3.10.0 was released this morning and includes a number
of things that I think bear highlighting.

* With the removal of the nova-network/proxy code in novaclient we
found ourselves with a hole and re-implemented the set of REST calls
that OSC required to continue to support networks and security groups
on nova-network clouds.  In the process of doing this we discovered a
CLI change that was required in 'network create', the --subnet option
is actually required (for nova-network only) for the call to succeed
so we now enforce that in the command.
* One other incompatible CLI change is the requirement to include the
positional argument  in the 'volume snapshot create'
command.  Again what was implemented is not what was intended, and any
command that includes both the --volume argument and the snapshot name
will continue to work. The Backward Incompatible Changes doc[1] has
more details on these changes.
* A number of new Network API-based commands have been added, as this
is already longer than most will read see the 3.10.0 Release Notes for
details.[2]

## OSC Core Team

I am of mixed emotions in announcing a couple of core team changes:
Huanxuan Ao is leaving to focus on completing his thesis and Rui Chen
has been added. They both have been doing excellent work for some time
and we look forward to Rui joining the core team.  Huanxuan, thank you
very much, we appreciate all of your contributions to OSC and
OpenStack in general.

On a related note, OSC was affected pretty hard by the end of OSIC as
a number of the people implementing new Network and Volume commands
were impacted.  Much of what we added in this release was contributed
by that crew and we appreciate their contributions as well.  There
remains some unfinished work that we will sort out and re-prioritize
as we talk to the affected projects.  I plan to do some of that in
Boston next week.


If you have read this far, thank you.  I do not write a lot, and when
I do I seem to try to make up for that.

dt


[0] http://eavesdrop.openstack.org/#OpenStackClient_Team_Meeting
[1] 
https://docs.openstack.org/developer/python-openstackclient/backwards-incompatible.html#release-3-10
[2] 
https://docs.openstack.org/releasenotes/python-openstackclient/unreleased.html#id1

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

[Eric Fried]

Boden-

Can you please point to the change(s) that move the constants?  Or
provide some other way to figure out which are affected?

Thanks,
Eric (efried)

On 05/03/2017 09:30 AM, Boden Russell wrote:
> If your project uses neutron.plugins.common.constants please read on. If
> not, it's probably safe to discard this message.
> 
> A number of the constants from neutron.plugins.common.constants have
> moved into neutron-lib:
> - The service type constants are in neutron_lib.plugins.constants
> - Many of the others are in neutron_lib.constants
> - A few have not yet been rehomed into neutron-lib
> 
> Suggested actions:
> - If you work on a stadium project, you should already be covered [1].
> - Otherwise, please move your project's imports to use the constants in
> neutron-lib rather than neutron. See the work in [1] for reference.
> 
> Once we see sub-projects moved off these constants, we'll begin removing
> them from neutron.plugins.common.constants (likely as a set of patches).
> We can discuss this topic in our weekly neutron meeting.
> 
> Thanks
> 
> 
> [1]
> https://review.openstack.org/#/q/message:%22use+neutron-lib+constants+rather%22
> 
> __
> OpenStack Development Mailing 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] VMware Voting CI

[Jeremy Stanley]

On 2017-05-03 09:06:55 -0500 (-0500), Sean McGinnis wrote:
[...]
> This CI account, however, appears to be used for multiple projects.
> I think it got voting rights via a different project.
[...]

Doesn't work like that; there are project-specific "-ci" groups in
our Gerrit which your ACLs are configured independently to allow for
Verify+/-1 permission. In the case of openstack/cinder changes, this
is controlled in the cinder-ci group:
https://review.openstack.org/#/admin/groups/cinder-ci,members

Any member of the cinder-release group (the "owner" configured for
cinder-ci) can update the membership there at any time. I _thought_
we had this better documented, but couldn't find it so have proposed
a new subsection for the Infra Manual:
https://review.openstack.org/462176

Hope that helps!
-- 
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-dev] [horizon] Next 2 weekly meetings cancelled

[Rob Cresswell]

Hi everyone!

The next two weekly IRC meetings (3rd May, 10th May) are cancelled. I'm away 
this week and next week is the summit. Meetings will resume on the 17th!

For those going to the summit, please read 
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115982.html for 
meetup info.

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

[openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

[Boden Russell]

If your project uses neutron.plugins.common.constants please read on. If
not, it's probably safe to discard this message.

A number of the constants from neutron.plugins.common.constants have
moved into neutron-lib:
- The service type constants are in neutron_lib.plugins.constants
- Many of the others are in neutron_lib.constants
- A few have not yet been rehomed into neutron-lib

Suggested actions:
- If you work on a stadium project, you should already be covered [1].
- Otherwise, please move your project's imports to use the constants in
neutron-lib rather than neutron. See the work in [1] for reference.

Once we see sub-projects moved off these constants, we'll begin removing
them from neutron.plugins.common.constants (likely as a set of patches).
We can discuss this topic in our weekly neutron meeting.

Thanks


[1]
https://review.openstack.org/#/q/message:%22use+neutron-lib+constants+rather%22

__
OpenStack Development Mailing 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] Project on-boarding - are you going? What do you need/want to know?

[Matt Riedemann]

Some of the nova team is on a hangout trying to figure out how we're 
going to structure the nova project on-boarding session at the Forum [1].


We've got an etherpad started here [2].

It became abundantly clear very early that we don't know who is going to 
be attending a session like this and we need some help from the community.


So do you plan on going to this session and if so, what do you need to 
know or care about learning?


Are you an operator or an application developer? Do you have some 
experience with openstack or are you brand new and you're being sent by 
your company to learn about things and start contributing upstream, but 
don't know where to start? Or are you an operator that's been running 
Nova for awhile now and want to know more about how it works so you can 
tweak it?


If you have any feedback here, please let us know (like, within the next 
48 hours please).


[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18688/nova-project-onboarding

[2] https://etherpad.openstack.org/p/BOS-forum-nova-project-onboarding

--

Thanks,

Matt

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

Re: [openstack-dev] VMware Voting CI

[Ivan Kolodyazhny]

Big +1 to Sean especially for Cinder-related issues

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, May 3, 2017 at 5:06 PM, Sean McGinnis  wrote:

> Hey everyone,
>
> I'm looking for some background on the VMware NSX CI. Specifically,
> why this CI is enabled for voting.
>
> We had discussed whether to have "stable" CI's vote in the Cinder
> project a while back, and other than potentially some benefit in
> doing scripted reporting, we couldn't really think of a good
> reason to have third party CI voting.
>
> This CI account, however, appears to be used for multiple projects.
> I think it got voting rights via a different project. I'm just
> wondering if there is still a valid reason for that.
>
> I think this has come up before, and to be clear, it does not block
> anything when there ends up a -1 from this CI. The issue I have
> with it is when looking in a summary list of patches, even if Jenkins
> has voted +1, if the VMware NSX CI has failed, it ends up with a big
> ol' red -1 in the Verified column, making it look like there is an
> issue with the patch. Which likely means unless someone is
> specifically interested in that patch, they will see the red -1 and
> move on.
>
> Does anyone have the background as to why this CI has voting rights,
> and whether it should still have them?
>
> Thanks,
> Sean (smcginnis)
>
>
> __
> OpenStack Development Mailing 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] [vitrage] Alarm Banner for Vitrage Dashboard ?

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I agree that there should be two blueprints, one for Horizon and one for 
Vitrage. For new APIs we usually write a spec file with the API definition, so 
other people can comment on gerrit.

Thanks, and looking forward to the blueprint ☺
Ifat.


From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 3 May 2017 at 14:19
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Yes, the banner would be displayed on all Horizon screens, not just Vitrage.
Agree that this would mean changes in both Horizon and some supporting code in 
Vitrage.

Would this mean 2x Blueprints ?
 - one in Horizon for the display side of the Banner, and
 - one in Vitrage to make the Alarm Counts accessible to Horizon

I think for Horizon, they only write a blueprint (and no spec file).
What is required for Vitrage ?   Just a blueprint or a spec file as well ?

I’ll definitely run the blueprint / spec file by you before submitting.

I am not attending the Boston Summit.  Although there is a handful of people 
from
Wind River attending.

thanks for the input,
Greg.


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Wednesday, May 3, 2017 at 3:02 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Hi Greg,

It sounds like a great idea.
Do you plan to show this banner in all Horizon menus (your screenshot shows 
“Compute/Instances”), or just in Vitrage? for the first option I think you 
would need to write the code in Horizon itself, not in vitrage-dashboard.

Let me know if you need any assistance with this blueprint. Also, if you are 
attending the Boston summit, we can meet and discuss it.

Best Regards,
Ifat.

From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, 2 May 2017 at 20:03
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Any opinions on whether an Alarm Banner for the Vitrage Dashboard would be a 
useful blueprint for improved usability ?

i.e. an ACTIVE Alarm Counts Banner in the Top Navbar of Horizon

· populated with the Active Alarm Counts for Critical, Major, Minor, 
Warning Severities from Vitrage,

· visible at ALL times,

· auto-refreshed relatively every 5 secs (say) ... configurable,

· selecting it takes you directly to the Vitrage -> Alarms panel

let me know if we think this would be useful to submit as a blueprint to the 
Vitrage Dashboard project,
Greg.

[cid:image001.png@01D2C431.53CEF780]
__
OpenStack Development Mailing 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] Deployment for production

[Remo Mattei]

Did you build it with packstack or triple o? 

Inviato da iPhone

> Il giorno 03 mag 2017, alle ore 01:41, Fawaz Mohammed 
>  ha scritto:
> 
> Hi Satish,
> 
> I believe RDO is not meant to be for production. I prefer to use the original 
> upstream project "TripleO" as they have better documentation.
> 
> Other production grade deployment tools are:
> Fuel: 
> https://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide.html
>   
> Support CentOS and Ubuntu as hosts.
> 
> Charm: 
> https://docs.openstack.org/developer/charm-guide/ 
> Support Ubuntu only.
> 
> 
>> On May 3, 2017 11:00 AM, "Satish Patel"  wrote:
>> We did POC on RDO and we are happy with product but now question is, should 
>> we use RDO for production deployment or other open source flavor available 
>> to deploy on prod. Not sure what is the best method of production deployment?
>> 
>> Sent from my iPhone
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> !DSPAM:1,5909980a99391285818740!
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> !DSPAM:1,5909980a99391285818740!
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] VMware Voting CI

[Sean McGinnis]

Hey everyone,

I'm looking for some background on the VMware NSX CI. Specifically,
why this CI is enabled for voting.

We had discussed whether to have "stable" CI's vote in the Cinder
project a while back, and other than potentially some benefit in
doing scripted reporting, we couldn't really think of a good
reason to have third party CI voting.

This CI account, however, appears to be used for multiple projects.
I think it got voting rights via a different project. I'm just
wondering if there is still a valid reason for that.

I think this has come up before, and to be clear, it does not block
anything when there ends up a -1 from this CI. The issue I have
with it is when looking in a summary list of patches, even if Jenkins
has voted +1, if the VMware NSX CI has failed, it ends up with a big
ol' red -1 in the Verified column, making it look like there is an
issue with the patch. Which likely means unless someone is
specifically interested in that patch, they will see the red -1 and
move on.

Does anyone have the background as to why this CI has voting rights,
and whether it should still have them?

Thanks,
Sean (smcginnis)


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

Re: [openstack-dev] [nova][deployment] Changing to run nova-api/meta-api under uwsgi by default

[Emilien Macchi]

On Wed, May 3, 2017 at 9:17 AM, Matt Riedemann  wrote:
> Chris Dent has a change up to devstack [1] which is going to make
> nova-api/meta-api run under uwsgi by default on master (Pike).
>
> That depends on a grenade change [2] which is simply there so we can roll
> through upgrades from Ocata to Pike with eventlet, but new installs in Pike
> via devstack will be using uwsgi.
>
> This is just a heads up that the change is happening and once we're doing it
> in devstack then other deployment tooling projects like TripleO and Kolla
> can investigate adding support for running nova-api under uwsgi too.

ack. Thanks for keeping us updated, I think it's very useful.

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



-- 
Emilien Macchi

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

Re: [Openstack-operators] Openstack-Ansible (Ocata branch) deployment failing - "No matching distribution found for mysql-python"

[Andy McCrae]

Hi Eugene,

With just that error it's a bit difficult to see exactly why it's failing.

Could you use paste.openstack.org (or similar) to paste a more detailed log
of the error/output?

I'd also suggest jumping into #openstack-ansible on the Freenode irc
server, there are usually some people about who may be able to help and
provide more feedback/pointers.

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

[openstack-dev] [swift] Adding our developments to Assosciated projects list

[Nejc Bat]

Greetings,

Since I haven't found any appropriate guideline on the webpages and
wiki I have decided to contact the lists. I apologize in
advance if I'm spamming a bit.

As part of the IOStack project (http://iostack.eu/) we developed a
really promising feature for Swift that we called Crystal
(http://crystal-sds.org/)

I'm interested what is the official process of getting our results
featured in the "Associated Projects"
(https://docs.openstack.org/developer/swift/associated_projects.html)
part of the documentation.

Any help will be greatly appreciated. Thank you in advance.

--

*Best regards, / Lep pozdrav,

Nejc Bat
/Project Manager / Vodja projektov/*
--
E-mail: nejc@arctur.si

Arctur d.o.o.
Industrijska cesta 1a, Kromberk
SI-5000 Nova Gorica
Slovenija / EU

Phone: (+386) 5 3029 070
GSM: (+386) 41 400 987
Telefax: (+386) 5 3022 042
Internet: http://www.arctur.net/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Sean McGinnis]

On Wed, May 03, 2017 at 01:14:18PM +, Andrea Frittoli wrote:
> 
> > >
> 
> > Now that this is all in place, I think it's working well and I would like
> > to see it continue that way. IMO, tempest proper should not have anything
> > that isn't universally applicable to real world deployments. Not just for
> > things like Ceph, but things like the manage/unmanage backend specific
> > tests that were added and broke a large majority of third party CI.
> >
> 
> Is there a policy in Cinder that a backend must implement a certain set of
> APIs? If so we could think of testing only that set of APIs in Tempest, so
> that
> any app developer knows that he/she can rely on that minimum set of APIs.
> 

Yes, there is a minimum feature set that all backend drivers must support.
That base functionality can be found here [0] and here [1].

[0] 
https://docs.openstack.org/developer/cinder/devref/drivers.html#core-functionality
[1] 
https://github.com/openstack/cinder/blob/master/cinder/interface/volume_driver.py

The issue we've had with some of the tempest tests isn't actually around
whether the given backend supports the API. It's the way the API is used
that becomes a challenge.

I'll use the manage/unmanage snapshot one as an example. This is not one
of the required APIs, but many backends do support it. But the way this
API works is you are basically saying "manage this snapshot that you
identify as X", where "X" can be different things depending on the volume
driver being used. It's the storage device's native way of identifying
a snapshot, which may or may not be our Cinder snapshot ID.

So that test was added based on the way the LVM driver works for this.
That part is great, we get some more code coverage in the gate. But then
each volume driver that uses a different ID had to first a) start failing
CI, b) troubleshoot what happened to cause this new failure, c) reconfig
their CI to skip this test. Repeat cycle for each test added that does
something specific to how one or a small subset of backends work.


__
OpenStack Development Mailing 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] [devstack] [all] systemd in devstack by default

[Matt Riedemann]

On 5/3/2017 5:09 AM, Sean Dague wrote:

If you run into any other issues please pop into #openstack-qa (or
respond to this email) and we'll try to work through them.


Something has definitely gone haywire in the cells v1 job since 5/1 and 
the journal log handler:


http://status.openstack.org/elastic-recheck/#1580728

We're seeing UnicodeDecodeErrors. I don't know why it's just that job 
that's failing though since the same code and test tickling it exists in 
all of the other jobs too. It could just be something to do with how 
cells v1 handles vm state changes at the top which turns it into a hard 
failure.


--

Thanks,

Matt

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

Re: [Openstack] Adding our developments to Assosciated projects list

[Doug Hellmann]

You probably want to start by contacting the swift development team,
since they own that content.

Send email to the openstack-dev mailing list with "[swift]" in the
subject line so anyone filtering the list will see it.

Doug

Excerpts from Nejc Bat's message of 2017-05-03 10:54:52 +0200:
> Dear all,
> 
> I don't want to come across as fussy, but I assume that the answer to my 
> question is too difficult: I'm interested what is the official process 
> of getting our results featured in the "Associated Projects" 
> (https://docs.openstack.org/developer/swift/associated_projects.html) 
> part of the documentation.
> 
> Any hint and help will be much appreciated. Thank you in advance.
> 
> *Best regards, / Lep pozdrav,
> 
> Nejc Bat
> /Project Manager / Vodja projektov/*
> --
> E-mail: nejc@arctur.si
> 
> Arctur d.o.o.
> Industrijska cesta 1a, Kromberk
> SI-5000 Nova Gorica
> Slovenija / EU
> 
> Phone: (+386) 5 3029 070
> GSM: (+386) 41 400 987
> Telefax: (+386) 5 3022 042
> Internet: http://www.arctur.net/
> Nejc Bat je 18. 04. 2017 ob 11:17 napisal:
> > Greetings,
> >
> > Since I haven't found any appropriate guideline on the webpages and 
> > wiki I have decided to contact the general lists. I apologize in 
> > advance if I'm spamming a bit.
> >
> > As part of the IOStack project (http://iostack.eu/) we developed a 
> > really promising feature for Swift that we called Crystal 
> > (http://crystal-sds.org/)
> >
> > I'm interested what is the official process of getting our results 
> > featured in the "Associated Projects" 
> > (https://docs.openstack.org/developer/swift/associated_projects.html) 
> > part of the documentation.
> >
> > Any help will be greatly appreciated. Thank you in advance.
> > -- 
> >
> > *Best regards, / Lep pozdrav,
> >
> > Nejc Bat
> > /Project Manager / Vodja projektov/*
> > --
> > E-mail: nejc@arctur.si
> >
> > Arctur d.o.o.
> > Industrijska cesta 1a, Kromberk
> > SI-5000 Nova Gorica
> > Slovenija / EU
> >
> > Phone: (+386) 5 3029 070
> > GSM: (+386) 41 400 987
> > Telefax: (+386) 5 3022 042
> > Internet: http://www.arctur.net/

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

[openstack-dev] [nova][deployment] Changing to run nova-api/meta-api under uwsgi by default

[Matt Riedemann]

Chris Dent has a change up to devstack [1] which is going to make 
nova-api/meta-api run under uwsgi by default on master (Pike).


That depends on a grenade change [2] which is simply there so we can 
roll through upgrades from Ocata to Pike with eventlet, but new installs 
in Pike via devstack will be using uwsgi.


This is just a heads up that the change is happening and once we're 
doing it in devstack then other deployment tooling projects like TripleO 
and Kolla can investigate adding support for running nova-api under 
uwsgi too.


[1] https://review.openstack.org/#/c/457715/
[2] https://review.openstack.org/#/c/460543/

--

Thanks,

Matt

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

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Andrea Frittoli]

On Tue, May 2, 2017 at 4:56 PM Sean McGinnis  wrote:

> On Tue, May 02, 2017 at 03:36:20PM +0200, Jordan Pittier wrote:
> > On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann 
> > wrote:
> >
> > > In Cinder, there are many features/APIs which are backend specific and
> > > will return 405 or 501 if same is not implemented on any backend [1].
> > > If such tests are implemented in Tempest, then it will break some gate
> > > where that backend job is voting. like ceph job in glance_store gate.
> > >
> > > There been many such cases recently where ceph jobs were broken due to
> > > such tests and recently it is for force-delete backup feature[2].
> > > Reverting force-delete tests in [3]. To resolve such cases at some
> > > extend, Jon is going to add a white/black list of tests which can run
> > > on ceph job [4] depends on what all feature ceph implemented. But this
> > > does not resolve it completely due to many reason like
> > > 1. External use of Tempest become difficult where user needs to know
> > > what all tests to skip for which backend
> > > 2. Tempest tests become too specific to backend.
> > >
> > > Now there are few options to resolve this:
> > > 1. Tempest should not tests such API/feature which are backend
> > > specific like mentioned by api-ref like[1].
> > >
> > So basically, if one of the 50 Cinder driver doesn't support a feature,
> we
> > should never test that feature ? What about the 49 other drivers ? If a
> > feature exists and can be tested in the Gate (with whatever default
> > config/driver is shipped) then I think we should test it.
> >
> 50? Over 100 as of Ocata.
>
> Well, is tempest's purpose in life to provide complete gate test coverage,
> or is tempest's purpose in life to give operators a tool to validate that
> their deployment is working as expected?
>

Neither.

Tempest is used for several different purposes, but I would say it was never
meant to ensure 100% coverage of the API. It is used by many operators to
validate their deployments, even if that part is better achieved via the
"scenario" tests, as opposed to the "API" tests.

Main use cases for Tempest are:
- integration (cross-service) testing in the gate
- help to ensure API backward compatibility / stability
- home for interoperability tests


> In attempting to do things in the past, I've received push back based on
> the argument that it was the latter. For this reason, in-tree tempest tests
> were added to Cinder to give us a way to get better test coverage for our
> own sake.
>

There are several use cases for in-tree tests.
Some examples:

Test that provide very little cross-service validation (e.g. most API
negative
tests) do not need to be in Tempest. Running a full cloud is expensive
resource and time-wise, and it's not the best test environment to run a
large
combination of negative test cases.

Many tests cannot be driven via API. It's very hard for instance to test
any transient resource state via API, since there's not enough control via
the API.

Scheduler tests are not best implemented via API as well, since they often
require
several nodes and resources when executed in a full cloud environment.


> Now that this is all in place, I think it's working well and I would like
> to see it continue that way. IMO, tempest proper should not have anything
> that isn't universally applicable to real world deployments. Not just for
> things like Ceph, but things like the manage/unmanage backend specific
> tests that were added and broke a large majority of third party CI.
>

Is there a policy in Cinder that a backend must implement a certain set of
APIs? If so we could think of testing only that set of APIs in Tempest, so
that
any app developer knows that he/she can rely on that minimum set of APIs.

If the list of APIs is not constrained on cinder side, the next driver
could come
along that does not support an API, and then we would have to stop testing
it
in Tempest - which is not an option.

Another point is that API that rely on services other than nova are best
tested
in Tempest, so that the tests run in the gate of other services as well -
or at
least the cinder functional test job should run against the other services
as well.


>
> Backend specific things should not be part of tempest in my opinion. We
> should cover those things through in-tree tempest plugins and our own
> testing.
> >
> > > 2. Tempest test can be disabled/skip based on backend. - This is not
> > > good idea as it increase config options and overhead of setting those.
> > >
> > Using regex and blacklist, any 3rd party CI can skip any test based on
> the
> > test ID. Without introducing a config flag. See:
> >
> https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871
> >
> >
> > > 3. Tempest test can verify behavior with if else condition as per
> > > backend. This is bad idea and lose the test strength.
> > >
> 

Re: [openstack-dev] [neutron] stepping down from infra liaison

[Andreas Scheuring]

Really sad to hear that.

It was a pleasure working with you - all the best for your future!
-- 
-
Andreas 
IRC: andreas_s



On Mi, 2017-05-03 at 00:39 +, Das, Anindita wrote:
> Hi All,
> 
>  
> 
> Some of you already know about the recent changes in OSIC.
> Unfortunately, I am impacted by these changes.
> 
>  
> 
> So I will not be able to contribute to neutron and fulfill my
> responsibilities as infra liaison. It was a very rewarding experience
> working with everybody in the neutron community. Thank you to everyone
> who helped me to contribute to neutron in the past few releases.
> 
>  
> 
> Hopefully, I will get an opportunity in the future to return to
> OpenStack development. Till then will be cheering you on from the
> sidelines.
> 
>  
> 
> Thanks,
> 
> Anindita (irc:dasanind)
> 
>  
> 
> P.S. Will still be available in IRC on and off. Please don’t hesitate
> to ping me if in case I can be of any help.
> 
> 
> __
> OpenStack Development Mailing 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] [kolla][kolla-ansible] Proposing Bertrand Lallau for kolla and kolla-ansible core

[Mauricio Lima]

+1

2017-05-03 1:43 GMT-03:00 Christian Berendt 
:

> +1
>
> > On 2. May 2017, at 17:30, Michał Jastrzębski  wrote:
> >
> > Hello,
> >
> > It's my pleasure to start another core reviewer vote. Today it's
> > Bertrand (blallau). Consider this mail my +1 vote. Members of
> > kolla-ansible and kolla core team, please cast your votes:) Voting
> > will be open for 2 weeks (until 16th of May).
> >
> > I also wanted to say that Bertrand went through our core mentorship
> > program (if only for few weeks because he did awesome job before too)
> > :)
> >
> > Thank you,
> > Michal
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __
> OpenStack Development Mailing 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][cinder][ceph] should Tempest tests the backend specific feature?

[Andrea Frittoli]

On Tue, May 2, 2017 at 2:41 PM Jordan Pittier 
wrote:

> On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann 
> wrote:
>
>> In Cinder, there are many features/APIs which are backend specific and
>> will return 405 or 501 if same is not implemented on any backend [1].
>> If such tests are implemented in Tempest, then it will break some gate
>> where that backend job is voting. like ceph job in glance_store gate.
>>
>> There been many such cases recently where ceph jobs were broken due to
>> such tests and recently it is for force-delete backup feature[2].
>> Reverting force-delete tests in [3]. To resolve such cases at some
>> extend, Jon is going to add a white/black list of tests which can run
>> on ceph job [4] depends on what all feature ceph implemented. But this
>> does not resolve it completely due to many reason like
>> 1. External use of Tempest become difficult where user needs to know
>> what all tests to skip for which backend
>> 2. Tempest tests become too specific to backend.
>>
>> Now there are few options to resolve this:
>> 1. Tempest should not tests such API/feature which are backend
>> specific like mentioned by api-ref like[1].
>>
> So basically, if one of the 50 Cinder driver doesn't support a feature, we
> should never test that feature ? What about the 49 other drivers ? If a
> feature exists and can be tested in the Gate (with whatever default
> config/driver is shipped) then I think we should test it.
>
>
>> 2. Tempest test can be disabled/skip based on backend. - This is not
>> good idea as it increase config options and overhead of setting those.
>>
> Using regex and blacklist, any 3rd party CI can skip any test based on the
> test ID. Without introducing a config flag. See:
> https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871
>

This way each 3rd party system has to maintain its own list, which has the
advantage that
different teams maintain their own list (which is nice from an ownership
and scale pov).

However I think such list of tests are not as re-usable as having a
devstack plugin (or an
ansible or puppet module) changing a few tempest config options.


>
>> 3. Tempest test can verify behavior with if else condition as per
>> backend. This is bad idea and lose the test strength.
>>
> Yeah, that's bad.
>
>>
>> IMO options 1 is better options. More feedback are welcome.
>
>
>> ..1
>> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
>> ..2 https://bugs.launchpad.net/glance/+bug/1687538
>> ..3 https://review.openstack.org/#/c/461625/
>> ..4
>> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>>
>> -gmann
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing 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][cinder][ceph] should Tempest tests the backend specific feature?

[Andrea Frittoli]

On Tue, May 2, 2017 at 6:46 AM Ghanshyam Mann 
wrote:

> In Cinder, there are many features/APIs which are backend specific and
> will return 405 or 501 if same is not implemented on any backend [1].
> If such tests are implemented in Tempest, then it will break some gate
> where that backend job is voting. like ceph job in glance_store gate.
>

Having a test in Tempest is important for interoperability and API backward
compatibility.
As long as available features are discoverable and reported in a consistent
way, it
is possible for app developer to write application that will work fine
against
different backends.


>
> There been many such cases recently where ceph jobs were broken due to
> such tests and recently it is for force-delete backup feature[2].
> Reverting force-delete tests in [3]. To resolve such cases at some
> extend, Jon is going to add a white/black list of tests which can run
> on ceph job [4] depends on what all feature ceph implemented. But this
> does not resolve it completely due to many reason like
> 1. External use of Tempest become difficult where user needs to know
> what all tests to skip for which backend
> 2. Tempest tests become too specific to backend.
>
> Now there are few options to resolve this:
> 1. Tempest should not tests such API/feature which are backend
> specific like mentioned by api-ref like[1].
> 2. Tempest test can be disabled/skip based on backend. - This is not
> good idea as it increase config options and overhead of setting those.
>

Tempest has many options because we decide not to rely on discovery, i.e.
we configure what we expect to find in the target cloud. I don't think we
can use
this as a factor to influence the decision in this case.


> 3. Tempest test can verify behavior with if else condition as per
> backend. This is bad idea and lose the test strength.
>
> IMO options 1 is better options. More feedback are welcome.
>
> ..1
> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
> ..2 https://bugs.launchpad.net/glance/+bug/1687538
> ..3 https://review.openstack.org/#/c/461625/
> ..4
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>
> -gmann
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Goodbye ironic o/

[Vasyl Saienko]

Mario,

So sorry to hear that you won't be working on Ironic anymore :(
Good luck with your new assignments!

On Tue, May 2, 2017 at 7:10 AM, Ranganathan, Shobha <
shobha.ranganat...@intel.com> wrote:

> Hi Mario,
>
>
>
> Sorry to hear that you won’t be working on Ironic anymore!
>
> Best of luck on whatever you are doing next!
>
>
>
> Shobha
>
>
>
> *From:* John Villalovos [mailto:openstack@sodarock.com]
> *Sent:* Monday, May 1, 2017 9:14 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [ironic] Goodbye ironic o/
>
>
>
> Mario,
>
> So sorry you won't be working with us on Ironic anymore :( You have been
> an great part of Ironic and I'm glad I got to know you.
>
> Hopefully I will get to work with you again. Best of luck for the future!
>
> John
>
>
>
> On Fri, Apr 28, 2017 at 9:12 AM, Mario Villaplana <
> mario.villapl...@gmail.com> wrote:
>
> Hi ironic team,
>
>
>
> You may have noticed a decline in my upstream contributions the past few
> weeks. Unfortunately, I'm no longer being paid to work on ironic. It's
> unlikely that I'll be contributing enough to keep up with the project in my
> new job, too, so please do feel free to remove my core access.
>
>
>
> It's been great working with all of you. I've learned so much about open
> source, baremetal provisioning, Python, and more from all of you, and I
> will definitely miss it. I hope that we all get to work together again in
> the future someday.
>
>
>
> I am not sure that I'll be at the Forum during the day, but please do ping
> me for a weekend or evening hangout if you're attending. I'd love to show
> anyone who's interested around the Boston area if our schedules align.
>
>
>
> Also feel free to contact me via IRC/email/carrier pigeon with any
> questions about work in progress I had upstream.
>
>
>
> Good luck with the project, and thanks for everything!
>
>
>
> Best wishes,
>
> Mario Villaplana
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Deep dive Thursday May 4th 1400 UTC on deployed-server

[James Slagle]

I saw there was no deep dive scheduled for tomorrow, so I decided I'd
go ahead and plan one.

It will be recorded if you can't make it on the short notice.

I plan to cover the "deployed-server" feature in TripleO. We have been
using this feature since Newton to drive our multinode CI. I'll go
over how the multinode CI uses this feature to test TripleO on
pre-provisioned nodes.

I'll also discuss the improvements that were done in Ocata to make
this feature ready for end user consumption. Finally, I'll cover
what's being done in Pike around using this feature more fully for an
end to end "split-stack".

Thursday May 4th at 1400 UTC at https://bluejeans.com/176756457/

You don't want to miss it! (or maybe you do). Go Owls!

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] Deployment for production

[Matthias Runge]

On 03/05/17 10:41, Fawaz Mohammed wrote:
> Hi Satish,
> 
> I believe RDO is not meant to be for production. I prefer to use the
> original upstream project "TripleO" as they have better documentation.
> 
I guess you meant, you were using the TripleO installer from RDO project?

There are quite a few organizations using packages from RDO for their
production environment.

Please note, updates are only provided for a limited amount of time, see
https://www.rdoproject.org/rdo/release-cadence/

Matthias
-- 
Matthias Runge 

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

Re: [openstack-dev] [all] Yakumo: Pythonic, unified OpenStack client library

[Andrea Frittoli]

On Wed, May 3, 2017 at 12:44 PM Brian Curtin  wrote:

> On Tue, May 2, 2017 at 10:46 PM, Akira Yoshiyama  > wrote:
>
>> Hello all,
>>
>> I'm pleased to announce Yakumo, yet another unified OpenStack client
>> library with an interactive shell. You can find Yakumo below:
>>
>>PyPI: https://pypi.python.org/pypi/yakumo/
>>Github: https://github.com/yosshy/python-yakumo/
>>
>> Yakumo development focuses to:
>>
>> * Pythonic: handles each cloud resource as an object in the same manner
>> * Unified: handles all OpenStack APIs at once
>
>
Does Yakumo provide some plugin mechanism, or do you plan to include and
support
all OpenStack services in Yakumo?


> * Less dependency: no import of other OpenStack client libraries
>>
>> Why do we have to specify IDs of cloud resources in Python
>> programming? Python is an object-oriented programming language. IMO,
>> we should use objects to represent cloud resources, including method
>> arguments. It's one of the reasons I've started Yakumo project.
>>
>> Yakumo 0.11.0 suports OpenStack APIs below:
>>
>> * Identity API v2/v3
>> * Compute API v2
>> * Networking v2
>> * Image Service API v1/v2
>> * Block Storage v1/v2
>> * Object Storage v1
>>
>> Yakumo has 23 sample smoke tests below for the APIs now. It's useful
>> to test your cloud and learn usage of Yakumo.
>>
>>https://github.com/yosshy/python-yakumo/tree/master/yakumo/smoketests
>>
>> And also you can use 'ossh', an interactive python shell in Yakumo.
>> It's a good example.
>> # ossh --os-cloud=mypackstack
>>
>> Finding existing resources:
>> (c is an client object automatically generated for mypackstack
>> environment)
>> >>> i = c.image.find_one(name="trusty")
>> >>> f = c.flavor.find_one(name='m1.small')
>> >>> k = c.key_pair.find_one(name='key1')
>> >>> n = c.network.find_one(name='private')
>> >>> i, f, k, n
>> (> (id="887b0393-5065-4bcf-941d-623100baa06e", name="trusty")>,
>> ,
>> ,
>> > (id="22e3fa30-11c0-4065-bbf7-8d8bbb50f63b", name="private")>)
>>
>> Creating a server:
>> >>> s = c.server.create(name='vm1', image=i, flavor=f, networks=[n],
>> key_pair=k)
>> >>> s
>> > (id="b1477f6c-bbc4-4c37-ba05-14b935a5d08c" empty)>
>>
>> Waiting for building task finished:
>> >>> s.wait_for_finished()
>> >>> s.status
>> u'ACTIVE'
>>
>> Deleting the server:
>> >>> s.delete()
>>
>> See README for more usage and details:
>>
>>https://github.com/yosshy/python-yakumo/blob/master/README.md
>>
>> Feedback is welcome!
>>
>
It's not clear to me what is the specific use case this library aims to
cover.
Is it meant for application development or testing or both?
What are its benefit compared to openstacksdk and tempest clients?


>
>> Cheers,
>> Akira Yoshiyama
>
>
> Looks almost exactly like openstacksdk. Why duplicate that and pollute an
> already crowded space as there are already far too many existing libraries
> to work with OpenStack?
>
__
> OpenStack Development Mailing 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][heat][murano][daisycloud] Removing Heat support from Tempest

[Andrea Frittoli]

On Tue, May 2, 2017 at 5:33 PM Matthew Treinish 
wrote:

> On Tue, May 02, 2017 at 09:49:14AM +0530, Rabi Mishra wrote:
> > On Fri, Apr 28, 2017 at 2:17 PM, Andrea Frittoli <
> andrea.fritt...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra 
> wrote:
> > >
> > >> On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli <
> > >> andrea.fritt...@gmail.com> wrote:
> > >>
> > >>> Dear stackers,
> > >>>
> > >>> starting in the Liberty cycle Tempest has defined a set of projects
> > >>> which are in scope for direct
> > >>> testing in Tempest [0]. The current list includes keystone, nova,
> > >>> glance, swift, cinder and neutron.
> > >>> All other projects can use the same Tempest testing infrastructure
> (or
> > >>> parts of it) by taking advantage
> > >>> the Tempest plugin and stable interfaces.
> > >>>
> > >>> Tempest currently hosts a set of API tests as well as a service
> client
> > >>> for the Heat project.
> > >>> The Heat service client is used by the tests in Tempest, which run in
> > >>> Heat gate as part of the grenade
> > >>> job, as well as in the Tempest gate (check pipeline) as part of the
> > >>> layer4 job.
> > >>> According to code search [3] the Heat service client is also used by
> > >>> Murano and Daisycore.
> > >>>
> > >>
> > >> For the heat grenade job, I've proposed two patches.
> > >>
> > >> 1. To run heat tree gabbi api tests as part of grenade 'post-upgrade'
> > >> phase
> > >>
> > >> https://review.openstack.org/#/c/460542/
> > >>
> > >> 2. To remove tempest tests from the grenade job
> > >>
> > >> https://review.openstack.org/#/c/460810/
> > >>
> > >>
> > >>
> > >>> I proposed a patch to Tempest to start the deprecation counter for
> Heat
> > >>> / orchestration related
> > >>> configuration items in Tempest [4], and I would like to make sure
> that
> > >>> all tests and the service client
> > >>> either find a new home outside of Tempest, or are removed, by the end
> > >>> the Pike cycle at the latest.
> > >>>
> > >>> Heat has in-tree integration tests and Gabbi based API tests, but I
> > >>> don't know if those provide
> > >>> enough coverage to replace the tests on Tempest side.
> > >>>
> > >>>
> > >> Yes, the heat gabbi api tests do not yet have the same coverage as the
> > >> tempest tree api tests (lacks tests using nova, neutron and swift
> > >> resources),  but I think that should not stop us from *not* running
> the
> > >> tempest tests in the grenade job.
> > >>
> > >> I also don't know if the tempest tree heat tests are used by any other
> > >> upstream/downstream jobs. We could surely add more tests to bridge
> the gap.
> > >>
> > >> Also, It's possible to run the heat integration tests (we've enough
> > >> coverage there) with tempest plugin after doing some initial setup,
> as we
> > >> do in all our dsvm gate jobs.
> > >>
> > >> It would propose to move tests and client to a Tempest plugin owned /
> > >>> maintained by
> > >>> the Heat team, so that the Heat team can have full flexibility in
> > >>> consolidating their integration
> > >>> tests. For Murano and Daisycloud - and any other team that may want
> to
> > >>> use the Heat service
> > >>> client in their tests, even if the client is removed from Tempest, it
> > >>> would still be available via
> > >>> the Heat Tempest plugin. As long as the plugin implements the service
> > >>> client interface,
> > >>> the Heat service client will register automatically in the service
> > >>> client manager and be available
> > >>> for use as today.
> > >>>
> > >>>
> > >> if I understand correctly, you're proposing moving the existing
> tempest
> > >> tests and service clients to a separate repo managed by heat team.
> Though
> > >> that would be collective decision, I'm not sure that's something I
> would
> > >> like to do. To start with we may look at adding some of the missing
> pieces
> > >> in heat tree itself.
> > >>
> > >
> > > I'm proposing to move tests and the service client outside of tempest
> to a
> > > new home.
> > >
> > > I also suggested that the new home could be a dedicate repo, since that
> > > would allow you to maintain the
> > > current branchless nature of those tests. A more detailed discussion
> about
> > > the topic can be found
> > > in the corresponding proposed queens goal [5],
> > >
> > > Using a dedicated repo *is not* a precondition for moving tests and
> > > service client out of Tempest.
> > >
> > >
> > We probably are mixing two different things here.
> >
> > 1. Moving in-tree heat templest plugn and tests to a dedicated repo
> >
> > Though we don't have any plans for it now, we may have to do it when/if
> > it's accepted as a community goal.
> >
> > 2.  Moving tempest tree heat tests and heat service client to a new home
> > and owner.
> >
> > I don't think that's something heat team would like to do given that we
> > don't use these tests anywhere and would probably spend time improving
> the
> > coverage of 

Re: [openstack-dev] [all] Yakumo: Pythonic, unified OpenStack client library

[Brian Curtin]

On Tue, May 2, 2017 at 10:46 PM, Akira Yoshiyama 
wrote:

> Hello all,
>
> I'm pleased to announce Yakumo, yet another unified OpenStack client
> library with an interactive shell. You can find Yakumo below:
>
>PyPI: https://pypi.python.org/pypi/yakumo/
>Github: https://github.com/yosshy/python-yakumo/
>
> Yakumo development focuses to:
>
> * Pythonic: handles each cloud resource as an object in the same manner
> * Unified: handles all OpenStack APIs at once
> * Less dependency: no import of other OpenStack client libraries
>
> Why do we have to specify IDs of cloud resources in Python
> programming? Python is an object-oriented programming language. IMO,
> we should use objects to represent cloud resources, including method
> arguments. It's one of the reasons I've started Yakumo project.
>
> Yakumo 0.11.0 suports OpenStack APIs below:
>
> * Identity API v2/v3
> * Compute API v2
> * Networking v2
> * Image Service API v1/v2
> * Block Storage v1/v2
> * Object Storage v1
>
> Yakumo has 23 sample smoke tests below for the APIs now. It's useful
> to test your cloud and learn usage of Yakumo.
>
>https://github.com/yosshy/python-yakumo/tree/master/yakumo/smoketests
>
> And also you can use 'ossh', an interactive python shell in Yakumo.
> It's a good example.
> # ossh --os-cloud=mypackstack
>
> Finding existing resources:
> (c is an client object automatically generated for mypackstack environment)
> >>> i = c.image.find_one(name="trusty")
> >>> f = c.flavor.find_one(name='m1.small')
> >>> k = c.key_pair.find_one(name='key1')
> >>> n = c.network.find_one(name='private')
> >>> i, f, k, n
> ( (id="887b0393-5065-4bcf-941d-623100baa06e", name="trusty")>,
> ,
> ,
>  (id="22e3fa30-11c0-4065-bbf7-8d8bbb50f63b", name="private")>)
>
> Creating a server:
> >>> s = c.server.create(name='vm1', image=i, flavor=f, networks=[n],
> key_pair=k)
> >>> s
>  (id="b1477f6c-bbc4-4c37-ba05-14b935a5d08c" empty)>
>
> Waiting for building task finished:
> >>> s.wait_for_finished()
> >>> s.status
> u'ACTIVE'
>
> Deleting the server:
> >>> s.delete()
>
> See README for more usage and details:
>
>https://github.com/yosshy/python-yakumo/blob/master/README.md
>
> Feedback is welcome!
>
> Cheers,
> Akira Yoshiyama


Looks almost exactly like openstacksdk. Why duplicate that and pollute an
already crowded space as there are already far too many existing libraries
to work with OpenStack?
__
OpenStack Development Mailing 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] [vitrage] Alarm Banner for Vitrage Dashboard ?

[Waines, Greg]

Yes, the banner would be displayed on all Horizon screens, not just Vitrage.
Agree that this would mean changes in both Horizon and some supporting code in 
Vitrage.

Would this mean 2x Blueprints ?
 - one in Horizon for the display side of the Banner, and
 - one in Vitrage to make the Alarm Counts accessible to Horizon

I think for Horizon, they only write a blueprint (and no spec file).
What is required for Vitrage ?   Just a blueprint or a spec file as well ?

I’ll definitely run the blueprint / spec file by you before submitting.

I am not attending the Boston Summit.  Although there is a handful of people 
from
Wind River attending.

thanks for the input,
Greg.


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Wednesday, May 3, 2017 at 3:02 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Hi Greg,

It sounds like a great idea.
Do you plan to show this banner in all Horizon menus (your screenshot shows 
“Compute/Instances”), or just in Vitrage? for the first option I think you 
would need to write the code in Horizon itself, not in vitrage-dashboard.

Let me know if you need any assistance with this blueprint. Also, if you are 
attending the Boston summit, we can meet and discuss it.

Best Regards,
Ifat.

From: "Waines, Greg" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, 2 May 2017 at 20:03
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Alarm Banner for Vitrage Dashboard ?

Any opinions on whether an Alarm Banner for the Vitrage Dashboard would be a 
useful blueprint for improved usability ?

i.e. an ACTIVE Alarm Counts Banner in the Top Navbar of Horizon

· populated with the Active Alarm Counts for Critical, Major, Minor, 
Warning Severities from Vitrage,

· visible at ALL times,

· auto-refreshed relatively every 5 secs (say) ... configurable,

· selecting it takes you directly to the Vitrage -> Alarms panel

let me know if we think this would be useful to submit as a blueprint to the 
Vitrage Dashboard project,
Greg.

[cid:image001.png@01D2C3DD.8DB7AFE0]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Fwd: [AOSUG] OpenStack Australia Day Melbourne - 1 month to go!

[Blair Bethwaite]

Aussie Stackers, get amongst it!

-- Forwarded message --
From: Jessica Field 
Date: 3 May 2017 at 16:25
Subject: [AOSUG] OpenStack Australia Day Melbourne - 1 month to go!
To: aosug-annou...@meetup.com


Hi OzStackers,

There’s now less than one month to go until OpenStack Australia Day comes
to Melbourne!

We’ve added a few speakers to the website to give you an idea of what to
expect on the day. So far, the agenda features local speakers from the
University
of Melbourne , Monash University
 and the National eResearch Collaboration Tools
and Resources project (Nectar ), as well as
international speakers from the OpenStack Foundation 
, Cloudify by Gigaspaces , EasyStack
 and more.

Speaker submissions are open until the 8th of May, so there’s still time to
submit your presentation. To submit a talk, please visit:
australiaday.openstack.org.au

OpenStack Australia Day Melbourne is supported by Aptira
, Veritas , Cumulus Networks
, Rackspace
, RedHat , SUSE
 and The Register .
If you’d like to be involved, please let us know as soon as possible. We’ve
added a range of unique add-on packages including food carts and cocktail
packages to help draw more attention to your sponsor area on the day. Oh –
did we mention there’s a donut wall?! For more information or to request a
sponsorship pack, please visit australiaday.openstack.org.au.

Tickets are still on sale, but spaces are limited. Register today
 to avoid disappointment. I hope to
see you all there!

Jess




--
This message was sent by Meetup on behalf of Jessica Field

from Australian OpenStack User Group
.
To report this message, please click here

To block the sender of this message, please click here

To unsubscribe from special announcements from your Organizer(s), click here


Meetup, POB 4668 #37895 NY NY USA 10163 <#m_1026249296055576842_> |
supp...@meetup.com



-- 
Blair Bethwaite
Senior HPC Consultant

Monash eResearch Centre
Monash University
Room G26, 15 Innovation Walk, Clayton Campus
Clayton VIC 3800
Australia
Mobile: 0439-545-002
Office: +61 3-9903-2800
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [TripleO][CI] Quickstart deep dive

[Gabriele Cerami]

A video from the recording of the deep-dive is now available at

https://youtu.be/qaTwGBuLoRc

Thanks to everyone for the participation, we hope it helped.


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

[openstack-dev] [tripleo] images.rdoproject.org / thirdparty-logs.rdoproject.org is going tdown for a short maintenance

[Attila Darazs]

I need to reboot this machine for updates/fixes. It should be a short 
downtime, but a few jobs/downloads might be interrupted, so I announce 
it here for reference.


This jobs serves both TripleO and RDO jobs, so I CC both mailing list.

Best regards,
Attila

__
OpenStack Development Mailing 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] [devstack] [all] systemd in devstack by default

[Sean Dague]

On 05/02/2017 08:30 AM, Sean Dague wrote:
> We started running systemd for devstack in the gate yesterday, so far so
> good.
> 
> The following patch (which will hopefully land soon), will convert the
> default local use of devstack to systemd as well -
> https://review.openstack.org/#/c/461716/. It also includes substantially
> updated documentation.
> 
> Once you take this patch, a "./clean.sh" is recommended. Flipping modes
> can cause some cruft to build up, and ./clean.sh should be pretty good
> at eliminating them.
> 
> https://review.openstack.org/#/c/461716/2/doc/source/development.rst is
> probably specifically interesting / useful for people to read, as it
> shows how the standard development workflows will change (for the
> better) with systemd.
> 
>   -Sean

As a follow up, there are definitely a few edge conditions we've hit
with some jobs, so the following is provided as information in case you
have a job that seems to fail in one of these ways.

Doing process stop / start
==

The nova live migration job is special, it was restarting services
manually, however it was doing so with some copy / pasted devstack
code, which means it didn't evolve with the rest of devstack. So the
stop code stopped working (and wasn't robust enough to make it clear
that was the issue).

https://review.openstack.org/#/c/461803/ is the fix (merged)

run_process limitations
===

When doing the systemd conversion I looked for a path forward which
was going to make 90% of everything just work. The key trick here was
that services start as the "stack" user, and aren't daemonizing away
from the console. We can take the run_process command and make that
the ExecStart in a unit file.

*Except* that only works if the command is specified by an *absolute
path*.

So things like this in kuryr-libnetwork become an issue
https://github.com/openstack/kuryr-libnetwork/blob/3e2891d6fc5d55b3712258c932a5a8b9b323f6c2/devstack/plugin.sh#L148

There is also a second issue there, which is calling sudo in the
run_process line. If you need to run as a user/group different than
the default, you need to specify that directly.

The run_process command now supports that -
https://github.com/openstack-dev/devstack/blob/803acffcf9254e328426ad67380a99f4f5b164ec/functions-common#L1531-L1535

And lastly, run_process really always did expect that the thing you
started remained attached to the console. These are run as "simple"
services in systemd. If you are running a thing which already
daemonizes systemd is going to assume (correctly in this simple mode)
the fact that the process detatched from it means it died, and kill
and clean it up.

This is the issue the OpenDaylight plugin ran
into. https://review.openstack.org/#/c/461889/ is the proposed fix.



If you run into any other issues please pop into #openstack-qa (or
respond to this email) and we'll try to work through them.

-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] [designate] Synchronize bind9 backend

[Lars-Erik Helander]

We are using designate with a bind9 backend in a newton based Openstack system.
When the designate processes and the bind9 process are restarted they get out 
of synch. The zones in designate are no longer in bind9. How can I get the 
bind9 backend to get synchronized after a restart?

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

[openstack-dev] [oslo] cancel weekly meeting in next week (05/08)

[ChangBo Guo]

Hi folks,

Just a reminder that we will skip oslo weekly meeting in next week, most
people should be in the Boston Summit :-)

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