date:20131111

On 11/11/2013 03:13 AM, Rahul M R wrote:
> Hi all,
> 
> I'm new to this mailing list :)
> 
> I am currently working on the Snabbswitch project < 
> https://github.com/SnabbCo/snabbswitch/wiki >. We are developing an OpenStack 
> Neutron plugin (targeting Icehouse release). Snabbswitch makes use of an 
> experimental patch to QEMU (not merged to mainline yet) that adds support for 
> a user-space PCI device. This device is not supported by the libvirt XML 
> (yet). So, in order to use this feature, some command line arguments will 
> have to be passed to QEMU when booting an instance.
> 
> Therefore, I'd like to make a proposal for enabling a libvirt feature: 
> pass-through of QEMU command line args < 
> http://libvirt.org/drvqemu.html#qemucommand >. This will allow us to boot 
> instances with the necessary QEMU command line arguments.
> 
> Now regarding the implementation of this feature, currently the plan is as 
> follows:
> 
> 1. Add metadata when creating an instance using the nova boot API. For e.g.: 
> libvirt_qemu_cli_args=["-arg1", "-arg2"]
> 
> 2. The libvirt driver will process the instance's metadata and generate the 
> necessary XML (for the instance's libvirt.xml). For e.g.:
> 
> 
> ...
> 
>-arg1
>-arg2
> 
> ...
> 
> 
> 
> I'd love to get some feedback regarding the above proposal.
> Also, are there any specific requirements for making a Nova Blueprint (i.e., 
> equivalent of < https://wiki.openstack.org/wiki/Neutron/BlueprintTemplate > )?
> 
> We would like to have this feature included in Icehouse release.
> 
> Thanks in advance.

This sounds like it may be reasonable for testing, but for something to
get merged, I'd like to see it done "right".  I don't think exposing
qemu command line arguments directly to the API user is something we
would ever want to do.

That would mean getting patches merged upstream so the feature is
exposed to us properly via libvirt xml.  Then we can look at the right
way to expose it via nova.

-- 
Russell Bryant

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

Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !!

On 11/04/2013 08:25 PM, Roshan Agrawal wrote:
> The community site for Solum has gone live! www.Solum.io
>   - this is a landing page for all things Solum
> related.
> 
> Also check out the blog section on the site. 
> 
> The logo: is a placeholder for now. We are working on a cool new logo -
> but the placeholder right now isn't too bad either, is it?

One nit, instead of linking to github, it would be better to link to
OpenStack's git interface since that's what we're trying to provide as
the canonical repo now.

http://git.openstack.org/cgit/stackforge/solum

-- 
Russell Bryant

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

Re: [openstack-dev] Request for review

2013-11-11 Thread Flavio Percoco


On 11/11/13 09:07 +0100, Matthias Runge wrote:

On 11/09/2013 11:45 AM, Michael Bright wrote:


Could someone review this please, it's a small patch but has taken a
while ...
https://review.openstack.org/#/c/51263/


It would be very helpful, if you'd mention the project (in this case
nova), in the subject line.



I'd prefer folks not sending review requests to the mailing list,
unless the patch is essential, in which case a better explanation of
why it is essential and what the patch does would definitely be worth
it.

All core contributors receive notification emails and monitor the
patches upstream.

Cheers,
FF

--
@flaper87
Flavio Percoco

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

[openstack-dev] [Openstack] [Trove] Backups Amazon like

2013-11-11 Thread Giuseppe Galeota

Dear all,
the Relational Database service for Amazon talk about:

   - Automated Backups – Turned on by default, the automated backup feature
   of Amazon RDS enables point-in-time recovery for your DB Instance. Amazon
   RDS will backup your database and transaction logs and store both for a
   user-specified retention period. This allows you to restore your DB
   Instance to any second during your retention period, up to the last five
   minutes. Your automatic backup retention period can be configured to up to
   thirty five days.


   - DB Snapshots – DB Snapshots are user-initiated backups of your DB
   Instance. These full database backups will be stored by Amazon RDS until
   you explicitly delete them. You can create a new DB Instance from a DB
   Snapshot whenever you desire.


Does it exist a Trove project for Automated backups?

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

Re: [openstack-dev] [Nova] Enabling libvirt feature: pass-through of QEMU command line args

2013-11-11 Thread Daniel P. Berrange

On Mon, Nov 11, 2013 at 01:43:59PM +0530, Rahul M R wrote:
> Hi all,
> 
> I'm new to this mailing list :)
> 
> I am currently working on the Snabbswitch project < 
> https://github.com/SnabbCo/snabbswitch/wiki >. We are developing an OpenStack 
> Neutron plugin (targeting Icehouse release). Snabbswitch makes use of an 
> experimental patch to QEMU (not merged to mainline yet) that adds support for 
> a user-space PCI device. This device is not supported by the libvirt XML 
> (yet). So, in order to use this feature, some command line arguments will 
> have to be passed to QEMU when booting an instance.
> 
> Therefore, I'd like to make a proposal for enabling a libvirt feature: 
> pass-through of QEMU command line args < 
> http://libvirt.org/drvqemu.html#qemucommand >. This will allow us to boot 
> instances with the necessary QEMU command line arguments.
> 
> Now regarding the implementation of this feature, currently the plan is as 
> follows:
> 
> 1. Add metadata when creating an instance using the nova boot API. For e.g.: 
> libvirt_qemu_cli_args=["-arg1", "-arg2"]
> 
> 2. The libvirt driver will process the instance's metadata and generate the 
> necessary XML (for the instance's libvirt.xml). For e.g.:
> 
> 
> ...
> 
>-arg1
>-arg2
> 
> ...
> 
> 
> 
> I'd love to get some feedback regarding the above proposal.

The QEMU command line passthrough feature is only intended for adhoc testing.
Anything that is intended to be supported for production deployments must
have explicit support in the XML config, so I'd reject any patch that attempts
to add use of QEMU command line passthrough in Nova. That the feature is also
not even accepted in upstream QEMU is another mark against merging it.

So if you want this feature in OpenStack, you'll need to focus on getting
the code merged into upstream QEMU and get any neccessary support into
libvirt if none of the existing network configs are suitable. Once that is
done we can look at OpenStack patches to enable it.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [horizon] User registrations

2013-11-11 Thread Shake Chen

the most important is the user can get back password, modify own email
address.




On Mon, Nov 11, 2013 at 2:31 PM, Lyle, David  wrote:

> I think there is certainly interest.  I do think it will need to be highly
> configurable to be useful.  The problem, as Dolph points out, is that each
> deployment has its own workflow.
>
> Points of configuration:
> -Does the local keystone deployment policy support self-registration?  The
> default is no.  So, at that point access to self-registration should be
> hidden.
>
> -How many steps are required in the registration process?
>
> -Is payment information required?  Address?
>
> -How is the registration confirmed, email, text, ?
>
> -CAPTCHA?
>
> I think the two main reasons such a facility is not present in Horizon are:
> 1. Until recently determining keystone's access policy was not possible.
> 2. The actual implementation is highly deployment dependent.
>
> -David
>
> From: Dolph Mathews [mailto:dolph.math...@gmail.com]
> Sent: Monday, November 11, 2013 8:57 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [horizon] User registrations
>
> So, there's a bunch of use case questions here where I suspect there are
> no correct answers (so preferences will vary per deployment). The first
> ones that come to mind-
>
> Are the users accessing this web form trusted or untrusted?
>
> Do they need to be verified, somehow? Are they going to be billed for
> their resource consumption?
>
> After registration, should they own their own domain in keystone? Or be
> assigned their own project in an existing domain? Or simply be added to an
> existing group with limited authorization?
>
> On Sun, Nov 10, 2013 at 6:26 PM, Paul Belanger <
> paul.belan...@polybeacon.com> wrote:
> Greeting,
>
> In a previous thread I talked about building an application atop of
> horizon and keystone.  So far things are working out pretty well.  One
> thing I have been trying to figure out is how to move forward with
> user registration for the horizon application.  A few moons ago, IIRC,
> horizon actually use django-registration however the move to Keystone
> removed that functionality.
>
> For me, I'd like to expose some functionality within my web
> application allow users to register vs having an admin provisioning
> accounts.
>
> So, I'm curious if there is anything interest in having such a module
> back in horizon but leveraging keystone this time around. I'm actually
> curious to hear how people see this working since this is the next
> thing I need to deal with.
>
> --
> Paul Belanger | PolyBeacon, Inc.
> Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
> Github: https://github.com/pabelanger | Twitter:
> https://twitter.com/pabelanger
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
>
> -Dolph
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] Congress: an open policy framework

2013-11-11 Thread Flavio Percoco


On 02/11/13 21:31 -0700, Tim Hinrichs wrote:

Hi OpenStackers,

We've been working on an open policy framework for OpenStack that we're calling 
Congress.  We've been talking with OpenStack users and several of our partners 
to understand the kinds of rules and regulations they envision enforcing with a 
policy-based management framework.  Across the board they are interested in 
policies that span networking, compute, storage, etc.

The idea behind Congress is to have a single policy engine that integrates any 
collection of external authentication and data stores and allows cloud 
administrators to write policies over those data stores in a rich, declarative 
language.  The policy engine can either enforce the policy proactively (i.e. 
preventing policy violations before they occur) or reactively (identifying 
violations after they occur and taking corrective action) or a combination 
(proactively when possible and reactively when not).  The policy engine can 
also interact with the administrator, explaining the causes of violations, 
computing potential remediation plans, and simulating action executions to 
understand what violations those actions might cause.

While the project is still in the early stages, we have identified a grammar 
for the policy language, implemented a policy engine, and written a proof of 
concept integration for ActiveDirectory.  We would love to get participation 
and feedback.



Have you guys looked into oslo-incubator/policy.py ?

What's wrong with the grammar used there?

Have you guys considered starting your work from there?

Although you're planning to create a policy service, it may make sense
to be compliant with what OpenStack uses and maybe, you could maintain
the whole policy library at some point.

FF

--
@flaper87
Flavio Percoco

___
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?

2013-11-11 Thread Rosa, Andrea (HP Cloud Services)

Hi 

>Generally mock is supposed to be used over mox now for python 3 support.

That is my understanding too

>As for when to use mock vs stubs, I think you'll get different opinions from
>different people. Stubs are quick and easy and that's what I used early when I
>started contributing to the project, but since then have preferred mox/mock
>since they validate that methods are actually called with specific parameters,
>which can get lost when simply stubbing a method call out. In other words, if
>I'm stubbing a method and doing assertions within it (which you'll usually 
>see),
>if that method is never called (maybe the code changed since the test was
>written), the assertions are lost and the test is essentially broken.
>
>So I think in general it's best to use mock now unless you have a good reason
>not to.


AFAIK We all agree that for mocking we move to mock but there is no indication 
about using mock or stub, and that's good to me.
Mocking and stubbing are two different philosophies, I don't think one is 
better than the other.
I found this article [1] really useful.
HTH
Regards

[1] http://martinfowler.com/articles/mocksArentStubs.html
--
Andrea Rosa



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

Re: [openstack-dev] [Nova] Enabling libvirt feature: pass-through of QEMU command line args

2013-11-11 Thread Rahul M R

Hi again,

Thanks for the quick feedback!

FYI we already have a developer working on the QEMU integration and we intend 
to add support for the feature in libvirt XML (the "right" way :). In the 
meantime we wanted to avoid having to maintain a separate patch (for Nova) for 
clients to install and thought it'll be good to have the CLI passthrough option 
enabled in Nova itself.

Thanks for the feedback once again.

Regards,
Rahul


On 11-Nov-2013, at 3:55 PM, "Daniel P. Berrange"  wrote:

> On Mon, Nov 11, 2013 at 01:43:59PM +0530, Rahul M R wrote:
>> Hi all,
>> 
>> I'm new to this mailing list :)
>> 
>> I am currently working on the Snabbswitch project < 
>> https://github.com/SnabbCo/snabbswitch/wiki >. We are developing an 
>> OpenStack Neutron plugin (targeting Icehouse release). Snabbswitch makes use 
>> of an experimental patch to QEMU (not merged to mainline yet) that adds 
>> support for a user-space PCI device. This device is not supported by the 
>> libvirt XML (yet). So, in order to use this feature, some command line 
>> arguments will have to be passed to QEMU when booting an instance.
>> 
>> Therefore, I'd like to make a proposal for enabling a libvirt feature: 
>> pass-through of QEMU command line args < 
>> http://libvirt.org/drvqemu.html#qemucommand >. This will allow us to boot 
>> instances with the necessary QEMU command line arguments.
>> 
>> Now regarding the implementation of this feature, currently the plan is as 
>> follows:
>> 
>> 1. Add metadata when creating an instance using the nova boot API. For e.g.: 
>> libvirt_qemu_cli_args=["-arg1", "-arg2"]
>> 
>> 2. The libvirt driver will process the instance's metadata and generate the 
>> necessary XML (for the instance's libvirt.xml). For e.g.:
>> 
>> 
>> ...
>> 
>>   -arg1
>>   -arg2
>> 
>> ...
>> 
>> 
>> 
>> I'd love to get some feedback regarding the above proposal.
> 
> The QEMU command line passthrough feature is only intended for adhoc testing.
> Anything that is intended to be supported for production deployments must
> have explicit support in the XML config, so I'd reject any patch that attempts
> to add use of QEMU command line passthrough in Nova. That the feature is also
> not even accepted in upstream QEMU is another mark against merging it.
> 
> So if you want this feature in OpenStack, you'll need to focus on getting
> the code merged into upstream QEMU and get any neccessary support into
> libvirt if none of the existing network configs are suitable. Once that is
> done we can look at OpenStack patches to enable it.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
> 
> ___
> 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] [Openstack] [Trove] Backups Amazon like

2013-11-11 Thread Denis Makogon

For Havana release Trove doesn't support automated backups, it has only
backup-on-demand.
About restoring, Trove supports restoring only on instance creation.


2013/11/11 Giuseppe Galeota 

> Dear all,
> the Relational Database service for Amazon talk about:
>
>- Automated Backups – Turned on by default, the automated backup
>feature of Amazon RDS enables point-in-time recovery for your DB Instance.
>Amazon RDS will backup your database and transaction logs and store both
>for a user-specified retention period. This allows you to restore your DB
>Instance to any second during your retention period, up to the last five
>minutes. Your automatic backup retention period can be configured to up to
>thirty five days.
>
>
>- DB Snapshots – DB Snapshots are user-initiated backups of your DB
>Instance. These full database backups will be stored by Amazon RDS until
>you explicitly delete them. You can create a new DB Instance from a DB
>Snapshot whenever you desire.
>
>
> Does it exist a Trove project for Automated backups?
>
> Many thanks,
> Giuseppe
>
> ___
> 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] [Nova] Configuration validation

2013-11-11 Thread Nikola Đipanov

Hey all,

