Re: [openstack-dev] New PyCharm License

[Noorul Islam K M]

Andrew Melton  writes:

> Hi devs,
>
>
> I've got the new license for the next year. As always, please reply to this 
> email with your launchpad-id if you would like a license.
>
>
> Also, if there are other JetBrains products you use to contribute to 
> OpenStack, please let me know and I will request licenses.
>

My id is noorul

Thanks and Regards
Noorul

__
OpenStack Development Mailing 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] [Solum] Core Reviewer Change

[Noorul Islam K M]

Adrian Otto adrian.o...@rackspace.com writes:

 Solum Core Reviewer Team,

 I propose the following change to our core reviewer group:

 -lifeless (Robert Collins) [inactive]
 +murali-allada (Murali Allada)
 +james-li (James Li)

 Please let me know your votes (+1, 0, or -1).


+1

Regards,
Noorul

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

Re: [openstack-dev] [Solum] Core Reviewer Change

[Noorul Islam K M]

Adrian Otto adrian.o...@rackspace.com writes:

 Solum Core Reviewer Team,

 I propose the following change to our core reviewer group:

 +stannie (Pierre Padrixe)

 Please let me know your votes (+1, 0, or -1).


+1

Regards,
Noorul

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

Re: [openstack-dev] What projects need help?

[Noorul Islam K M]

Brian Jarrett celttec...@gmail.com writes:

 Developers,

 I'm looking to become a contributor.  I've already signed the CLA, etc. and
 I'm looking through tons of documentation, but I'm thinking it might be
 good to have a project I could focus on.

 Are there any projects that could use more developers?  I would imagine
 there are some that are saturated, while some other projects are moving
 slower than the rest.

 I'd be willing to work on just about anything, it'll just take me some time
 to get up to speed.  I've programmed in Python for years using libraries
 like SQLAlchemy and Flask, I've just never worked with a CI/automated
 environment before.

 Any tips and points in the right direction would be greatly appreciated.


Take a look at http://solum.io and see if that interests you.

http://wiki.openstack.org/wiki/Solum

Thanks and Regards,
Noorul

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

[openstack-dev] [nova] Audit Log

[Noorul Islam K M]

Hello all,

I was looking for audit logs in nova. I found [1] but could not find the
launchpad entry audit-logging as mentioned in the wiki page.

Is this yet to be implemented or am I looking at the wrong place?

Regards,
Noorul

[1] https://wiki.openstack.org/wiki/AuditLogging

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

Re: [openstack-dev] [Solum] PTL Candidacy Open

[Noorul Islam K M]

Anita Kuno ante...@anteaya.info writes:

 On 05/27/2014 06:25 PM, Adrian Otto wrote:

 Team,
 
 If you would like to declare a candidacy for PTL for Solum, you may send an 
 email with the subject [Solum] Solum PTL Candidacy” to this mailing list 
 declaring your candidacy. Please respond with candidacy notices no later 
 than 00:00 UTC on 2014-06-02. 
 
 The following rules apply:
 
 https://wiki.openstack.org/wiki/Solum/Elections
 
 Thanks,
 
 Adrian
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 According to the election guidelines set out in the above wiki url, no
 candidate came forward for the Solum PTL position and the current PTL
 retains his position.

 https://review.openstack.org/#/admin/groups/231,members

 Congratulations to Adrian Otto!


Congratulations Adrian!

Regards,
Noorul

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

Re: [openstack-dev] WSME / Pecan and only supporting JSON?

[Noorul Islam K M]

