Re: [openstack-dev] [all] Capability Discovery API

[Ziad Sawalha]

What does ³Flavor sizes² include? Memory, CPU count? Is there a
wide-enough care for other measures of performance or compatibility like:
- virtualization type: none (hardware/metal), xen, kvm, hyperv
- cpu speed, cache or some form of performance index
- volume types: SATA, SSD, iSCSI, and a performance index


On 3/17/15, 9:22 PM, "John Dickinson"  wrote:

>
>> On Mar 17, 2015, at 1:02 PM, Davis, Amos (PaaS-Core)
>> wrote:
>> 
>> All,
>> The Application EcoSystem Working Group realized during the mid-cycle
>>meetup in Philadelphia that there is no way to get the capabilities of
>>an Openstack cloud so that applications can measure their compatibility
>>against that cloud.  In other words,  if we create an Openstack App
>>Marketplace and have developers make apps to be in that marketplace,
>>then we'll have no way for apps to verify that they can run on that
>>cloud.  We'd like to ask that there be a standard set of API calls
>>created that allow a cloud to list its capabilities.  The cloud
>>"features" or capabilities list should return True/False API responses
>>and could include but is not limited to the below examples.  Also,
>>https://review.openstack.org/#/c/162655/ may be a good starting point
>>for this request.
>> 
>> 
>> Glance:
>> URL/upload
>> types (raw, qcow, etc)
>> 
>> Nova:
>> Suspend/Resume VM
>> Resize
>> Flavor sizes supported
>> Images Available
>> Quota Limits
>> VNC support
>> 
>> Neutron:
>> Types of Networking (neutron, neutron + ml2, nova-network aka linux
>>bridge, other)
>> Types of SDN in use?
>> Shared tenant networks
>> Anything else?
>> 
>> 
>> Ceph/Cinder:
>> LVM or other?
>> SCSI-backed?
>> Any others?
>> 
>> Swift:
>> ?
>
>Swift's capabilities are discoverable via an "/info" endpoint. The docs
>are at:
>
>http://docs.openstack.org/developer/swift/api/discoverability.html
>
>Example output from my dev environment and from Rackspace Cloud Files and
>from a SwiftStack lab cluster:
>
>https://gist.github.com/notmyname/438392d57c2f3d3ee327
>
>
>Clients use these to ensure a unified experience across clusters and that
>features are supported before trying to use them.
>
>> 
>> Best Regards,
>> Amos Davis
>> amos.da...@hp.com
>> 
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] Hacking and PEP 257: Extra blank line at end of multi-line docstring

[Ziad Sawalha]

Guido kindly updated PEP-257 for us[1]. So now the hacking guide content 
accurately matches PEP-257 (no extra line required at the end of a multi-line 
docstring).

This alone should resolve the patch and comments that initiated this discussion.

With regards to automating the checks and gates, we’ll experiment with gating 
on this using the flake8 pep257 plugin[2] and submit the jobs that come out of 
that to stackforge. There are still some patches[3] to get in to pep257 and the 
flake8 plugin (for PEP-257 and for compatibility with the latest pep8 version).

Z

[1] https://codereview.appspot.com/69870043
[2] https://pypi.python.org/pypi/flake8-docstrings/0.1.4
[3] https://github.com/GreenSteam/pep257/pull/64


On Feb 24, 2014, at 6:56 PM, Ziad Sawalha 
mailto:ziad.sawa...@rackspace.com>> wrote:

Seeking some clarification on the OpenStack hacking guidelines for multi-string 
docstrings.

Q: In OpenStack projects, is a blank line before the triple closing quotes 
recommended (and therefore optional - this is what PEP-257 seems to suggest), 
required, or explicitly rejected (which could be one way to interpret the 
hacking guidelines since they omit the blank line).

This came up in a commit review, and here are some references on the topic:

Quoting PEP-257: “The BDFL [3] recommends inserting a blank line between the 
last paragraph in a multi-line docstring and its closing quotes, placing the 
closing quotes on a line by themselves. This way, Emacs' fill-paragraph command 
can be used on it.”

Sample from pep257 (with extra blank line):

def complex(real=0.0, imag=0.0):
"""Form a complex number.

Keyword arguments:
real -- the real part (default 0.0)
imag -- the imaginary part (default 0.0)

"""
if imag == 0.0 and real == 0.0: return complex_zero
...

The multi-line docstring example in 
http://docs.openstack.org/developer/hacking/ has no extra blank line before the 
ending triple-quotes:

"""A multi line docstring has a one-line summary, less than 80 characters.

Then a new paragraph after a newline that explains in more detail any
general information about the function, class or method. Example usages
are also great to have here if it is a complex class for function.

When writing the docstring for a class, an extra line should be placed
after the closing quotations. For more in-depth explanations for these
decisions see http://www.python.org/dev/peps/pep-0257/

If you are going to describe parameters and return values, use Sphinx, the
appropriate syntax is as follows.

:param foo: the foo parameter
:param bar: the bar parameter
:returns: return_type -- description of the return value
:returns: description of the return value
:raises: AttributeError, KeyError
"""