During the summit session on the the VMWare driver roadmap, a topic of
validating the passed configuration prior to starting services came up
(see [1] for more detail on how it's connected to that specific topic).

Several ideas were thrown around during the session mostly documented in
[1].

There are a few more cases when something like this could be useful (see
bug [2] and related patch [3]), and I was wondering if a slightly
different approach might be useful. For example use an already existing
validation hook in the service class [4] to call into a validation
framework that will potentially stop the service with proper
logging/notifications. The obvious benefit would be that there is no
pre-run required from the user, and the danger of running a
misconfigured stack is smaller.

Since there is already a blueprint raised based on the etherpad [1]- I
am bringing this up here so that we can agree on the approach, before
raising another one to solve the same problem.

Thanks,

Nikola

[1] https://etherpad.openstack.org/p/T4tQMQf5uS
[2] https://bugs.launchpad.net/nova/+bug/1243614
[3] https://review.openstack.org/#/c/53303/
[4] http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283

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

[openstack-dev] [Nova] Recent change breaks manual control of service enabled / disabled status - suggest it is backed out and re-worked

2013-11-11 Thread Day, Phil

Hi Folks,

I'd like to get some eyes on a bug I just filed:  
https://bugs.launchpad.net/nova/+bug/1250049

A recent change (https://review.openstack.org/#/c/52189/9 ) introduced the 
automatic disable / re-enable of nova-compute when connection to libvirt is 
lost and recovered.   The problem is that it doesn't take any account of the 
fact that a cloud administrator may have other reasons for disabling a service, 
and always put nova-compute back into an enabled state.

The impact of this is pretty big for us - at any point in time we have a number 
of servers disabled for various operational reasons, and there are times when 
we need to restart libvirt as part of a deployment.  With this change in place 
all of those hosts are returned to an enabled state, and the reason that they 
were disabled is lost.

While I like the concept that an error condition like this should disable the 
host from a scheduling perspective, I think it needs to be implemented as an 
additional form of disablement (i.e a separate value kept in the ServiceGroup 
API), not an override of the current one.

I'd like to propose that the current change is reverted as a priority, and a 
new approach then submitted as a second step that works alongside the current 
enable /disable reason.

Sorry for not catching this in the review stage - I didn't notice this one at 
all.

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

[openstack-dev] Grenade gate test issues

2013-11-11 Thread Tom Leaman

One of my patches for Glance (https://review.openstack.org/#/c/46479/)
consistently fails to pass the grenade test in the gate.

The n-cpu logs show many lines like:
2013-11-06 10:26:41.101 26085 WARNING nova.virt.libvirt.driver [-] URI 
qemu:///system does not support events: adding cb to list

Searching around, I've found a couple of reports of similar issues with
no clear indication of what the root cause of the problem was or how to
solve it.

I have opened a bug report
(https://bugs.launchpad.net/grenade/+bug/1241479) which received a
comment indicating that the problem is likely to be a breaking change in
my patch. If this is the case, I cannot see which part of my patch is
breaking backward compatibility.

I have tried running similar grenade tests on my local development
machine which have passed and I'm now running out of ideas to solve this.

If anyone has any similar experience or suggestions of further steps I
could take to get to the root of this, I'd be most grateful to hear them.

Tom


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

Re: [openstack-dev] [Nova] Configuration validation

2013-11-11 Thread John Garbutt

I like the idea of a more general config validation phase to help
people when first starting out.

My worry is that it would slow down the starting back up of servers
for people deploying their code using CI, where the have already
verified their configuration. But maybe its so fast I don't care, but
I just felt I should raise that.

John

On 11 November 2013 11:44, Nikola Đipanov  wrote:
> Hey all,
>
> During the summit session on the the VMWare driver roadmap, a topic of
> validating the passed configuration prior to starting services came up
> (see [1] for more detail on how it's connected to that specific topic).
>
> Several ideas were thrown around during the session mostly documented in
> [1].
>
> There are a few more cases when something like this could be useful (see
> bug [2] and related patch [3]), and I was wondering if a slightly
> different approach might be useful. For example use an already existing
> validation hook in the service class [4] to call into a validation
> framework that will potentially stop the service with proper
> logging/notifications. The obvious benefit would be that there is no
> pre-run required from the user, and the danger of running a
> misconfigured stack is smaller.
>
> Since there is already a blueprint raised based on the etherpad [1]- I
> am bringing this up here so that we can agree on the approach, before
> raising another one to solve the same problem.
>
> Thanks,
>
> Nikola
>
> [1] https://etherpad.openstack.org/p/T4tQMQf5uS
> [2] https://bugs.launchpad.net/nova/+bug/1243614
> [3] https://review.openstack.org/#/c/53303/
> [4] http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283
>
> ___
> 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] [nova] Configure overcommit policy

2013-11-11 Thread Alexander Kuznetsov

Hi all,


While studying Hadoop performance in a virtual environment, I found an
interesting problem with Nova scheduling. In OpenStack cluster, we have
overcommit policy, allowing to put on one compute more vms than resources
available for them. While it might be suitable for general types of
workload, this is definitely not the case for Hadoop clusters, which
usually consume 100% of system resources.

Is there any way to tell Nova to schedule specific instances (the ones
which consume 100% of system resources) without overcommitting resources on
compute node?


Alexander Kuznetsov.
___
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?

2013-11-11 Thread John Garbutt

On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)
 wrote:
> Hi
>
>>Generally mock is supposed to be used over mox now for python 3 support.
>
> That is my understanding too

+1

But I don't think we should waste all our time re-writing all our mox
and stub tests. Lets just leave this to happen organically for now as
we add and refactor tests. We probably need to take the hit at some
point, but that doesn't feel like we should do that right now.

>>As for when to use mock vs stubs, I think you'll get different opinions from
>>different people. Stubs are quick and easy and that's what I used early when I
>>started contributing to the project, but since then have preferred mox/mock
>>since they validate that methods are actually called with specific parameters,
>>which can get lost when simply stubbing a method call out. In other words, if
>>I'm stubbing a method and doing assertions within it (which you'll usually 
>>see),
>>if that method is never called (maybe the code changed since the test was
>>written), the assertions are lost and the test is essentially broken.
>>
>>So I think in general it's best to use mock now unless you have a good reason
>>not to.

+1

All new tests should use mock

> AFAIK We all agree that for mocking we move to mock but there is no 
> indication about using mock or stub, and that's good to me.
> Mocking and stubbing are two different philosophies, I don't think one is 
> better than the other.
> I found this article [1] really useful.
> HTH
> Regards
>
> [1] http://martinfowler.com/articles/mocksArentStubs.html

In mock things are stubs by default, which really handy. I like how
the behaviour verification in mock sits in the same place as the state
verification. In terms of books, I am quite a fan of the book by Roy
Osherove.

John

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

Re: [openstack-dev] [nova] How to fix the race condition issue between deleting and soft reboot?

2013-11-11 Thread John Garbutt

It seems we still agreed that terminate should be able to happen at any time.

I thought I remembered some code in the manager that treats
InstanceNotFound errors differently.

I would rather we ensure InstanceNotFound is raised to indicate we
have hit this race condition, and let the compute manager unify how we
deal with that across all sorts of operations.

John

On 11 November 2013 02:57, Wangpan  wrote:
> Hi all,
>
> I want to re-ask this problem after the Hongkong summit, you may have time
> to discuss this issue now.
> Thanks a lot!
>
> 2013-11-11
> 
> Wangpan
> 
> 发件人："Wangpan"
> 发送时间：2013-11-04 12:08
> 主题：[openstack-dev] [nova] How to fix the race condition issue between
> deleting and soft reboot?
> 收件人："OpenStack Development Mailing List (not for usage
> questions)"
> 抄送：
>
> Hi all,
>
> I have a question about fixing a race condition issue between deleting and
> soft reboot,
> the issue is that:
> 1. If we soft reboot an instance, and then delete it, the instance may not
> be deleted and stand on deleting task state, this is because the bug below,
> https://bugs.launchpad.net/nova/+bug/213
> and I have fixed this bug yet several months ago(just for libvirt driver).
> 2. The other issue is, if the instance is rebooted just before deleting the
> files under instance dir, then it may become to a running deleted one, and
> this bug is at below:
> https://bugs.launchpad.net/nova/+bug/1246181
> I want to fix it now, and I need your advice.
> The commit is here: https://review.openstack.org/#/c/54477/ , you can post
> your advice on gerrit or mail to me.
>
> The ways to fix bug #2 may be these(just for libvirt driver in my mind):
> 1. Add a lock to reboot operation like the deleting operation, so the reboot
> operation and the delete operation will be done in sequence.
> But on the other hand, the soft reboot operation may cost 120s if the
> instance doesn't support graceful shutdown, I think it is too long for a
> user to delete an instance, so this may not be the best way.
> 2. Check the instance state at the last of _cleanup method in libvirt
> driver, and if it is still running, destroy it again.
> This way is usable but both Nikola Dipanov and I don't like this 'ugly' way.
> 3. Check the instance vm state and task state in nova db before booting in
> reboot, if it is deleted/deleting, stop the reboot process, this will access
> db at driver level, it is a 'ugly' way, too.
>
> Nikola suggests that 'maybe we can leverage task/vm states and refactor how
> reboot is done so we can back out of a reboot on a delete', but I think we
> should let user delete an instance at any time and any state, so the delete
> operation during 'soft reboot' may not be forbidden.
>
> Thanks and waiting for your voice!
>
> 2013-11-04
> 
> Wangpan
>
> ___
> 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] [Nova] Configuration validation

2013-11-11 Thread Nikola Đipanov

On 11/11/13 12:55, John Garbutt wrote:
> I like the idea of a more general config validation phase to help
> people when first starting out.
> 
> My worry is that it would slow down the starting back up of servers
> for people deploying their code using CI, where the have already
> verified their configuration. But maybe its so fast I don't care, but
> I just felt I should raise that.
> 

Thanks John,

This is a valid point that makes me think that there might be some
upgrade implications to such an approach that we might want to consider
also.

N.

> John
> 
> On 11 November 2013 11:44, Nikola Đipanov  wrote:
>> Hey all,
>>
>> During the summit session on the the VMWare driver roadmap, a topic of
>> validating the passed configuration prior to starting services came up
>> (see [1] for more detail on how it's connected to that specific topic).
>>
>> Several ideas were thrown around during the session mostly documented in
>> [1].
>>
>> There are a few more cases when something like this could be useful (see
>> bug [2] and related patch [3]), and I was wondering if a slightly
>> different approach might be useful. For example use an already existing
>> validation hook in the service class [4] to call into a validation
>> framework that will potentially stop the service with proper
>> logging/notifications. The obvious benefit would be that there is no
>> pre-run required from the user, and the danger of running a
>> misconfigured stack is smaller.
>>
>> Since there is already a blueprint raised based on the etherpad [1]- I
>> am bringing this up here so that we can agree on the approach, before
>> raising another one to solve the same problem.
>>
>> Thanks,
>>
>> Nikola
>>
>> [1] https://etherpad.openstack.org/p/T4tQMQf5uS
>> [2] https://bugs.launchpad.net/nova/+bug/1243614
>> [3] https://review.openstack.org/#/c/53303/
>> [4] http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283
>>
>> ___
>> 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] Grenade gate test issues

2013-11-11 Thread Sean Dague

That patch changes a value in a config file, and that value change is
apparently needed for the new code to work. (I'm guessing, it's not
obvious to me that this is the case, but I'm still jet lagged).

Upgrade (currently) means you can the grizzly config file generated by
devstack on a master environment. So if you are changing the default
value of a config, you have to do it via oslo.config default changes,
not just the file itself.

-Sean

On 11/11/2013 06:47 AM, Tom Leaman wrote:
> One of my patches for Glance (https://review.openstack.org/#/c/46479/)
> consistently fails to pass the grenade test in the gate.
> 
> The n-cpu logs show many lines like:
> 2013-11-06 10:26:41.101 26085 WARNING nova.virt.libvirt.driver [-] URI 
> qemu:///system does not support events: adding cb to list
> 
> Searching around, I've found a couple of reports of similar issues with
> no clear indication of what the root cause of the problem was or how to
> solve it.
> 
> I have opened a bug report
> (https://bugs.launchpad.net/grenade/+bug/1241479) which received a
> comment indicating that the problem is likely to be a breaking change in
> my patch. If this is the case, I cannot see which part of my patch is
> breaking backward compatibility.
> 
> I have tried running similar grenade tests on my local development
> machine which have passed and I'm now running out of ideas to solve this.
> 
> If anyone has any similar experience or suggestions of further steps I
> could take to get to the root of this, I'd be most grateful to hear them.
> 
> Tom
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Configuration validation

2013-11-11 Thread Gary Kotton

Hi,
I think that John has a very valid point. My understanding from the
session was that this should be a stand alone tool that will also work
across services, that is, if neutron is configured then it will check that
the neutron credentials are correct.
Thanks
Gary

On 11/11/13 1:55 PM, "John Garbutt"  wrote:

>I like the idea of a more general config validation phase to help
>people when first starting out.
>
>My worry is that it would slow down the starting back up of servers
>for people deploying their code using CI, where the have already
>verified their configuration. But maybe its so fast I don't care, but
>I just felt I should raise that.
>
>John
>
>On 11 November 2013 11:44, Nikola Đipanov  wrote:
>> Hey all,
>>
>> During the summit session on the the VMWare driver roadmap, a topic of
>> validating the passed configuration prior to starting services came up
>> (see [1] for more detail on how it's connected to that specific topic).
>>
>> Several ideas were thrown around during the session mostly documented in
>> [1].
>>
>> There are a few more cases when something like this could be useful (see
>> bug [2] and related patch [3]), and I was wondering if a slightly
>> different approach might be useful. For example use an already existing
>> validation hook in the service class [4] to call into a validation
>> framework that will potentially stop the service with proper
>> logging/notifications. The obvious benefit would be that there is no
>> pre-run required from the user, and the danger of running a
>> misconfigured stack is smaller.
>>
>> Since there is already a blueprint raised based on the etherpad [1]- I
>> am bringing this up here so that we can agree on the approach, before
>> raising another one to solve the same problem.
>>
>> Thanks,
>>
>> Nikola
>>
>> [1] https://etherpad.openstack.org/p/T4tQMQf5uS
>> [2] https://bugs.launchpad.net/nova/+bug/1243614
>> [3] https://review.openstack.org/#/c/53303/
>> [4] 
>>http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283
>>
>> ___
>> 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] [Neutron] - Vendor specific erros

2013-11-11 Thread Avishay Balderman

Hi
Some of the DB entities in the LBaaS domain inherit from 
HasStatusDescription
With this we can set the entity status (ACTIVE, PENDING_CREATE,etc) and a 
description for the status.
There are flows in the Radware LBaaS driver that the  driver needs to set the 
entity status to ERROR and it is able to set the description of the error -  
the description is Radware specific.
My question is:  Does it make sense to do that?
After all the tenant is aware to the fact that he works against Radware load 
balancer -  the tenant selected Radware as the lbaas provider in the UI.
Any reason not to do that?

This is a generic issue/question and does not relate  to a specific plugin or 
driver.

Thanks

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

Re: [openstack-dev] RFC: reverse the default Gerrit sort order

2013-11-11 Thread Chris Jones

Hey

On 11 November 2013 12:36, Monty Taylor  wrote:

> In the meantime, I've been making complex search queries in the search
> box and then just saving the resulting URL as 'saved search' link.
>

I got bored enough with maintaining them in the tiny search box, that I
quickly whipped up:

https://github.com/cmsj/os-oddsods/blob/master/reviews.py

(but it still doesn't solve the sort order problem, which is the thing I
would most like to have the ability to control!)

-- 
Cheers,

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

Re: [openstack-dev] [summit] Youtube stream from Design Summit?

2013-11-11 Thread Chris Jones

Hi

On 5 November 2013 16:28, Christopher Yeoh  wrote:

> IMO video doesn't really matter as the most critical thing to see is the
> etherpad
>

I think it would be interesting to experiment with having a Hangout up on
the projected display.

My experience of remote participation at the Ubuntu Developer Summits of
old (projecting IRC up onto the second display) was that the folk in the
room didn't notice the IRC session very much, it was just noisy background
text. When interaction did happen it felt very strange and you had a lot of
latency (because typing).

A hangout ought to allow remote people to make themselves heard *and* do
the funky switch-video-to-active-speaker thing, so people in the room get a
giant visual clue that someone is trying to take part.

It's a lot of extra tech overhead for the folks running the summit though,
so I would suggest just starting it in the most popular track (or a track
which we know is going to need a high degree of remote participation
because key folk have been unable to attend in person).

-- 
Cheers,

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

[openstack-dev] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Nicolas Barcet

Dear TC members,

Our companies are actively encouraging our respective customers to have the
patches they mission us to make be contributed back upstream.  In order to
encourage this behavior from them and others, it would be nice that if
could gain some visibility as "sponsors" of the patches in the same way we
get visibility as "authors" of the patches today.

The goal here is not to provide yet another way to count affiliations of
direct contributors, nor is it a way to introduce sales pitches in contrib.
 The only acceptable and appropriate use of the proposal we are making is
to signal when a patch made by a contributor for another comany than the
one he is currently employed by.

For example if I work for a company A and write a patch as part of an
engagement with company B, I would signal that Company B is the sponsor of
my patch this way, not Company A.  Company B would under current
circumstances not get any credit for their indirect contribution to our
code base, while I think it is our intent to encourage them to contribute,
even indirectly.

To enable this, we are proposing that the commit text of a patch may
include a
   sponsored-by: 
line which could be used by various tools to report on these commits.
 Sponsored-by should not be used to report on the name of the company the
contributor is already affiliated to.

We would appreciate to see your comments on the subject and eventually get
your approval for it's use.

Boris Rensky, Tristan Goode, Nick Barcet
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Horizon PTL candidacy

2013-11-11 Thread Thierry Carrez

The two candidates who nominated themselves in time for this election are:

* David Lyle
* Matthias Runge

The election will be set up tomorrow, and will stay open for voting for
a week.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Neutron] Troubleshooting OVS RPC API unit test error

Hi,

I'm experiencing an issue where I run the unit tests on my local
machine and the unit tests pass, while on the Jenkins system they
fail with a very strange error.


2013-11-11 13:16:04.132 | 
2013-11-11 13:16:04.132 | Traceback (most recent call last):
2013-11-11 13:16:04.132 |   File 
"/home/jenkins/workspace/gate-neutron-python26/neutron/tests/unit/openvswitch/test_ovs_rpcapi.py",
 line 91, in test_tunnel_update
2013-11-11 13:16:04.133 | tunnel_type=None)
2013-11-11 13:16:04.133 |   File 
"/home/jenkins/workspace/gate-neutron-python26/neutron/tests/unit/openvswitch/test_ovs_rpcapi.py",
 line 38, in _test_ovs_api
2013-11-11 13:16:04.133 | expected_msg['version'] = 
rpcapi.BASE_RPC_API_VERSION
2013-11-11 13:16:04.134 | TypeError: 'Mock' object does not support item 
assignment

The review can be found here.

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

The rpcapi object is an instance of the AgentNotifierApi class in the OVS 
Neutron Plugin module, which now has an additional mixin 
(qos_rpc.QoSAgentRpcApiMixin) - perhaps I'm missing some "magic"
somewhere?

Any help would be greatly appreciated.

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

[openstack-dev] [Murano] Team Meeting reminder - October 28

2013-11-11 Thread Serg Melikyan

Hi folks

This is just a reminder about the regular meeting of Murano-team in IRC.
The meeting will be held in #openstack-meeting-alt channel at 8am Pacific.

We'll discuss news from summit, the status of our current deliveries, and
the issues which we recently faced with it.

The complete agenda of the meeting is available here:
https://wiki.openstack.org/wiki/Meetings/MuranoAgenda

-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] Team Meeting reminder - October 28