Michael Davies mich...@the-davies.net writes:

 Hi everyone,

 Over in Ironic Land we're looking at removing XML support from ironic-api
 (i.e. https://bugs.launchpad.net/ironic/+bug/1271317)

 I've been looking, but I can't seem to find an easy way to modify the
 accepted content_types.

 Are there any wsgi / WSME / Pecan experts out there who can point me in the
 right direction?


Also in Solum we have a use case where in we would like to have
pecan+wsme accept content-type application/x-yaml.

It will be great if this can be made configurable.

Regards,
Noorul

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

Re: [openstack-dev] [Solum] Question about Zuul's role in Solum

[Noorul Islam K M]

devdatta kulkarni devdatta.kulka...@rackspace.com writes:

 Hi,

 I have been looking at Zuul for last few days and had a question
 about its intended role within Solum.

 From what I understand, Zuul is a code gating system.

 I have been wondering if code gating is something we are considering as a 
 feature
 to be provided in Solum? If yes, then Zuul is a perfect fit.
 But if not, then we should discuss what benefits do we gain by using Zuul
 as an integral part of Solum.

 It feels to me that right now we are treating Zuul as a conduit for 
 triggering job(s)
 that would do the following:
 - clone/download source
 - run tests
 - create a deployment unit (DU) if tests pass
 - upload DU to glance
 - trigger the DU deployment workflow

 In the language-pack working group we have talked about being able to do
 CI on the submitted code and building the DUs only after tests pass. 
 Now, there is a distinction between doing CI on merged code vs.
 doing it before code is permanently merged to master/stable branches.
 The latter is what a 'code gating' system does, and Zuul is a perfect fit for 
 this.
 For the former though, using a code gating system is not be needed.
 We can achieve the former with an API endpoint, a queue,
 and a mechanism to trigger job(s) that perform above mentioned steps.

 I guess it comes down to Solum's vision. If the vision includes supporting, 
 among other things, code gating
 to ensure that Solum-managed code is never broken, then Zuul is a perfect fit.
 Of course, in that situation we would want to ensure that the gating 
 functionality is pluggable
 so that operators can have a choice of whether to use Zuul or something else.
 But if the vision is to be that part of an overall application lifecycle 
 management flow which deals with
 creation and scaling of DUs/plans/assemblies but not necessarily be a code 
 gate, then we should re-evaluate Zuul's role
 as an integral part of Solum.

 Thoughts?


Is Zuul tightly couple with launchpad? I see that most of the
information that it displays is coming from launchpad.

If it is, is it a good idea to force launchpad on users?

Regards,
Noorul

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

Re: [openstack-dev] [keystone] Integrating with 3rd party DB

[Noorul Islam K M]

Jamie Lennox jamielen...@redhat.com writes:

 - Original Message -
 From: Noorul Islam K M noo...@noorul.com
 To: Dolph Mathews dolph.math...@gmail.com
 Cc: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Friday, 7 February, 2014 2:00:34 PM
 Subject: Re: [openstack-dev] [keystone] Integrating with 3rd party DB
 
 Dolph Mathews dolph.math...@gmail.com writes:
 
  On Thu, Feb 6, 2014 at 6:38 AM, Noorul Islam Kamal Malmiyoda 
  noo...@noorul.com wrote:
 
  Hello stackers,
 
  We have a database with tables users, projects, roles, etc. Is there
  any reference implementation or best practices to make keystone use
  this DB instead of its own?
 
 
  What's the problem you're having? Does the schema in this database differ
  from what keystone expects? What have you tried so far?
 
 
 I am trying to figure out the best way of integrating keystone with 3rd
 party database. I have been reading but I would like to get expert
 opinion on which is the best way of doing it.
 
 Regards,
 Noorul

 How obscure is this database? If it can integrate with SQLAlchemy then it's
 going to be relatively trivial and BY FAR the best approach. 


That database is accessible only using APIs. We have APIs to
authenticate users against this DB, read projects to which user has
access to, and roles to which user belongs to.

 If that's not going to work then your only other option is to implement the 
 database as its own backend for each of the managers. If you look through
 the folders in keystone (identity, credentials etc) you'll see a Driver class 
 for most of them that you will have to implement for your database. There 
 are examples of the sqlalchemy (and some LDAP) backends there that you can 
 work from. 


I will look at LDAP back-end code.

 I'd try to avoid the second case if you can avoid it. We've gotten better at 
 keeping the driver interface stable but you're going to have a constant 
 battle keeping interfaces and functionality up to date with the keystone
 code. 


So, if I understand correctly, in any case we need to modify keystone
code.

Thank you for the explanation.

Regards,
Noorul

 
 
 
  I have been reading
  https://wiki.openstack.org/wiki/Keystone/Federation/Blueprint but I
  could not find a open reference implementation for the same.
 
  Regards,
  Noorul
 
  ___
  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 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] [All] Python 3.3 gates are failing

[Noorul Islam K M]

Recently python3.3 jobs started failing. Noticed this in
python-solumclient project but it looks like a common problem.

python-solumclient

http://logs.openstack.org/72/57172/2/check/gate-python-solumclient-python33/8da814d/console.html

python-novaclient

http://logs.openstack.org/46/71846/1/check/gate-python-novaclient-python33/68bc48a/console.html

Regards,
Noorul

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

Re: [openstack-dev] a common client library

[Noorul Islam K M]

Doug Hellmann doug.hellm...@dreamhost.com writes:

 Several people have mentioned to me that they are interested in, or
 actively working on, code related to a common client library -- something
 meant to be reused directly as a basis for creating a common library for
 all of the openstack clients to use. There's a blueprint [1] in oslo, and I
 believe the keystone devs and unified CLI teams are probably interested in
 ensuring that the resulting API ends up meeting all of our various
 requirements.

 If you're interested in this effort, please subscribe to the blueprint and
 use that to coordinate efforts so we don't produce more than one common
 library. ;-)


Solum is already using it https://review.openstack.org/#/c/58067/

I would love to watch this space.

Regards,
Noorul

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

Re: [openstack-dev] [Solum] Devstack gate is failing

[Noorul Islam K M]

Anne Gentle a...@openstack.org writes:

 On Wed, Jan 8, 2014 at 8:26 AM, Noorul Islam Kamal Malmiyoda 
 noo...@noorul.com wrote:


 On Jan 8, 2014 6:11 PM, Sean Dague s...@dague.net wrote:
 
  On 01/07/2014 11:27 PM, Noorul Islam Kamal Malmiyoda wrote:
   On Wed, Jan 8, 2014 at 9:43 AM, Georgy Okrokvertskhov
   gokrokvertsk...@mirantis.com wrote:
   Should we rather revert patch to make gate working?
  
  
   I think it is always good to have test packages reside in
   test-requirements.txt. So -1 on reverting that patch.
  
   Here [1] is a temporary solution.
  
   Regards,
   Noorul
  
   [1] https://review.openstack.org/65414
 
  If Solum is trying to be on the road to being an OpenStack project, why
  would it go out of it's way to introduce an incompatibility in the way
  all the actual OpenStack packages work in the gate?
 
  Seems very silly to me, because you'll have to add oslo.sphinx back into
  test-requirements.txt the second you want to be considered for
 incubation.
 

 I am not sure why it seems silly to you. We are not anyhow removing
 oslo.sphinx from the repository. We are just removing it before installing
 the packages from test-requirements.txt

 in the devstack gate. How does that affects incubation? Am I missing
 something?


 Docs are a requirement, and contributor docs are required for applying for
 incubation. [1] Typically these are built through Sphinx and consistency is
 gained through oslo.sphinx, also eventually we can offer consistent
 extensions. So a perception that you're skipping docs would be a poor
 reflection on your incubation application. I don't think that's what's
 happening here, but I want to be sure you understand the consistency and
 doc needs.

 See also
 http://lists.openstack.org/pipermail/openstack-dev/2014-January/023582.htmlfor
 similar issues, we're trying to figure out the best solution. Stay
 tuned.