Regards,

Ziad

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

Re: [openstack-dev] Hacking and PEP 257: Extra blank line at end of multi-line docstring

[Ziad Sawalha]

On Feb 26, 2014, at 11:47 AM, Joe Gordon  wrote:

> On Wed, Feb 26, 2014 at 9:05 AM, David Ripton  wrote:
>> On 02/26/2014 11:40 AM, Joe Gordon wrote:
>> 
>>> This is missing the point about manually enforcing style. If you pass
>>> the 'pep8' job there is no need to change any style.
>> 
>> 
>> In a perfect world, yes.
> 
> While there are exceptions to this,  this just sounds like being extra
> nit-picky.  

The current reality is that reviewers do vote and comment based on the rules in
the hacking guide. In terms of style, whether my patch gets approved or not 
depends
on who reviews it.

I think that clarifying this in the hacking guide and including it in our test 
suites
would remove the personal bias from it. I don’t see folks complaining that 
Jenkins is
being nit-picky as a reviewer.

> The important aspect here is the mindset, if we don't gate
> on style rule x, then we shouldn't waste valuable human review time
> and patch revisions on trying to manually enforce it (And yes there
> are exceptions to this).
> 
>> 
>> In the real world, there are several things in PEP8 or our project
>> guidelines that the tools don't enforce perfectly.  I think it's fine for
>> human reviewers to point such things out.  (And then submit a patch to
>> hacking to avoid the need to do so in the future.)
> 
> To clarify, we don't rely on long term human enforcement for something
> that a computer can do.
> 

Precisely. I’m offering to include this as a patch to hacking or even a separate
test that we can add (without gating initially).

>> 
>> --
>> David Ripton   Red Hat   drip...@redhat.com
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Hacking and PEP 257: Extra blank line at end of multi-line docstring

[Ziad Sawalha]

On Feb 25, 2014, at 5:18 PM, Kevin L. Mitchell  
wrote:

> On Tue, 2014-02-25 at 00:56 +0000, Ziad Sawalha wrote:
>> Seeking some clarification on the OpenStack hacking guidelines for
>> multi-string docstrings. 
>> 
>> 
>> Q: In OpenStack projects, is a blank line before the triple closing
>> quotes recommended (and therefore optional - this is what PEP-257
>> seems to suggest), required, or explicitly rejected (which could be
>> one way to interpret the hacking guidelines since they omit the blank
>> line).
> 
> 
> I lobbied to relax that restriction, because I happen to use Emacs, and
> know that that limitation no longer exists with Emacs.

Given the recommendation in PEP-257 is based solely on that, should
we explicitly recommend not including that extra space?

Should we add that rule to hacking?

>  I submitted the
> change that eliminated that language from nova's HACKING at the time…

Thanks, Kevin - based on that I’ll resubmit my change without the blank line.


> -- 
> Kevin L. Mitchell 
> Rackspace
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Hacking and PEP 257: Extra blank line at end of multi-line docstring

[Ziad Sawalha]

On Feb 25, 2014, at 4:08 PM, Joe Gordon  wrote:

> On Mon, Feb 24, 2014 at 4:56 PM, Ziad Sawalha
>  wrote:
>> Seeking some clarification on the OpenStack hacking guidelines for
>> multi-string docstrings.
>> 
>> Q: In OpenStack projects, is a blank line before the triple closing quotes
>> recommended (and therefore optional - this is what PEP-257 seems to
>> suggest), required, or explicitly rejected (which could be one way to
>> interpret the hacking guidelines since they omit the blank line).
>> 
>> This came up in a commit review, and here are some references on the topic:
> 
> Link?

https://review.openstack.org/#/c/73515/4/heat/api/aws/exception.py

> Style should never ever be enforced by a human,

Agreed. I’d be happy to include a PEP-257 plugin to flake8 (or
a change to the hacking library) customized for our rules in the
hacking doc.

I’m actually testing a fork of a flake8 plugin here: 
https://github.com/ziadsawalha/flake8_docstrings

> if the code passed
> the pep8 job, then its acceptable.

PEP-8 does not cover this. PEP-257 combined with the our OpenStack hacking 
standards.

>> 
>> Quoting PEP-257: "The BDFL [3] recommends inserting a blank line between the
>> last paragraph in a multi-line docstring and its closing quotes, placing the
>> closing quotes on a line by themselves. This way, Emacs' fill-paragraph
>> command can be used on it."
>> 
>> Sample from pep257 (with extra blank line):
>> 
>> def complex(real=0.0, imag=0.0):
>>"""Form a complex number.
>> 
>>Keyword arguments:
>>real -- the real part (default 0.0)
>>imag -- the imaginary part (default 0.0)
>> 
>>"""
>>if imag == 0.0 and real == 0.0: return complex_zero
>>...
>> 
>> 
>> The multi-line docstring example in
>> http://docs.openstack.org/developer/hacking/ has no extra blank line before
>> the ending triple-quotes:
>> 
>> """A multi line docstring has a one-line summary, less than 80 characters.
>> 
>> Then a new paragraph after a newline that explains in more detail any
>> general information about the function, class or method. Example usages
>> are also great to have here if it is a complex class for function.
>> 
>> When writing the docstring for a class, an extra line should be placed
>> after the closing quotations. For more in-depth explanations for these
>> decisions see http://www.python.org/dev/peps/pep-0257/
>> 
>> If you are going to describe parameters and return values, use Sphinx, the
>> appropriate syntax is as follows.
>> 
>> :param foo: the foo parameter
>> :param bar: the bar parameter
>> :returns: return_type -- description of the return value
>> :returns: description of the return value
>> :raises: AttributeError, KeyError
>> """
>> 
>> Regards,
>> 
>> Ziad
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Hacking and PEP 257: Extra blank line at end of multi-line docstring