2013-11-11 Thread Serg Melikyan

Sorry for the wrong date in the title - our next meeting is today, Nov 11


On Mon, Oct 28, 2013 at 12:30 PM, Alexander Tivelkov  wrote:

> Hi folks
>
> This is just a reminder about the regular meeting of Murano-team in IRC.
> The meeting will be held in #openstack-meeting-alt channel at 8am Pacific.
>
> We'll discuss the status of our current delivery (Murano 0.3) and the
> issues which we recently faced with it.
>
> The complete agenda of the meeting is available here:
> https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
>
> --
> Kind Regards,
> Alexander Tivelkov
> Principal Software Engineer
>
> OpenStack Platform Product division
> Mirantis, Inc
>
> +7(495) 640 4904, ext 0236
> +7-926-267-37-97(cell)
> Vorontsovskaya street 35 B, building 3,
> Moscow, Russia.
> ativel...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Request for review

2013-11-11 Thread Michael Bright

OK, point taken.

When I finally get this (nova) fix out the door I'll look to concentrate on
reviewing/helping others as this is purely volunteer work.

Cheers,
Mike.




On 11 November 2013 11:16, Flavio Percoco  wrote:

> On 11/11/13 09:07 +0100, Matthias Runge wrote:
>
>> On 11/09/2013 11:45 AM, Michael Bright wrote:
>>
>>>
>>> Could someone review this please, it's a small patch but has taken a
>>> while ...
>>> https://review.openstack.org/#/c/51263/
>>>
>>>  It would be very helpful, if you'd mention the project (in this case
>> nova), in the subject line.
>>
>>
> I'd prefer folks not sending review requests to the mailing list,
> unless the patch is essential, in which case a better explanation of
> why it is essential and what the patch does would definitely be worth
> it.
>
> All core contributors receive notification emails and monitor the
> patches upstream.
>
> Cheers,
> FF
>
> --
> @flaper87
> Flavio Percoco
>
>
> ___
> 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] [Neutron] IPv6 sub-team?

2013-11-11 Thread Kyle Mestery (kmestery)


On Nov 8, 2013, at 12:01 AM, Brian Haley  wrote:

> On 11/08/2013 11:21 AM, Collins, Sean (Contractor) wrote:
>> How about scheduling an IRC meeting in close proximity to the other
>> Neutron meetings on Mondays?
>> 
>> * 20:00 to 21:00 UTC, before the Neutron meeting
> 
> +0
> 
>> OR
>> 
>> * 23:00 UTC - after the distributed virtual router meeting?
> 
> -1
> 
> I'd prefer a different day altogether since three meetings in a row would be 
> tough, but that's just my opinion…
> 
+1 to this.

> -Brian
> 
> 
> ___
> 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] [Neutron] IPv6 sub-team?

2013-11-11 Thread Stephen Wong

+1 for me as well.

So have we finalized on the meeting time?

Thanks,
- Stephen


On Mon, Nov 11, 2013 at 6:56 AM, Kyle Mestery (kmestery)
 wrote:
>
> On Nov 8, 2013, at 12:01 AM, Brian Haley  wrote:
>
>> On 11/08/2013 11:21 AM, Collins, Sean (Contractor) wrote:
>>> How about scheduling an IRC meeting in close proximity to the other
>>> Neutron meetings on Mondays?
>>>
>>> * 20:00 to 21:00 UTC, before the Neutron meeting
>>
>> +0
>>
>>> OR
>>>
>>> * 23:00 UTC - after the distributed virtual router meeting?
>>
>> -1
>>
>> I'd prefer a different day altogether since three meetings in a row would be 
>> tough, but that's just my opinion…
>>
> +1 to this.
>
>> -Brian
>>
>>
>> ___
>> 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] [horizon] User registrations

2013-11-11 Thread

David's questions are good ones.  I do like the idea of self-registration, but 
the admin will almost certainly want some controls over their initial placement 
in the system (domain, project, roles, etc).  I think part of this blueprint 
should include the specification / editing of these defaults in a new page on 
Horizon.

Jeff

-Original Message-
From: Lyle, David 
Sent: Sunday, November 10, 2013 11:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [horizon] User registrations

I think there is certainly interest.  I do think it will need to be highly 
configurable to be useful.  The problem, as Dolph points out, is that each 
deployment has its own workflow.  

Points of configuration:
-Does the local keystone deployment policy support self-registration?  The 
default is no.  So, at that point access to self-registration should be hidden.

-How many steps are required in the registration process?

-Is payment information required?  Address?  

-How is the registration confirmed, email, text, ?

-CAPTCHA?  

I think the two main reasons such a facility is not present in Horizon are:
1. Until recently determining keystone's access policy was not possible.
2. The actual implementation is highly deployment dependent.

-David 

From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Monday, November 11, 2013 8:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [horizon] User registrations

So, there's a bunch of use case questions here where I suspect there are no 
correct answers (so preferences will vary per deployment). The first ones that 
come to mind-

Are the users accessing this web form trusted or untrusted?

Do they need to be verified, somehow? Are they going to be billed for their 
resource consumption?

After registration, should they own their own domain in keystone? Or be 
assigned their own project in an existing domain? Or simply be added to an 
existing group with limited authorization?

On Sun, Nov 10, 2013 at 6:26 PM, Paul Belanger  
wrote:
Greeting,

In a previous thread I talked about building an application atop of horizon and 
keystone.  So far things are working out pretty well.  One thing I have been 
trying to figure out is how to move forward with user registration for the 
horizon application.  A few moons ago, IIRC, horizon actually use 
django-registration however the move to Keystone removed that functionality.

For me, I'd like to expose some functionality within my web application allow 
users to register vs having an admin provisioning accounts.

So, I'm curious if there is anything interest in having such a module back in 
horizon but leveraging keystone this time around. I'm actually curious to hear 
how people see this working since this is the next thing I need to deal with.

--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger

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




-- 

-Dolph
___
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] [Neutron] IPv6 sub-team?

OK - how about Thursdays, 21:00 UTC?
-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: [rally] Rally nova instances are not shown via console

 

On 2013-11-11 05:35, Anastasia Sklyankina wrote: 

> Hello, team!
> 
> I noticed that instances created by rally are displayed only on Horizon (in 
> active state), but not in CLI. 
> After test execution (for example, NovaServers.boot_server) there are 7 
> active instances on a dashboard but if I run "nova-list" command in CLI it 
> returnes only one instance (test_vm1) created manually later. 
> Something is wrong with rally mechanism of test execution or anything else?

My best guess would be that you need to run "nova list --all-tenants" to
see the Rally-created instances. By default nova list only shows
instances from the user's tenant (even if that user is admin). 

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

Re: [openstack-dev] [TripleO] Releases of this week

2013-11-11 Thread Roman Podoliaka

Hey all,

I've closed all the bugs we've released fixes for.

I've also created a wiki page [1] describing the process of making new
releases. Feel free to update and use it.

Roman

[1] https://wiki.openstack.org/wiki/TripleO/ReleaseManagement

On Wed, Nov 6, 2013 at 11:02 AM, Roman Podoliaka
 wrote:
> Hey,
>
> Cool! Thanks for sharing this!
>
> Roman
>
>
> On Wednesday, November 6, 2013, Sergey Lukjanov wrote:
>>
>> Here is the script for processing bug while releasing -
>> https://github.com/ttx/openstack-releasing/blob/master/process_bugs.py
>>
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>>
>> On Nov 6, 2013, at 1:42 PM, Roman Podoliaka 
>> wrote:
>>
>> Hey,
>>
>> Oh, that's a pity. I didn't know that. Sure I'll update the doc and look
>> for a way to automize the process.
>>
>> Roman
>>
>> On Wednesday, November 6, 2013, Robert Collins wrote:
>>
>> Awesome work - thank you!!!
>>
>> Can you please add to your docs though, that we need to go and close
>> the bugs in the project (either via a script or by hand) - gerrit
>> leaves them as Fix Committed today.
>>
>> Cheers,
>> Rob
>>
>> On 2 November 2013 04:38, Roman Podoliaka  wrote:
>> > Hi all,
>> >
>> > This week I've been doing releases of all projects, which belong to
>> > TripleO program. Here are release notes you might be interested in:
>> >
>> > os-collect-config  - 0.1.5 (was 0.1.4):
>> > - default polling interval was reduced to 30 seconds
>> > - requirements were updated to use the new iso8601 version
>> > fixing important bugs
>> >
>> > diskimage-builder - 0.0.9 (was 0.0.8)
>> >  - added support for bad Fedora image mirrors (retry the
>> > request once on 404)
>> >  - removed dependency on dracut-network from fedora element
>> >  - fixed the bug with removing of lost+found dir if it's not
>> > found
>> >
>> > tripleo-image-elements  - 0.1.0 (was 0.0.4)
>> >  - switched to tftpd-hpa on Fedora and Ubuntu
>> >  - made it possible to disable file injection in Nova
>> >  - switched seed vm to Neutron native PXE
>> >  - added Fedora support to apache2 element
>> >  - fixed processing of routes in init-neutron-ovs
>> >  - fixed Heat watch server url key name in seed vm metadata
>> >
>> > tripleo-heat-templates - 0.1.0 (was 0.0.1)
>> >  - disabled Nova Baremetal file injection (undercloud)
>> >  - made LaunchConfiguration resources mergeable
>> >  - made neutron public interface configurable (overcloud)
>> >  - made it possible to set public interface IP (overcloud)
>> >  - allowed making the public interface a VLAN (overcloud)
>> >  - added a wait condition for signalling that overcloud is ready
>> >  - added metadata for Nova floating-ip extension
>> >  - added tuskar API service configuration
>> >  - hid AdminToken in Heat templates
>> >  - added Ironic service configuration
>> >
>> >  tuskar - 0.0.2 (was 0.0.1)
>> >  - made it possible to pass Glance image id
>> >  - fixed the bug with duplicated Resource Class names
>> >
>> >  tuskar-ui - 0.0.2 (was 0.0.1)
>> >   - resource class creation form no longer ignores the image
>> > selection
>> >   - separated flavors creation step
>> >   - fail gracefully on node detail page when no overcloud
>> >   - added validation of MAC addresses and CIDR values
>> >   - stopped appending Resource Class name to Resource Class
>> > flavors
>> >   - fixed JS warnings when $ is not available
>> >   - fixed links and naming in Readme
>> >   - various code and test fixes (pep8, refactoring)
>> >
>> >   python-tuskarclient - 0.0.2 (was 0.0.1)
>> >   - fixed processing of 301 response code
>> >
>> >   os-apply-config and os-refresh-config haven't had new commits
>> > since the last release
>> >
>> > This also means that:
>> > 1. We are now releasing all the projects we have.
>> > 2. *tuskar* projects have got PyPi entries.
>> >
>> > Last but not least.
>> >
>> > I'd like to say a big thank you to Chris Jones who taught me 'Release
>> > Management 101' and provided patches to openstack/infra-config to make
>> > all our projects 'releasable'; Robert Collins for his advice on
>> > version numbering; Clark Boylan and Jeremy Stanley for landing of
>> > Gerrit ACL patches and debugging PyPi uploads issues; Radomir
>> > Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui.
>> >
>> > Thank you all guys, you've helped me a lot!
>> >
>> > Roman
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Robert Collins 
>> Distinguished Technologist<