I have seen that, also posted solum issue [1] there yesterday. I started
this thread to have consensus on making solum devstack gate non-voting
until the issue gets fixed. Also proposed a temporary solution with
which we can solve the issue for the time being. Since the gate is
failing for all the patches, it is affecting every patch.

Regards,
Noorul

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-January/023618.html
[2] https://review.openstack.org/65414



 1.
 https://github.com/openstack/governance/blob/master/reference/incubation-integration-requirements

 Regards,
 Noorul

  -Sean
 
  --
  Sean Dague
  Samsung Research America
  s...@dague.net / sean.da...@samsung.com
  http://dague.net
 
 
  ___
  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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] [Climate] Oslo Policy and the best way for using it ?

[Noorul Islam K M]

Sylvain Bauza sylvain.ba...@bull.net writes:

 Le 15/11/2013 11:20, Julien Danjou a écrit :

 On Fri, Nov 15 2013, Sylvain Bauza wrote:

 Any help from Oslo mainteners ? Any doc in there ?
 You want to use the latest version from oslo-incubator, for sure.

 I think Ceilometer is good starting example as how to use it, as our
 policy usage is still minimal.

 Thanks for the reply,

 Digging into
 https://github.com/openstack/ceilometer/blob/master/ceilometer/api/acl.py for
 implementation but can't find where the unittests are.


Are you looking for [1]

Regards,
Noorul

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/tests/api/v2/test_acl_scenarios.py

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

[openstack-dev] [Solum] Version scheme

[Noorul Islam K M]

Hello all,

We need to decide on version scheme that we are going to use. 

Monty Taylor said the following in one of the comments for review [1]:

Setting a version here enrolls solum in managing its version in a
pre-release versioning manner, such that non-tagged versions will
indicated that they are leading up to 0.0.1. If that's the model solum
wants to do (similar to the server projects) then I recommend replacing
0.0.1 with 2014.1.0.

Regards,
Noorul

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

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

Re: [openstack-dev] [Solum] Version scheme

[Noorul Islam K M]

Monty Taylor mord...@inaugust.com writes:

 On 11/14/2013 10:36 AM, Murali Allada wrote:
 I'm not a big fan of using date information in the version number. Is
 there an advantage to doing that? Using a model like 0.0.1 makes it
 easier to communicate.
 
 A better approach might be to use  *Major.Minor.Revision.Build*. If we
 want to use dates, *Year.Month.Day.Build  or
 Year.**Minor.Revision.Build *might be a better approach.. Do any
 openstack projects use the build number in the version? or is there a
 way for the build process to insert the build number in there?

 To be clear, this isn't really a call to design a versioning scheme from
 scratch - there are two schemes currently in use, and solum should use
 one of them.

 The main reason to do 2014.1.0 is to align with OpenStack, so it depends
 on intent a little bit. The advantage to the Year.Minor.Revision is
 that, since OpenStack is on a date-based release cycle, it communicates
 that fact.

 The main reason to do a semver style Major.Minor.Patch scheme is to
 communicate api changes across releases. This is the reason we release
 our libraries using that scheme.

 In terms of mechanics, the way it works for both schemes is that the
 version produced is based on git tags. If a revision is tagged, that is
 the version that is produced in the tarball.

 If a version is NOT tagged, there are two approaches.

 Since the date-based versions have a predictable next version, we have
 intermediary versions marked as leading up to that version.
 Specifically, the form is:

 %(version_in_setup_cfg)s.dev%(num_revisions_since_last_tag)s.g%(git_short_sha)

 the dev prefix is a PEP440 compliant indiciation that this is a
 development version that is leading towards the version indicated.

 For semver-based versions, intermediary versions are marked as following
 the previous release. So we get:

 %(most_recent_tag)s.%(num_revisions_since_last_tag)s.g%(git_short_sha)s

 I would honestly recommend aligning with OpenStack and putting 2014.1.0
 into the setup.cfg version line for solum itself and doing date-based
 releases. For python-solumclient, since it's a library, I recommend not
 listing a version in setup.cfg and doing semver-based versions. This way
 you'll be operating in the same way as the rest of the project.


Thank you for explaining in detail. This is insightful!

Regards,
Noorul

 
 On Nov 14, 2013, at 8:23 AM, Noorul Islam K M noo...@noorul.com
 mailto:noo...@noorul.com
  wrote:
 

 Hello all,

 We need to decide on version scheme that we are going to use.

 Monty Taylor said the following in one of the comments for review [1]:

 Setting a version here enrolls solum in managing its version in a
 pre-release versioning manner, such that non-tagged versions will
 indicated that they are leading up to 0.0.1. If that's the model solum
 wants to do (similar to the server projects) then I recommend replacing
 0.0.1 with 2014.1.0.

 Regards,
 Noorul

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

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto: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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Command Line Interface for Solum

[Noorul Islam K M]

Angus Salkeld asalk...@redhat.com writes:

 On 14/11/13 13:32 +0530, Noorul Islam Kamal Malmiyoda wrote:

On Nov 14, 2013 1:10 PM, Adrian Otto adrian.o...@rackspace.com wrote:

 Noorul,

 On Nov 13, 2013, at 7:43 PM, Noorul Islam K M noo...@noorul.com
  wrote:

  Doug Hellmann doug.hellm...@dreamhost.com writes:
 
  On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.com