[Ziad Sawalha]

Seeking some clarification on the OpenStack hacking guidelines for multi-string 
docstrings.

Q: In OpenStack projects, is a blank line before the triple closing quotes 
recommended (and therefore optional - this is what PEP-257 seems to suggest), 
required, or explicitly rejected (which could be one way to interpret the 
hacking guidelines since they omit the blank line).

This came up in a commit review, and here are some references on the topic:

Quoting PEP-257: “The BDFL [3] recommends inserting a blank line between the 
last paragraph in a multi-line docstring and its closing quotes, placing the 
closing quotes on a line by themselves. This way, Emacs' fill-paragraph command 
can be used on it.”

Sample from pep257 (with extra blank line):

def complex(real=0.0, imag=0.0):
"""Form a complex number.

Keyword arguments:
real -- the real part (default 0.0)
imag -- the imaginary part (default 0.0)

"""
if imag == 0.0 and real == 0.0: return complex_zero
...

The multi-line docstring example in 
http://docs.openstack.org/developer/hacking/ has no extra blank line before the 
ending triple-quotes:

"""A multi line docstring has a one-line summary, less than 80 characters.

Then a new paragraph after a newline that explains in more detail any
general information about the function, class or method. Example usages
are also great to have here if it is a complex class for function.

When writing the docstring for a class, an extra line should be placed
after the closing quotations. For more in-depth explanations for these
decisions see http://www.python.org/dev/peps/pep-0257/

If you are going to describe parameters and return values, use Sphinx, the
appropriate syntax is as follows.

:param foo: the foo parameter
:param bar: the bar parameter
:returns: return_type -- description of the return value
:returns: description of the return value
:raises: AttributeError, KeyError
"""

Regards,

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

[openstack-dev] Satori Project Update (Configuration Discovery)

[Ziad Sawalha]

We had our first team meeting[1] today and will be holding weekly team meetings 
on Mondays at 15:00 UTC on #openstack-meeting-alt.

An early prototype of Satori is available on pypi [2].

We’re working towards adding the following features before making an 
announcement to the user list on availability of satori:

- usability improvements such as update docs and additional CLI error trapping
- include an in-host discovery component (that logs on to servers and discover 
running and/or installed software).

We’re available on #satori and eager to get feedback on the work we are doing.

Ziad

[1] https://wiki.openstack.org/wiki/Satori/MeetingLogs
[2] https://pypi.python.org/pypi/satori


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

Re: [openstack-dev] [Neutron] Rename 'tenant' to 'project' as per Keystone?

[Ziad Sawalha]

I can speak to the first "project->tenant” part.

In the beginning there was Nova and Swift. Nova (NASA) used the term project. 
Swift (Rackspace) used the term account.

When we created Keystone to provide a common auth system, we were also 
interested in developing a common multi-tenant-accounting framework [see 1, 2], 
so we introduced what we believed was a generic term - tenant - that did not 
inherit the NASA or Rackspace-specific organizational models.

Most new OpeenStack projects coming in adopted “tenant", but we were not able 
to complete the the changes to the Nova or Swift codebases.

The Keystone v2 API released in Diablo was implemented with the term “tenant”  
(v1 and v1.1 were Rackspace Auth API versions).

Hope that helps provide some historical context (at least the piece of the 
history that I did participate in).

Z

[1] last updated spec https://github.com/ziadsawalha/multi-tenant-accounting 
(in 
pdf)
[2] on the wiki https://wiki.openstack.org/wiki/Openstack-accounting


On Dec 3, 2013, at 8:56 PM, Yongsheng Gong 
mailto:gong...@unitedstack.com>> wrote:

who can tell me the whole story about keystone(or openstack) changes between 
project->tenant->project?


On Wed, Dec 4, 2013 at 9:58 AM, Adam Young 
mailto:ayo...@redhat.com>> wrote:
On 11/26/2013 12:07 PM, Maru Newby wrote:
Keystone is almost finished replacing the term 'tenant' with 'project' (see 
recent thread 
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html)  
and we might want to think about how and when Neutron makes a similar 
transition.  It's an unlikely priority in the near term given the focus on 
stability, but I wanted to broach the topic for discussion in case people think 
it might be worth attempting later in the cycle.  I've filed a preliminary 
blueprint in any case: 
https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project


Maru


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
yes please!


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

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

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