___
OpenStack-dev mailing list
OpenStack-dev@l

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Mark McLoughlin

Hi Nick,

On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
> Dear TC members,
> 
> Our companies are actively encouraging our respective customers to have the
> patches they mission us to make be contributed back upstream.  In order to
> encourage this behavior from them and others, it would be nice that if
> could gain some visibility as "sponsors" of the patches in the same way we
> get visibility as "authors" of the patches today.
> 
> The goal here is not to provide yet another way to count affiliations of
> direct contributors, nor is it a way to introduce sales pitches in contrib.
>  The only acceptable and appropriate use of the proposal we are making is
> to signal when a patch made by a contributor for another comany than the
> one he is currently employed by.
> 
> For example if I work for a company A and write a patch as part of an
> engagement with company B, I would signal that Company B is the sponsor of
> my patch this way, not Company A.  Company B would under current
> circumstances not get any credit for their indirect contribution to our
> code base, while I think it is our intent to encourage them to contribute,
> even indirectly.
> 
> To enable this, we are proposing that the commit text of a patch may
> include a
>sponsored-by: 
> line which could be used by various tools to report on these commits.
>  Sponsored-by should not be used to report on the name of the company the
> contributor is already affiliated to.

Honestly, I've an immediately negative reaction to the prospect of e.g.

  Sponsored-By: Red Hat
  Sponsored-By: IBM

appearing in our commit messages.

I feel strongly that the project is first and foremost a community of
individuals and we instinctively push as much of corporate backing side
of things outside of the project. We try to spend as little time as
possible talking about our affiliations as possible.

And, IMHO, the git commit log is particularly sacred ground - almost
above anything else, it is a place for purely technical details.

However, I do think we'll be able to figure out some way of making it
easier for tools to track more complex affiliations.

Our affiliation databases are all keyed off email addresses right now,
so how about if we allowed for encoding affiliation/sponsorship in
addresses? e.g.

  Author: Mark McLoughlin 

and we could register that address as "work done by Mark on behalf of
IBM" ?

Mark.

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

[openstack-dev] [Murano] Team Meeting minutes - 11/11

2013-11-11 Thread Serg Melikyan

Hi,

Thanks everyone who has joined Murano IRC meeting.
These are the meeting minutes and the action items:
*http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-11-11-15.01.html
*
Complete logs can be found here:
*http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-11-11-15.01.log.html
*

-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base


On 2013-11-11 09:57, Mark McLoughlin wrote:

Hi Nick,

On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:

Dear TC members,

Our companies are actively encouraging our respective customers to 
have the
patches they mission us to make be contributed back upstream.  In 
order to

encourage this behavior from them and others, it would be nice that if
could gain some visibility as "sponsors" of the patches in the same 
way we

get visibility as "authors" of the patches today.

The goal here is not to provide yet another way to count affiliations 
of
direct contributors, nor is it a way to introduce sales pitches in 
contrib.
 The only acceptable and appropriate use of the proposal we are making 
is
to signal when a patch made by a contributor for another comany than 
the

one he is currently employed by.

For example if I work for a company A and write a patch as part of an
engagement with company B, I would signal that Company B is the 
sponsor of

my patch this way, not Company A.  Company B would under current
circumstances not get any credit for their indirect contribution to 
our
code base, while I think it is our intent to encourage them to 
contribute,

even indirectly.

To enable this, we are proposing that the commit text of a patch may
include a
   sponsored-by: 
line which could be used by various tools to report on these commits.
 Sponsored-by should not be used to report on the name of the company 
the

contributor is already affiliated to.


Honestly, I've an immediately negative reaction to the prospect of e.g.

  Sponsored-By: Red Hat
  Sponsored-By: IBM

appearing in our commit messages.

I feel strongly that the project is first and foremost a community of
individuals and we instinctively push as much of corporate backing side
of things outside of the project. We try to spend as little time as
possible talking about our affiliations as possible.

And, IMHO, the git commit log is particularly sacred ground - almost
above anything else, it is a place for purely technical details.

However, I do think we'll be able to figure out some way of making it
easier for tools to track more complex affiliations.

Our affiliation databases are all keyed off email addresses right now,
so how about if we allowed for encoding affiliation/sponsorship in
addresses? e.g.

  Author: Mark McLoughlin 

and we could register that address as "work done by Mark on behalf of
IBM" ?

Mark.


Another option that would work today is to just submit work for a 
different company under an e-mail address associated with that company.  
I guess I'm not positive the metrics tools would handle a single person 
submitting for multiple companies correctly, but if they don't that's 
probably something that could and should be fixed in the tools since 
it's a perfectly valid situation.


-Ben

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

[openstack-dev] guest instance and L2 based network failover

2013-11-11 Thread John Gruber

I found other posts which deal with the HA topic in general, but I did not
find one that strictly discussed the specifics or guidance on guest
instance network failover mechanisms.

I'm currently developing against neutron Grizzly using the OVS plugin with
VLANs and GRE tunnelling.   Flooding is working on both.  Tell us to move
to Havana is not a show stopper, but will require work.

I have guest instances which want to use their own L2 failover mechanism.
They are clustered VMs which migrate L3 fixed_ip addresses based on a
triggered failover, which can happen for many different reasons.  On
typical dynamic learning Ethernet, the VMs send out GARPs which takes care
of the network update.

In neutron I can make port updates to move the fixed_ips from one port to
another, but that takes time to let everything catch up and delays the
failover process significantly.  I know what ports should be allowed
traffic for specific fixed_ips on a failover event, so it would be great if
I could allow everything I need before a failover is triggered.  Currently
the ip_spoofing_rule in the iptables firewall is getting in the way as it
will only let traffic originate from fixed_ips associated with a port. I
would love to be able to associate a specific fixed_ip with multiple ports
which would adjust the iptables rule, but that's a pretty fundamental
change seeing that IPAllocation is a foreign key to port in the data model.
For that matter on the engress rule, I would also like to allow multiple
MAC addresses in the destination filter, but that not a requirement to make
this work quickly.

Anyone have a convenient way to augment the iptable ip_spoofing_rule to
allow for my failover  without waiting on port updates to the controller to
migrate fixed_ips between ports? I have a mechanism to allow each fixed_ip
address to have its own port (MAC address) if that helps, but it
complicates the orchestration of both the guest instance setup and failover.

Has there been any discussion around secondary_fixed_ips or
clustered_fixed_ips which can be associated with more than one port at a
time that I've missed on the mailing list?

Thanks for your help everyone.

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

[openstack-dev] [oslo][heat] oslo.db session and model_query()

2013-11-11 Thread Steven Hardy

Hi all,

I've been digging into our DB API code, aiming to align it more closely
with the recommendations in the oslo.db docs.

https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/session.py#L35

However, I'm confused by the references to model_query in the docs, which
seem to imply there is a reference model_query which will do certain things
(e.g implicitly use a session when called without one)

Is this just a hangover from moving from another project (nova?), i.e
should we be aligning with a model_query implementation similar to that in
nova, or should oslo.db have a base implementation which can be reused?

Clarification or pointers to further docs would be much appreciated! :)

Steve

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

[openstack-dev] sqlalchemy-migrate needs a new release

2013-11-11 Thread Roman Podoliaka

Hey all,

As you may know, in our global requirements list [1] we are currently
depending on SQLAlchemy 0.7.x versions (which is 'old stable' branch
and will be deprecated soon). This is mostly due to the fact, that the
latest release of sqlalchemy-migrate from PyPi doesn't support
SQLAlchemy 0.8.x+.

At the same time, distros have been providing patches for fixing this
incompatibility for a long time now. Moreover, those patches have been
merged to sqlalchemy-migrate master too.

As we are now maintaining sqlalchemy-migrate, we could make a new
release of it. This would allow us to bump the version of SQLAlchemy
release we are depending on (as soon as we fix all the bugs we have)
and let distros maintainers stop carrying their own patches.

This has been discussed at the design summit [2], so we just basically
need a volunteer from [3] Gerrit ACL group to make a new release.

Is sqlalchemy-migrate stable enough to make a new release? I think,
yes. The commits we've merged since we adopted this library, only fix
a few issues with SQLAlchemy 0.8.x compatibility and enable running of
tests (we are currently testing all new changes on py26/py27,
SQLAlchemy 0.7.x/0.8.x, SQLite/MySQL/PostgreSQL).

Who wants to help? :)

Thanks,
Roman

[1] 
https://github.com/openstack/requirements/blob/master/global-requirements.txt
[2] https://etherpad.openstack.org/p/icehouse-oslo-db-migrations
[3] https://review.openstack.org/#/admin/groups/186,members

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

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base

On 11/11/2013 10:57 AM, Mark McLoughlin wrote:
> Hi Nick,
> 
> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
>> Dear TC members,
>>
>> Our companies are actively encouraging our respective customers to have the
>> patches they mission us to make be contributed back upstream.  In order to
>> encourage this behavior from them and others, it would be nice that if
>> could gain some visibility as "sponsors" of the patches in the same way we
>> get visibility as "authors" of the patches today.
>>
>> The goal here is not to provide yet another way to count affiliations of
>> direct contributors, nor is it a way to introduce sales pitches in contrib.
>>  The only acceptable and appropriate use of the proposal we are making is
>> to signal when a patch made by a contributor for another comany than the
>> one he is currently employed by.
>>
>> For example if I work for a company A and write a patch as part of an
>> engagement with company B, I would signal that Company B is the sponsor of
>> my patch this way, not Company A.  Company B would under current
>> circumstances not get any credit for their indirect contribution to our
>> code base, while I think it is our intent to encourage them to contribute,
>> even indirectly.
>>
>> To enable this, we are proposing that the commit text of a patch may
>> include a
>>sponsored-by: 
>> line which could be used by various tools to report on these commits.
>>  Sponsored-by should not be used to report on the name of the company the
>> contributor is already affiliated to.
> 
> Honestly, I've an immediately negative reaction to the prospect of e.g.
> 
>   Sponsored-By: Red Hat
>   Sponsored-By: IBM
> 
> appearing in our commit messages.
> 
> I feel strongly that the project is first and foremost a community of
> individuals and we instinctively push as much of corporate backing side
> of things outside of the project. We try to spend as little time as
> possible talking about our affiliations as possible.
> 
> And, IMHO, the git commit log is particularly sacred ground - almost
> above anything else, it is a place for purely technical details.

This was exactly my reaction, as well.  I just hadn't been able to come
up with a good alternate proposal, yet.

> However, I do think we'll be able to figure out some way of making it
> easier for tools to track more complex affiliations.
> 
> Our affiliation databases are all keyed off email addresses right now,
> so how about if we allowed for encoding affiliation/sponsorship in
> addresses? e.g.
> 
>   Author: Mark McLoughlin 
> 
> and we could register that address as "work done by Mark on behalf of
> IBM" ?

That doesn't seem any better to me.  It actually seems more likely to
break, since someone could be using an email address with '+' in it for
some other reason, right?

I think it may be worth looking at this from a different angle.  Perhaps
we should tone down the focus on company metrics, and perhaps remove
them completely from anything we control or have influence over.

-- 
Russell Bryant

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

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Davanum Srinivas

@Ben,