wrote:
 
 
  Hello all,
 
  I registered a new blueprint [1] for command line client interface for
  Solum. We need to decide whether we should have a separate repository
  for this or go with new unified CLI framework [2]. Since Solum is not
  part of OpenStack I think it is not the right time to go with the
  unified CLI.
 
 
  One of the key features of the cliff framework used for the unified
command
  line app is that the subcommands can be installed independently of the
main
  program. So you can write plugins that work with the openstack client,
but
  put them in the solum client library package (and source repository).
That
  would let you, for example:
 
   $ pip install python-solumclient
   $ pip install python-openstackclient
   $ openstack solum make me a paas
 
  Dean has done a lot of work to design a consistent
noun-followed-by-verb
  command structure, so please look at that work when picking subcommand
  names (for example, you shouldn't use solum as a prefix as I did in my
  example above, since we are removing the project names from the
commands).
 
 
  I think we should follow this. If others have no objection, I will
  submit a review to openstack-infra/config to create a new repository
  named python-solumclient with intial code from cookiecutter template.
 
  Adrian,
 
  Does this blue-print require to be in Approved state to perform
  above task?

 Thanks for the enthusiasm! I'd like further input from additional team
members before advancing on this.


I think whichever path we take a separate repository is required.

 Yip, no harm making the new repo IMO.


Here [1] it is.

Regards,
Noorul

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

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

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Noorul Islam K M]

Jay Lau jay.lau@gmail.com writes:

 Hi,

 I noticed that we are now using mock, mox and stub for unit test, just
 curious do we have any guidelines for this, in which condition shall we use
 mock, mox or stub?


There is already a blueprint [1] in Nova project to replace Mox with mock.

Also it has a link to ML thread [2].

Regards,
Noorul

[1] https://blueprints.launchpad.net/nova/+spec/mox-to-mock-conversion
[2] http://lists.openstack.org/pipermail/openstack-dev/2013-July/012484.html

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

Re: [openstack-dev] [Solum] Choice of API infrastructure

[Noorul Islam K M]

Doug Hellmann doug.hellm...@dreamhost.com writes:

 On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 11/02/2013 11:26 PM, Russell Bryant wrote:

 On 11/02/2013 11:54 AM, Adrian Otto wrote:

 Noorul,

 I agree that key decisions should be tracked in blueprints. This is the
 one for this decision which was made in our 2013-10-18 public meeting.
 Jay's submission is consistent with the direction indicated by the team.

 https://blueprints.launchpad.net/solum/+spec/rest-api-base

 Transcript log:
 http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html
 http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html


 Heh, not much discussion there.  :-)


 Agreed. I actually didn't know anything about the discussion -- I wasn't
 at the meeting. I just figured I would throw some example code up to Gerrit
 that shows how Falcon can be used for the API plumbing. Like I mentioned in
 a previous email, I believe it's much easier to discuss things when there
 is sample code...


  Here's my take ... Pecan+WSME has been pushed as the thing to
 standardize on across most OpenStack APIs.  Ceilometer (and maybe
 others?) are already using it.  Others, such as Nova, are planning to
 use it this cycle. [1][2]


 I've used both actually, and I've come to prefer Falcon because of its
 simplicity and specifically because of the following things:

 * It's lack of integration with WSME, which I don't care for. I don't care
 for WSME because I believe it tries to put the model at the view layer,
 instead of where it belongs, at the model layer.


 The models defined in WSME are completely different from the database
 models, and should not be used outside of the API code. Think of them as
 declaring the models for the consumer of the API, rather than the
 implementer of the API.

 The benefits of declaring WSME classes include automatic serialization in
 JSON and XML, generating WADL files to be included in the API docs (work is
 already happening to make this available for everyone), and consistent
 input and output types for API endpoints (making it easier for consumers of
 the API to use it and for implementers to validate inputs and assume
 consistent defaults).

 And, to be clear, Pecan and WSME are integrated by Pecan can definitely be
 used without WSME. I included WSME in the proposal to replace the
 home-grown WSGI framework because I thought it added significant benefits,
 but it is not going to be appropriate for all situations (streaming large
 image files is one example).


 * It doesn't need a configuration file, specifically a configuration file
 that is a Python file as opposed to an .ini file.


 Pecan does not require a configuration file. It can use one, but we set up
 the WSGI app factory in ceilometer to not use one and I expect the other
 projects to work the same way.



I see that in ceilometer project has both pypy and py33 gates switched
off. Is this because of Pecan + WSME? From one of the conversations on
IRC, it looks like Solum project would like to be py33 compatible from
the beginning.

Having said that, pecan fails to install on pypy and py33. See
https://review.openstack.org/#/c/55083

Thanks and Regards
Noorul

 Tuesday (today) at 2:00 there is a session in the Oslo track (
 http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee)
 to discuss tips and pain points with Pecan  WSME. I didn't intend to
 revisit the decision to start adopting either (we've spent an hour at each
 of the last summits going over that, as well as many email threads), but I
 do want to clear up any other misconceptions and discuss issues with either
 tool so that feedback can be incorporated upstream. Now that both Pecan and
 WSME are on stackforge, we have already had a few patches from OpenStack
 developers intended to improve and adjust them to meet our needs better.

 Doug




  I care less about the particular choice and more about consistency.  It
 brings a lot of value, such as making it a lot easier for developers to
 jump around between the OpenStack projects.  Can we first at least agree
 that there is value in standardizing on *something* for most OpenStack
 APIs?


 I completely understand the need for consistency. I pushed my patch as an
 example of how to do things the Falcon way. While I would prefer Falcon
 over Pecan (and certainly over Pecan+WSME), I will respect the push towards
 consistency if that's what is most important.

 That said, I also believe that the projects in Stackforge should be the
 laboratories of experiment, and these projects may serve as a good
 playground for various implementations of things. I remind the reader that
 over time, the development community has standardized on various things,
 only to find a better implementation in an incubated project. Pecan+WSME is
 actually an example of that experimentation turned accepted standard.


 Best,
 -jay


  I understand that there may be cases where the needs for an API justify
 

Re: [openstack-dev] [Solum] Choice of API infrastructure

[Noorul Islam K M]

Russell Bryant rbry...@redhat.com writes:

 On 11/02/2013 11:54 AM, Adrian Otto wrote:

 Noorul,
 
 I agree that key decisions should be tracked in blueprints. This is the
 one for this decision which was made in our 2013-10-18 public meeting.
 Jay's submission is consistent with the direction indicated by the team.
 
 https://blueprints.launchpad.net/solum/+spec/rest-api-base
 
 Transcript log:
 http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html
 http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html

 Heh, not much discussion there.  :-)

 Here's my take ... Pecan+WSME has been pushed as the thing to
 standardize on across most OpenStack APIs.  Ceilometer (and maybe
 others?) are already using it.  Others, such as Nova, are planning to
 use it this cycle. [1][2]

 I care less about the particular choice and more about consistency.  It
 brings a lot of value, such as making it a lot easier for developers to
 jump around between the OpenStack projects.  Can we first at least agree
 that there is value in standardizing on *something* for most OpenStack APIs?

 I understand that there may be cases where the needs for an API justify
 being different.  Marconi being more of a data-plane API vs
 control-plane means that performance concerns are much higher, for example.

 If we agree that consistency is good, does Solum have needs that make it
 different than the majority of OpenStack APIs?  IMO, it does not.

 Can someone lay out a case for why all OpenStack projects should be
 using Falcon, if that's what you think Solum should use?

 Also, is anyone willing to put up the equivalent of Jay's review [3],
 but with Pecan+WSME, to help facilitate the discussion?


I will work on this and submit one.

Regards,
Noorul

 [1]
 http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee
 [2]
 http://icehousedesignsummit.sched.org/event/4a7316a4f5c6f783e362cbba2644bae2
 [3] https://review.openstack.org/#/c/55040/

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

Re: [openstack-dev] [Solum] Stackforge Repo Ready

[Noorul Islam K M]

Noorul Islam K M noo...@noorul.com writes:

 Adrian Otto adrian.o...@rackspace.com writes:

 Team,

 Our StackForge code repo is open, so you may begin submitting code for 
 review. For those new to the process, I made a will page with links to the 
 repo and information about how to contribute:

 https://wiki.openstack.org/wiki/Solum/Contributing


 1. .gitreview file is missing, so I submitted a patch 

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

 This patch also contains update to README to include relevant project
 information.

 2. My review request got rejected by Jenkins. A re-base against [1] is
not helping.

 3. Github repo [2] is behind [1]. It is not mirrored yet?


I cross verified and it looks like they are in sync. Also I think this
is the first review after the initial repository setup. Did we miss
anything that is causing Jenkins to fail?

Thanks and Regards
Noorul


 [1] git://git.openstack.org/stackforge/solum
 [2] https://github.com/stackforge/solum

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

[openstack-dev] [Solum] Dissecting the very first review

[Noorul Islam K M]

Now we have the first patch [1] merged into the repository using
OpenStack review process. I would like to bring into notice some minor
issues.

First of all I would like to thank [2] Swapnil for fixing the patch.

1. Look at patch set 3 and it changed the Author and also the Committer. I
   am not sure how that happened. I have been using gerrit outside of
   OpenStack and I never saw something like that.

2. Another strange part is that, the author date is Oct 1, 2013 12:53 PM

Also an ideal process for helping with others patch is discussed in [2].

Regards,
Noorul

[1] https://review.openstack.org/#/c/54877/
[2] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html

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

[openstack-dev] [Solum] Tracking technology choices using blue prints

[Noorul Islam K M]

I was looking at the review [1]. And at that point I vaguely remembered
a discussion on IRC about framework choice for WSGI. But those
discussions are not captured in document and brought to conclusion. So,
I think it will be great, if we create blue print for all technology
choices.

Any thoughts on this?

Regards,
Noorul

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

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

Re: [openstack-dev] [Solum] Dissecting the very first review

[Noorul Islam K M]

Clark Boylan clark.boy...@gmail.com writes:

 On Fri, Nov 1, 2013 at 6:29 PM, Noorul Islam K M noo...@noorul.com wrote:


 Now we have the first patch [1] merged into the repository using
 OpenStack review process. I would like to bring into notice some minor
 issues.

 First of all I would like to thank [2] Swapnil for fixing the patch.

 1. Look at patch set 3 and it changed the Author and also the Committer. I
am not sure how that happened. I have been using gerrit outside of
OpenStack and I never saw something like that.

 2. Another strange part is that, the author date is Oct 1, 2013 12:53 PM

 Also an ideal process for helping with others patch is discussed in [2].

 Regards,
 Noorul

 [1] https://review.openstack.org/#/c/54877/
 [2] 
 http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html

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

 The Author, Committer, and Date are determined by the local git making
 the commit. Gerrit is just displaying what was pushed to it. As a
 reviewer if those items are important you can ask the author of a
 patchset to push a new patchset that includes updated and potentially
 more correct information. This may involve correcting local settings
 (eg system clock) or you can override the values by passing the
 '--author' and '--date' options to `git commit`.