Metrics tools i believe are already using information in the .mailmap
file (see nova's for example).

-- dims

On Mon, Nov 11, 2013 at 11:09 AM, Ben Nemec  wrote:
> On 2013-11-11 09:57, Mark McLoughlin wrote:
>>
>> Hi Nick,
>>
>> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
>>>
>>> Dear TC members,
>>>
>>> Our companies are actively encouraging our respective customers to have
>>> the
>>> patches they mission us to make be contributed back upstream.  In order
>>> to
>>> encourage this behavior from them and others, it would be nice that if
>>> could gain some visibility as "sponsors" of the patches in the same way
>>> we
>>> get visibility as "authors" of the patches today.
>>>
>>> The goal here is not to provide yet another way to count affiliations of
>>> direct contributors, nor is it a way to introduce sales pitches in
>>> contrib.
>>>  The only acceptable and appropriate use of the proposal we are making is
>>> to signal when a patch made by a contributor for another comany than the
>>> one he is currently employed by.
>>>
>>> For example if I work for a company A and write a patch as part of an
>>> engagement with company B, I would signal that Company B is the sponsor
>>> of
>>> my patch this way, not Company A.  Company B would under current
>>> circumstances not get any credit for their indirect contribution to our
>>> code base, while I think it is our intent to encourage them to
>>> contribute,
>>> even indirectly.
>>>
>>> To enable this, we are proposing that the commit text of a patch may
>>> include a
>>>sponsored-by: 
>>> line which could be used by various tools to report on these commits.
>>>  Sponsored-by should not be used to report on the name of the company the
>>> contributor is already affiliated to.
>>
>>
>> Honestly, I've an immediately negative reaction to the prospect of e.g.
>>
>>   Sponsored-By: Red Hat
>>   Sponsored-By: IBM
>>
>> appearing in our commit messages.
>>
>> I feel strongly that the project is first and foremost a community of
>> individuals and we instinctively push as much of corporate backing side
>> of things outside of the project. We try to spend as little time as
>> possible talking about our affiliations as possible.
>>
>> And, IMHO, the git commit log is particularly sacred ground - almost
>> above anything else, it is a place for purely technical details.
>>
>> However, I do think we'll be able to figure out some way of making it
>> easier for tools to track more complex affiliations.
>>
>> Our affiliation databases are all keyed off email addresses right now,
>> so how about if we allowed for encoding affiliation/sponsorship in
>> addresses? e.g.
>>
>>   Author: Mark McLoughlin 
>>
>> and we could register that address as "work done by Mark on behalf of
>> IBM" ?
>>
>> Mark.
>
>
> Another option that would work today is to just submit work for a different
> company under an e-mail address associated with that company.  I guess I'm
> not positive the metrics tools would handle a single person submitting for
> multiple companies correctly, but if they don't that's probably something
> that could and should be fixed in the tools since it's a perfectly valid
> situation.
>
> -Ben
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: http://davanum.wordpress.com

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

[openstack-dev] [Heat] HOT software configuration refined after design summit discussions

2013-11-11 Thread Thomas Spatzier


Hi all,

I have just posted the following wiki page to reflect a refined proposal
for HOT software configuration based on discussions at the design summit
last week. Angus also put a sample up in an etherpad last week, but we did
not have enough time to go thru it in the design session. My write-up is
based on Angus' sample, actually a refinement, and on discussions we had in
breaks, plus it is trying to reflect all the good input from ML discussions
and Steve Baker's initial proposal.

https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP

Please review and provide feedback.

Regards,
Thomas


___
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?

2013-11-11 Thread Jay Lau

Got it. Thanks.

Jay


2013/11/11 Davanum Srinivas 

> Feedback from some of the Nova sessions were,
>
> "If you are writing new tests, try to use mock."
> "Writing new tests to cover more code (esp drivers) is more preferable
> to any effort that just converts from mox to mock"
>
> -- dims
>
> On Sun, Nov 10, 2013 at 11:25 PM, Noorul Islam K M 
> wrote:
> > Jay Lau  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
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Monty Taylor



On 11/11/2013 11:41 AM, Russell Bryant wrote:
> On 11/11/2013 10:57 AM, Mark McLoughlin wrote:
>> Hi Nick,
>>
>> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
>>> Dear TC members,
>>>
>>> Our companies are actively encouraging our respective customers to have the
>>> patches they mission us to make be contributed back upstream.  In order to
>>> encourage this behavior from them and others, it would be nice that if
>>> could gain some visibility as "sponsors" of the patches in the same way we
>>> get visibility as "authors" of the patches today.
>>>
>>> The goal here is not to provide yet another way to count affiliations of
>>> direct contributors, nor is it a way to introduce sales pitches in contrib.
>>>  The only acceptable and appropriate use of the proposal we are making is
>>> to signal when a patch made by a contributor for another comany than the
>>> one he is currently employed by.
>>>
>>> For example if I work for a company A and write a patch as part of an
>>> engagement with company B, I would signal that Company B is the sponsor of
>>> my patch this way, not Company A.  Company B would under current
>>> circumstances not get any credit for their indirect contribution to our
>>> code base, while I think it is our intent to encourage them to contribute,
>>> even indirectly.
>>>
>>> To enable this, we are proposing that the commit text of a patch may
>>> include a
>>>sponsored-by: 
>>> line which could be used by various tools to report on these commits.
>>>  Sponsored-by should not be used to report on the name of the company the
>>> contributor is already affiliated to.
>>
>> Honestly, I've an immediately negative reaction to the prospect of e.g.
>>
>>   Sponsored-By: Red Hat
>>   Sponsored-By: IBM
>>
>> appearing in our commit messages.
>>
>> I feel strongly that the project is first and foremost a community of
>> individuals and we instinctively push as much of corporate backing side
>> of things outside of the project. We try to spend as little time as
>> possible talking about our affiliations as possible.
>>
>> And, IMHO, the git commit log is particularly sacred ground - almost
>> above anything else, it is a place for purely technical details.
> 
> This was exactly my reaction, as well.  I just hadn't been able to come
> up with a good alternate proposal, yet.
> 
>> However, I do think we'll be able to figure out some way of making it
>> easier for tools to track more complex affiliations.
>>
>> Our affiliation databases are all keyed off email addresses right now,
>> so how about if we allowed for encoding affiliation/sponsorship in
>> addresses? e.g.
>>
>>   Author: Mark McLoughlin 
>>
>> and we could register that address as "work done by Mark on behalf of
>> IBM" ?
> 
> That doesn't seem any better to me.  It actually seems more likely to
> break, since someone could be using an email address with '+' in it for
> some other reason, right?
> 
> I think it may be worth looking at this from a different angle.  Perhaps
> we should tone down the focus on company metrics, and perhaps remove
> them completely from anything we control or have influence over.


While I agree with the sentiment strongly - I like that the things we
control have them, because it means we can shape them with some sanity.
The companies all want to track this data, and will track this data. If
we don't have a hand in it, it's going to get tracked elsewhere and
probably in a much more biased manner.

Amazing as it may seem, the competitive nature amongst the companies on
this has been a positive thing so far. In a status report I sent up the
chain at HP recently, I was able to point at HP's participation, as well
as my team's role in that - net result - more headcount for Monty, which
as I'm sure we all know means more heads working on core openstack
things that are not driven by vendor plugins.

Remember that the folks paying for all of us to work on an Open Source
project are doing so for a myriad of reasons, and not all of them are
"because Open Source is the right thing to do" The more we can provide
ammunition to those of us who are straddling the line of getting and
allocating those resources, the better.

So, back to the proposal at hand - I think Mark is right that the git
commit log isn't really the place to try to capture that - but I'm not
sure I grok where the right place is. Perhaps we need to brainstorm more?

Monty

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

[openstack-dev] [Mistral] Community meeting minutes - 11/11/2013

2013-11-11 Thread Renat Akhmerov

Hi,

Thanks for coming to the IRC community meeting today at #openstack-meeting. 
Please also join us next time to be aware of and participate in all the 
exciting activities.

Here’s the full log and minutes of the today’s meeting:

Log: 
http://eavesdrop.openstack.org/meetings/mistral/2013/mistral.2013-11-11-16.01.log.html
Minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2013/mistral.2013-11-11-16.01.html


Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Anne Gentle

On Mon, Nov 11, 2013 at 8:20 AM, Nicolas Barcet  wrote:

> Dear TC members,
>
> Our companies are actively encouraging our respective customers to have
> the patches they mission us to make be contributed back upstream.  In order
> to encourage this behavior from them and others, it would be nice that if
> could gain some visibility as "sponsors" of the patches in the same way we
> get visibility as "authors" of the patches today.
>

I think this statement is a decent description of the goal, my paraphrasing
would be "reward upstream through recognition." But there has to be a
better way than commit messages. We should also serve users better by
perhaps indicating that a company they trust and partner with is ensuring
OpenStack is all they, the users, want it to be. I agree the commit message
is sacred but besides, users shouldn't have to sift through Gerrit patches.

Also realize that there's research [1] about motivations for contributing
to community work:
reciprocity (I help because others help me)
recognition
efficiency (saves time)
attachment or commitment to a group

What about something with attribution in the docs for the feature? Can we
play around with that a while? Attribution is going to have to be
incorporated better into the docs for the CC By licensing anyway. Any
thoughts on docs as placement for "This feature brought to you by " We need to play with the words more. Sponsored
by brings up ickies for me, sounds like it turns others off too. Let's be
careful with wording and placement both.

Thanks,
Anne

1.
http://www.connectedaction.net/wp-content/uploads/2009/05/2001-peter-kollock-economies-of-online-cooperation.htm


>
> The goal here is not to provide yet another way to count affiliations of
> direct contributors, nor is it a way to introduce sales pitches in contrib.
>  The only acceptable and appropriate use of the proposal we are making is
> to signal when a patch made by a contributor for another comany than the
> one he is currently employed by.
>
> For example if I work for a company A and write a patch as part of an
> engagement with company B, I would signal that Company B is the sponsor of
> my patch this way, not Company A.  Company B would under current
> circumstances not get any credit for their indirect contribution to our
> code base, while I think it is our intent to encourage them to contribute,
> even indirectly.
>
> To enable this, we are proposing that the commit text of a patch may
> include a
>sponsored-by: 
> line which could be used by various tools to report on these commits.
>  Sponsored-by should not be used to report on the name of the company the
> contributor is already affiliated to.
>
> We would appreciate to see your comments on the subject and eventually get
> your approval for it's use.
>
> Boris Rensky, Tristan Goode, Nick Barcet
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Anne Gentle
annegen...@justwriteclick.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Mark McLoughlin

On Mon, 2013-11-11 at 11:41 -0500, Russell Bryant wrote:
> On 11/11/2013 10:57 AM, Mark McLoughlin wrote:
> > Hi Nick,
> > 
> > On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
> >> Dear TC members,
> >>
> >> Our companies are actively encouraging our respective customers to have the
> >> patches they mission us to make be contributed back upstream.  In order to
> >> encourage this behavior from them and others, it would be nice that if
> >> could gain some visibility as "sponsors" of the patches in the same way we
> >> get visibility as "authors" of the patches today.
> >>
> >> The goal here is not to provide yet another way to count affiliations of
> >> direct contributors, nor is it a way to introduce sales pitches in contrib.
> >>  The only acceptable and appropriate use of the proposal we are making is
> >> to signal when a patch made by a contributor for another comany than the
> >> one he is currently employed by.
> >>
> >> For example if I work for a company A and write a patch as part of an
> >> engagement with company B, I would signal that Company B is the sponsor of
> >> my patch this way, not Company A.  Company B would under current
> >> circumstances not get any credit for their indirect contribution to our
> >> code base, while I think it is our intent to encourage them to contribute,
> >> even indirectly.
> >>
> >> To enable this, we are proposing that the commit text of a patch may
> >> include a
> >>sponsored-by: 
> >> line which could be used by various tools to report on these commits.
> >>  Sponsored-by should not be used to report on the name of the company the
> >> contributor is already affiliated to.
> > 
> > Honestly, I've an immediately negative reaction to the prospect of e.g.
> > 
> >   Sponsored-By: Red Hat
> >   Sponsored-By: IBM
> > 
> > appearing in our commit messages.
> > 
> > I feel strongly that the project is first and foremost a community of
> > individuals and we instinctively push as much of corporate backing side
> > of things outside of the project. We try to spend as little time as
> > possible talking about our affiliations as possible.
> > 
> > And, IMHO, the git commit log is particularly sacred ground - almost
> > above anything else, it is a place for purely technical details.
> 
> This was exactly my reaction, as well.  I just hadn't been able to come
> up with a good alternate proposal, yet.
> 
> > However, I do think we'll be able to figure out some way of making it
> > easier for tools to track more complex affiliations.
> > 
> > Our affiliation databases are all keyed off email addresses right now,
> > so how about if we allowed for encoding affiliation/sponsorship in
> > addresses? e.g.
> > 
> >   Author: Mark McLoughlin 
> > 
> > and we could register that address as "work done by Mark on behalf of
> > IBM" ?
> 
> That doesn't seem any better to me.  It actually seems more likely to
> break, since someone could be using an email address with '+' in it for
> some other reason, right?

Oh, I'm not saying we parse the "ibm" bit and key off that. Just that we
can associate affiliation with email address while still allowing people
to use the same email address for everything.

A better example - say Robert De Niro works for Nebula but uses his
gmail address for everything:

  Author: Robert De Niro 

but if he did some work sponsored by the NSA, he could do:

  Author: Robert De Niro 

and we'd have the tracking tools associate the first email address with
Nebula and the second with the NSA.

> I think it may be worth looking at this from a different angle.  Perhaps
> we should tone down the focus on company metrics, and perhaps remove
> them completely from anything we control or have influence over.

I'm down with that. We've definitely jumped the shark on this.

Mark.


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

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base


On 2013-11-11 10:49, Davanum Srinivas wrote:

@Ben,

Metrics tools i believe are already using information in the .mailmap
file (see nova's for example).


Having just been through this process, I'm afraid not. :-)  Stackalytics 
uses 
https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json and Activity Board uses https://github.com/openstack-infra/activity-board/blob/master/browser/data/affs/openstack-community-affs.csv


Also, the mailmaps for some projects (oslo-incubator for example) are so 
incomplete that they would require massive updates to be useful for 
this.


There was actually a discussion about the proliferation of affiliation 
data not too long ago: 
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016900.html


-Ben

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

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base

On 11/11/2013 12:08 PM, Mark McLoughlin wrote:
> On Mon, 2013-11-11 at 11:41 -0500, Russell Bryant wrote:
>> On 11/11/2013 10:57 AM, Mark McLoughlin wrote:
>>> Hi Nick,
>>>
>>> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
 Dear TC members,

 Our companies are actively encouraging our respective customers to have the
 patches they mission us to make be contributed back upstream.  In order to
 encourage this behavior from them and others, it would be nice that if
 could gain some visibility as "sponsors" of the patches in the same way we
 get visibility as "authors" of the patches today.

 The goal here is not to provide yet another way to count affiliations of
 direct contributors, nor is it a way to introduce sales pitches in contrib.
  The only acceptable and appropriate use of the proposal we are making is
 to signal when a patch made by a contributor for another comany than the
 one he is currently employed by.

 For example if I work for a company A and write a patch as part of an
 engagement with company B, I would signal that Company B is the sponsor of
 my patch this way, not Company A.  Company B would under current
 circumstances not get any credit for their indirect contribution to our
 code base, while I think it is our intent to encourage them to contribute,
 even indirectly.

 To enable this, we are proposing that the commit text of a patch may
 include a
sponsored-by: 
 line which could be used by various tools to report on these commits.
  Sponsored-by should not be used to report on the name of the company the
 contributor is already affiliated to.
>>>
>>> Honestly, I've an immediately negative reaction to the prospect of e.g.
>>>
>>>   Sponsored-By: Red Hat
>>>   Sponsored-By: IBM
>>>
>>> appearing in our commit messages.
>>>
>>> I feel strongly that the project is first and foremost a community of
>>> individuals and we instinctively push as much of corporate backing side
>>> of things outside of the project. We try to spend as little time as
>>> possible talking about our affiliations as possible.
>>>
>>> And, IMHO, the git commit log is particularly sacred ground - almost
>>> above anything else, it is a place for purely technical details.
>>
>> This was exactly my reaction, as well.  I just hadn't been able to come
>> up with a good alternate proposal, yet.
>>
>>> However, I do think we'll be able to figure out some way of making it
>>> easier for tools to track more complex affiliations.
>>>
>>> Our affiliation databases are all keyed off email addresses right now,
>>> so how about if we allowed for encoding affiliation/sponsorship in
>>> addresses? e.g.
>>>
>>>   Author: Mark McLoughlin 
>>>
>>> and we could register that address as "work done by Mark on behalf of
>>> IBM" ?
>>
>> That doesn't seem any better to me.  It actually seems more likely to
>> break, since someone could be using an email address with '+' in it for
>> some other reason, right?
> 
> Oh, I'm not saying we parse the "ibm" bit and key off that. Just that we
> can associate affiliation with email address while still allowing people
> to use the same email address for everything.
> 
> A better example - say Robert De Niro works for Nebula but uses his
> gmail address for everything:
> 
>   Author: Robert De Niro 
> 
> but if he did some work sponsored by the NSA, he could do:
> 
>   Author: Robert De Niro 
> 
> and we'd have the tracking tools associate the first email address with
> Nebula and the second with the NSA.

Oh OK, I get it now.  That seems fine.  It keeps the git log more
pristine, and uses the same thing (email address) that we use already
for building.  There's really no technical work required to implement
this, which is nice.  It would just be a recommended convention.

>> I think it may be worth looking at this from a different angle.  Perhaps
>> we should tone down the focus on company metrics, and perhaps remove
>> them completely from anything we control or have influence over.
> 
> I'm down with that. We've definitely jumped the shark on this.

But Monty makes a good point that if we don't produce this information,
someone else will with potentially questionable accuracy.

It's a tough situation, because we really do need to work to encourage
viewing the project as a community of individuals, at least within the
technical community.

-- 
Russell Bryant

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

Re: [openstack-dev] [openstack-tc] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Jay S Bryant

Mark,

Well stated.  I think it is important that OpenStack continue to be 
focussed on individuals contributing to the community and not 
corporations.

There are plenty of metrics already being compiled using e-mail addresses. 
 In fact, I think the visibility of 'sponsors' is already available as a 
result through websites like Stackalytics (http://stackalytics.com/) . 
Highlighting the sponsors of individual commits seems unnecessary.

That's my two cents.

Jay S. Bryant
Linux Developer - 
OpenStack Enterprise Edition

Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey

From:   Mark McLoughlin 
To: Nicolas Barcet , 
Cc: OpenStack Development Mailing List 
, openstack...@lists.openstack.org, 
Boris Renski , Tristan Goode 
Date:   11/11/2013 09:58 AM
Subject:Re: [openstack-dev] [openstack-tc] Proposal to recognize 
indirect contributions to our code base

Hi Nick,

On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
> Dear TC members,
> 
> Our companies are actively encouraging our respective customers to have 
the
> patches they mission us to make be contributed back upstream.  In order 
to
> encourage this behavior from them and others, it would be nice that if
> could gain some visibility as "sponsors" of the patches in the same way 
we
> get visibility as "authors" of the patches today.
> 
> The goal here is not to provide yet another way to count affiliations of
> direct contributors, nor is it a way to introduce sales pitches in 
contrib.
>  The only acceptable and appropriate use of the proposal we are making 
is
> to signal when a patch made by a contributor for another comany than the
> one he is currently employed by.
> 
> For example if I work for a company A and write a patch as part of an
> engagement with company B, I would signal that Company B is the sponsor 
of
> my patch this way, not Company A.  Company B would under current
> circumstances not get any credit for their indirect contribution to our
> code base, while I think it is our intent to encourage them to 
contribute,
> even indirectly.
> 
> To enable this, we are proposing that the commit text of a patch may
> include a
>sponsored-by: 
> line which could be used by various tools to report on these commits.
>  Sponsored-by should not be used to report on the name of the company 
the
> contributor is already affiliated to.

Honestly, I've an immediately negative reaction to the prospect of e.g.

  Sponsored-By: Red Hat
  Sponsored-By: IBM

appearing in our commit messages.

I feel strongly that the project is first and foremost a community of
individuals and we instinctively push as much of corporate backing side
of things outside of the project. We try to spend as little time as
possible talking about our affiliations as possible.

And, IMHO, the git commit log is particularly sacred ground - almost
above anything else, it is a place for purely technical details.

However, I do think we'll be able to figure out some way of making it
easier for tools to track more complex affiliations.

Our affiliation databases are all keyed off email addresses right now,
so how about if we allowed for encoding affiliation/sponsorship in
addresses? e.g.

  Author: Mark McLoughlin 

and we could register that address as "work done by Mark on behalf of
IBM" ?

Mark.

___
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] Proposal to recognize indirect contributions to our code base

On 11/11/2013 12:09 PM, Anne Gentle wrote:
> What about something with attribution in the docs for the feature? Can
> we play around with that a while? Attribution is going to have to be
> incorporated better into the docs for the CC By licensing anyway. Any
> thoughts on docs as placement for "This feature brought to you by
> " We need to play with the words more.
> Sponsored by brings up ickies for me, sounds like it turns others off
> too. Let's be careful with wording and placement both.

This sounds like it could get really messy.  Once a feature goes in, it
becomes a collaboration between many people over time.  It sounds like
it would get into the same situation as our copyright headers in source
files (wildly incomplete).

This also has a tendency to just recognize feature adds, and not common
work.  Lack of or minimal contributions to common work by some
organizations is already a pretty big problem in various parts of OpenStack.

-- 
Russell Bryant

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

Re: [openstack-dev] [nova][api] Is this a potential issue

2013-11-11 Thread Jiang, Yunhong

Resend after the HK summit, hope someone can give me hint on it.

Thanks
--jyh

> -Original Message-
> From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com]
> Sent: Thursday, November 07, 2013 5:39 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [nova][api] Is this a potential issue
> 
> Hi, all
>   I'm a bit confused of followed code in ./compute/api.py, which will be
> invoked by api/openstack/compute/servers.py, _action_revert_resize().
>   From the code seems there is a small windows between get the
> migration object and update migration.status. If another API request
> comes at this small window, it means two utility will try to revert resize at
> same time. Is this a potential issue?
>   Currently implementation already roll back the reservation if
> something wrong, but not sure if we should update state to "reverting" as
> a transaction in get_by_instance_and_status()?
> 
> --jyh
> 
> def revert_resize(self, context, instance):
> """Reverts a resize, deleting the 'new' instance in the process."""
> elevated = context.elevated()
> migration =
> migration_obj.Migration.get_by_instance_and_status(
> elevated, instance.uuid, 'finished')
>   >>Here we get the migration object
> 
> # reverse quota reservation for increased resource usage
> deltas = self._reverse_upsize_quota_delta(context, migration)
> reservations = self._reserve_quota_delta(context, deltas)
> 
> instance.task_state = task_states.RESIZE_REVERTING
> instance.save(expected_task_state=None)
> 
> migration.status = 'reverting'
> >>Here
> we update the status.
> migration.save()
> 
> ___
> 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] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Daniel P. Berrange

On Mon, Nov 11, 2013 at 12:27:35PM -0500, Russell Bryant wrote:
> On 11/11/2013 12:09 PM, Anne Gentle wrote:
> > What about something with attribution in the docs for the feature? Can
> > we play around with that a while? Attribution is going to have to be
> > incorporated better into the docs for the CC By licensing anyway. Any
> > thoughts on docs as placement for "This feature brought to you by
> > " We need to play with the words more.
> > Sponsored by brings up ickies for me, sounds like it turns others off
> > too. Let's be careful with wording and placement both.
> 
> This sounds like it could get really messy.  Once a feature goes in, it
> becomes a collaboration between many people over time.  It sounds like
> it would get into the same situation as our copyright headers in source
> files (wildly incomplete).

I think that's a very good point about the distinction between initial
dev work vs ongoing maintenance of it. I don't think we want todo something
which puts too much emphasis on the initial dev work, at the cost of the
ongoing maint work that follows.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [Nova] Configuration validation

2013-11-11 Thread Tracy Jones

I had envisioned this as a standalone tool which would be run after an initial 
deployment to validate the config.  I like the idea of hooking it into an 
existing framework - but i agree that we certainly don’t want to slow things 
down.  I wonder if we could use some sort of cookie to track when we validated 
the config and only revalidate when needed.  As i get further in the BP i’ll 
investigate these options.

Tracy

On Nov 11, 2013, at 4:31 AM, Gary Kotton  wrote:

> Hi,
> I think that John has a very valid point. My understanding from the
> session was that this should be a stand alone tool that will also work
> across services, that is, if neutron is configured then it will check that
> the neutron credentials are correct.
> Thanks
> Gary
> 
> On 11/11/13 1:55 PM, "John Garbutt"  wrote:
> 
>> I like the idea of a more general config validation phase to help
>> people when first starting out.
>> 
>> My worry is that it would slow down the starting back up of servers
>> for people deploying their code using CI, where the have already
>> verified their configuration. But maybe its so fast I don't care, but
>> I just felt I should raise that.
>> 
>> John
>> 
>> On 11 November 2013 11:44, Nikola Đipanov  wrote:
>>> Hey all,
>>> 
>>> During the summit session on the the VMWare driver roadmap, a topic of
>>> validating the passed configuration prior to starting services came up
>>> (see [1] for more detail on how it's connected to that specific topic).
>>> 
>>> Several ideas were thrown around during the session mostly documented in
>>> [1].
>>> 
>>> There are a few more cases when something like this could be useful (see
>>> bug [2] and related patch [3]), and I was wondering if a slightly
>>> different approach might be useful. For example use an already existing
>>> validation hook in the service class [4] to call into a validation
>>> framework that will potentially stop the service with proper
>>> logging/notifications. The obvious benefit would be that there is no
>>> pre-run required from the user, and the danger of running a
>>> misconfigured stack is smaller.
>>> 
>>> Since there is already a blueprint raised based on the etherpad [1]- I
>>> am bringing this up here so that we can agree on the approach, before
>>> raising another one to solve the same problem.
>>> 
>>> Thanks,
>>> 
>>> Nikola
>>> 
>>> [1] https://etherpad.openstack.org/p/T4tQMQf5uS
>>> [2] https://bugs.launchpad.net/nova/+bug/1243614
>>> [3] https://review.openstack.org/#/c/53303/
>>> [4] 
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283
>>> 
>>> ___
>>> 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] [openstack-tc] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Anne Gentle

On Mon, Nov 11, 2013 at 11:27 AM, Russell Bryant  wrote:

> On 11/11/2013 12:09 PM, Anne Gentle wrote:
> > What about something with attribution in the docs for the feature? Can
> > we play around with that a while? Attribution is going to have to be
> > incorporated better into the docs for the CC By licensing anyway. Any
> > thoughts on docs as placement for "This feature brought to you by
> > " We need to play with the words more.
> > Sponsored by brings up ickies for me, sounds like it turns others off
> > too. Let's be careful with wording and placement both.
>
> This sounds like it could get really messy.  Once a feature goes in, it
> becomes a collaboration between many people over time.  It sounds like
> it would get into the same situation as our copyright headers in source
> files (wildly incomplete).
>
> This also has a tendency to just recognize feature adds, and not common
> work.  Lack of or minimal contributions to common work by some
> organizations is already a pretty big problem in various parts of
> OpenStack.
>
>
Great point. I'm also trying to point out that common areas like doc could
use the attention and would give attribution. Also trying to focus on
users, and avoid a "how it's made" focus. But clearly ongoing maintenance
is a concern with "sponsored" patches.


> --
> Russell Bryant
>
> ___
> OpenStack-TC mailing list
> openstack...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposal to recognize indirect contributions to our code base

2013-11-11 Thread Daniel P. Berrange

On Mon, Nov 11, 2013 at 03:20:20PM +0100, Nicolas Barcet wrote:
> Dear TC members,
> 
> Our companies are actively encouraging our respective customers to have the
> patches they mission us to make be contributed back upstream.  In order to
> encourage this behavior from them and others, it would be nice that if
> could gain some visibility as "sponsors" of the patches in the same way we
> get visibility as "authors" of the patches today.
> 
> The goal here is not to provide yet another way to count affiliations of
> direct contributors, nor is it a way to introduce sales pitches in contrib.
>  The only acceptable and appropriate use of the proposal we are making is
> to signal when a patch made by a contributor for another comany than the
> one he is currently employed by.
> 
> For example if I work for a company A and write a patch as part of an
> engagement with company B, I would signal that Company B is the sponsor of
> my patch this way, not Company A.  Company B would under current
> circumstances not get any credit for their indirect contribution to our
> code base, while I think it is our intent to encourage them to contribute,
> even indirectly.
> 
> To enable this, we are proposing that the commit text of a patch may
> include a
>sponsored-by: 
> line which could be used by various tools to report on these commits.
>  Sponsored-by should not be used to report on the name of the company the
> contributor is already affiliated to.
> 
> We would appreciate to see your comments on the subject and eventually get
> your approval for it's use.

IMHO, lets call this what it is: "marketing".

I'm fine with the idea of a company wanting to have recognition for work
that they fund. They can achieve this by putting out a press release or
writing a blog post saying that they "funded awesome feature XYZ to bring
benefits ABC to the project" on their own websites, or any number of other
marketing approaches. Most / many companies and individuals contributing
to OpenStack in fact already do this very frequently which is fine / great.

I don't think we need to, nor should we, add anything to our code commits,
review / development workflow / toolchain to support such marketing pitches.
The identities recorded in git commits / gerrit reviewes / blueprints etc
should exclusively focus on technical authorship, not sponsorship. Leave
the marketing pitches for elsewhere.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [Nova] Configuration validation

On 11/11/2013 07:38 AM, Nikola Đipanov wrote:
> On 11/11/13 12:55, John Garbutt wrote:
>> I like the idea of a more general config validation phase to help
>> people when first starting out.
>>
>> My worry is that it would slow down the starting back up of servers
>> for people deploying their code using CI, where the have already
>> verified their configuration. But maybe its so fast I don't care, but
>> I just felt I should raise that.
>>
> 
> Thanks John,
> 
> This is a valid point that makes me think that there might be some
> upgrade implications to such an approach that we might want to consider
> also.

I like the idea of doing it during service startup.  I'd like to
actually see that it's painfully slow and must be separate before
assuming that's the answer.  I really can't image it taking that long.
It's not a complex algorithm.  It's some sanity checks on combinations
of config values.

-- 
Russell Bryant

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

Re: [openstack-dev] Nova XML serialization bug 1223358 moving discussion here to get more people involved

2013-11-11 Thread Rosa, Andrea (HP Cloud Services)

Hi all

I realised that I sent this request just the Friday before the HK summit, a 
really bad timing :(
Resending, anyone is available to have a look at  this thread?
Please note that the code change has a -1 and I am not submitting a new patch 
as we (the reviewer and myself) are stuck in finding a common solution for the 
original bug.
As soon as we have a consensus I'll be really happy to submit a new patch.

Regards
--
Andrea Rosa

>-Original Message-
>From: Rosa, Andrea (HP Cloud Services)
>Sent: 01 November 2013 14:35
>To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
>Subject: [openstack-dev] Nova XML serialization bug 1223358 moving
>discussion here to get more people involved
>
>Hi all
>
>Long story short: a long time ago I raised a bug [1] and I started to work on 
>the
>fix:  GuoHui LIu (the reviewer) and myself had long and useful discussion
>about the right solution for  that but now we are stuck and we need some
>more opinions to find a proper one.
>
>And now the long story:
>When we have an instance booted from a volume and we don't specify the
>image details in the boot command the XML serialization of instance details
>fails and the API call (like nova show) returns a 500 error.
>The problem is that the image properties is mandatory to serialize but the xml
>serializer can't manage properly an empty value.
>In particular in the xmlutil we a have the class Selector which selects datum
>within a specific object, that class is designed to deal with missing data in 
>the
>object but not to deal with an empty object.
>At this moment to deal with missing data the logic used in the method is to
>catch KeyError or IndexError exceptions:
>try:
>obj = obj[elem]
>except (KeyError, IndexError):
>if do_raise:
>raise KeyError(elem)
>
>My simple fix was to following the same logic and add a new exception to get
>caught TypeError which is raised when the passed object is empty (it is an
>empty string).
>
>One of the main complain was that this approach tends to add some business
>logic in the xmlutil and also adding a new exception could hide some potential
>errors.
>I can't disagree but at the same time I say that I am following the same logic
>that we already have there.
>
>We are now stuck, because the long-term solution probably is to rethink the
>XML serialization process to allow more flexibility but that doesn't seem an
>easy task and I really want to get this bug fixed.
>
>What do you think?
>Anyone is available to have a look and give us an opinion?
>
>Please @Llu feel free to add your comments or any missing points.
>
>PS: I am not an expert of the nova xmlutil, could be that I am missing some
>easy points if so, please let me know.
>
>Thanks
>--
>Andrea Rosa
>
>[1] https://bugs.launchpad.net/nova/+bug/1223358
>
>
>___
>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] [qa] Policy on spelling and grammar

2013-11-11 Thread David Kranz

I have seen a wide variety of -1'ing (and in many cases approving) 
patches for minor spelling or grammatical errors and think we need a 
policy about this. Given the large number of contributors for whom 
English is not their native language, I would be in favor of rejecting 
spelling errors in variable or method names but being more lenient in 
comments, commit messages, READMEs, etc. What do you all think?


 -David

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

Re: [openstack-dev] iso8601 filling up nova logs

I didn't see a change yet for this, so I went ahead and submitted one: 
https://review.openstack.org/#/c/55882/


-Ben

On 2013-11-07 02:00, Davanum Srinivas wrote:

+1 - looks like this is where you need to add it [1], if so, the
change needs to be in oslo-incubator repo first [2], so please submit
a review there

[1]
https://github.com/openstack/nova/blob/master/nova/openstack/common/log.py#L128
[2]
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/log.py#L130

On Thu, Nov 7, 2013 at 3:45 PM, Tracy Jones  wrote:
My nova logs are full of this - is it ok if I make a change to the 
default

log level to set iso8601 to WARN?