The point I am trying to make is that, these things should be looked
into before the patch gets merged.

Thanks and Regards
Noorul

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

Re: [openstack-dev] [Solum] Stackforge Repo Ready

[Noorul Islam K M]

Adrian Otto adrian.o...@rackspace.com writes:

 Team,

 Our StackForge code repo is open, so you may begin submitting code for 
 review. For those new to the process, I made a will page with links to the 
 repo and information about how to contribute:

 https://wiki.openstack.org/wiki/Solum/Contributing


1. .gitreview file is missing, so I submitted a patch 

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

This patch also contains update to README to include relevant project
information.

2. My review request got rejected by Jenkins. A re-base against [1] is
   not helping.

3. Github repo [2] is behind [1]. It is not mirrored yet?

Regards,
Noorul

[1] git://git.openstack.org/stackforge/solum
[2] https://github.com/stackforge/solum

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

Re: [openstack-dev] Newbie python novaclient question

[Noorul Islam K M]

Alex la6...@gmail.com writes:

 Thank you Noorul. I looked at the review. My question is that in 
 openstackcomputeshell.main which line call the v1_1/ shell.py.function?


I would look at get_subcommand_parser() method.

Thanks and Regards
Noorul



 On Oct 10, 2013, at 9:03 PM, Noorul Islam K M noo...@noorul.com wrote:

 A L la6...@gmail.com writes:
 
 Dear Openstack Dev Gurus,
 
 I am trying to understand the python novaclient code. Can someone please
 point me to where in openstackcomputeshell class in shell.py does the
 actual function or class related to an argument gets called?
 
 
 This review [1] is something I submitted and it adds a sub command. May
 be this will give you some clue.
 
 [1] https://review.openstack.org/#/c/40181/
 
 Thanks and Regards
 Noorul

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

Re: [openstack-dev] Newbie python novaclient question

[Noorul Islam K M]

Alex la6...@gmail.com writes:

 Yes , this method seems to look for the corresponding action but still 
 doesn't seem to be the one actually calling them.


Are you looking for this which is inside **main** method?

args = subcommand_parser.parse_args(argv)

Thanks and Regards
Noorul

 Regards
 Al



 On Oct 10, 2013, at 11:07 PM, Noorul Islam K M noo...@noorul.com wrote:

 Alex la6...@gmail.com writes:
 
 Thank you Noorul. I looked at the review. My question is that in 
 openstackcomputeshell.main which line call the v1_1/ shell.py.function?
 
 
 I would look at get_subcommand_parser() method.
 
 Thanks and Regards
 Noorul
 
 
 
 On Oct 10, 2013, at 9:03 PM, Noorul Islam K M noo...@noorul.com wrote:
 
 A L la6...@gmail.com writes:
 
 Dear Openstack Dev Gurus,
 
 I am trying to understand the python novaclient code. Can someone please
 point me to where in openstackcomputeshell class in shell.py does the
 actual function or class related to an argument gets called?
 
 
 This review [1] is something I submitted and it adds a sub command. May
 be this will give you some clue.
 
 [1] https://review.openstack.org/#/c/40181/
 
 Thanks and Regards
 Noorul

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

Re: [openstack-dev] Newbie python novaclient question

[Noorul Islam K M]

A L la6...@gmail.com writes:

 Dear Openstack Dev Gurus,

 I am trying to understand the python novaclient code. Can someone please
 point me to where in openstackcomputeshell class in shell.py does the
 actual function or class related to an argument gets called?


This review [1] is something I submitted and it adds a sub command. May
be this will give you some clue.

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

Thanks and Regards
Noorul

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

Re: [openstack-dev] what is the code organization of nova

[Noorul Islam K M]

Aparna Datt aparna.cl...@gmail.com writes:

 hi i was going through code of nova on github...but there are no readme
 files available regarding code organization of nova. Can anyone provide me
 with a link from where i can begin reading the code ? or if anyone can help
 me by indicators on from which files / folders the nova begins its
 processing?


Apart from what others pointed, I suggest to take a look at this.

http://www.youtube.com/watch?v=P4OU-rOQ4as

Thanks and Regards
Noorul

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

Re: [openstack-dev] Help needed in installing xmlsec1 python library

[Noorul Islam K M]

D.Selvaraj ds...@kent.ac.uk writes:

 Hi Stackers,

 Can someone please suggest me with an easy way to download Xmlsec module in 
 my unix environment ? I have downloaded it but I am not able to install it. 
 When I click make it shows an error stating there is no make available. 
 Please help



More information will be helpful to provide concrete answers.

1. Which version of Unix?
2. Where did you download the package from?
3. What are the steps you followed?

Thanks and Regards
Noorul

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

Re: [openstack-dev] can't install devstack - nova-api did not start

[Noorul Islam K M]