2:39:54.683 DEBUG iso8601.iso8601 [-] Parsed 2013-11-06T06:38:00Z into
{'tz_sign': None, 'second_fraction': None, 'hour': u'06', 'tz_hour': 
None,

'month': u'11', 'timezone': u'Z', 'second': u'00', 'tz_minute': None,
'year': u'2013', 'separator': u'T', 'day': u'06', 'minute': u'38'} 
with
default timezone  from 
(pid=14941)
parse_date 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:166
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'2013' for 
'year'

with default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'11' for 
'month' with

default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'06' for 'day' 
with

default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'06' for 'hour' 
with

default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'38' for 
'minute'

with default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'00' for 
'second'

with default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.686 DEBUG iso8601.iso8601 [-] Parsed 2013-11-0



___
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]: Welcome to the community site for Solum !!

2013-11-11 Thread Roshan Agrawal


> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Monday, November 11, 2013 3:35 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Solum]: Welcome to the community site for
> Solum !!
> 
> On 11/04/2013 08:25 PM, Roshan Agrawal wrote:
> > The community site for Solum has gone live! www.Solum.io
> >   - this is a landing page for all things Solum
> > related.
> >
> > Also check out the blog section on the site.
> >
> > The logo: is a placeholder for now. We are working on a cool new logo
> > - but the placeholder right now isn't too bad either, is it?
> 
> One nit, instead of linking to github, it would be better to link to 
> OpenStack's
> git interface since that's what we're trying to provide as the canonical repo
> now.
> http://git.openstack.org/cgit/stackforge/solum
> Russell Bryant

Russell, done. Checkout latest @ solum.io

Thanks,
Roshan

 ___
> 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] [Neutron] IPv6 sub-team?

2013-11-11 Thread Shixiong Shang

+1.

We have great interest to run OpenStack over IPv6 and would love to be a
part of the discussion.

Please let me know the date and the time.

Thanks!

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

Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !!

On 11/11/2013 01:05 PM, Roshan Agrawal wrote:
>> One nit, instead of linking to github, it would be better to link to 
>> OpenStack's
>> git interface since that's what we're trying to provide as the canonical repo
>> now.
>> http://git.openstack.org/cgit/stackforge/solum
>> Russell Bryant
> 
> Russell, done. Checkout latest @ solum.io

Thanks.

Now that it isn't a github link, I don't think you can use the octocat
anymore.

https://github.com/logos

-- 
Russell Bryant

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

Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread Clint Byrum

Excerpts from David Kranz's message of 2013-11-11 09:58:59 -0800:
> I have seen a wide variety of -1'ing (and in many cases approving) 
> patches for minor spelling or grammatical errors and think we need a 
> policy about this. Given the large number of contributors for whom 
> English is not their native language, I would be in favor of rejecting 
> spelling errors in variable or method names but being more lenient in 
> comments, commit messages, READMEs, etc. What do you all think?
> 

The point of code review is to find defects. Misspelled words are defects
in the English language encoded in the change. In fact, commit messages
in particular are critical to get right as they cannot ever be fixed,
and they are generally the most useful when under a stressful situation
trying to determine the nature of a regression.

Many of our contributors are also newbies to python, and we do not let
them get away with obvious mistakes in python code. English is just a
language with a different interpreter (a more forgiving one, for sure,
but also one with many versions at various stages of implementation).

In fact, our large percentage of non-native english speakers is a reason
to be extremely careful about grammar and spelling so as not to confuse
non-native speakers with incorrect grammar and spelling.

I believe that if a -1 for a spelling mistake is causing more than an
extremely short turn around time then either the submitter is not engaged
with the project and thus not responsive to the -1, or the reviewers
are over-taxed and the given project needs more reviewers.

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

Re: [openstack-dev] [qa] Policy on spelling and grammar

As long as the -1's include a correction that can be copied
and pasted, I think they're OK.

I know I would be grateful if someone were to
proofread my work, if I had to document in a second-language.

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

Re: [openstack-dev] [Neutron] IPv6 sub-team?

On Mon, Nov 11, 2013 at 01:16:43PM -0500, Shixiong Shang wrote:
> +1.
> 
> We have great interest to run OpenStack over IPv6 and would love to be a
> part of the discussion.

Excellent - please see the thread I've made in OpenStack-Dev - we're
tossing out times for the IRC meeting, that works for everyone
interested.

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

Re: [openstack-dev] [Solum] Some initial code copying for db/migration

2013-11-11 Thread Clayton Coleman



- Original Message -
> > 1) Using objects as an abstraction for versioned data:
> >This seems like a good direction overall, especially from the
> >point-of-view
> >of backwards compatibility of consumers of the object. However, after
> >looking through some
> >of the objects defined in nova/objects/, I am not sure if I understand
> >how
> >this works. Specifically, it is not clear to me how might the consumer
> >of the
> >object be able to query different versions of it at runtime.
> 
> The object registry is handled by the metaclass in objects/base.py. It
> automatically collects objects that inherit from NovaObject, and allows
> multiple versions of the same object to exist. We don't have anything
> that needs to specifically ask the registry directly for "foo object
> version X", so there's no interface for doing that right now. We do,
> however, have incoming objects over RPC that need to be re-hydrated,
> with an "is this compatible" version check. We also have the ability to
> downlevel an object using the obj_make_compatible() method. We are
> planning to always roll the conductor code first, which means it can
> take the newest version of an object from the schema (in whatever state
> it's in) and backlevel it to the version being asked for by a remote RPC
> client.

For places where we may not have an RPC isolation layer, it's similar - the 
code knows what version of the schema to ask for, and the object abstraction 
hides the details of converting between older to newer.

We probably need to map out the scenarios where multiversion is enabled for 
live upgrade - that's the most critical place where you need to ask for 
specific versions.  The Google F1 live schema change paper has a good summary 
of the core issues [1] (and a great diagram on page 9) with live schema 
migration that apply to generic SQL dbs as well.  There are five distinct 
phases:

  1) new code is available that can read the old schema and the new schema, but 
continues to read the old schema
  2) additive elements of the new schema are enabled
  3) new code begins copying/deleting data as its read / updated, and a 
background process is converting the rest of the data
  4) new code starts reading/querying the new fields
  5) old schema data is dropped once all code is reading the new schema

The new code has to know whether it should read the new or old schema - it 
can't read the new schema (query by new column names, by updated data, etc) 
until all of the reads are complete and in place in #4.  That could be a config 
value, something in memory triggered by an admin, etc.

> 
> > 2) Using objects as an abstraction to support different kinds of backends
> >(SQL and non-SQL backends):
> >- Again, a good direction overall. From implementation point-of-view
> >though
> >this may become tricky, in the sense that the object layer would need to
> >be
> >designed with just the right amount of logic so as to be able to work
> >with either
> >a SQL or a non-SQL backend. It will be good to see some examples of how
> >this might
> >be done if there are any existing examples somewhere.
> 
> We don't have any examples of using a non-SQL backend for general
> persistence in Nova, which means we don't have an example of using
> objects to hide it. If what NovaObject currently provides is not
> sufficient to hide the intricacies of a non-SQL persistence layer, I
> think it's probably best to build that on top of what we've got in the
> object model.

The abstraction will probably always leak something, but in general it comes 
down to isolating a full transaction behind a coarse method.  Was going to try 
to demonstrate that as I went.

[1] 
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/41376.pdf

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

Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread Gary Kotton

I am in favor/favour of the -1 with suggestions on what to change. The
more input we can provide on a review the better.
Thanks
Gary

On 11/11/13 8:21 PM, "Collins, Sean (Contractor)"
 wrote:

>As long as the -1's include a correction that can be copied
>and pasted, I think they're OK.
>
>I know I would be grateful if someone were to
>proofread my work, if I had to document in a second-language.
>
>-- 
>Sean M. Collins
>___
>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] [qa] Policy on spelling and grammar


On 2013-11-11 12:19, Clint Byrum wrote:

Excerpts from David Kranz's message of 2013-11-11 09:58:59 -0800:

I have seen a wide variety of -1'ing (and in many cases approving)
patches for minor spelling or grammatical errors and think we need a
policy about this. Given the large number of contributors for whom
English is not their native language, I would be in favor of rejecting
spelling errors in variable or method names but being more lenient in
comments, commit messages, READMEs, etc. What do you all think?



The point of code review is to find defects. Misspelled words are 
defects

in the English language encoded in the change. In fact, commit messages
in particular are critical to get right as they cannot ever be fixed,
and they are generally the most useful when under a stressful situation
trying to determine the nature of a regression.

Many of our contributors are also newbies to python, and we do not let
them get away with obvious mistakes in python code. English is just a
language with a different interpreter (a more forgiving one, for sure,
but also one with many versions at various stages of implementation).

In fact, our large percentage of non-native english speakers is a 
reason

to be extremely careful about grammar and spelling so as not to confuse
non-native speakers with incorrect grammar and spelling.


I was just writing the same thing when I saw your e-mail.  It's hard 
enough to understand English when it's written properly, and stuff like 
docstrings tend to be written once and read many times by many different 
people, so it's important to get them right in the first place.


-Ben

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

Re: [openstack-dev] [qa] Policy on spelling and grammar


On 2013-11-11 12:21, Collins, Sean (Contractor) wrote:

As long as the -1's include a correction that can be copied
and pasted, I think they're OK.

I know I would be grateful if someone were to
proofread my work, if I had to document in a second-language.


+1 to this as well.  I figure that as a reasonably literate native 
English speaker I should be leaving a recommended alternative if I'm 
going to play grammar nazi, especially when it's obvious that the 
committer is not a native English speaker.


-Ben

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

[openstack-dev] [neutron] Group-based Policy Sub-team Meetings

2013-11-11 Thread Kyle Mestery (kmestery)

Hi folks! Hope everyone had a safe trip back from Hong Kong. Friday
afternoon in the Neutron sessions we discussed the "Group-based
Policy Abstraction" BP [1]. It was decided we would try to have a weekly
IRC meeting to drive out further requirements with the hope of coming
up with a list of actionable tasks to begin working on by December.
I've tentatively set the meeting [2] for Thursdays at 1600 UTC on the
#openstack-meeting-alt IRC channel. If there are serious conflicts with
this day and time, please speak up soon. Otherwise, we'll host our
first meeting on Thursday this week.

Thanks!
Kyle

[1] 
https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
[2] 
https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !!

2013-11-11 Thread Rajdeep Dua

Congrats!



On Monday, November 11, 2013 11:51 PM, Russell Bryant  
wrote:
 
On 11/11/2013 01:05 PM, Roshan Agrawal wrote:
>> One nit, instead of linking to github, it would be better to link to 
>> OpenStack's
>> git interface since that's what we're trying to provide as the canonical repo
>> now.
>> http://git.openstack.org/cgit/stackforge/solum
>> Russell Bryant
> 
> Russell, done. Checkout latest @ solum.io

Thanks.

Now that it isn't a github link, I don't think you can use the octocat
anymore.

https://github.com/logos


-- 
Russell Bryant

___
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] Shall backward compatibility env. vars be removed from python-clients?

2013-11-11 Thread Kevin L. Mitchell

On Sat, 2013-11-09 at 14:14 +0800, Sam Morrison wrote:
> I think you need to do option 2 and print deprecation warnings, then the 
> question becomes for how long.
> 
> I think there is a policy for this and that it is deprecate in N remove in N+1
> Clients are a bit different so maybe keep it for ~6 months?

The thing here is, these environment variables have already been
deprecated for quite some time.  The question is, have they been
deprecated long enough that we're clear to drop them entirely?
-- 
Kevin L. Mitchell 
Rackspace


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

Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread James Slagle

-1 from me as well.

When I first started with OpenStack, I probably would have agreed with
letting small grammar mistakes and typos slide by.

However, I now feel that getting commit messages right is more
important.  Also keep in mind that with small grammar mistakes, the
intent may be obvious to a native English speaker, but to another
non-native English speaker it may not be.  And just a few small
grammar mistakes/misspellings/typos can add up until the meaning may
be harder to figure out for another non-native English speaker.

Also, I can't speak for everyone, but in general I've found most folks
open to grammar corrections if English is not their native language
b/c they want to learn and fix the mistakes.


-- 
-- James Slagle
--

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

Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread Jay S Bryant

+2 to Clint's comments.

As OpenStack gains a wider following in the corporate world and given that 
the code for OpenStack may be seen by anyone, I think it is very important 
to get spelling and grammar right.  I also think it is important to ensure 
that the commit messages concisely communicate the change that is being 
made.

I regularly comment on misspellings and in the case that a commit message 
is difficult to understand provide suggestions for rewording to make sure 
I understand what is being communicated.

So, I think -1's are fine as long is assistance is being provided.

The point of OpenStack is to have a collaborative community.  Some people 
bring better spelling and grammar to the table than others as a 
contribution.



Jay S. Bryant
Linux Developer - 
OpenStack Enterprise Edition
   
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Clint Byrum 
To: openstack-dev , 
Date:   11/11/2013 12:21 PM
Subject:Re: [openstack-dev] [qa] Policy on spelling and grammar



Excerpts from David Kranz's message of 2013-11-11 09:58:59 -0800:
> I have seen a wide variety of -1'ing (and in many cases approving) 
> patches for minor spelling or grammatical errors and think we need a 
> policy about this. Given the large number of contributors for whom 
> English is not their native language, I would be in favor of rejecting 
> spelling errors in variable or method names but being more lenient in 
> comments, commit messages, READMEs, etc. What do you all think?
> 

The point of code review is to find defects. Misspelled words are defects
in the English language encoded in the change. In fact, commit messages
in particular are critical to get right as they cannot ever be fixed,
and they are generally the most useful when under a stressful situation
trying to determine the nature of a regression.

Many of our contributors are also newbies to python, and we do not let
them get away with obvious mistakes in python code. English is just a
language with a different interpreter (a more forgiving one, for sure,
but also one with many versions at various stages of implementation).

In fact, our large percentage of non-native english speakers is a reason
to be extremely careful about grammar and spelling so as not to confuse
non-native speakers with incorrect grammar and spelling.

I believe that if a -1 for a spelling mistake is causing more than an
extremely short turn around time then either the submitter is not engaged
with the project and thus not responsive to the -1, or the reviewers
are over-taxed and the given project needs more reviewers.

___
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] Horizon PTL candidacy

2013-11-11 Thread Clint Byrum

Excerpts from Matthias Runge's message of 2013-11-11 00:04:52 -0800:
> On 11/10/2013 11:53 PM, John Dickinson wrote:
> > A random off-the-top-of-my-head use case would be to subscribe to
> > events from creating or changing objects in a particular Swift
> > account or container. This would allow much more efficient listings
> > in Horizon for active containers (and may also be consumed by other
> > listeners too).
> > 
> > --John
> > 
> 
> yupp.
> There are many many usecases for this, and we'd get rid of pulling
> services for status.
> 

Note that Heat can also make use of this, and a need for such things
came up during several session discussions. I forget who said this,
but it sums up the problem:

"Polling sucks"

I'd hope that we keep it a public API of some sorts, so that users can
also take advantage of it.

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

Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread John Griffith