XINYU ZHAO xyzje...@gmail.com writes:

 Hi Sean
 I uninstalled the oslo.config 1.1.1 version and run devstack, but this time
 it stopped at

 2013-08-09 18:55:16 + /opt/stack/new/keystone/bin/keystone-manage db_sync
 2013-08-09 18:55:16 Traceback (most recent call last):
 2013-08-09 18:55:16   File
 /opt/stack/new/keystone/bin/keystone-manage, line 16, in module
 2013-08-09 18:55:16 from keystone import cli
 2013-08-09 18:55:16   File /opt/stack/new/keystone/keystone/cli.py,
 line 23, in module
 2013-08-09 18:55:16 from oslo.config import cfg
 2013-08-09 18:55:16 ImportError: No module named config
 2013-08-09 18:55:16 + [[ PKI == \P\K\I ]]


 An unexpected error prevented the server from fulfilling your request.
 (ProgrammingError) (1146, Table 'keystone.service' doesn't exist) 'INSERT
 INTO service (id, type, extra) VALUES (%s, %s, %s)'
 ('32578395572b4cf2a70ba70b6031cd1d', 'identity', '{name: keystone,
 description: Keystone Identity Service}') (HTTP 500)
 2013-08-12 18:36:45 + KEYSTONE_SERVICE=
 2013-08-12 18:36:45 + keystone endpoint-create --region RegionOne
 --service_id --publicurl http://127.0.0.1:5000/v2.0 --adminurl
 http://127.0.0.1:35357/v2.0 --internalurl http://127.0.0.1:5000/v2.0

 it seems that  oslo.config was not properly imported after i re-installed
 it.
 but when i list the pip installations, it is there.

 /usr/local/bin/pip freeze |grep oslo.config
 -e git+
 http://10.145.81.234/openstackci/gerrit/p/oslo.config@c65d70c02494805ce50b88f343f8fafe7a521724#egg=oslo.config-master
 root@devstack-4:/# /usr/local/bin/pip search oslo.config
 oslo.config   - Oslo configuration API
   INSTALLED: 1.2.0.a192.gc65d70c
   LATEST:1.1.1




Please paste the output of 

pip show oslo.config

Thanks and Regards
Noorul


 On Sat, Aug 10, 2013 at 7:07 AM, Sean Dague s...@dague.net wrote:

 Silly pip, trix are for kids.

 Ok, well:

 sudo pip install -I oslo.config==1.1.1

 then pip uninstall oslo.config

 On 08/09/2013 06:58 PM, Roman Gorodeckij wrote:

 stack@hp:~/devstack$ sudo pip install oslo.config
 Requirement already satisfied (use --upgrade to upgrade): oslo.config in
 /opt/stack/oslo.config
 Requirement already satisfied (use --upgrade to upgrade): six in
 /usr/local/lib/python2.7/dist-**packages (from oslo.config)
 Cleaning up...
 stack@hp:~/devstack$ sudo pip uninstall oslo.config
 Can't uninstall 'oslo.config'. No files were found to uninstall.
 stack@hp:~/devstack$

 stack@hp:~/devstack$ cat /tmp/devstack/log//screen-n-**api.log
 | touch /opt/stack/status/stack/n-**api.failurenova 
 /usr/local/bin/nova-api |

 Traceback (most recent call last):
File /usr/local/bin/nova-api, line 6, in module
  from nova.cmd.api import main
File /opt/stack/nova/nova/cmd/api.**py, line 29, in module
  from nova import config
File /opt/stack/nova/nova/config.**py, line 22, in module
  from nova.openstack.common.db.**sqlalchemy import session as
 db_session
File 
 /opt/stack/nova/nova/**openstack/common/db/**sqlalchemy/session.py,
 line 279, in module
  deprecated_opts=[cfg.**DeprecatedOpt('sql_connection'**,
 AttributeError: 'module' object has no attribute 'DeprecatedOpt'

 nothing changed.

 On Aug 9, 2013, at 6:11 PM, Sean Dague s...@dague.net wrote:

  This should be addressed by the latest devstack, however because we
 moved to oslo.config out of git, some install environments might still have
 oslo.config 1.1.0 somewhere, that pip no longer sees (so can't uninstall)

 sudo pip install oslo.config
 sudo pip uninstall oslo.config

 rerun devstack, see if it works.

 -Sean

 On 08/09/2013 09:14 AM, Roman Gorodeckij wrote:

 Tried to install devstack to dedicated server, ip's are defined.

 Here's the output:

 13-08-09 09:06:28 ++ echo -ne '\015'

 2013-08-09 09:06:28 + NL=$'\r'
 2013-08-09 09:06:28 + screen -S stack -p n-api -X stuff 'cd
 /opt/stack/nova  /'sr/local/bin/nova-api || touch
 /opt/stack/status/stack/n-**api.failure
 2013-08-09 09:06:28 + echo 'Waiting for nova-api to start...'
 2013-08-09 09:06:28 Waiting for nova-api to start...
 2013-08-09 09:06:28 + wait_for_service 60http://192.168.1.6:8774
 2013-08-09 09:06:28 + local timeout=60
 2013-08-09 09:06:28 + local url=http://192.168.1.6:8774
 2013-08-09 09:06:28 + timeout 60 sh -c 'while ! http_proxy=
 https_proxy= curl -shttp://192.168.1.6:8774  /dev/null; do sleep 1;
 done'
 2013-08-09 09:07:28 + die 698 'nova-api did not start'
 2013-08-09 09:07:28 + local exitcode=0
 stack@hp:~/devstack$ 2013-08-09 09:07:28 + set +o xtrace

 Here's the log:

 2013-08-09 09:07:28 [ERROR] ./stack.sh:698 nova-api did not start
 stack@hp:~/devstack$ cat /tmp/devstack/log//screen-n-**api.log
 t/stack/status/stack/n-api.**failurenova  /usr/local/bin/nova-api
 || touch /op

 Traceback (most recent call last):
File /usr/local/bin/nova-api, line 6, in module
  from nova.cmd.api import main
File /opt/stack/nova/nova/cmd/api.**py, line 29, in module
  from nova import config
File 

Re: [openstack-dev] Any one can help on nova source hacking?

[Noorul Islam K M]

Zhang, Li ((Victor,ES-OCTO-HCC-CHINA-BJ)) li.zhan...@hp.com writes:

 Dear stackers,

 Recently, I am planning to hack the source of the nova project, it is really 
 a huge project in openstack!

 I got lost in  where to start from, anybody out there can give a hint
 on this?

I also started recently.

1. First thing I did is to go through 'Contribute to OpenStack' section
   in the wiki page https://wiki.openstack.org/wiki/Main_Page

2. docs.openstack.org also has several documentations.

3. For nova https://launchpad.net/nova page has links to more documents.
   If you are looking at low level API documentation here it is 

   http://docs.openstack.org/developer/nova/devref/index.html

4. The following links were also helpful

   http://www.sandywalsh.com/2012/04/openstack-nova-internals-pt1-overview.html

   http://www.sandywalsh.com/2012/09/openstack-nova-internals-pt2-services.html

   After this there were no follow-up articles.

5. This document is very high level but has a comprehensive diagram in
   it 

   http://www.sandywalsh.com/2012/09/openstack-nova-internals-pt2-services.html

I hope this helps. If you find anything interesting, let me know.

Thanks and Regards
Noorul

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

Re: [openstack-dev] [Nova] nova-api won't start in devstack

[Noorul Islam K M]

Edgar Magana emag...@plumgrid.com writes:

 I found the problem:
 python-boto and python-cmd2 had the wrong version.

 I have already installed those libraries.

Remove them, they are installed using pip (at least python-cmd2) I
believe.

Thanks and Regards
Noorul


 Cheers,

 Edgar

 From:  Edgar Magana emag...@plumgrid.com
 Date:  Tuesday, August 6, 2013 11:33 AM
 To:  OpenStack List openstack-dev@lists.openstack.org
 Subject:  [Nova] nova-api won't start in devstack

 I just downloaded devstack and I am getting this error:

 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last):
 2013-08-06 11:28:28.938 TRACE nova   File /usr/local/bin/nova-api, line
 10, in module
 2013-08-06 11:28:28.938 TRACE nova sys.exit(main())
 2013-08-06 11:28:28.938 TRACE nova   File /opt/stack/nova/nova/cmd/api.py,
 line 51, in main
 2013-08-06 11:28:28.938 TRACE nova server = service.WSGIService(api,
 use_ssl=should_use_ssl)
 2013-08-06 11:28:28.938 TRACE nova   File /opt/stack/nova/nova/service.py,
 line 311, in __init__
 2013-08-06 11:28:28.938 TRACE nova self.app = self.loader.load_app(name)
 2013-08-06 11:28:28.938 TRACE nova   File /opt/stack/nova/nova/wsgi.py,
 line 488, in load_app
 2013-08-06 11:28:28.938 TRACE nova return deploy.loadapp(config:%s %
 self.config_path, name=name)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in
 loadapp
 2013-08-06 11:28:28.938 TRACE nova return loadobj(APP, uri, name=name,
 **kw)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in
 loadobj
 2013-08-06 11:28:28.938 TRACE nova return context.create()
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in
 create
 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in
 invoke
 2013-08-06 11:28:28.938 TRACE nova **context.local_conf)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in
 fix_call
 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw)
 2013-08-06 11:28:28.938 TRACE nova   File
 /opt/stack/nova/nova/api/openstack/urlmap.py, line 160, in urlmap_factory
 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(app_name,
 global_conf=global_conf)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in
 get_app
 2013-08-06 11:28:28.938 TRACE nova name=name,
 global_conf=global_conf).create()
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in
 create
 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in
 invoke
 2013-08-06 11:28:28.938 TRACE nova **context.local_conf)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in
 fix_call
 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw)
 2013-08-06 11:28:28.938 TRACE nova   File
 /opt/stack/nova/nova/api/auth.py, line 59, in pipeline_factory
 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(pipeline[-1])
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in
 get_app
 2013-08-06 11:28:28.938 TRACE nova name=name,
 global_conf=global_conf).create()
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in
 create
 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 146, in
 invoke
 2013-08-06 11:28:28.938 TRACE nova return fix_call(context.object,
 context.global_conf, **context.local_conf)
 2013-08-06 11:28:28.938 TRACE nova   File
 /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in
 fix_call
 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw)
 2013-08-06 11:28:28.938 TRACE nova   File
 /opt/stack/nova/nova/api/openstack/__init__.py, line 251, in factory
 2013-08-06 11:28:28.938 TRACE nova return cls()
 2013-08-06 11:28:28.938 TRACE nova   File
 /opt/stack/nova/nova/api/openstack/compute/__init__.py, line 141, in
 __init__
 2013-08-06 11:28:28.938 TRACE nova super(APIRouterV3,
 self).__init__(init_only)
 2013-08-06 11:28:28.938 TRACE nova   File
 /opt/stack/nova/nova/api/openstack/__init__.py, line 323, in __init__
 2013-08-06 11:28:28.938 TRACE nova missing_apis=missing_core_extensions)
 2013-08-06 11:28:28.938 TRACE nova CoreAPIMissing: Core API extensions are
 missing: set(['flavors', 'limits', 

Re: [openstack-dev] OpenStack Requirements

[Noorul Islam K M]

Yijing Zhang traceyzh...@siu.edu writes:

 Hello,

 I'd like you to do a OpenStack Requirements code review. The reason I send
 this request is another patch of mine is depends on whether this one patch
 get approved.

 Please visit https://review.openstack.org/#/c/38429/



I am new here. Is it required to inform mailing list for reviewing. I
thought Gerrit takes care of that.

Regards,
Noorul
 Regards and best wishes,

 Yijing Zhang
 ___
 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