On Tue, Nov 12, 2013 at 2:49 AM, James Slagle  wrote:
> -1 from me as well.
>
> When I first started with OpenStack, I probably would have agreed with
> letting small grammar mistakes and typos slide by.
>
> However, I now feel that getting commit messages right is more
> important.  Also keep in mind that with small grammar mistakes, the
> intent may be obvious to a native English speaker, but to another
> non-native English speaker it may not be.  And just a few small
> grammar mistakes/misspellings/typos can add up until the meaning may
> be harder to figure out for another non-native English speaker.
>
> Also, I can't speak for everyone, but in general I've found most folks
> open to grammar corrections if English is not their native language
> b/c they want to learn and fix the mistakes.
>
>
> --
> -- James Slagle
> --
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Guess I'm in the minority with here... some of the nits in commit
messages and comments is a bit extreme.  Sure there are some cases
where I think offering a correction is great/appropriate, but for
example issuing a -1 on somebody's patch because they mixed up their
use of 'there' seems a bit lame.

Seems to me there's a middle ground here, but honestly if you're value
add to the review process is catching grammatical or spelling errors
in comments and commit messages I'd argue that in most cases it would
be nice to have more substantive feedback to go along with it.  I
happen to be a top offender here in terms of grammar or spelling
errors in comments so I'm a bit biased on the topic. :)

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

Re: [openstack-dev] Horizon PTL candidacy

2013-11-11 Thread Gabriel Hurley

We all agree on the benefits of an event-driven "push" system, but the basis 
for this already exists in OpenStack. The RPC notification code exists in Oslo 
and most of the IaaS projects are using it now. There were (should have been?) 
conversations about how to leverage this data stream in the Horizon sessions in 
Hong Kong.

As I understood it, Marconi has a completely different goal (queuing service a 
la SQS) which operates as a "building block" service for user applications, not 
as a publication channel for the core OpenStack infrastructure.

Anyhow, we agree on the goal and have plans for how to do it already; Marconi 
ought to be an orthogonal concern when it's ready for graduation.

My two cents,

 - Gabriel

> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: Monday, November 11, 2013 11:02 AM
> To: openstack-dev
> Subject: Re: [openstack-dev] Horizon PTL candidacy
> 
> Excerpts from Matthias Runge's message of 2013-11-11 00:04:52 -0800:
> > On 11/10/2013 11:53 PM, John Dickinson wrote:
> > > A random off-the-top-of-my-head use case would be to subscribe to
> > > events from creating or changing objects in a particular Swift
> > > account or container. This would allow much more efficient listings
> > > in Horizon for active containers (and may also be consumed by other
> > > listeners too).
> > >
> > > --John
> > >
> >
> > yupp.
> > There are many many usecases for this, and we'd get rid of pulling
> > services for status.
> >
> 
> Note that Heat can also make use of this, and a need for such things came up
> during several session discussions. I forget who said this, but it sums up the
> problem:
> 
> "Polling sucks"
> 
> I'd hope that we keep it a public API of some sorts, so that users can also 
> take
> advantage of it.
> 
> ___
> 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] [Horizon] Introduction of AngularJS in membership workflow

2013-11-11 Thread Jordan OMara

Hello Horizon!

On November 11th, we submitted a patch to introduce AngularJS into
Horizon [1]. We believe AngularJS adds a lot of value to Horizon.

First, AngularJS allows us to write HTML templates for interactive
elements instead of doing jQuery-based DOM manipulation. This allows
the JavaScript layer to focus on business logic, provides easy to
write JavaScript testing that focuses on the concern (e.g. business
logic, template, DOM manipulation), and eases the on-boarding for new
developers working with the JavaScript libraries.

Second, AngularJS is not an all or nothing solution and integrates
with the existing Django templates. For each feature that requires
JavaScript, we can write a self-contained directive to handle the DOM,
a template to define our view and a controller to contain the business
logic. Then, we can add this directive to the existing template. To
see an example in action look at _workflow_step_update_member.html
[2]. It can also be done incrementally - this isn't an all-or-nothing
approach with a massive front-end time investment, as the Angular
components can be introduced over time.

Finally, the initial work to bring AngularJS to Horizon provides a

springboard to remove the "DOM Database" (i.e. hidden-divs) used on
the membership page (and others). Instead of abusing the DOM, we can
instead expose an API for membership data, add an AngularJS resource
(i.e. reusable representation of API entities) for the API. The data
can then be loaded data asynchronously and allow the HTML to focus on
expressing a semantic representation of the data to the user.

Please give our patch a try! You can find the interactions on

Domains/Groups, Flavors/Access(this form does not seem to work in
current master or on my patch) and Projects/Users&Groups. You should
notice that it behaves...exactly the same!

We look forward to your feedback.
Jordan O'Mara & Jirka Tomasek

[1] [https://review.openstack.org/#/c/55901/]
[2] [https://github.com/jsomara/horizon/blob/angular2/horizon/templates/horizon/common/_workflow_step_update_members.html]

--
Jordan O'Mara
Red Hat Engineering, Raleigh

pgpZe8F1BKZYs.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

2013-11-11 Thread Joe Gordon

On Sun, Nov 10, 2013 at 3:50 PM, Sean Dague  wrote:

> Not that I know of. I've considered writing my own gerrit front end
> mail service to do just that, because I agree, the current mail volume
> and granularity is not very good. If I manage to carve time on it,
> I'll do it on stackforge. Joe Gordon took a different approach and
> wrote a front end client to mark review threads read that are past.
>

https://github.com/jogo/gerrit-gmail


>
> On Thu, Nov 7, 2013 at 8:40 PM, David Ripton  wrote:
> > On 11/07/2013 07:54 PM, Sean Dague wrote:
> >>
> >> On 11/08/2013 01:37 AM, Pedro Roque Marques wrote:
> >>>
> >>> Radomir,
> >>> An extra issue that i don't believe you've covered so far is about
> >>> comment ownership. I've just read an email on the list that follows a
> >>> pattern that i've heard many complaints about:
> >>> -1 with a reasonable comment, submitter addresses the comment,
> >>> reviewer never comes back.
> >>>
> >>> Reviewers do need to allocate time to come back and follow up on the
> >>> answers to their comments.
> >>>
> >>> Perhaps there is an issue with the incentive system. You can earn karma
> >>> by doing a code review... certainly you want to incentivise developers
> that
> >>> help the project by improving the code quality. But if the incentive
> system
> >>> allows for "drive by shooting" code reviews that can be a problem.
> >>
> >>
> >> It's not really an incentive system problem, this is some place where
> >> there are some gerrit limitations (especially when your list of reviewed
> >> code is long). Hopefully once we get a gerrit upgrade we can dashboard
> >> out some new items like that via the new rest API.
> >>
> >> I agree that reviewers could be doing better. But definitely also
> >> realize that part of this is just that there is *so* much code to
> review.
> >>
> >> Realize that most core reviewers aren't ignoring or failing to come back
> >> on patches intentionally. There is just *so* much of it. I feel guilty
> >> all the time by how big a review queue I have, but I also need a few
> >> hours a day not doing OpenStack (incredible to believe). This is where
> >> non core reviewers can really help in addressing the first couple of
> >> rounds of review to prune and improve the easy stuff.
> >>
> >> We're all in this together,
> >
> >
> > Is there a way for Gerrit to only send email when action is required,
> rather
> > than on any change to any review you've touched?  If Gerrit sent less
> mail,
> > it would be easier to treat its mails as a critical call to action to
> > re-review.  (There's probably a way to use fancy message filtering to
> > accomplish this, but that would only work for people willing/able to set
> up
> > such filtering.)
> >
> > --
> > 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
>
>
>
> --
> Sean Dague
> 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

Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread Tim Bell


As a speaker of the Queen's English, I find flavor to be incorrect. Does that 
mean I can -1 any patch that does not use flavour ?

At CERN, we are working with 130 countries in a single community. The value of 
the contribution of non-english speakers far exceeds the occasional 
misunderstandings.

Giving grammar/spellings -1 excludes major sections of the community from 
contribution.

As our aim is meritocracy (in python, computer architecture and design rather 
than spelling), I'd propose

- If someone identifies a need for clarification/correction as part of a 
review, they also submit the replacement text rather than just -1.
- The submitter incorporates that change into a patch

Tim

> -Original Message-
> From: John Griffith [mailto:john.griff...@solidfire.com]
> Sent: 11 November 2013 20:03
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [qa] Policy on spelling and grammar
> 
> On Tue, Nov 12, 2013 at 2:49 AM, James Slagle  wrote:
> > -1 from me as well.
> >
> > When I first started with OpenStack, I probably would have agreed with
> > letting small grammar mistakes and typos slide by.
> >
> > However, I now feel that getting commit messages right is more
> > important.  Also keep in mind that with small grammar mistakes, the
> > intent may be obvious to a native English speaker, but to another
> > non-native English speaker it may not be.  And just a few small
> > grammar mistakes/misspellings/typos can add up until the meaning may
> > be harder to figure out for another non-native English speaker.
> >
> > Also, I can't speak for everyone, but in general I've found most folks
> > open to grammar corrections if English is not their native language
> > b/c they want to learn and fix the mistakes.
> >
> >
> > --
> > -- James Slagle
> > --
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Guess I'm in the minority with here... some of the nits in commit messages 
> and comments is a bit extreme.  Sure there are some cases
> where I think offering a correction is great/appropriate, but for example 
> issuing a -1 on somebody's patch because they mixed up their
> use of 'there' seems a bit lame.
> 
> Seems to me there's a middle ground here, but honestly if you're value add to 
> the review process is catching grammatical or spelling
> errors in comments and commit messages I'd argue that in most cases it would 
> be nice to have more substantive feedback to go along
> with it.  I happen to be a top offender here in terms of grammar or spelling 
> errors in comments so I'm a bit biased on the topic. :)
> 
> ___
> 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] [Neutron] Reminder no Neuron team meeting Nov 11th

2013-11-11 Thread Mark McClain

All-

I hope everyone had safe travels from the Icehouse summit.  As previously 
discussed, we will not be meeting today (November 11th).  We will resume our 
weekly meetings on November 18th at 2100 UTC.  

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

Re: [openstack-dev] Shall backward compatibility env. vars be removed from python-clients?

2013-11-11 Thread Dean Troyer

On Mon, Nov 11, 2013 at 12:46 PM, Kevin L. Mitchell <
kevin.mitch...@rackspace.com> wrote:

> The thing here is, these environment variables have already been
> deprecated for quite some time.  The question is, have they been
> deprecated long enough that we're clear to drop them entirely?
>

I say yes, over a year in the auth variable cases seems to be plenty long
to me.

Related but different are the now-long-undocumented option names with
underscores in them.  I've noticed new undocumented ones get added from
time to time alongside the same option with dashes.  ???

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

2013-11-11 Thread Michael Basnight

> On Nov 11, 2013, at 11:27 AM, Joe Gordon  wrote:
> 
> 
>> On Sun, Nov 10, 2013 at 3:50 PM, Sean Dague  wrote:
>> Not that I know of. I've considered writing my own gerrit front end
>> mail service to do just that, because I agree, the current mail volume
>> and granularity is not very good. If I manage to carve time on it,
>> I'll do it on stackforge. Joe Gordon took a different approach and
>> wrote a front end client to mark review threads read that are past.
> 
> https://github.com/jogo/gerrit-gmail
>  

Joe described this to me, and it sounded hawt. Thanks for sending this out. 

From what I gather it auto marks email as read based on merges and abandons. 
Joe, are there any dependencies, workflows, insights you can share wrt this?___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Script to operate on trove

2013-11-11 Thread Krishanu Dhar

Hi,

I have to query the network and fetch details of all the hardware devices
present in the datacenter and maintain the details in the back-end db. I
plan to use trove as the back-end database. I have code written to get the
details from the devices, but not sure how to perform operations in the
open stack db.

Can someone help me with a sample code that creates/updates tables in trove
please?

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

Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread Christopher Armstrong

On Mon, Nov 11, 2013 at 12:19 PM, Clint Byrum  wrote:

> Excerpts from David Kranz's message of 2013-11-11 09:58:59 -0800:
> > I have seen a wide variety of -1'ing (and in many cases approving)
> > patches for minor spelling or grammatical errors and think we need a
> > policy about this. Given the large number of contributors for whom
> > English is not their native language, I would be in favor of rejecting
> > spelling errors in variable or method names but being more lenient in
> > comments, commit messages, READMEs, etc. What do you all think?
> >
>
> The point of code review is to find defects. Misspelled words are defects
> in the English language encoded in the change. In fact, commit messages
> in particular are critical to get right as they cannot ever be fixed,
> and they are generally the most useful when under a stressful situation
> trying to determine the nature of a regression.
>
> Many of our contributors are also newbies to python, and we do not let
> them get away with obvious mistakes in python code. English is just a
> language with a different interpreter (a more forgiving one, for sure,
> but also one with many versions at various stages of implementation).
>
> In fact, our large percentage of non-native english speakers is a reason
> to be extremely careful about grammar and spelling so as not to confuse
> non-native speakers with incorrect grammar and spelling.
>
> I believe that if a -1 for a spelling mistake is causing more than an
> extremely short turn around time then either the submitter is not engaged
> with the project and thus not responsive to the -1, or the reviewers
> are over-taxed and the given project needs more reviewers.
>
>

It would be so much nicer if there were some easy way for the reviewer
himself to fix the typos directly (in a way that can trivially be accepted
by the submitter of the patch into his own patch -- with a click of a
button).


-- 
Christopher Armstrong
http://radix.twistedmatrix.com/
http://planet-if.com/
___
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

2013-11-11 Thread Dean Troyer

On Mon, Nov 11, 2013 at 12:01 AM, Clayton Coleman wrote:

> The implication I heard from the session is the command infrastructure and
> client code have or will have a well defined interface from the framework,
> although I haven't looked through current state enough to say that's
> totally true today.  If that interface is in place we certainly would be
> better isolated from upstream.
>

OSC has a very simple plugin mechanism that is little more than pre-defined
entry point groups that are scanned for additional commands.  That works
but doesn't properly leverage the desirable common bits, such as auth, that
are available to the built-in clients.  Enhancing this has not been a high
priority before now but needs to be done.

I guess it depends where we want to spend our focus as well - do we write
> something that in the long run we'd end up porting, or benefit from the
> work the common client is doing (doc, common patterns, keystone auth work
> with x509 and potentially Kerberos, bash completion, etc) as well as help
> them out.
>

I'd suggest you focus on putting together a clean and well-defined library
API that implements your REST API.  Consider that work is going on to
refactor the implementation of these layers in existing clients and that
some of the library APIs will be changing.  Specifically, the first of
these efforts is a much-needed cleanup of the Identity Auth interfaces and
the migration of existing clients to use that rather than their own
embedded auth.

Please don't just copy one of the existing clients, down that path lies
madness.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Shall backward compatibility env. vars be removed from python-clients?

2013-11-11 Thread Kevin L. Mitchell

On Mon, 2013-11-11 at 13:35 -0600, Dean Troyer wrote:
> Related but different are the now-long-undocumented option names with
> underscores in them.  I've noticed new undocumented ones get added
> from time to time alongside the same option with dashes.  ??? 

I discourage those when I catch them in novaclient, but I figure if we
can remove the NOVA_* environment variables, we can probably also remove
those wholesale, and that should effectively discourage the
pattern-matching that causes developers to try to include them in the
first place :)
-- 
Kevin L. Mitchell 
Rackspace


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

Re: [openstack-dev] [qa] Policy on spelling and grammar