date:20131024

Hi, Salvatore,

I guess 'router_service_type' extension is used together with
'router_service_insertion'.

The purpose of this blueprint is to allow multiple vendor's routing
services coexist in a network. One router can be implemented by L3 agent,
another one might be from vArmour, NVP or Cisco, for example.

Thanks,
Gary


On Thu, Oct 24, 2013 at 4:13 PM, Salvatore Orlando wrote:

> Gary,
>
> In the context of the nvp plugin we use a mechanism for enabling
> 'advanced' capabilities of a router leveraging a 'router_service_type'
> extension.
> this allow us to configure two types of routers, one which does just L3
> forwarding, NAT and a few other things, and another one which also has the
> capability of hosting adv services such as firewall and load balancing.
>
> Is this similar to what you want to achieve with this blueprint?
>
> Regards,
> Salvatore
>
>
> On 25 October 2013 01:03, Gary Duan  wrote:
>
>> Hi, Oda-san,
>>
>> Thanks for your response.
>>
>> L3 agent function should remain the same, as one driver implementation of
>> L3 router plugin.
>>
>> My understanding is your lbaas driver can be running on top of L3 agent
>> and LVS' own routing services. Is my understanding correct?
>>
>> Thanks,
>> Gary
>>
>>
>> On Thu, Oct 24, 2013 at 3:16 PM, Itsuro ODA  wrote:
>>
>>> Hi,
>>>
>>> We are going to implement 2-arm type lbaas using LVS, and have submitted
>>> the following BPs.
>>>
>>>
>>> https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion
>>> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver
>>> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features
>>>
>>> Maybe the first one is same as yours.
>>> We are happy if we just concentrate making a provider driver.
>>>
>>> Thanks.
>>> Itsuro Oda
>>>
>>> On Thu, 24 Oct 2013 11:56:53 -0700
>>> Gary Duan  wrote:
>>>
>>> > Hi,
>>> >
>>> > I've registered a BP for L3 router service integration with service
>>> > framework.
>>> >
>>> > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type
>>> >
>>> > In general, the implementation will align with how LBaaS is integrated
>>> with
>>> > the framework. One consideration we heard from several team members is
>>> to
>>> > be able to support vendor specific features and extensions in the
>>> service
>>> > plugin.
>>> >
>>> > Any comment is welcome.
>>> >
>>> > Thanks,
>>> > Gary
>>>
>>> --
>>> Itsuro ODA 
>>>
>>>
>>> ___
>>> 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] [Neutron] L3 router service integration with Service Type Framework

Hi, Geoff,

This is because I haven't added spec to the BP yet.

Gary


On Thu, Oct 24, 2013 at 4:51 PM, Geoff Arnold  wrote:

> I’m getting a *“**Not allowed here”* error when I click through to the
> BP. (Yes, I’m subscribed.)
>
> On Oct 24, 2013, at 11:56 AM, Gary Duan  wrote:
>
> Hi,
>
> I've registered a BP for L3 router service integration with service
> framework.
>
> https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type
>
> In general, the implementation will align with how LBaaS is integrated
> with the framework. One consideration we heard from several team members is
> to be able to support vendor specific features and extensions in the
> service plugin.
>
> Any comment is welcome.
>
> Thanks,
> Gary
>
>
> ___
> 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] [Heat] HOT Software configuration proposal

2013-10-24 Thread Keith Bray

Hi Thomas, here's my opinion:  Heat and Solum contributors will work
closely together to figure out where specific feature implementations
belong... But, in general, Solum is working at a level above Heat.  To
write a Heat template, you have to know about infrastructure setup and
configuration settings of infrastructure and API services.  I believe
Solum intends to provide the ability to tweak and configure the amount of
complexity that gets exposed or hidden so that it becomes easier for cloud
consumers to just deal with their application and not have to necessarily
know or care about the underlying infrastructure and API services, but
that level of detail can be exposed to them if necessary. Solum will know
what infrastructure and services to set up to run applications, and it
will leverage Heat and Heat templates for this.

The Solum project has been very vocal about leveraging Heat under the hood
for the functionality and vision of orchestration that it intends to
provide.  It seems, based on this thread (and +1 from me), enough people
are interested in having Heat provide some level of software
orchestration, even if it's just bootstrapping other CM tools and
coordinating the "when are you done", and I haven't heard any Solum folks
object to Heat implementing software orchestration capabilities... So, I'm
looking forward to great discussions on this topic for Heat at the summit.
 If you recall, Adrian Otto (who announced project Solum) was also the one
who was vocal at the Portland summit about the need for HOT syntax.  I
think both projects are on a good path with a lot of fun collaboration
time ahead.

Kind regards,
-Keith

On 10/24/13 7:56 AM, "Thomas Spatzier"  wrote:

>Hi all,
>
>maybe a bit off track with respect to latest concrete discussions, but I
>noticed the announcement of project "Solum" on openstack-dev.
>Maybe this is playing on a different level, but I still see some relation
>to all the software orchestration we are having. What are your opinions on
>this?
>
>BTW, I just posted a similar short question in reply to the Solum
>announcement mail, but some of us have mail filters an might read [Heat]
>mail with higher prio, and I was interested in the Heat view.
>
>Cheers,
>Thomas
>
>Patrick Petit  wrote on 24.10.2013 12:15:13:
>> From: Patrick Petit 
>> To: OpenStack Development Mailing List
>,
>> Date: 24.10.2013 12:18
>> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>>
>> Sorry, I clicked the 'send' button too quickly.
>>
>> On 10/24/13 11:54 AM, Patrick Petit wrote:
>> > Hi Clint,
>> > Thank you! I have few replies/questions in-line.
>> > Cheers,
>> > Patrick
>> > On 10/23/13 8:36 PM, Clint Byrum wrote:
>> >> Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:
>> >>> Dear Steve and All,
>> >>>
>> >>> If I may add up on this already busy thread to share our experience
>> >>> with
>> >>> using Heat in large and complex software deployments.
>> >>>
>> >> Thanks for sharing Patrick, I have a few replies in-line.
>> >>
>> >>> I work on a project which precisely provides additional value at the
>> >>> articulation point between resource orchestration automation and
>> >>> configuration management. We rely on Heat and chef-solo respectively
>> >>> for
>> >>> these base management functions. On top of this, we have developed
>>an
>> >>> event-driven workflow to manage the life-cycles of complex software
>> >>> stacks which primary purpose is to support middleware components as
>> >>> opposed to end-user apps. Our use cases are peculiar in the sense
>that
>> >>> software setup (install, config, contextualization) is not a
>>one-time
>> >>> operation issue but a continuous thing that can happen any time in
>> >>> life-span of a stack. Users can deploy (and undeploy) apps long time
>> >>> after the stack is created. Auto-scaling may also result in an
>> >>> asynchronous apps deployment. More about this latter. The framework
>we
>> >>> have designed works well for us. It clearly refers to a PaaS-like
>> >>> environment which I understand is not the topic of the HOT software
>> >>> configuration proposal(s) and that's absolutely fine with us.
>However,
>> >>> the question for us is whether the separation of software config
>>from
>> >>> resources would make our life easier or not. I think the answer is
>> >>> definitely yes but at the condition that the DSL extension preserves
>> >>> almost everything from the expressiveness of the resource element.
>>In
>> >>> practice, I think that a strict separation between resource and
>> >>> component will be hard to achieve because we'll always need a little
>> >>> bit
>> >>> of application's specific in the resources. Take for example the
>> >>> case of
>> >>> the SecurityGroups. The ports open in a SecurityGroup are
>>application
>> >>> specific.
>> >>>
>> >> Components can only be made up of the things that are common to all
>> >> users
>> >> of said component. Also components would, if I understand the concept
>

[openstack-dev] [Ironic] Nominating Lucas Gomes to ironic core

2013-10-24 Thread Devananda van der Veen

Hi all,

I'd like to nominate Lucas Gomes for ironic-core. He's been consistently
doing reviews for several months and has led a lot of the effort on the API
and client libraries.

Thanks for the great work!
-Deva

http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework

2013-10-24 Thread Geoff Arnold

I’m getting a “Not allowed here” error when I click through to the BP. (Yes, 
I’m subscribed.)

On Oct 24, 2013, at 11:56 AM, Gary Duan  wrote:

> Hi,
> 
> I've registered a BP for L3 router service integration with service framework.
> 
> https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type
> 
> In general, the implementation will align with how LBaaS is integrated with 
> the framework. One consideration we heard from several team members is to be 
> able to support vendor specific features and extensions in the service plugin.
> 
> Any comment is welcome.
> 
> Thanks,
> Gary
> 
> 
> ___
> 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] L3 router service integration with Service Type Framework

2013-10-24 Thread Itsuro ODA

Hi Gray,

Thanks for your response.

Our plan is as follows:
* LVS driver is one of lbaas provider driver.
  It communicates with l3_agent instead of lbaas_agent.
* For l3_agent side, I think the implementation is same as
  fwaas. L3NATAgent inherits like LVSL3AgentRpcCallback
  class added which communicates with LVS provider driver.
  So l3_agent functions already existed are not changed,
  just added LB function.
  I think the implementation would change depending on
  the service chaining discussion.

Thanks,
Itsuto Oda

# note that Toshihiro Iwamoto, a main developer of our BPs
# may replay instead of me. He will attend the HK summit.

On Thu, 24 Oct 2013 16:03:25 -0700
Gary Duan  wrote:

> Hi, Oda-san,
> 
> Thanks for your response.
> 
> L3 agent function should remain the same, as one driver implementation of
> L3 router plugin.
> 
> My understanding is your lbaas driver can be running on top of L3 agent and
> LVS' own routing services. Is my understanding correct?
> 
> Thanks,
> Gary
> 
> 
> On Thu, Oct 24, 2013 at 3:16 PM, Itsuro ODA  wrote:
> 
> > Hi,
> >
> > We are going to implement 2-arm type lbaas using LVS, and have submitted
> > the following BPs.
> >
> >
> > https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion
> > https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver
> > https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features
> >
> > Maybe the first one is same as yours.
> > We are happy if we just concentrate making a provider driver.
> >
> > Thanks.
> > Itsuro Oda
> >
> > On Thu, 24 Oct 2013 11:56:53 -0700
> > Gary Duan  wrote:
> >
> > > Hi,
> > >
> > > I've registered a BP for L3 router service integration with service
> > > framework.
> > >
> > > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type
> > >
> > > In general, the implementation will align with how LBaaS is integrated
> > with
> > > the framework. One consideration we heard from several team members is to
> > > be able to support vendor specific features and extensions in the service
> > > plugin.
> > >
> > > Any comment is welcome.
> > >
> > > Thanks,
> > > Gary
> >
> > --
> > Itsuro ODA 
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

-- 
Itsuro ODA 


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

Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework

2013-10-24 Thread Salvatore Orlando

Gary,

In the context of the nvp plugin we use a mechanism for enabling 'advanced'
capabilities of a router leveraging a 'router_service_type' extension.
this allow us to configure two types of routers, one which does just L3
forwarding, NAT and a few other things, and another one which also has the
capability of hosting adv services such as firewall and load balancing.

Is this similar to what you want to achieve with this blueprint?

Regards,
Salvatore


On 25 October 2013 01:03, Gary Duan  wrote:

> Hi, Oda-san,
>
> Thanks for your response.
>
> L3 agent function should remain the same, as one driver implementation of
> L3 router plugin.
>
> My understanding is your lbaas driver can be running on top of L3 agent
> and LVS' own routing services. Is my understanding correct?
>
> Thanks,
> Gary
>
>
> On Thu, Oct 24, 2013 at 3:16 PM, Itsuro ODA  wrote:
>
>> Hi,
>>
>> We are going to implement 2-arm type lbaas using LVS, and have submitted
>> the following BPs.
>>
>>
>> https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion
>> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver
>> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features
>>
>> Maybe the first one is same as yours.
>> We are happy if we just concentrate making a provider driver.
>>
>> Thanks.
>> Itsuro Oda
>>
>> On Thu, 24 Oct 2013 11:56:53 -0700
>> Gary Duan  wrote:
>>
>> > Hi,
>> >
>> > I've registered a BP for L3 router service integration with service
>> > framework.
>> >
>> > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type
>> >
>> > In general, the implementation will align with how LBaaS is integrated
>> with
>> > the framework. One consideration we heard from several team members is
>> to
>> > be able to support vendor specific features and extensions in the
>> service
>> > plugin.
>> >
>> > Any comment is welcome.
>> >
>> > Thanks,
>> > Gary
>>
>> --
>> Itsuro ODA 
>>
>>
>> ___
>> 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] [Neutron] L3 router service integration with Service Type Framework

Hi, Oda-san,

Thanks for your response.

L3 agent function should remain the same, as one driver implementation of
L3 router plugin.

My understanding is your lbaas driver can be running on top of L3 agent and
LVS' own routing services. Is my understanding correct?

Thanks,
Gary


On Thu, Oct 24, 2013 at 3:16 PM, Itsuro ODA  wrote:

> Hi,
>
> We are going to implement 2-arm type lbaas using LVS, and have submitted
> the following BPs.
>
>
> https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion
> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver
> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features
>
> Maybe the first one is same as yours.
> We are happy if we just concentrate making a provider driver.
>
> Thanks.
> Itsuro Oda
>
> On Thu, 24 Oct 2013 11:56:53 -0700
> Gary Duan  wrote:
>
> > Hi,
> >
> > I've registered a BP for L3 router service integration with service
> > framework.
> >
> > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type
> >
> > In general, the implementation will align with how LBaaS is integrated
> with
> > the framework. One consideration we heard from several team members is to
> > be able to support vendor specific features and extensions in the service
> > plugin.
> >
> > Any comment is welcome.
> >
> > Thanks,
> > Gary
>
> --
> Itsuro ODA 
>
>
> ___
> 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] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Boris Pavlovic

Michael,


>> - pruning isn't done by the system automatically, so we have to assume
it never happens


We are working around it
https://blueprints.launchpad.net/nova/+spec/db-purge-engine



>>  - we need to have a clearer consensus about what we think the maximum
>> size of a nova deployment is. Are we really saying we don't support
>> nova installs with a million instances? If so what is the maximum
>> number of instances we're targeting? Having a top level size in mind
>> isn't a bad thing, but I don't think we have one at the moment that we
>> all agree on. Until that happens I'm going to continue targeting the
>> largest databases people have told me about (plus a fudge factor).


Rally https://wiki.openstack.org/wiki/Rally should help us to determine
this.

At this moment I can just use theoretical knowledges.
(and they said even 1mln instances in current nova implementation won't
work)



Best regards,
Boris Pavlovic



On Fri, Oct 25, 2013 at 2:35 AM, Michael Still  wrote:

> On Fri, Oct 25, 2013 at 9:07 AM, Boris Pavlovic  wrote:
> > Johannes,
> >
> > +1, purging should help here a lot.
>
> Sure, but my point is more:
>
>  - pruning isn't done by the system automatically, so we have to
> assume it never happens
>
>  - we need to have a clearer consensus about what we think the maximum
> size of a nova deployment is. Are we really saying we don't support
> nova installs with a million instances? If so what is the maximum
> number of instances we're targeting? Having a top level size in mind
> isn't a bad thing, but I don't think we have one at the moment that we
> all agree on. Until that happens I'm going to continue targeting the
> largest databases people have told me about (plus a fudge factor).
>
> Michael
>
> --
> Rackspace Australia
>
> ___
> 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] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Mark Washenberger

On Thu, Oct 24, 2013 at 3:06 PM, Robert Collins
wrote:

> On 25 October 2013 10:04, Chris Behrens  wrote:
> >
> > On Oct 24, 2013, at 1:33 PM, Robert Collins 
> wrote:
> >
> >> -2 to 10 minute downtimes.
> >>
> >> +1 to doing the evolution gracefully. There is a spec for doing that
> >> from the H summit; someone just needs to implement it.
> >
> > +1.  IMO, we need to move to a model where code can understand multiple
> schemas and migrate to newer schema on the fly.  The object code in nova
> will be able to help us do this.  Combine this with some sort of background
> task if you need to speed up the conversion.  Any migrations that need to
> run through all of the data in a table during downtime is just not going to
> scale.
> >
> > I am personally tired of having to deal with DB migrations having to run
> for 1 hour during upgrades that happened numerous times throughout the
> Havana development cycle.
>
> We had a clear design at the H summit, and folk committed to working
> on it (Johannes and Mark W); not sure what happened...
>

/me runs from room crying


>
> https://etherpad.openstack.org/p/HavanaNoDowntimeDBMigrations
>
> -Rob
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> 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]LBaaS] - Questions on IP Allocation Logic for VIP

2013-10-24 Thread Pattabi Ayyasami

Hi,



We encounter the following error in our lab when we auto allocate the VIP IP 
Address for create_vip API.



==

ERROR: quantumclient.shell Unable to complete operation for network 
f51735cc-c62e-438d-bc9f-26792c2486b9.

The IP address 172.21.72.8 is in use.

==


We basically have the following questions.



1. How does neutron/quantum checks if IP address is already used or not?

   (Engineer data with NULL ID on ipallocation table, so he wonders if data 
with NULL ID has something to do with IP address allocation)

2. Will Data with NULL ID on ipallocations be removed sometime after? If so 
what would be the timing ?

3. Value of first_ip in ipavailabilityranges seems to be increasing rapidly, 
but when this value will be reset ?


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

Re: [openstack-dev] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Michael Still

On Fri, Oct 25, 2013 at 9:07 AM, Boris Pavlovic  wrote:
> Johannes,
>
> +1, purging should help here a lot.

Sure, but my point is more:

 - pruning isn't done by the system automatically, so we have to
assume it never happens

 - we need to have a clearer consensus about what we think the maximum
size of a nova deployment is. Are we really saying we don't support
nova installs with a million instances? If so what is the maximum
number of instances we're targeting? Having a top level size in mind
isn't a bad thing, but I don't think we have one at the moment that we
all agree on. Until that happens I'm going to continue targeting the
largest databases people have told me about (plus a fudge factor).

Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [Nova] Blueprint review process

2013-10-24 Thread Alan Kavanagh

Is this really a viable solution? 
I believe its more "democratic to ensure everyone gets a chance to present the 
blueprint" someone has spent time to write. This was no favoritism or biased 
view will ever take place and we let the community gauge the interest. 

/Alan

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: October-24-13 5:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Blueprint review process

On 10/24/2013 10:52 AM, Gary Kotton wrote:
> 
> 
> On 10/24/13 4:46 PM, "Dan Smith"  wrote:
> 
>>> In the last meeting we discussed an idea that I think is worth 
>>> trying at least for icehouse-1 to see if we like it or not.  The 
>>> idea is that
>>> *every* blueprint starts out at a Low priority, which means "best 
>>> effort, but no promises".  For a blueprint to get prioritized 
>>> higher, it should have 2 nova-core members signed up to review the 
>>> resulting code.
>>
>> Huge +1 to this. I'm in favor of the whole plan, but specifically the 
>> prioritization piece is very important, IMHO.
> 
> I too am in favor of the idea. It is just not clear how 2 Nova cores 
> will be signed up.

Good point, there was no detail on that.  I propose just comments on the 
blueprint whiteboard.  It can be something simple like this to indicate that 
Dan and I have agreed to review the code for something:

"nova-core reviewers: russellb, dansmith"

--
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] [Neutron] L3 router service integration with Service Type Framework

2013-10-24 Thread Itsuro ODA

Hi,

We are going to implement 2-arm type lbaas using LVS, and have submitted
the following BPs.

https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion
https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver
https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features

Maybe the first one is same as yours.
We are happy if we just concentrate making a provider driver.

Thanks.
Itsuro Oda

On Thu, 24 Oct 2013 11:56:53 -0700
Gary Duan  wrote:

> Hi,
> 
> I've registered a BP for L3 router service integration with service
> framework.
> 
> https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type
> 
> In general, the implementation will align with how LBaaS is integrated with
> the framework. One consideration we heard from several team members is to
> be able to support vendor specific features and extensions in the service
> plugin.
> 
> Any comment is welcome.
> 
> Thanks,
> Gary

-- 
Itsuro ODA 


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

Re: [openstack-dev] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Boris Pavlovic

Johannes,

+1, purging should help here a lot.


Best regards,
Boris Pavlovic


On Fri, Oct 25, 2013 at 2:01 AM, Johannes Erdfelt wrote:

> On Fri, Oct 25, 2013, Michael Still  wrote:
> > On Fri, Oct 25, 2013 at 8:19 AM, Johannes Erdfelt 
> wrote:
> > > On Fri, Oct 25, 2013, Michael Still  wrote:
> >
> > >> However, when I run it with medium sized (30 million instances)
> > >> databases, the change does cause a 10 minute downtime. I don't
> > >> personally think the change is worth such a large outage, but perhaps
> > >> everyone else disagrees.
> > >
> > > I'm not sure how you could have 30 million instances. That's a lot of
> > > hardware! :)
> >
> > This has come up a couple of times on this thread, so I want to
> > reinforce -- that database is a real user database. There are users
> > out there _right_now_ with 30 million rows in their instance tables
> > and using nova quite happily. Now, not all those instances are
> > _running_, but they're still in the table.
>
> Why no pruning?
>
> The easiest way to reduce the amount of time migrations take to run is
> to reduce the amount of rows that need to be migrated.
>
> The amount of unnecessary data in tables has been steadily increasing.
> I'm looking at you reservations table.
>
> JE
>
>
> ___
> 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] Does DB schema hygiene warrant long migrations?

On 25 October 2013 10:04, Chris Behrens  wrote:
>
> On Oct 24, 2013, at 1:33 PM, Robert Collins  wrote:
>
>> -2 to 10 minute downtimes.
>>
>> +1 to doing the evolution gracefully. There is a spec for doing that
>> from the H summit; someone just needs to implement it.
>
> +1.  IMO, we need to move to a model where code can understand multiple 
> schemas and migrate to newer schema on the fly.  The object code in nova will 
> be able to help us do this.  Combine this with some sort of background task 
> if you need to speed up the conversion.  Any migrations that need to run 
> through all of the data in a table during downtime is just not going to scale.
>
> I am personally tired of having to deal with DB migrations having to run for 
> 1 hour during upgrades that happened numerous times throughout the Havana 
> development cycle.

We had a clear design at the H summit, and folk committed to working
on it (Johannes and Mark W); not sure what happened...

https://etherpad.openstack.org/p/HavanaNoDowntimeDBMigrations

-Rob
-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Johannes Erdfelt

On Fri, Oct 25, 2013, Michael Still  wrote:
> On Fri, Oct 25, 2013 at 8:19 AM, Johannes Erdfelt  
> wrote:
> > On Fri, Oct 25, 2013, Michael Still  wrote:
> 
> >> However, when I run it with medium sized (30 million instances)
> >> databases, the change does cause a 10 minute downtime. I don't
> >> personally think the change is worth such a large outage, but perhaps
> >> everyone else disagrees.
> >
> > I'm not sure how you could have 30 million instances. That's a lot of
> > hardware! :)
> 
> This has come up a couple of times on this thread, so I want to
> reinforce -- that database is a real user database. There are users
> out there _right_now_ with 30 million rows in their instance tables
> and using nova quite happily. Now, not all those instances are
> _running_, but they're still in the table.

Why no pruning?

The easiest way to reduce the amount of time migrations take to run is
to reduce the amount of rows that need to be migrated.

The amount of unnecessary data in tables has been steadily increasing.
I'm looking at you reservations table.

JE


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

Re: [openstack-dev] [Neutron] FWaaS IceHouse summit prep and IRC meeting

2013-10-24 Thread Rajesh Mohan

This is good discussion.

+1 for using Neutron ports for defining zones. I see Kaiwei's point but for
DELL, neutron ports makes more sense.

I am not sure if I completely understood the bump-in-the-wire/zone
discussion. DELL security appliance allows using different zones with
bump-in-the-wire. If the firewall is inserted in bump-in-the-wire mode
between router and LAN hosts, then it does makes sense to apply different
zones on ports connected to LAN and Router. The there are cases where the
end-users apply same zones on both sides but this is a decision we should
leave to end customers. We should allow configuring zones in
bump-in-the-wire mode as well.





On Wed, Oct 23, 2013 at 12:08 PM, Sumit Naiksatam
wrote:

> Log from today's meeting:
>
>
> http://eavesdrop.openstack.org/meetings/networking_fwaas/2013/networking_fwaas.2013-10-23-18.02.log.html
>
> Action items for some of the folks included.
>
> Please join us for the meeting next week.
>
> Thanks,
> ~Sumit.
>
> On Tue, Oct 22, 2013 at 2:00 PM, Sumit Naiksatam  > wrote:
>
>> Reminder - we will have the Neutron FWaaS IRC meeting tomorrow Wednesday
>> 18:00 UTC (11 AM PDT).
>>
>> Agenda:
>> * Tempest tests
>> * Definition and use of zones
>> * Address Objects
>> * Counts API
>> * Service Objects
>> * Integration with service type framework
>> * Open discussion - any other topics you would like to bring up for
>> discussion during the summit.
>>
>> https://wiki.openstack.org/wiki/Meetings/FWaaS
>>
>> Thanks,
>> ~Sumit.
>>
>>
>> On Sun, Oct 13, 2013 at 1:56 PM, Sumit Naiksatam <
>> sumitnaiksa...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> For the next of phase of FWaaS development we will be considering a
>>> number of features. I am proposing an IRC meeting on Oct 16th Wednesday
>>> 18:00 UTC (11 AM PDT) to discuss this.
>>>
>>> The etherpad for the summit session proposal is here:
>>> https://etherpad.openstack.org/p/icehouse-neutron-fwaas
>>>
>>> and has a high level list of features under consideration.
>>>
>>> Thanks,
>>> ~Sumit.
>>>
>>>
>>>
>>
>>
>
> ___
> 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] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Michael Still

On Fri, Oct 25, 2013 at 8:19 AM, Johannes Erdfelt  wrote:
> On Fri, Oct 25, 2013, Michael Still  wrote:

>> However, when I run it with medium sized (30 million instances)
>> databases, the change does cause a 10 minute downtime. I don't
>> personally think the change is worth such a large outage, but perhaps
>> everyone else disagrees.
>
> I'm not sure how you could have 30 million instances. That's a lot of
> hardware! :)

This has come up a couple of times on this thread, so I want to
reinforce -- that database is a real user database. There are users
out there _right_now_ with 30 million rows in their instance tables
and using nova quite happily. Now, not all those instances are
_running_, but they're still in the table.

Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Jay Pipes


On 10/24/2013 04:40 PM, Boris Pavlovic wrote:

Hi,


1) If you have 30 million instance it means that you have 300 million
instance_system_metadata records
All these records will be downloaded every 6 seconds (in periodic tasks)
to compute_nodes => which means that OpenStack on scale out of box
doesn't work.

If you have 3 million instance the situation is the same (OpenStack
doesn't work). but migration will be done for 1 minute.

So it is maximum 1 minute downtime (in actually non real case).


This change is actually very important because VARCHAR works much much
faster then BLOB (Text) records.


This is actually not always true. It depends on:

* What RDBMS you are using
* What storage engine within MySQL, if using MySQL
* What the data access/modification patterns on the field are

The last bullet is very important. For fields that:

* Are not used in predicates or aggregates (i.e. not used in JOIN 
conditions, WHERE clauses, or GROUP BY/HAVING clauses)

* Are rarely read or updated
* Are typically longer than 200-300 bytes of data

It's typically more efficient (both from a fill factor perspective and 
from a log structure perspective) to leave the field as TEXT rather than 
using VARCHAR. The reason is twofold:


1) Using TEXT saves space in the main data pages of the storage engine 
since a pointer to external data file is stored in the data page instead 
of the data itself, meaning more records of that table can fit in a 
single fixed-byte-size data page, which means fewer disk and memory 
reads to find a record, which means faster seeks and scans.


2) When modifying the value of the TEXT field, there is no chance that a 
clustered index-organized table layout (like, say, InnoDB uses) would 
need to perform a rebalancing action due to the new size of the TEXT 
data causing the record to not fit on its containing data page -- 
something that would happen a lot more if VARCHAR was used.


If the data is:

1) Often used in predicates or aggregates
2) Often updated and the size of the updated field stays a similar range
3) ALWAYS within a small, defined range of bytes (say... 32-64 bytes)

Then it's often advantageous to use VARCHAR (or CHAR) over TEXT.

But it's wrong to say that it is ALWAYS faster to use VARCHAR vs. BLOB/TEXT.

Best,
-jay


So this is important change and shouldn't be -2.


Best regards,
Boris Pavlovic





On Fri, Oct 25, 2013 at 12:30 AM, Michael Still mailto:mi...@stillhq.com>> wrote:

Hi.

Because I am a grumpy old man I have just -2'ed
https://review.openstack.org/#/c/39685/ and I wanted to explain my
rationale. Mostly I am hoping for a consensus to form -- if I am wrong
then I'll happy remove my vote from this patch.

This patch does the reasonably sensible thing of converting two
columns from being text to varchar, which reduces their expense to the
database. Given the data stored is already of limited length, it
doesn't impact our functionality at all either.

However, when I run it with medium sized (30 million instances)
databases, the change does cause a 10 minute downtime. I don't
personally think the change is worth such a large outage, but perhaps
everyone else disagrees.

Discuss.

Thanks,
Michael

PS: I could see a more complicated approach where we did these changes
"in flight" by adding columns, using a periodic task to copy data to
the new columns, and then dropping the old. That's a lot more
complicated to implement though.

--
Rackspace Australia




___
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] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Johannes Erdfelt

On Fri, Oct 25, 2013, Michael Still  wrote:
> Because I am a grumpy old man I have just -2'ed
> https://review.openstack.org/#/c/39685/ and I wanted to explain my
> rationale. Mostly I am hoping for a consensus to form -- if I am wrong
> then I'll happy remove my vote from this patch.
> 
> This patch does the reasonably sensible thing of converting two
> columns from being text to varchar, which reduces their expense to the
> database. Given the data stored is already of limited length, it
> doesn't impact our functionality at all either.
> 
> However, when I run it with medium sized (30 million instances)
> databases, the change does cause a 10 minute downtime. I don't
> personally think the change is worth such a large outage, but perhaps
> everyone else disagrees.

I'm not sure how you could have 30 million instances. That's a lot of
hardware! :)

However, in our Rackspace sized deploys (less than 30 million
instances), we've seen many migrations take longer than 10 minutes.

DB migrations are one of the biggest problems we've been facing lately.
Especially since a lot of migrations have been done over the past number
of months ended up causing a lot of pain considering the value they
bring.

For instance, migration 185 was particularly painful. It only "renamed"
the indexes, but it required rebuilding them. This took a long time for
such a simple task.

So I'm very interested in figuring out some sort of solution that makes
database migrations much less painful.

That said, I'm hesitant to say that cleanups like these shouldn't be
done. At a certain point we'll build a significant amount of technical
debt around the database that we're afraid to touch.

> PS: I could see a more complicated approach where we did these changes
> "in flight" by adding columns, using a periodic task to copy data to
> the new columns, and then dropping the old. That's a lot more
> complicated to implement though.

You mean an expand/contract style of migrations?

It's been discussed at previous summits, but it's a lot of work.

It's also at the mercy of the underlying database engine. For instance,
MySQL (depending the version and the underlying database engine) will
recreate the table when adding columns. This will grab a lock and take
a long time.

JE

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

[openstack-dev] [marconi] Sharding feature design

2013-10-24 Thread Kurt Griffiths

Folks,

We’ve been discussing Marconi’s storage sharding architecture over the past 
couple of weeks and I took some time today to draw up our current thinking on 
the design. I’ve also added this link to the blueprint.

http://grab.by/rsoI

I’d like to get the team’s thoughts on this and get the design finalized.

See also: https://blueprints.launchpad.net/marconi/+spec/storage-sharding

Thanks!

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

Re: [openstack-dev] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Chris Behrens


On Oct 24, 2013, at 1:33 PM, Robert Collins  wrote:

> -2 to 10 minute downtimes.
> 
> +1 to doing the evolution gracefully. There is a spec for doing that
> from the H summit; someone just needs to implement it.

+1.  IMO, we need to move to a model where code can understand multiple schemas 
and migrate to newer schema on the fly.  The object code in nova will be able 
to help us do this.  Combine this with some sort of background task if you need 
to speed up the conversion.  Any migrations that need to run through all of the 
data in a table during downtime is just not going to scale.

I am personally tired of having to deal with DB migrations having to run for 1 
hour during upgrades that happened numerous times throughout the Havana 
development cycle.

- Chris

> 
> -Rob
> 
> On 25 October 2013 09:30, Michael Still  wrote:
>> Hi.
>> 
>> Because I am a grumpy old man I have just -2'ed
>> https://review.openstack.org/#/c/39685/ and I wanted to explain my
>> rationale. Mostly I am hoping for a consensus to form -- if I am wrong
>> then I'll happy remove my vote from this patch.
>> 
>> This patch does the reasonably sensible thing of converting two
>> columns from being text to varchar, which reduces their expense to the
>> database. Given the data stored is already of limited length, it
>> doesn't impact our functionality at all either.
>> 
>> However, when I run it with medium sized (30 million instances)
>> databases, the change does cause a 10 minute downtime. I don't
>> personally think the change is worth such a large outage, but perhaps
>> everyone else disagrees.
>> 
>> Discuss.
>> 
>> Thanks,
>> Michael
>> 
>> PS: I could see a more complicated approach where we did these changes
>> "in flight" by adding columns, using a periodic task to copy data to
>> the new columns, and then dropping the old. That's a lot more
>> complicated to implement though.
>> 
>> --
>> Rackspace Australia
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> 
> ___
> 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] Disable async network allocation

2013-10-24 Thread Melanie Witt

On Oct 24, 2013, at 7:47 AM, "Day, Phil"  wrote:

> Yep, that was the feature I was referring to.  
> 
> As I said I don't have anything defiant that shows this to be not working 
> (and the code looks fine) - just wanted to try and simplify the world a bit 
> for a while.

Of course. That's what I meant, that you might be able to use the info to 
revert it locally in your environment to help you track down the Neutron issue 
you're investigating.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Boris Pavlovic

Hi,

1) If you have 30 million instance it means that you have 300 million
instance_system_metadata records
All these records will be downloaded every 6 seconds (in periodic tasks) to
compute_nodes => which means that OpenStack on scale out of box doesn't
work.

If you have 3 million instance the situation is the same (OpenStack doesn't
work). but migration will be done for 1 minute.

So it is maximum 1 minute downtime (in actually non real case).

This change is actually very important because VARCHAR works much much
faster then BLOB (Text) records.
So this is important change and shouldn't be -2.

Best regards,
Boris Pavlovic

On Fri, Oct 25, 2013 at 12:30 AM, Michael Still  wrote:

> Hi.
>
> Because I am a grumpy old man I have just -2'ed
> https://review.openstack.org/#/c/39685/ and I wanted to explain my
> rationale. Mostly I am hoping for a consensus to form -- if I am wrong
> then I'll happy remove my vote from this patch.
>
> This patch does the reasonably sensible thing of converting two
> columns from being text to varchar, which reduces their expense to the
> database. Given the data stored is already of limited length, it
> doesn't impact our functionality at all either.
>
> However, when I run it with medium sized (30 million instances)
> databases, the change does cause a 10 minute downtime. I don't
> personally think the change is worth such a large outage, but perhaps
> everyone else disagrees.
>
> Discuss.
>
> Thanks,
> Michael
>
> PS: I could see a more complicated approach where we did these changes
> "in flight" by adding columns, using a periodic task to copy data to
> the new columns, and then dropping the old. That's a lot more
> complicated to implement though.
>
> --
> Rackspace Australia
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Does DB schema hygiene warrant long migrations?

-2 to 10 minute downtimes.

+1 to doing the evolution gracefully. There is a spec for doing that
from the H summit; someone just needs to implement it.

-Rob

On 25 October 2013 09:30, Michael Still  wrote:
> Hi.
>
> Because I am a grumpy old man I have just -2'ed
> https://review.openstack.org/#/c/39685/ and I wanted to explain my
> rationale. Mostly I am hoping for a consensus to form -- if I am wrong
> then I'll happy remove my vote from this patch.
>
> This patch does the reasonably sensible thing of converting two
> columns from being text to varchar, which reduces their expense to the
> database. Given the data stored is already of limited length, it
> doesn't impact our functionality at all either.
>
> However, when I run it with medium sized (30 million instances)
> databases, the change does cause a 10 minute downtime. I don't
> personally think the change is worth such a large outage, but perhaps
> everyone else disagrees.
>
> Discuss.
>
> Thanks,
> Michael
>
> PS: I could see a more complicated approach where we did these changes
> "in flight" by adding columns, using a periodic task to copy data to
> the new columns, and then dropping the old. That's a lot more
> complicated to implement though.
>
> --
> Rackspace Australia
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] extend Network topology view in horizon

2013-10-24 Thread Toshiyuki Hayashi

Hi Raja,

I'm sorry, I haven't careated documents yet. When I create, I'll share you.

Thanks,
Toshi


On Wed, Oct 23, 2013 at 6:39 AM, Raja Srinivasan
 wrote:
> Hi Toshi
> If you have some documentation on the demo, please share it.
>
>
> Thanks & Regards
> Raja Srinivasan
> E:  raja.sriniva...@riverbed.com
> P: +1(408) 598-1175
>
> -Original Message-
> From: Toshiyuki Hayashi [mailto:haya...@ntti3.com]
> Sent: Tuesday, October 22, 2013 10:47 PM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] extend Network topology view in horizon
>
> Hi,
>
> Regarding No.2, I'm gonna support FWaaS/LBaaS/VPNaaS, and I've just started 
> creating a demo for that. So I'll add the blueprint soon.
>
> Thanks,
> Toshi
>
>
>
> On Tue, Oct 22, 2013 at 2:02 AM, Ofer Blaut  wrote:
>> Hi
>>
>> It will be helpful to extend Network topology view in horizon
>>
>> 1. Admin should be able to see the entire/per tenant network topology (we 
>> might need a flag to enable/disable it).
>>
>> 2. Supporting ICON for FWaaS/LBaaS/VPNaaS on both admin & tenant
>> level, so it will be easy to see the deployments
>>
>> Are there any blueprints to support it ?
>>
>> Thanks
>>
>> Ofer
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Toshiyuki Hayashi
> NTT Innovation Institute Inc.
> Tel:650-579-0800 ex4292
> mail:haya...@ntti3.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Toshiyuki Hayashi
NTT Innovation Institute Inc.
Tel:650-579-0800 ex4292
mail:haya...@ntti3.com

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

[openstack-dev] Does DB schema hygiene warrant long migrations?

2013-10-24 Thread Michael Still

Hi.

Because I am a grumpy old man I have just -2'ed
https://review.openstack.org/#/c/39685/ and I wanted to explain my
rationale. Mostly I am hoping for a consensus to form -- if I am wrong
then I'll happy remove my vote from this patch.

This patch does the reasonably sensible thing of converting two
columns from being text to varchar, which reduces their expense to the
database. Given the data stored is already of limited length, it
doesn't impact our functionality at all either.

However, when I run it with medium sized (30 million instances)
databases, the change does cause a 10 minute downtime. I don't
personally think the change is worth such a large outage, but perhaps
everyone else disagrees.

Discuss.

Thanks,
Michael

PS: I could see a more complicated approach where we did these changes
"in flight" by adding columns, using a periodic task to copy data to
the new columns, and then dropping the old. That's a lot more
complicated to implement though.

-- 
Rackspace Australia

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

Re: [openstack-dev] [GIT] Reset a commit in Gerrit

2013-10-24 Thread Floren Llanos

Thanks all for the information!

Floren

2013/10/21 Thierry Carrez :
> Dolph Mathews wrote:
>> On Sun, Oct 20, 2013 at 1:31 PM, Edgar Magana > > wrote:
>> Just just need to send a patch to gerrit.
>>
>> From you local repo, do the necessary fixes and be sure everything
>> is just
>> as you want.
>> Then simply run:
>> #git commit -a --amend
>> #git review
>>
>>
>> The only "gotcha" here is that you need to maintain the same Change-Id
>> that was appended to your original commit message (and push it to the
>> same branch in gerrit, if you specified one originally). Removing or
>> altering the Change-Id will prevent your patch from updating your
>> existing review. The rest of your commit message can be freely rewritten.
>
> Additionally here are a few links to our doc:
> https://wiki.openstack.org/wiki/GerritWorkflow
> https://wiki.openstack.org/wiki/GerritJenkinsGit
>
> Regards,
>
> --
> Thierry Carrez (ttx)
>
> ___
> 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] Blueprint review process

On 24 October 2013 04:33, Russell Bryant  wrote:
> Greetings,
>
> At the last Nova meeting we started talking about some updates to the
> Nova blueprint process for the Icehouse cycle.  I had hoped we could
> talk about and finalize this in a Nova design summit session on "Nova
> Project Structure and Process" [1], but I think we need to push forward
> on finalizing this as soon as possible so that it doesn't block current
> work being done.

Cool

> Here is a first cut at the process.  Let me know what you think is
> missing or should change.  I'll get the result of this thread posted on
> the wiki.
>
> 1) Proposing a Blueprint
>
> Proposing a blueprint for Nova is not much different than other
> projects.  You should follow the instructions here:
>
> https://wiki.openstack.org/wiki/Blueprints
>
> The particular important step that seems to be missed by most is:
>
> "Once it is ready for PTL review, you should set:
>
> Milestone: Which part of the release cycle you think your work will be
> proposed for merging."
>
> That is really important.  Due to the volume of Nova blueprints, it
> probably will not be seen until you do this.

The other thing I'm seeing some friction on is 'significant features'
: it sometimes feels like folk are filing blueprints for everything
that isn't 'the code crashed' style problems, and while I appreciate
folk wanting to work within the system, blueprints are a heavyweight
tool, primarily suited for things that require significant
coordination.

> 2) Blueprint Review Team
>
> Ensuring blueprints get reviewed is one of the responsibilities of the
> PTL.  However, due to the volume of Nova blueprints, it's not practical
> for me to do it alone.  A team of people (nova-drivers) [2], a subset of
> nova-core, will be doing blueprint reviews.

Why a subset of nova-core? With nova-core defined as 'knows the code
well *AND* reviews a lot', I can see that those folk are in a position
to spot a large class of design defects. However, there are plenty of
folk with expertise in e.g. SOA, operations, deployment @ scale, who
are not nova-core but who will spot plenty of issues. Is there some
way they can help out?

> By having more people reviewing blueprints, we can do a more thorough
> job and have a higher quality result.
>
> Note that even though there is a nova-drivers team, *everyone* is
> encouraged to participate in the review process by providing feedback on
> the mailing list.

I'm not sure about this bit here: blueprints don't have the spec
content, usually thats in an etherpad; etherpads are editable by
everyone - wouldn't it be better to keep the conversation together? I
guess part of my concern here comes back to the (ab)use of blueprints
for shallow features.

> 3) Blueprint Review Criteria
>
> Here are some things that the team reviewing blueprints should look for:
>
> The blueprint ...
>
>  - is assigned to the person signing up to do the work
>
>  - has been targeted to the milestone when the code is
>planned to be completed
>
>  - is an appropriate feature for Nova.  This means it fits with the
>vision for Nova and OpenStack overall.  This is obviously very
>subjective, but the result should represent consensus.
>
>  - includes enough detail to be able to complete an initial design
>review before approving the blueprint. In many cases, the design
>review may result in a discussion on the mailing list to work
>through details. A link to this discussion should be left in the
>whiteboard of the blueprint for reference.  This initial design
>review should be completed before the blueprint is approved.
>
>  - includes information that describes the user impact (or lack of).
>Between the blueprint and text that comes with the DocImpact flag [3]
>in commits, the docs team should have *everything* they need to
>thoroughly document the feature.

I'd like to add:
 - has an etherpad with the design (the blueprint summary has no
markup and is a poor place for capturing the design).

> Once the review has been complete, the blueprint should be marked as
> approved and the priority should be set.  A set priority is how we know
> from the blueprint list which ones have already been reviewed.


> 4) Blueprint Prioritization
>
> I would like to do a better job of using priorities in Icehouse.  The
> priority field services a couple of purposes:
>
>   - helps reviewers prioritize their time
>
>   - helps set expectations for the submitter for how reviewing this
> work stacks up against other things
>
> In the last meeting we discussed an idea that I think is worth trying at
> least for icehouse-1 to see if we like it or not.  The idea is that
> *every* blueprint starts out at a Low priority, which means "best
> effort, but no promises".  For a blueprint to get prioritized higher, it
> should have 2 nova-core members signed up to review the resulting code.
>
> If we do this, I suspect we may end up with more blueprints at Low, but
> I also

Re: [openstack-dev] [Nova] Stable/Havana Gate broken

2013-10-24 Thread Gary Kotton

Thanks for doing this.
Gary

From: Joe Gordon mailto:joe.gord...@gmail.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, October 24, 2013 9:48 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova] Stable/Havana Gate broken

This is being tracked in bug https://bugs.launchpad.net/tempest/+bug/1244055 
and a fix is working its way through the gate now 
(https://review.openstack.org/#/c/53699/)


On Thu, Oct 24, 2013 at 2:51 PM, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Hi,
The gate for stable Hanava is broken in Nova with the following error:


 ==
2013-10-24 
12:48:35.629
 | FAIL: setUpClass 
(tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629
 | setUpClass (tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629
 | --
2013-10-24 
12:48:35.629
 | _StringException: Traceback (most recent call last):
2013-10-24 
12:48:35.629
 |   File "tempest/scenario/manager.py", line 204, in setUpClass
2013-10-24 
12:48:35.629
 | cls.manager = OfficialClientManager(username, password, tenant_name)
2013-10-24 
12:48:35.630
 |   File "tempest/scenario/manager.py", line 69, in __init__
2013-10-24 
12:48:35.630
 | tenant_name)
2013-10-24 
12:48:35.630
 |   File "tempest/scenario/manager.py", line 101, in _get_compute_client
2013-10-24 
12:48:35.630
 | http_log_debug=True)
2013-10-24 
12:48:35.630
 |   File "/opt/stack/new/python-novaclient/novaclient/client.py", line 450, in 
Client
2013-10-24 
12:48:35.630
 | client_class = get_client_class(version)
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/client.py", line 446, in 
get_client_class
2013-10-24 
12:48:35.631
 | return utils.import_class(client_path)
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/utils.py", line 336, in 
import_class
2013-10-24 
12:48:35.631
 | __import__(mod_str)
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/__init__.py", line 
17, in 
2013-10-24 
12:48:35.631
 | from novaclient.v1_1.client import Client   # noqa
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/client.py", line 
18, in 
2013-10-24 
12:48:35.632
 | from novaclient.v1_1 import agents
2013-10-24 
12:48:35.632

Re: [openstack-dev] [Nova] Stable/Havana Gate broken

This is being tracked in bug
https://bugs.launchpad.net/tempest/+bug/1244055and a fix is working
its way through the gate now (
https://review.openstack.org/#/c/53699/)


On Thu, Oct 24, 2013 at 2:51 PM, Gary Kotton  wrote:

> Hi,
> The gate for stable Hanava is broken in Nova with the following error:
>
>  
> ==2013-10-24
>  12:48:35.629 
> 
>  | FAIL: setUpClass 
> (tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)2013-10-24 
> 12:48:35.629 
> 
>  | setUpClass 
> (tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)2013-10-24 
> 12:48:35.629 
> 
>  | 
> --2013-10-24
>  12:48:35.629 
> 
>  | _StringException: Traceback (most recent call last):2013-10-24 
> 12:48:35.629 
> 
>  |   File "tempest/scenario/manager.py", line 204, in setUpClass2013-10-24 
> 12:48:35.629 
> 
>  | cls.manager = OfficialClientManager(username, password, 
> tenant_name)2013-10-24 12:48:35.630 
> 
>  |   File "tempest/scenario/manager.py", line 69, in __init__2013-10-24 
> 12:48:35.630 
> 
>  | tenant_name)2013-10-24 12:48:35.630 
> 
>  |   File "tempest/scenario/manager.py", line 101, in 
> _get_compute_client2013-10-24 12:48:35.630 
> 
>  | http_log_debug=True)2013-10-24 12:48:35.630 
> 
>  |   File "/opt/stack/new/python-novaclient/novaclient/client.py", line 450, 
> in Client2013-10-24 12:48:35.630 
> 
>  | client_class = get_client_class(version)2013-10-24 12:48:35.631 
> 
>  |   File "/opt/stack/new/python-novaclient/novaclient/client.py", line 446, 
> in get_client_class2013-10-24 12:48:35.631 
> 
>  | return utils.import_class(client_path)2013-10-24 12:48:35.631 
> 
>  |   File "/opt/stack/new/python-novaclient/novaclient/utils.py", line 336, 
> in import_class2013-10-24 12:48:35.631 
> 
>  | __import__(mod_str)2013-10-24 12:48:35.631 
> 
>  |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/__init__.py", 
> line 17, in 2013-10-24 12:48:35.631 
> 
>  | from novaclient.v1_1.client import Client   # noqa2013-10-24 
> 12:48:35.631 
> 
>  |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/client.py", line 
> 18, in 2013-10-24 12:48:35.632 
> 
>  | from novaclient.v1_1 import agents2013-10-24 12:48:35.632 
> 
>  |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/agents.py", line 
> 22, in 2013-10-24 12:48:35.632 
>

[openstack-dev] [Neutron] L3 router service integration with Service Type Framework

Hi,

I've registered a BP for L3 router service integration with service
framework.

https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type

In general, the implementation will align with how LBaaS is integrated with
the framework. One consideration we heard from several team members is to
be able to support vendor specific features and extensions in the service
plugin.

Any comment is welcome.

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

Re: [openstack-dev] Remove vim modelines?

I guess I get to buck the trend :).

On 25 October 2013 01:38, Joe Gordon  wrote:
> Since the beginning of OpenStack we have had vim modelines all over the
> codebase, but after seeing this patch
> https://review.opeenstack.org/#/c/50891/ I took a further look into vim
> modelines and think we should remove them. Before going any further, I
> should point out these lines don't bother me too much but I figured if we
> could get consensus, then we could shrink our codebase by a little bit.
>
> Sidenote: This discussion is being moved to the mailing list because it
> 'would be better to have a mailing list thread about this rather than bits
> and pieces of discussion in gerrit' as this change requires multiple
> patches.  https://review.openstack.org/#/c/51295/.

I don't deeply care about them, but I think the logic being used to
promote their removal is flawed.

> Why remove them?
>
> * Modelines aren't supported by default in debian or ubuntu due to security
> reasons: https://wiki.python.org/moin/Vim

This affects folk who haven't turned it on. We have no idea about how
many that is. The presumption is that if it's off by default everyone
has it off - but one of the first things most folk end up doing with
vim as they head down the path to poweruser is customing their
vimrc...

> * Having modelines for vim means if someone wants we should support
> modelines for emacs
> (http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables)
> etc. as well.  And having a bunch of headers for different editors in each
> file seems like extra overhead.

This is a slippery slope argument. We could equally say 'it's up to
the editors to support our style declaration, use a vim-compatible
plugin in your editor'. We can also say 'we'll directly support the
three most common editors' and gather data on that from our developer
surveys. (We /do/ gather developer data don't we? :) ).

> * There are other ways of making sure tabstop is set correctly for python
> files, see  https://wiki.python.org/moin/Vim.  I am a vIm user myself and
> have never used modelines.

The other ways won't help folk that

> * We have vim modelines in only 828 out of 1213 python files in nova (68%),
> so if anyone is using modelines today, then it only works 68% of the time in
> nova

That seems like a reason to add it to all files to me ;).

> * Why have the same config 828 times for one repo alone?  This violates the
> DRY principle (Don't Repeat Yourself).

The same argument applies to copyright licences, .py file suffixes and
common imports.
I do agree that the repeated unchanging nature of modelines is
suboptimal, and it would be
nice to be able to define the style hints to vim for an entire subtree.

This is probably possible through a little bit of scripting.

Since you skipped it, I should add a case for pushing modelines everywhere.

*) They help everyone when editing files where the format is less well
known than Python (.yaml for instance) or our style guide doesn't
match a global document (shell scripts, docbook).

*) They help casual contributors *more* than long time core
contributors : and those are the folk that are most likely to give up
and walk away. Keeping barriers to entry low is an important part of
making OpenStack development accessible to new participants.

*) We can move them to the very end of the file where ~nobody will see them.

*) We can teach hacking to enforce a specific modeline per file type,
avoiding accidental mistakes.

*) Possibly we can move the copyright licence grants to the end of the
files as well, making opening our source code up much more pleasant.

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Nova] Blueprint review process

On 10/24/2013 11:32 AM, Thierry Carrez wrote:
> Russell Bryant wrote:
>> At the last Nova meeting we started talking about some updates to the
>> Nova blueprint process for the Icehouse cycle.  I had hoped we could
>> talk about and finalize this in a Nova design summit session on "Nova
>> Project Structure and Process" [1], but I think we need to push forward
>> on finalizing this as soon as possible so that it doesn't block current
>> work being done.
>>
>> Here is a first cut at the process.  Let me know what you think is
>> missing or should change.  I'll get the result of this thread posted on
>> the wiki.
>> [...]
> 
> +1
> 
> That's pretty much how I would like every project to handle their
> blueprints. For smaller projects I guess the "2 core signed up for
>> =Medium blueprints" requirement can be handled informally, but the rest
> is spot-on and should be applicable everywhere.
> 

If that's the case, then I can just work on updating the main Blueprints
page [1] with a little bit more detail.  I suppose there's not that much
missing.  In particular, I would add:

 - notes on blueprint review criteria

 - the use of -driver teams by some projects to review

 - some more info on prioriization based on review bandwidth, and nova's
specific requirement for reviewer support for a priority > Low

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

-- 
Russell Bryant

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

Re: [openstack-dev] RFC - Icehouse logging harmonization

On 10/24/2013 11:46 AM, Brant Knudson wrote:
> 
> On a previous project, I wrote a library that provided a command-line
> option to set the logging levels for different loggers. This was handy
> for developers and for support. An example translated to Keystone would
> be like
> 
> keystone-all --logging=keystone.identity=DEBUG
> 
> Now the keystone.identity loggers are DEBUG while the rest of the
> loggers are still at INFO or whatever their default is. This would be
> used if you think the problem is in the identity backend. It's more
> convenient than editing a config file.
> 
> Also, in our config file we listed the important loggers and had the
> default levels for them... for keystone it would be like
> 
> # keystone.identity=INFO
> # keystone.assignment=INFO
> # dogpile=WARNING
> 
> This was useful for developers and customers alike, because it was then
> easier to figure out what the loggers are.

We support something like that (from oslo-incubator's logging code):

# list of logger=LEVEL pairs (list value)
#default_log_levels=amqplib=WARN,sqlalchemy=WARN,boto=WARN,suds=INFO,keystone=INFO,eventlet.wsgi.server=WARN

-- 
Russell Bryant

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

Re: [openstack-dev] Distributed Virtual Router Discussion

2013-10-24 Thread Henry Gessau

On Wed, Oct 23, at 7:35 am, Sylvain Afchain 
wrote:

> I'm interested as well. On our side we are working on this BP
> https://blueprints.launchpad.net/neutron/+spec/l3-high-availability

And might be good to revisit the Multi-host DHCP and L3 blueprint
https://blueprints.launchpad.net/neutron/+spec/quantum-multihost


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

[openstack-dev] [State-Management] Agenda for today meeting at 2000 UTC

2013-10-24 Thread Joshua Harlow

Hi all,

The [state-management] project team holds a weekly meeting in 
#openstack-meeting on thursdays, 2000 UTC. The next meeting is today, 
2013-10-24!!!

As usual, everyone is welcome :-)

Link: https://wiki.openstack.org/wiki/Meetings/StateManagement
Taskflow: https://wiki.openstack.org/TaskFlow

## Agenda (30-60 mins):

- Discuss any action items from last meeting.
- Discuss ongoing status of the overall effort and any needed coordination.
- Continue missed items from last week.
- Discuss blueprints for icehouse.
- Discuss about any other potential new use-cases for said library.
- Discuss about any other ideas, problems, open-reviews, issues, solutions, 
questions (and more!).

Any other topics are welcome :-)

See you all soon!

--

Joshua Harlow

It's openstack, relax... | harlo...@yahoo-inc.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-24 Thread Daniel Salinas

I am 1% behind that idea.  It makes things easier to manage.


On Thu, Oct 24, 2013 at 10:44 AM, Tim Simpson wrote:

>  So if we decide to support any number of config options for each various
> datastore version, eventually we'll have large config files that will be
> hard to manage.
>
>  What about storing the extra config info for each datastore version in
> its own independent config file? So rather than having one increasingly
> bloated config file used by everything, you could optionally specify a file
> in the datastore_versions table of the database that would be looked up
> similar to how we load template files on demand.
>
>  - Tim
>  --
> *From:* Ilya Sviridov [isviri...@mirantis.com]
> *Sent:* Thursday, October 24, 2013 7:40 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Trove] How users should specify a
> datastore type when creating an instance
>
>So, we have 2 places for configuration management - database and
> config file
>
>  Config file for tunning all datasource type behavior during installation
> and database for all changeable configurations during usage and
> administration of Trove installation.
>
>  Database usecases:
>  - update/custom image
>  - update/custom packages
>  - activating/deactivating datastore_type
>
>  Config file usecases:
>  - security group policy
>  - provisioning mechanism
>  - guest configuration parameters per database engine
>  - provisioning  parameters, templates
>  - manager class
>  ...
>
>  In case if i need to register one more MySQL installation with following
> customization:
>  - custom heat template
>  - custom packages and additional monitoring tool package
>  - open specific port for working with my monitoring tool on instance
>
>  According to current concept should i add one more section in addition
> to existing mysql like below?
>
> [monitored_mysql]
> mount_point=/var/lib/mysql
>
> #8080 is port of my monitoring tool
>  trove_security_group_rule_ports = 3306, 8080
>  heat_template=/etc/trove/heat_templates/monitored_mysql.yaml
>  ...
>
>  and put additional packages to database configuration?
>
>
>
>
>
>  With best regards,
> Ilya Sviridov
>
>  
>
>
> On Wed, Oct 23, 2013 at 9:37 PM, Michael Basnight wrote:
>
>>
>> On Oct 23, 2013, at 10:54 AM, Ilya Sviridov wrote:
>>
>> > Besides the strategy of selecting the default behavior.
>> >
>> > Let me share with you my ideas of configuration management in Trove and
>> how the datastore concept can help with that.
>> >
>> > Initially there was only one database and all configuration was in one
>> config file.
>> > With adding of new databases, heat provisioning mechanism, we are
>> introducing more options.
>> >
>> > Not only assigning specific image_id, but custom packages, heat
>> templates, probably specific strategies of working with security groups.
>> > Such needs already exist because we have a lot of optional things in
>> config, and any new feature is implemented with back sight to already
>> existing legacy installations of Trove.
>> >
>> > What is  actually datastore_type + datastore_version?
>> >
>> > The model which glues all the bricks together, so let us use it for all
>> variable part of *service type* configuration.
>> >
>> > from current config file
>> >
>> > # Trove DNS
>> > trove_dns_support = False
>> >
>> > # Trove Security Groups for Instances
>> > trove_security_groups_support = True
>> > trove_security_groups_rules_support = False
>> > trove_security_group_rule_protocol = tcp
>> > trove_security_group_rule_port = 3306
>> > trove_security_group_rule_cidr = 0.0.0.0/0
>> >
>> > #guest_config = $pybasedir/etc/trove/trove-guestagent.conf.sample
>> > #cloudinit_location = /etc/trove/cloudinit
>> >
>> > block_device_mapping = vdb
>> > device_path = /dev/vdb
>> > mount_point = /var/lib/mysql
>> >
>> > All that configurations can be moved to data_strore (some defined in
>> heat templates) and be manageable by operator in case if any default
>> behavior should be changed.
>> >
>> > The trove-config becomes core functionality specific only.
>>
>>  Its fine for it to be in the config or the heat templates… im not sure
>> it matters. what i would like to see is that specific thing to each service
>> be in their own config group in the configuration.
>>
>> [mysql]
>> mount_point=/var/lib/mysql
>> …
>> [redis]
>> volume_support=False
>> …..
>>
>> and so on.
>>
>> ___
>> 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/open

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-24 Thread Tim Simpson

So if we decide to support any number of config options for each various 
datastore version, eventually we'll have large config files that will be hard 
to manage.

What about storing the extra config info for each datastore version in its own 
independent config file? So rather than having one increasingly bloated config 
file used by everything, you could optionally specify a file in the 
datastore_versions table of the database that would be looked up similar to how 
we load template files on demand.

- Tim

From: Ilya Sviridov [isviri...@mirantis.com]
Sent: Thursday, October 24, 2013 7:40 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type 
when creating an instance

So, we have 2 places for configuration management - database and config file

Config file for tunning all datasource type behavior during installation and 
database for all changeable configurations during usage and administration of 
Trove installation.

Database usecases:
- update/custom image
- update/custom packages
- activating/deactivating datastore_type

Config file usecases:
- security group policy
- provisioning mechanism
- guest configuration parameters per database engine
- provisioning  parameters, templates
- manager class
...

In case if i need to register one more MySQL installation with following 
customization:
- custom heat template
- custom packages and additional monitoring tool package
- open specific port for working with my monitoring tool on instance

According to current concept should i add one more section in addition to 
existing mysql like below?

[monitored_mysql]
mount_point=/var/lib/mysql

#8080 is port of my monitoring tool
trove_security_group_rule_ports = 3306, 8080
heat_template=/etc/trove/heat_templates/monitored_mysql.yaml
...

and put additional packages to database configuration?





With best regards,
Ilya Sviridov




On Wed, Oct 23, 2013 at 9:37 PM, Michael Basnight 
mailto:mbasni...@gmail.com>> wrote:

On Oct 23, 2013, at 10:54 AM, Ilya Sviridov wrote:

> Besides the strategy of selecting the default behavior.
>
> Let me share with you my ideas of configuration management in Trove and how 
> the datastore concept can help with that.
>
> Initially there was only one database and all configuration was in one config 
> file.
> With adding of new databases, heat provisioning mechanism, we are introducing 
> more options.
>
> Not only assigning specific image_id, but custom packages, heat templates, 
> probably specific strategies of working with security groups.
> Such needs already exist because we have a lot of optional things in config, 
> and any new feature is implemented with back sight to already existing legacy 
> installations of Trove.
>
> What is  actually datastore_type + datastore_version?
>
> The model which glues all the bricks together, so let us use it for all 
> variable part of *service type* configuration.
>
> from current config file
>
> # Trove DNS
> trove_dns_support = False
>
> # Trove Security Groups for Instances
> trove_security_groups_support = True
> trove_security_groups_rules_support = False
> trove_security_group_rule_protocol = tcp
> trove_security_group_rule_port = 3306
> trove_security_group_rule_cidr = 0.0.0.0/0
>
> #guest_config = $pybasedir/etc/trove/trove-guestagent.conf.sample
> #cloudinit_location = /etc/trove/cloudinit
>
> block_device_mapping = vdb
> device_path = /dev/vdb
> mount_point = /var/lib/mysql
>
> All that configurations can be moved to data_strore (some defined in heat 
> templates) and be manageable by operator in case if any default behavior 
> should be changed.
>
> The trove-config becomes core functionality specific only.

Its fine for it to be in the config or the heat templates… im not sure it 
matters. what i would like to see is that specific thing to each service be in 
their own config group in the configuration.

[mysql]
mount_point=/var/lib/mysql
…
[redis]
volume_support=False
…..

and so on.

___
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] RFC - Icehouse logging harmonization

2013-10-24 Thread Brant Knudson

On a previous project, I wrote a library that provided a command-line
option to set the logging levels for different loggers. This was handy for
developers and for support. An example translated to Keystone would be like

keystone-all --logging=keystone.identity=DEBUG

Now the keystone.identity loggers are DEBUG while the rest of the loggers
are still at INFO or whatever their default is. This would be used if you
think the problem is in the identity backend. It's more convenient than
editing a config file.

Also, in our config file we listed the important loggers and had the
default levels for them... for keystone it would be like

# keystone.identity=INFO
# keystone.assignment=INFO
# dogpile=WARNING

This was useful for developers and customers alike, because it was then
easier to figure out what the loggers are.

- Brant




On Thu, Oct 24, 2013 at 10:22 AM, Russell Bryant  wrote:

> On 10/24/2013 11:00 AM, Sean Dague wrote:
> > On 10/24/2013 10:05 AM, Dan Smith wrote:
> >>> Example 1:
> >>> ==
> >>>
> >>>  n-conductor log in tempest/devstack -
> >>>
> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz
> >>>
> >>>
> >>>
> >>>  Total log lines: 84076
> >>>  Total non DEBUG lines: 61
> >>>
> >>>  Question: do we need more than 1 level of DEBUG? 3 orders of
> >>> magnitude information change between INFO -> DEBUG seems too steep a
> >>> cliff.
> >>
> >> Some of them are not useful to me (but might be to others), like the
> >> amqp channel lines. However, everything else has been pretty crucial at
> >> one point or another when debugging issues that span between the two
> >> tightly-coupled services.
> >
> > Right, which is definitely why it's a conversation, to figure out what's
> > useful, and what isn't. We definitely don't want to remove things that
> > are useful.
> >
> > The amqp lines are 49562 of the DEBUG lines, so dropping those would
> > drop our DEBUG output in more than half, which would be cool if it
> > didn't have an impact of folks.
> >
> > I also just wanted to raise the question, are there multiple levels of
> > DEBUG that might make sense here? For instance, every received seems to
> > be followed by an unpacked, which actually has info that was in the
> > received hash -
> >
> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz#_2013-10-23_12_25_22_524
> >
> >
> > If we had DEBUG and DEBUG2 levels, where one of them would only be seen
> > at the higher debug level, would that be useful?
> >
> > I'm not actually trying to pick on conductor here, but it makes a good
> > example of a service that DEBUG level is extremely useful to
> > development, and is used heavily, and might make us thing about multi
> > levels of DEBUG to go deeper down the rabbit hole only if we really need
> > to.
>
> Note that we can't actually change the level used by other libs, like
> amqp.  However, we can set more granular logger levels.  We could
> re-define debug=True to only set up debug for openstack stuff, and add a
> new option debug_all=True that enables debugging for *everything*.
>
> --
> 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] [Climate] Weekly IRC team meeting

2013-10-24 Thread Sylvain Bauza

Cool. All the core devs gave a go, let's begin with Mondays 1000 UTC on 
#openstack-meeting


I modified the Meetings wikipage [1] and created a wikipage for our own 
agenda [2]



[1] : https://wiki.openstack.org/wiki/Meetings
[2] : https://wiki.openstack.org/wiki/Meetings/Climate

Thanks,
-Sylvain

Le 24/10/2013 17:23, Dina Belova a écrit :

+1


On Thu, Oct 24, 2013 at 5:43 PM, Nikolay Starodubtsev 
mailto:nstarodubt...@mirantis.com>> wrote:


+1, but we need to wait for Dina. She has more problems with
schedule than me

Nikolay Starodubtsev

Software Engineer

Mirantis Inc.

Skype: dark_harlequine1



On Thu, Oct 24, 2013 at 4:11 PM, Swann Croiset
mailto:swann.croi...@bull.net>> wrote:

+1

Le 24/10/2013 09:45, Sylvain Bauza a écrit :

Hi all,

Climate is growing and time is coming for having a weekly
meeting in between all of us.
There is a huge number of reviews in progress, and at least
the first agenda will be triaging those, making sure they are
either coming to trunk as soon as possible, or splitted into
smaller chunks of code.

The Icehouse summit is also coming, and I would like to take
opportunity to discuss about any topics we could raise during
the Summit.

Is Mondays 10:00am UTC [1] a convenient time for you ?

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=10&day=28&hour=10&min=0&sec=0&p1=195&p2=166

-Sylvain



-- 
Swann Croiset






--

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.



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

Re: [openstack-dev] [Nova] Blueprint review process

2013-10-24 Thread Thierry Carrez

Russell Bryant wrote:
> At the last Nova meeting we started talking about some updates to the
> Nova blueprint process for the Icehouse cycle.  I had hoped we could
> talk about and finalize this in a Nova design summit session on "Nova
> Project Structure and Process" [1], but I think we need to push forward
> on finalizing this as soon as possible so that it doesn't block current
> work being done.
> 
> Here is a first cut at the process.  Let me know what you think is
> missing or should change.  I'll get the result of this thread posted on
> the wiki.
> [...]

+1

That's pretty much how I would like every project to handle their
blueprints. For smaller projects I guess the "2 core signed up for
>=Medium blueprints" requirement can be handled informally, but the rest
is spot-on and should be applicable everywhere.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] RFC - Icehouse logging harmonization

On 10/24/2013 11:00 AM, Sean Dague wrote:
> On 10/24/2013 10:05 AM, Dan Smith wrote:
>>> Example 1:
>>> ==
>>>
>>>  n-conductor log in tempest/devstack -
>>> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz
>>>
>>>
>>>
>>>  Total log lines: 84076
>>>  Total non DEBUG lines: 61
>>>
>>>  Question: do we need more than 1 level of DEBUG? 3 orders of
>>> magnitude information change between INFO -> DEBUG seems too steep a
>>> cliff.
>>
>> Some of them are not useful to me (but might be to others), like the
>> amqp channel lines. However, everything else has been pretty crucial at
>> one point or another when debugging issues that span between the two
>> tightly-coupled services.
> 
> Right, which is definitely why it's a conversation, to figure out what's
> useful, and what isn't. We definitely don't want to remove things that
> are useful.
> 
> The amqp lines are 49562 of the DEBUG lines, so dropping those would
> drop our DEBUG output in more than half, which would be cool if it
> didn't have an impact of folks.
> 
> I also just wanted to raise the question, are there multiple levels of
> DEBUG that might make sense here? For instance, every received seems to
> be followed by an unpacked, which actually has info that was in the
> received hash -
> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz#_2013-10-23_12_25_22_524
> 
> 
> If we had DEBUG and DEBUG2 levels, where one of them would only be seen
> at the higher debug level, would that be useful?
> 
> I'm not actually trying to pick on conductor here, but it makes a good
> example of a service that DEBUG level is extremely useful to
> development, and is used heavily, and might make us thing about multi
> levels of DEBUG to go deeper down the rabbit hole only if we really need
> to.

Note that we can't actually change the level used by other libs, like
amqp.  However, we can set more granular logger levels.  We could
re-define debug=True to only set up debug for openstack stuff, and add a
new option debug_all=True that enables debugging for *everything*.

-- 
Russell Bryant

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

Re: [openstack-dev] [Climate] Weekly IRC team meeting

2013-10-24 Thread Dina Belova

+1


On Thu, Oct 24, 2013 at 5:43 PM, Nikolay Starodubtsev <
nstarodubt...@mirantis.com> wrote:

> +1, but we need to wait for Dina. She has more problems with schedule than
> me
>
>  Nikolay Starodubtsev
>
> Software Engineer
>
> Mirantis Inc.
>
> Skype: dark_harlequine1
>
>
> On Thu, Oct 24, 2013 at 4:11 PM, Swann Croiset wrote:
>
>>  +1
>>
>> Le 24/10/2013 09:45, Sylvain Bauza a écrit :
>>
>> Hi all,
>>
>> Climate is growing and time is coming for having a weekly meeting in
>> between all of us.
>> There is a huge number of reviews in progress, and at least the first
>> agenda will be triaging those, making sure they are either coming to trunk
>> as soon as possible, or splitted into smaller chunks of code.
>>
>> The Icehouse summit is also coming, and I would like to take opportunity
>> to discuss about any topics we could raise during the Summit.
>>
>> Is Mondays 10:00am UTC [1] a convenient time for you ?
>>
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=10&day=28&hour=10&min=0&sec=0&p1=195&p2=166
>>
>> -Sylvain
>>
>>
>>
>> --
>> Swann Croiset
>>
>>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Nova] Blueprint review process

2013-10-24 Thread Andrew Laski


On 10/24/13 at 11:07am, Russell Bryant wrote:

On 10/24/2013 10:52 AM, Gary Kotton wrote:



On 10/24/13 4:46 PM, "Dan Smith"  wrote:


In the last meeting we discussed an idea that I think is worth trying at
least for icehouse-1 to see if we like it or not.  The idea is that
*every* blueprint starts out at a Low priority, which means "best
effort, but no promises".  For a blueprint to get prioritized higher, it
should have 2 nova-core members signed up to review the resulting code.


Huge +1 to this. I'm in favor of the whole plan, but specifically the
prioritization piece is very important, IMHO.


I too am in favor of the idea. It is just not clear how 2 Nova cores will
be signed up.


Good point, there was no detail on that.  I propose just comments on the
blueprint whiteboard.  It can be something simple like this to indicate
that Dan and I have agreed to review the code for something:

   "nova-core reviewers: russellb, dansmith"


+1 to everything in Russells original email.  But for this point 
specifically I see it as resulting from conversations amongst Nova 
developers.  If some of us decide that a blueprint is important or very 
nice to have then we should sign up to help it through.  But there's 
nothing wrong with a low priority blueprint.  We may want to communicate 
that core members don't need to be hunted and recruited for absolutely 
every blueprint that's proposed.




--
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] [Climate] Weekly IRC team meeting

2013-10-24 Thread Yuriy Taraday

+1


On Thu, Oct 24, 2013 at 5:43 PM, Nikolay Starodubtsev <
nstarodubt...@mirantis.com> wrote:

> +1, but we need to wait for Dina. She has more problems with schedule than
> me
>
>  Nikolay Starodubtsev
>
> Software Engineer
>
> Mirantis Inc.
>
> Skype: dark_harlequine1
>
>
> On Thu, Oct 24, 2013 at 4:11 PM, Swann Croiset wrote:
>
>>  +1
>>
>> Le 24/10/2013 09:45, Sylvain Bauza a écrit :
>>
>> Hi all,
>>
>> Climate is growing and time is coming for having a weekly meeting in
>> between all of us.
>> There is a huge number of reviews in progress, and at least the first
>> agenda will be triaging those, making sure they are either coming to trunk
>> as soon as possible, or splitted into smaller chunks of code.
>>
>> The Icehouse summit is also coming, and I would like to take opportunity
>> to discuss about any topics we could raise during the Summit.
>>
>> Is Mondays 10:00am UTC [1] a convenient time for you ?
>>
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=10&day=28&hour=10&min=0&sec=0&p1=195&p2=166
>>
>> -Sylvain
>>
>>
>>
>> --
>> Swann Croiset
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

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

Re: [openstack-dev] RFC - Icehouse logging harmonization

2013-10-24 Thread Dan Smith

> If we had DEBUG and DEBUG2 levels, where one of them would only be seen
> at the higher debug level, would that be useful?

I'm fine with not seeing those for devstack runs, yeah.

--Dan

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

Re: [openstack-dev] [Nova] Blueprint review process

On 10/24/2013 10:52 AM, Gary Kotton wrote:
> 
> 
> On 10/24/13 4:46 PM, "Dan Smith"  wrote:
> 
>>> In the last meeting we discussed an idea that I think is worth trying at
>>> least for icehouse-1 to see if we like it or not.  The idea is that
>>> *every* blueprint starts out at a Low priority, which means "best
>>> effort, but no promises".  For a blueprint to get prioritized higher, it
>>> should have 2 nova-core members signed up to review the resulting code.
>>
>> Huge +1 to this. I'm in favor of the whole plan, but specifically the
>> prioritization piece is very important, IMHO.
> 
> I too am in favor of the idea. It is just not clear how 2 Nova cores will
> be signed up.

Good point, there was no detail on that.  I propose just comments on the
blueprint whiteboard.  It can be something simple like this to indicate
that Dan and I have agreed to review the code for something:

"nova-core reviewers: russellb, dansmith"

-- 
Russell Bryant

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

Re: [openstack-dev] RFC - Icehouse logging harmonization

2013-10-24 Thread Sean Dague


On 10/24/2013 10:05 AM, Dan Smith wrote:

Example 1:
==

 n-conductor log in tempest/devstack -
http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz


 Total log lines: 84076
 Total non DEBUG lines: 61

 Question: do we need more than 1 level of DEBUG? 3 orders of
magnitude information change between INFO -> DEBUG seems too steep a cliff.


Some of them are not useful to me (but might be to others), like the
amqp channel lines. However, everything else has been pretty crucial at
one point or another when debugging issues that span between the two
tightly-coupled services.


Right, which is definitely why it's a conversation, to figure out what's 
useful, and what isn't. We definitely don't want to remove things that 
are useful.


The amqp lines are 49562 of the DEBUG lines, so dropping those would 
drop our DEBUG output in more than half, which would be cool if it 
didn't have an impact of folks.


I also just wanted to raise the question, are there multiple levels of 
DEBUG that might make sense here? For instance, every received seems to 
be followed by an unpacked, which actually has info that was in the 
received hash - 
http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz#_2013-10-23_12_25_22_524


If we had DEBUG and DEBUG2 levels, where one of them would only be seen 
at the higher debug level, would that be useful?


I'm not actually trying to pick on conductor here, but it makes a good 
example of a service that DEBUG level is extremely useful to 
development, and is used heavily, and might make us thing about multi 
levels of DEBUG to go deeper down the rabbit hole only if we really need to.


-Sean

--
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Nova] Blueprint review process

On 10/24/2013 07:43 AM, Joe Gordon wrote:
> On Wed, Oct 23, 2013 at 4:33 PM, Russell Bryant  > wrote:
> 
> Here is a first cut at the process.  Let me know what you think is
> missing or should change.  I'll get the result of this thread posted on
> the wiki.


> ++ to the entire process, two comments though.
> 
> * It would be great to get this into a wiki for future reference
> * We shouldn't merge patches with un-approved blueprints. And when that
> happens having a wiki page to point to would be great.

Yep, I do want to get this on the wiki.  I just put it out on the list
for comments before making it official.

-- 
Russell Bryant

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

Re: [openstack-dev] Announcing Project Solum

On 10/24/2013 08:51 AM, Thomas Spatzier wrote:
> Hi Adrian,
> 
> really intersting! I wonder what the relation to all the software
> orchestration in Heat discussions is that have been going on for a while
> now.

It's a good question.  Personally, I would expect Heat to be a key
element of how Solum works.  There are a number of things Solum needs to
do on top of Heat, though, such as the git integration bit.

-- 
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] Blueprint review process

2013-10-24 Thread Gary Kotton



On 10/24/13 4:46 PM, "Dan Smith"  wrote:

>> In the last meeting we discussed an idea that I think is worth trying at
>> least for icehouse-1 to see if we like it or not.  The idea is that
>> *every* blueprint starts out at a Low priority, which means "best
>> effort, but no promises".  For a blueprint to get prioritized higher, it
>> should have 2 nova-core members signed up to review the resulting code.
>
>Huge +1 to this. I'm in favor of the whole plan, but specifically the
>prioritization piece is very important, IMHO.

I too am in favor of the idea. It is just not clear how 2 Nova cores will
be signed up.

>
>--Dan
>
>___
>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] RFC - Icehouse logging harmonization

On Thu, Oct 24, 2013 at 3:24 PM, Lars Kellogg-Stedman wrote:

> On Thu, Oct 24, 2013 at 07:05:19AM -0700, Dan Smith wrote:
> > Some of them are not useful to me (but might be to others), like the
> > amqp channel lines. However, everything else has been pretty crucial at
> > one point or another when debugging issues that span between the two
> > tightly-coupled services.
>
> I am completely unfamiliar with the code, so I apologize if these are
> dumb questions:
>
> - Is everything making use of Python's logging module?
>

AFAIK yes, and if not we should be.


> - Would this be a could use-case for that module's support of
>   file-based configuration
>   (http://docs.python.org/2/howto/logging.html#configuring-logging)
>
> Yes, we do that in nova already and should do it in neutron as well, see
http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/nova.conf.sample#n1408
http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/logging_sample.conf


> This would let a cloud deployer have much more granular control
> over what log messages show up (and even what log messages go where).
> For example, maybe I don't care about messages from
> quantum.openstack.common.rpc.impl_qpid, and I generally only want to
> log WARN and above, but I want to see DEBUG messages for
> quantum.plugins.openvswitch.agent.ovs_quantum_agent.
>
> Or is that Too Much Flexibility?


While I think giving the deployer such fine grain control is a good idea,
we want to include sane defaults when possible.


>
> --
> Lars Kellogg-Stedman 
>
>
> ___
> 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] Disable async network allocation

2013-10-24 Thread Day, Phil

>This is a quite interest findings. so If we use httplib, this won't happen?

That's my understanding.   It also looks like you might be able to configure 
the retrys in later versions of httplib2

-Original Message-
From: Nachi Ueno [mailto:na...@ntti3.com] 
Sent: 24 October 2013 00:38
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Disable async network allocation

Hi Phil

2013/10/21 Day, Phil :
> Hi Folks,
>
>
>
> I'm trying to track down a couple of obsecure issues in network port 
> creation where it would be really useful if I could disable the async 
> network allocation so that everything happens in the context of a 
> single eventlet rather than two (and also rule out if there is some obscure
> eventlet threading issue in here).   I thought it was configurable - but I
> don't see anything obvious in the code to go back to the old (slower) 
> approach of doing network allocation in-lien in the main create thread ?
>

May I ask the meaning of  " async network allocation" ?

>
> One of the issues I'm trying to track is Neutron occasionally creating 
> more than one port - I suspect a retry mechanism in the httplib2 is 
> sending the port create request multiple times if  Neutron is slow to 
> reply, resulting in Neutron processing it multiple times.  Looks like 
> only the Neutron client has chosen to use httplib2 rather that httplib 
> - anyone got any insight here ?

This is a quite interest findings. so If we use httplib, this won't happen?

>
>
> Sometimes of course the Neutron timeout results in the create request 
> being re-scheduled onto another node (which can it turn generate its own set 
> of
> port create requests).Its the thread behavior around how the timeout
> exception is handled that I'm slightly nervous of (some of the retries 
> seem to occur after the original network thread should have terminated).
>

I agree. The kind of unintentional retry causes issues.

>
> Thanks
>
> Phil
>

Best
Nachi

>
> ___
> 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] OpenStack Diagnostics project proposal

2013-10-24 Thread Oleg Gelbukh

Hey folks!

I'm totally excited to present to you a proposal of OpenStack Diagnostics
project (codenamed Rubick).

This project aims to provide a simple and convenient tool (or few tools)
for OpenStack cloud operator to inspect and validate a consistency and
correctness of configuration of their clouds. 'Configuration' I'm talking
about is not limited to parameters in configuration files across all
components of the platform, but also includes environment parameters (like
hardware or network configurations).

Look for the extended project proposal document, as well as some additional
notes and suggestions, on the OpenStack Wiki:
https://wiki.openstack.org/wiki/Rubick.
Source code is on Github: https://github.com/MirantisLabs/rubick.

We've also recorded a short video which shows basic workflow and gives some
reasoning behind the project: http://www.youtube.com/watch?v=zTfRopx5bcA

We're looking forward for your feedback. And if you want to improve it or
integrate it with other tools and initiatives - reach us, we always welcome
new collaborators.

--
Best regards,
Oleg Gelbukh
Mirantis Labs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Disable async network allocation

2013-10-24 Thread Day, Phil

Yep, that was the feature I was referring to.  

As I said I don't have anything defiant that shows this to be not working (and 
the code looks fine) - just wanted to try and simplify the world a bit for a 
while.

-Original Message-
From: Melanie Witt [mailto:melw...@yahoo-inc.com] 
Sent: 24 October 2013 02:48
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Disable async network allocation

On Oct 23, 2013, at 5:56 PM, Aaron Rosen  wrote:

> I believe he's referring to:
>  https://github.com/openstack/nova/blob/master/nova/network/model.py#L335
> https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1211

I found some more background on the feature (not configurable) which might help 
in trying revert it for testing.

https://blueprints.launchpad.net/nova/+spec/async-network-alloc

There was also addition of config option 'network_allocate_retries' which 
defaults to 0:

https://review.openstack.org/#/c/34473/
___
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] RFC - Icehouse logging harmonization

2013-10-24 Thread Lars Kellogg-Stedman

On Thu, Oct 24, 2013 at 07:05:19AM -0700, Dan Smith wrote:
> Some of them are not useful to me (but might be to others), like the
> amqp channel lines. However, everything else has been pretty crucial at
> one point or another when debugging issues that span between the two
> tightly-coupled services.

I am completely unfamiliar with the code, so I apologize if these are
dumb questions:

- Is everything making use of Python's logging module?
- Would this be a could use-case for that module's support of
  file-based configuration
  (http://docs.python.org/2/howto/logging.html#configuring-logging)

This would let a cloud deployer have much more granular control
over what log messages show up (and even what log messages go where).
For example, maybe I don't care about messages from
quantum.openstack.common.rpc.impl_qpid, and I generally only want to
log WARN and above, but I want to see DEBUG messages for
quantum.plugins.openvswitch.agent.ovs_quantum_agent.

Or is that Too Much Flexibility?

-- 
Lars Kellogg-Stedman 

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

[openstack-dev] Warning, entering meeting time confusion zone

2013-10-24 Thread Thierry Carrez

This is your semestrial public service announcement.

This Sunday a large chunk of the world will drop DST, while most
countries in North America will not (until November 3). This generally
results in widespread confusion and chaos until things settle a few
weeks later.

Remember *our meetings are all set in UTC time*, which does not observe
any DST. Therefore your favorite meeting time may or may not change next
week.

In doubt, check UTC times on https://wiki.openstack.org/wiki/Meetings
and convert them to whatever timezone you are in using things like
http://www.timeanddate.com/worldclock/fixedtime.html?hour=21&min=0&sec=0

First one to miss a meeting will be considered time-impaired and forced
to wear a UTC watch at all times.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] RFC - Icehouse logging harmonization

2013-10-24 Thread Dan Smith

> Example 1:
> ==
> 
> n-conductor log in tempest/devstack -
> http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz
> 
> 
> Total log lines: 84076
> Total non DEBUG lines: 61
> 
> Question: do we need more than 1 level of DEBUG? 3 orders of
> magnitude information change between INFO -> DEBUG seems too steep a cliff.

Some of them are not useful to me (but might be to others), like the
amqp channel lines. However, everything else has been pretty crucial at
one point or another when debugging issues that span between the two
tightly-coupled services.

--Dan

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

[openstack-dev] [Nova] Stable/Havana Gate broken

2013-10-24 Thread Gary Kotton

Hi,
The gate for stable Hanava is broken in Nova with the following error:


 ==
2013-10-24 
12:48:35.629
 | FAIL: setUpClass 
(tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629
 | setUpClass (tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629
 | --
2013-10-24 
12:48:35.629
 | _StringException: Traceback (most recent call last):
2013-10-24 
12:48:35.629
 |   File "tempest/scenario/manager.py", line 204, in setUpClass
2013-10-24 
12:48:35.629
 | cls.manager = OfficialClientManager(username, password, tenant_name)
2013-10-24 
12:48:35.630
 |   File "tempest/scenario/manager.py", line 69, in __init__
2013-10-24 
12:48:35.630
 | tenant_name)
2013-10-24 
12:48:35.630
 |   File "tempest/scenario/manager.py", line 101, in _get_compute_client
2013-10-24 
12:48:35.630
 | http_log_debug=True)
2013-10-24 
12:48:35.630
 |   File "/opt/stack/new/python-novaclient/novaclient/client.py", line 450, in 
Client
2013-10-24 
12:48:35.630
 | client_class = get_client_class(version)
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/client.py", line 446, in 
get_client_class
2013-10-24 
12:48:35.631
 | return utils.import_class(client_path)
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/utils.py", line 336, in 
import_class
2013-10-24 
12:48:35.631
 | __import__(mod_str)
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/__init__.py", line 
17, in 
2013-10-24 
12:48:35.631
 | from novaclient.v1_1.client import Client   # noqa
2013-10-24 
12:48:35.631
 |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/client.py", line 
18, in 
2013-10-24 
12:48:35.632
 | from novaclient.v1_1 import agents
2013-10-24 
12:48:35.632
 |   File "/opt/stack/new/python-novaclient/novaclient/v1_1/agents.py", line 
22, in 
2013-10-24 
12:48:35.632
 | from novaclient import base
2013-10-24 
12:48:35.632
 |   File "/opt/stack/new/python-novaclient/novaclient/base.py", line 166,

[openstack-dev] LBaaS: should we check for associations when deleting health monitor?

2013-10-24 Thread Oleg Bondarev

Hi,
Currently in LBaaS when health monitor object is deleted all associations
with pools are deleted automatically. A bug was reported recently in
Neutron where the reporter considers this behavior as wrong:
https://bugs.launchpad.net/neutron/+bug/1243129
I have no strong opinion so I'd like to hear others thoughts on this (devs
and vendors).

One option may be to add kind of 'force_delete' parameter to the delete
operation but that would require changes in api/docs/neutronclient/horizon
what is probably an overkill.

Please add your comments on bug in launchpad.

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

Re: [openstack-dev] [Nova] Blueprint review process

2013-10-24 Thread Dan Smith

> In the last meeting we discussed an idea that I think is worth trying at
> least for icehouse-1 to see if we like it or not.  The idea is that
> *every* blueprint starts out at a Low priority, which means "best
> effort, but no promises".  For a blueprint to get prioritized higher, it
> should have 2 nova-core members signed up to review the resulting code.

Huge +1 to this. I'm in favor of the whole plan, but specifically the
prioritization piece is very important, IMHO.

--Dan

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

Re: [openstack-dev] [Climate] Weekly IRC team meeting

2013-10-24 Thread Nikolay Starodubtsev

+1, but we need to wait for Dina. She has more problems with schedule than
me

Nikolay Starodubtsev

Software Engineer

Mirantis Inc.

Skype: dark_harlequine1


On Thu, Oct 24, 2013 at 4:11 PM, Swann Croiset wrote:

>  +1
>
> Le 24/10/2013 09:45, Sylvain Bauza a écrit :
>
> Hi all,
>
> Climate is growing and time is coming for having a weekly meeting in
> between all of us.
> There is a huge number of reviews in progress, and at least the first
> agenda will be triaging those, making sure they are either coming to trunk
> as soon as possible, or splitted into smaller chunks of code.
>
> The Icehouse summit is also coming, and I would like to take opportunity
> to discuss about any topics we could raise during the Summit.
>
> Is Mondays 10:00am UTC [1] a convenient time for you ?
>
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=10&day=28&hour=10&min=0&sec=0&p1=195&p2=166
>
> -Sylvain
>
>
>
> --
> Swann Croiset
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Remove vim modelines?

2013-10-24 Thread Morgan Fainberg

+1 and likely this should be added to hacking so they don't sneak back in
by accident / reviewers missing the line since we've had them for do long.

On Thursday, October 24, 2013, Flavio Percoco wrote:

> On 24/10/13 13:38 +0100, Joe Gordon wrote:
>
>> Since the beginning of OpenStack we have had vim modelines all over the
>> codebase, but after seeing this patch https://review.opeenstack.org/**
>> #/c/50891/ 
>> I took a further look into vim modelines and think we should remove them.
>> Before going any further, I should point out these lines don't bother me
>> too
>> much but I figured if we could get consensus, then we could shrink our
>> codebase
>> by a little bit.
>>
>> Sidenote: This discussion is being moved to the mailing list because it
>> 'would
>> be better to have a mailing list thread about this rather than bits and
>> pieces
>> of discussion in gerrit' as this change requires multiple patches.
>>  https://
>> review.openstack.org/#/c/**51295/
>> .
>>
>>
>> Why remove them?
>>
>> * Modelines aren't supported by default in debian or ubuntu due to
>> security
>> reasons: https://wiki.python.org/moin/**Vim
>> * Having modelines for vim means if someone wants we should support
>> modelines
>> for emacs (http://www.gnu.org/software/**emacs/manual/html_mono/emacs.**
>> html# 
>> Specifying-File-Variables) etc. as well.  And having a bunch of headers
>> for
>> different editors in each file seems like extra overhead.
>> * There are other ways of making sure tabstop is set correctly for python
>> files, see  
>> https://wiki.python.org/moin/**Vim.
>>  I am a vIm user myself and have
>> never used modelines.
>> * We have vim modelines in only 828 out of 1213 python files in nova
>> (68%), so
>> if anyone is using modelines today, then it only works 68% of the time in
>> nova
>> * Why have the same config 828 times for one repo alone?  This violates
>> the DRY
>> principle (Don't Repeat Yourself).
>>
>>
>> Related Patches:
>> https://review.openstack.org/#**/c/51295/
>> https://review.openstack.org/#**/q/status:open+project:**openstack/
>> nova+branch:master+topic:**noboilerplate,n,z
>>
>>
>
> /me is a vim user!
>
> +1 on removing those lines!
>
>  best,
>> Joe
>>
>
>  __**_
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>>
>
>
> --
> @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] Remove vim modelines?

2013-10-24 Thread Dolph Mathews

On Thu, Oct 24, 2013 at 8:19 AM, Flavio Percoco  wrote:

> On 24/10/13 13:38 +0100, Joe Gordon wrote:
>
>> Since the beginning of OpenStack we have had vim modelines all over the
>> codebase, but after seeing this patch https://review.opeenstack.org/**
>> #/c/50891/ 
>> I took a further look into vim modelines and think we should remove them.
>> Before going any further, I should point out these lines don't bother me
>> too
>> much but I figured if we could get consensus, then we could shrink our
>> codebase
>> by a little bit.
>>
>> Sidenote: This discussion is being moved to the mailing list because it
>> 'would
>> be better to have a mailing list thread about this rather than bits and
>> pieces
>> of discussion in gerrit' as this change requires multiple patches.
>>  https://
>> review.openstack.org/#/c/**51295/
>> .
>>
>>
>> Why remove them?
>>
>> * Modelines aren't supported by default in debian or ubuntu due to
>> security
>> reasons: https://wiki.python.org/moin/**Vim
>> * Having modelines for vim means if someone wants we should support
>> modelines
>> for emacs (http://www.gnu.org/software/**emacs/manual/html_mono/emacs.**
>> html# 
>> Specifying-File-Variables) etc. as well.  And having a bunch of headers
>> for
>> different editors in each file seems like extra overhead.
>> * There are other ways of making sure tabstop is set correctly for python
>> files, see  
>> https://wiki.python.org/moin/**Vim.
>>  I am a vIm user myself and have
>> never used modelines.
>> * We have vim modelines in only 828 out of 1213 python files in nova
>> (68%), so
>> if anyone is using modelines today, then it only works 68% of the time in
>> nova
>> * Why have the same config 828 times for one repo alone?  This violates
>> the DRY
>> principle (Don't Repeat Yourself).
>>
>>
>> Related Patches:
>> https://review.openstack.org/#**/c/51295/
>> https://review.openstack.org/#**/q/status:open+project:**openstack/
>> nova+branch:master+topic:**noboilerplate,n,z
>>
>>
>
> /me is a vim user!
>
> +1 on removing those lines!
>
>
+1 for dd:wq


>  best,
>> Joe
>>
>
>  __**_
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.**org 
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
>
> __**_
> 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

Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps

2013-10-24 Thread Morgan Fainberg

It seems like adopting 0.1.8 is the right approach. If it doesn't work with
other projects, we should work to help those projects get updated to work
with it.

--Morgan

On Thursday, October 24, 2013, Zhi Yan Liu wrote:

> Hi all,
>
> Adopt 0.1.8 as iso8601 minimum version:
> https://review.openstack.org/#/c/53567/
>
> zhiyan
>
> On Thu, Oct 24, 2013 at 4:09 AM, Dolph Mathews 
> >
> wrote:
> >
> > On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins <
> robe...@robertcollins.net >
> > wrote:
> >>
> >> On 24 October 2013 07:34, Mark Washenberger
> >> > wrote:
> >> > Hi folks!
> >> >
> >> > 1) Adopt 0.1.8 as the minimum version in openstack-requirements.
> >> > 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way,
> >> > and
> >> > just fix the tests so they don't care about these extra formats)
> >> > 3) Make Glance work with the added formats even if 0.1.4 is installed.
> >>
> >> I think we should do (1) because both (2) will permit surprising,
> >> nonobvious changes in behaviour and (3) is just nasty engineering.
> >> Alternatively, add a (4) which is (2) with "whinge on startup if 0.1.4
> >> is installed" to make identifying this situation easy.
> >
> >
> > I'm in favor of (1), unless there's a reason why 0.1.8 not viable for
> > another project or packager, in which case, I've never heard the term
> > "whinge" before so there should definitely be some of that.
> >
> >>
> >>
> >> The last thing a new / upgraded deployment wants is something like
> >> nova, or a third party API script failing in nonobvious ways with no
> >> breadcrumbs to lead them to 'upgrade iso8601' as an answer.
> >>
> >> -Rob
> >>
> >> --
> >> Robert Collins >
> >> Distinguished Technologist
> >> HP Converged Cloud
> >>
> >> ___
> >> 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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Remove vim modelines?

2013-10-24 Thread David Ripton


On 10/24/2013 08:38 AM, Joe Gordon wrote:


Why remove them?

* Modelines aren't supported by default in debian or ubuntu due to
security reasons: https://wiki.python.org/moin/Vim
* Having modelines for vim means if someone wants we should support
modelines for emacs
(http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables)
etc. as well.  And having a bunch of headers for different editors in
each file seems like extra overhead.
* There are other ways of making sure tabstop is set correctly for
python files, see https://wiki.python.org/moin/Vim.  I am a vIm user
myself and have never used modelines.
* We have vim modelines in only 828 out of 1213 python files in nova
(68%), so if anyone is using modelines today, then it only works 68% of
the time in nova
* Why have the same config 828 times for one repo alone?  This violates
the DRY principle (Don't Repeat Yourself).


Another +1 from a Vim user.  These patches are No Fun to review, so 
anyone who wants these gone, please pitch in.


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

Re: [openstack-dev] Cinder: create volume hold 'error' state.

2013-10-24 Thread Duncan Thomas

Can you pastebin the full cinder-volume.log please, from the moment
the create RPC comes in until the error (or just the full file if taht
is easier)

On 24 October 2013 13:36, ifzing  wrote:
> Hi all,
>
> I want create volume in horizon, but it report "error" msg.
> And I have following  action，
> 1. stop_service tgt
> 2. mv  /etc/init/tgt.conf  /etc/init/tgt.conf.disabled
> 3. restart_service iscsitarget
>
> And /var/log/cinder/* log is:
> ->
> cinder-api.log:2013-10-24 20:24:20DEBUG [cinder.service] publish_errors
> : False
> cinder-api.log:2013-10-24 20:24:20DEBUG [cinder.service]
> fatal_exception_format_errors : False
> cinder-api.log:2013-10-24 20:24:48AUDIT [cinder.api.v1.volumes]
> vol={'volume_metadata': [], 'availability_zone': u'nova', 'terminated_at':
> None, 'updated_at': datetime.datetime(2013, 10, 24, 12, 24, 45),
> 'snapshot_id': None, 'ec2_id': None, 'mountpoint': None, 'deleted_at': None,
> 'id': u'7ebff319-838a-4f09-807b-372be8b26c13', 'size': 1L, 'user_id':
> u'90b47b1766924e078ca9fc03e5153fd0', 'attach_time': None,
> 'display_description': u'', 'project_id':
> u'f822eef7155046a68d20d71f3c37ac43', 'launched_at': None, 'scheduled_at':
> datetime.datetime(2013, 10, 24, 12, 24, 45), 'status': u'error',
> 'volume_type_id': None, 'deleted': False, 'provider_location': None,
> 'volume_glance_metadata': [], 'host': u'SDE-main-controller',
> 'source_volid': None, 'provider_auth': None, 'display_name': u'12',
> 'instance_uuid': None, 'created_at': datetime.datetime(2013, 10, 24, 12, 24,
> 44), 'attach_status': u'detached', 'volume_type': None}
> cinder-scheduler.log:2013-10-24 20:24:20DEBUG [cinder.service]
> publish_errors : False
> cinder-scheduler.log:2013-10-24 20:24:20DEBUG [cinder.service]
> fatal_exception_format_errors : False
> cinder-volume.log:2013-10-24 20:24:45ERROR [cinder.volume.manager]
> volume volume-7ebff319-838a-4f09-807b-372be8b26c13: create failed
> cinder-volume.log:2013-10-24 20:24:45ERROR
> [cinder.openstack.common.rpc.amqp] Exception during message handling
> cinder-volume.log:LOG.error(_("volume %s: create failed"),
> volume_ref['name'])
> cinder-volume.log:ProcessExecutionError: Unexpected error while running
> command.
> ->
>
> Any body meet the same state?
> or, Any one have resolved it?
>
> regards,
> Thanks,
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Duncan Thomas

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

Re: [openstack-dev] Remove vim modelines?

2013-10-24 Thread Yuriy Taraday

+1 on the topic

How about we catch them in hacking so that they won't ever come back?


On Thu, Oct 24, 2013 at 4:53 PM, Davanum Srinivas  wrote:

> +1 to remove them.
>
> -- dims
>
> On Thu, Oct 24, 2013 at 8:44 AM, Monty Taylor 
> wrote:
> >
> >
> > On 10/24/2013 08:38 AM, Joe Gordon wrote:
> >> Since the beginning of OpenStack we have had vim modelines all over the
> >> codebase, but after seeing this
> >> patch https://review.opeenstack.org/#/c/50891/
> >>  I took a further look into
> vim
> >> modelines and think we should remove them. Before going any further, I
> >> should point out these lines don't bother me too much but I figured if
> >> we could get consensus, then we could shrink our codebase by a little
> bit.
> >>
> >> Sidenote: This discussion is being moved to the mailing list because it
> >> 'would be better to have a mailing list thread about this rather than
> >> bits and pieces of discussion in gerrit' as this change requires
> >> multiple patches.  https://review.openstack.org/#/c/51295/.
> >>
> >>
> >> Why remove them?
> >>
> >> * Modelines aren't supported by default in debian or ubuntu due to
> >> security reasons: https://wiki.python.org/moin/Vim
> >> * Having modelines for vim means if someone wants we should support
> >> modelines for emacs
> >> (
> http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables
> )
> >> etc. as well.  And having a bunch of headers for different editors in
> >> each file seems like extra overhead.
> >> * There are other ways of making sure tabstop is set correctly for
> >> python files, see  https://wiki..python.org/moin/Vim
> >> .  I am a vIm user myself and have
> >> never used modelines.
> >> * We have vim modelines in only 828 out of 1213 python files in nova
> >> (68%), so if anyone is using modelines today, then it only works 68% of
> >> the time in nova
> >> * Why have the same config 828 times for one repo alone?  This violates
> >> the DRY principle (Don't Repeat Yourself).
> >>
> >>
> >> Related Patches:
> >> https://review.openstack.org/#/c/51295/
> >>
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z
> >
> > I agree with everything - both not caring about this topic really, and
> > that we should just kill them and be done with it. Luckily, this is a
> > suuper easy global search and replace.
> >
> > Also, since we gate on pep8, if your editor is configured incorrectly,
> > you'll figure it out soon enough.
> >
> > ___
> > 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
>



-- 

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

Re: [openstack-dev] Remove vim modelines?

2013-10-24 Thread Flavio Percoco


On 24/10/13 13:38 +0100, Joe Gordon wrote:

Since the beginning of OpenStack we have had vim modelines all over the
codebase, but after seeing this patch https://review.opeenstack.org/#/c/50891/
I took a further look into vim modelines and think we should remove them.
Before going any further, I should point out these lines don't bother me too
much but I figured if we could get consensus, then we could shrink our codebase
by a little bit.

Sidenote: This discussion is being moved to the mailing list because it 'would
be better to have a mailing list thread about this rather than bits and pieces
of discussion in gerrit' as this change requires multiple patches.  https://
review.openstack.org/#/c/51295/.


Why remove them?

* Modelines aren't supported by default in debian or ubuntu due to security
reasons: https://wiki.python.org/moin/Vim
* Having modelines for vim means if someone wants we should support modelines
for emacs (http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#
Specifying-File-Variables) etc. as well.  And having a bunch of headers for
different editors in each file seems like extra overhead.
* There are other ways of making sure tabstop is set correctly for python
files, see  https://wiki.python.org/moin/Vim.  I am a vIm user myself and have
never used modelines.
* We have vim modelines in only 828 out of 1213 python files in nova (68%), so
if anyone is using modelines today, then it only works 68% of the time in nova
* Why have the same config 828 times for one repo alone?  This violates the DRY
principle (Don't Repeat Yourself).


Related Patches:
https://review.openstack.org/#/c/51295/
https://review.openstack.org/#/q/status:open+project:openstack/
nova+branch:master+topic:noboilerplate,n,z




/me is a vim user!

+1 on removing those lines!


best,
Joe



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



--
@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] Announcing Project Solum

2013-10-24 Thread Thomas Spatzier

Hi Adrian,

really intersting! I wonder what the relation to all the software
orchestration in Heat discussions is that have been going on for a while
now.

Regards,
Thomas

Adrian Otto  wrote on 23.10.2013 21:03:10:
> From: Adrian Otto 
> To: OpenStack Development Mailing List
,
> Date: 23.10.2013 21:07
> Subject: [openstack-dev] Announcing Project Solum
>
> OpenStack,
>
> OpenStack has emerged as the preferred choice for open cloud
> software worldwide. We use it to power our cloud, and we love it.
> We’re proud to be a part of growing its capabilities to address more
> needs every day. When we ask customers, partners, and community
> members about what problems they want to solve next, we have
> consistently found a few areas where OpenStack has room to grow in
> addressing the needs of software developers:

> 1)   Ease of application development and deployment via integrated
> support for Git, CI/CD, and IDEs
>
> 2)   Ease of application lifecycle management across dev, test, and
> production types of environments -- supported by the Heat project’s
> automated orchestration (resource deployment, monitoring-based self-
> healing, auto-scaling, etc.)
>
> 3)   Ease of application portability between public and private
> clouds -- with no vendor-driven requirements within the application
> stack or control system
>
> Along with eBay, RedHat, Ubuntu/Canonical, dotCloud/Docker,
> Cloudsoft, and Cumulogic, we at Rackspace are happy to announce we
> have started project Solum as an OpenStack Related open source
> project. Solum is a community-driven initiative currently in its
> open design phase amongst the seven contributing companies with more to
come.
>
> We plan to leverage the capabilities already offered in OpenStack in
> addressing these needs so anyone running an OpenStack cloud can make
> it easier to use for developers. By leveraging your existing
> OpenStack cloud, the aim of Project Solum is to reduce the number of
> services you need to manage in tackling these developer needs. You
> can use all the OpenStack services you already run instead of
> standing up overlapping, vendor-specific capabilities to accomplish this.
>
> We welcome you to join us to build this exciting new addition to the
> OpenStack ecosystem.
>
> Project Wiki
> https://wiki.openstack.org/wiki/Solum
>
> Lauchpad Project
> https://launchpad.net/solum
>
> IRC
> Public IRC meetings are held on Tuesdays 1600 UTC
> irc://irc.freenode.net:6667/solum
>
> Thanks,
>
> Adrian Otto___
> 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] [Heat] HOT Software configuration proposal

2013-10-24 Thread Thomas Spatzier

Hi all,

maybe a bit off track with respect to latest concrete discussions, but I
noticed the announcement of project "Solum" on openstack-dev.
Maybe this is playing on a different level, but I still see some relation
to all the software orchestration we are having. What are your opinions on
this?

BTW, I just posted a similar short question in reply to the Solum
announcement mail, but some of us have mail filters an might read [Heat]
mail with higher prio, and I was interested in the Heat view.

Cheers,
Thomas

Patrick Petit  wrote on 24.10.2013 12:15:13:
> From: Patrick Petit 
> To: OpenStack Development Mailing List
,
> Date: 24.10.2013 12:18
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Sorry, I clicked the 'send' button too quickly.
>
> On 10/24/13 11:54 AM, Patrick Petit wrote:
> > Hi Clint,
> > Thank you! I have few replies/questions in-line.
> > Cheers,
> > Patrick
> > On 10/23/13 8:36 PM, Clint Byrum wrote:
> >> Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:
> >>> Dear Steve and All,
> >>>
> >>> If I may add up on this already busy thread to share our experience
> >>> with
> >>> using Heat in large and complex software deployments.
> >>>
> >> Thanks for sharing Patrick, I have a few replies in-line.
> >>
> >>> I work on a project which precisely provides additional value at the
> >>> articulation point between resource orchestration automation and
> >>> configuration management. We rely on Heat and chef-solo respectively
> >>> for
> >>> these base management functions. On top of this, we have developed an
> >>> event-driven workflow to manage the life-cycles of complex software
> >>> stacks which primary purpose is to support middleware components as
> >>> opposed to end-user apps. Our use cases are peculiar in the sense
that
> >>> software setup (install, config, contextualization) is not a one-time
> >>> operation issue but a continuous thing that can happen any time in
> >>> life-span of a stack. Users can deploy (and undeploy) apps long time
> >>> after the stack is created. Auto-scaling may also result in an
> >>> asynchronous apps deployment. More about this latter. The framework
we
> >>> have designed works well for us. It clearly refers to a PaaS-like
> >>> environment which I understand is not the topic of the HOT software
> >>> configuration proposal(s) and that's absolutely fine with us.
However,
> >>> the question for us is whether the separation of software config from
> >>> resources would make our life easier or not. I think the answer is
> >>> definitely yes but at the condition that the DSL extension preserves
> >>> almost everything from the expressiveness of the resource element. In
> >>> practice, I think that a strict separation between resource and
> >>> component will be hard to achieve because we'll always need a little
> >>> bit
> >>> of application's specific in the resources. Take for example the
> >>> case of
> >>> the SecurityGroups. The ports open in a SecurityGroup are application
> >>> specific.
> >>>
> >> Components can only be made up of the things that are common to all
> >> users
> >> of said component. Also components would, if I understand the concept
> >> correctly, just be for things that are at the sub-resource level.
> >> Security groups and open ports would be across multiple resources, and
> >> thus would be separately specified from your app's component (though
it
> >> might be useful to allow components to export static values so that
the
> >> port list can be referred to along with the app component).
> Okay got it. If that's the case then that would work
> >>
> >>> Then, designing a Chef or Puppet component type may be harder than it
> >>> looks at first glance. Speaking of our use cases we still need a
little
> >>> bit of scripting in the instance's user-data block to setup a working
> >>> chef-solo environment. For example, we run librarian-chef prior to
> >>> starting chef-solo to resolve the cookbook dependencies. A cookbook
can
> >>> present itself as a downloadable tarball but it's not always the
> >>> case. A
> >>> chef component type would have to support getting a cookbook from a
> >>> public or private git repo (maybe subversion), handle situations
where
> >>> there is one cookbook per repo or multiple cookbooks per repo, let
the
> >>> user choose a particular branch or label, provide ssh keys if it's a
> >>> private repo, and so forth. We support all of this scenarios and so
we
> >>> can provide more detailed requirements if needed.
> >>>
> >> Correct me if I'm wrong though, all of those scenarios are just
> >> variations
> >> on standard inputs into chef. So the chef component really just has to
> >> allow a way to feed data to chef.
> >
> That's correct. Boils down to specifying correctly all the constraints
> that apply to deploying a cookbook in an instance from it's component
> description.
> >>
> >>> I am not sure adding component relations like the 'depends-on' would
> >>> rea

Re: [openstack-dev] Remove vim modelines?

2013-10-24 Thread Davanum Srinivas

+1 to remove them.

-- dims

On Thu, Oct 24, 2013 at 8:44 AM, Monty Taylor  wrote:
>
>
> On 10/24/2013 08:38 AM, Joe Gordon wrote:
>> Since the beginning of OpenStack we have had vim modelines all over the
>> codebase, but after seeing this
>> patch https://review.opeenstack.org/#/c/50891/
>>  I took a further look into vim
>> modelines and think we should remove them. Before going any further, I
>> should point out these lines don't bother me too much but I figured if
>> we could get consensus, then we could shrink our codebase by a little bit.
>>
>> Sidenote: This discussion is being moved to the mailing list because it
>> 'would be better to have a mailing list thread about this rather than
>> bits and pieces of discussion in gerrit' as this change requires
>> multiple patches.  https://review.openstack.org/#/c/51295/.
>>
>>
>> Why remove them?
>>
>> * Modelines aren't supported by default in debian or ubuntu due to
>> security reasons: https://wiki.python.org/moin/Vim
>> * Having modelines for vim means if someone wants we should support
>> modelines for emacs
>> (http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables)
>> etc. as well.  And having a bunch of headers for different editors in
>> each file seems like extra overhead.
>> * There are other ways of making sure tabstop is set correctly for
>> python files, see  https://wiki..python.org/moin/Vim
>> .  I am a vIm user myself and have
>> never used modelines.
>> * We have vim modelines in only 828 out of 1213 python files in nova
>> (68%), so if anyone is using modelines today, then it only works 68% of
>> the time in nova
>> * Why have the same config 828 times for one repo alone?  This violates
>> the DRY principle (Don't Repeat Yourself).
>>
>>
>> Related Patches:
>> https://review.openstack.org/#/c/51295/
>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z
>
> I agree with everything - both not caring about this topic really, and
> that we should just kill them and be done with it. Luckily, this is a
> suuper easy global search and replace.
>
> Also, since we gate on pep8, if your editor is configured incorrectly,
> you'll figure it out soon enough.
>
> ___
> 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] Remove vim modelines?

2013-10-24 Thread Monty Taylor



On 10/24/2013 08:38 AM, Joe Gordon wrote:
> Since the beginning of OpenStack we have had vim modelines all over the
> codebase, but after seeing this
> patch https://review.opeenstack.org/#/c/50891/
>  I took a further look into vim
> modelines and think we should remove them. Before going any further, I
> should point out these lines don't bother me too much but I figured if
> we could get consensus, then we could shrink our codebase by a little bit.
> 
> Sidenote: This discussion is being moved to the mailing list because it
> 'would be better to have a mailing list thread about this rather than
> bits and pieces of discussion in gerrit' as this change requires
> multiple patches.  https://review.openstack.org/#/c/51295/.
> 
> 
> Why remove them?
> 
> * Modelines aren't supported by default in debian or ubuntu due to
> security reasons: https://wiki.python.org/moin/Vim
> * Having modelines for vim means if someone wants we should support
> modelines for emacs
> (http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables)
> etc. as well.  And having a bunch of headers for different editors in
> each file seems like extra overhead.
> * There are other ways of making sure tabstop is set correctly for
> python files, see  https://wiki..python.org/moin/Vim
> .  I am a vIm user myself and have
> never used modelines.
> * We have vim modelines in only 828 out of 1213 python files in nova
> (68%), so if anyone is using modelines today, then it only works 68% of
> the time in nova
> * Why have the same config 828 times for one repo alone?  This violates
> the DRY principle (Don't Repeat Yourself).
> 
> 
> Related Patches:
> https://review.openstack.org/#/c/51295/
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z

I agree with everything - both not caring about this topic really, and
that we should just kill them and be done with it. Luckily, this is a
suuper easy global search and replace.

Also, since we gate on pep8, if your editor is configured incorrectly,
you'll figure it out soon enough.

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

Re: [openstack-dev] VPNaaS questions...

2013-10-24 Thread Paul Michali

I put the client code out for review as WIP:

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

Regards,

PCM (Paul Michali)

MAIL p...@cisco.com
IRC   pcm_  (irc.freenode.net)
TW   @pmichali

On Oct 23, 2013, at 4:53 PM, Nachi Ueno  wrote:

> Hi Paul
> 
> I rebased the patch, and working on unit testing too
> https://review.openstack.org/#/c/41827/
> 
> 
> 2013/10/23 Paul Michali :
>> See PCM: in-line.
>> 
>> 
>> PCM (Paul Michali)
>> 
>> MAIL p...@cisco.com
>> IRC   pcm_  (irc.freenode.net)
>> TW   @pmichali
>> 
>> On Oct 23, 2013, at 9:41 AM, Akihiro Motoki  wrote:
>> 
>> Hi Paul,
>> 
>> 
>> On Wed, Oct 23, 2013 at 9:56 PM, Paul Michali  wrote:
>> 
>> 
>> Hi guys,
>> 
>> Some questions on VPNaaS…
>> 
>> Can we get the review reopened of the service type framework changes for VPN
>> on the server side?
>> I was thinking of trying to rebase that patch, based on the latest from
>> master, but before doing so, I ran TOX on the latest master commit. TOX
>> fails with a bunch of errors, some reporting that the system is out of
>> memory. I have a 4GB Ubuntu 12.04 VM for this and I see it max out on
>> memory, when TOX is run on the whole Neutron code for py27. Anyone seen
>> this?
>> 
>> 
>> I see this too. On 4GB Ubuntu 13.04 VM, I have over 1GB swap while
>> running the whole test
>> and the test slows down after swap begins….
>> 
>> 
>> PCM: Whew! I was worried that it was something in my setup.  Any idea on a
>> root cause/workaround? Is this happening when Jenkins runs?
>> 
>> 
>> 
>> 
>> 
>> I have tried the current patch of service type framework, and found that
>> client changes are needed too. I have changes ready for review, should I
>> post them, or do we need to wait (or indicate some dependency on the server
>> side changes)?
>> 
>> 
>> My suggestion is to post a patch with WIP status.
>> We can test the server side patch with CLI. It really helps us all.
>> 
>> 
>> PCM: Thanks! I wasn't sure how to proceed as the client change is useless
>> w/o the server change.
> 
> Yeah, please push wip :)
> 
>> 
>> I see that there is VPN connection status and VPN service status. What is
>> the purpose of the latter? What is the status, if the service has multiple
>> connections in different states?
>> 
>> 
>> I see the same.
>> 
>> 
>> PCM: Yeah, need to understand what the desired meaning is for the service
>> status in this context.
>> 
> 
> In openswan impl,
> vpnservice state is the state of openswan process.
> ipsec-site-connection state is actual connection state.
> 
> so let's say we have two site.
> Vpnservice will be ACTIVE and ipsec-site-connection's state will be DOWN after
> we setup only one site.
> 
> 
>> 
>> 
>> Have you guys tried VPNaaS with Havana and the now default ML2 plugin? I got
>> a failure on connection create, saying that it could not find
>> get_l3_agents_hosting_routers() attribute. I haven't looked into this yet,
>> but will try as soon as I can.
>> 
>> 
>> I think https://bugs.launchpad.net/neutron/+bug/1238846 is same as
>> what you encountered.
>> I believe this bug was fixed in the final RC. Doesn't it work?
>> 
>> 
>> PCM: Ah, I missed that bug review. I probably need to update my repo with
>> the latest to pick this up.  Thanks!
>> 
>> Regards,
>> 
>> PCM
>> 
>> 
>> 
>> Thanks,
>> Akihiro
>> 
>> 
>> Thanks!
>> 
>> PCM (Paul Michali)
>> 
>> Contact info for Cisco users http://twiki.cisco.com/Main/pcm
>> 
>> 
>> 
>> ___
>> 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
>> 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-24 Thread Ilya Sviridov

So, we have 2 places for configuration management - database and config file

Config file for tunning all datasource type behavior during installation
and database for all changeable configurations during usage and
administration of Trove installation.

Database usecases:
- update/custom image
- update/custom packages
- activating/deactivating datastore_type

Config file usecases:
- security group policy
- provisioning mechanism
- guest configuration parameters per database engine
- provisioning  parameters, templates
- manager class
...

In case if i need to register one more MySQL installation with following
customization:
- custom heat template
- custom packages and additional monitoring tool package
- open specific port for working with my monitoring tool on instance

According to current concept should i add one more section in addition to
existing mysql like below?

[monitored_mysql]
mount_point=/var/lib/mysql

#8080 is port of my monitoring tool
trove_security_group_rule_ports = 3306, 8080
heat_template=/etc/trove/heat_templates/monitored_mysql.yaml
...

and put additional packages to database configuration?





With best regards,
Ilya Sviridov




On Wed, Oct 23, 2013 at 9:37 PM, Michael Basnight wrote:

>
> On Oct 23, 2013, at 10:54 AM, Ilya Sviridov wrote:
>
> > Besides the strategy of selecting the default behavior.
> >
> > Let me share with you my ideas of configuration management in Trove and
> how the datastore concept can help with that.
> >
> > Initially there was only one database and all configuration was in one
> config file.
> > With adding of new databases, heat provisioning mechanism, we are
> introducing more options.
> >
> > Not only assigning specific image_id, but custom packages, heat
> templates, probably specific strategies of working with security groups.
> > Such needs already exist because we have a lot of optional things in
> config, and any new feature is implemented with back sight to already
> existing legacy installations of Trove.
> >
> > What is  actually datastore_type + datastore_version?
> >
> > The model which glues all the bricks together, so let us use it for all
> variable part of *service type* configuration.
> >
> > from current config file
> >
> > # Trove DNS
> > trove_dns_support = False
> >
> > # Trove Security Groups for Instances
> > trove_security_groups_support = True
> > trove_security_groups_rules_support = False
> > trove_security_group_rule_protocol = tcp
> > trove_security_group_rule_port = 3306
> > trove_security_group_rule_cidr = 0.0.0.0/0
> >
> > #guest_config = $pybasedir/etc/trove/trove-guestagent.conf.sample
> > #cloudinit_location = /etc/trove/cloudinit
> >
> > block_device_mapping = vdb
> > device_path = /dev/vdb
> > mount_point = /var/lib/mysql
> >
> > All that configurations can be moved to data_strore (some defined in
> heat templates) and be manageable by operator in case if any default
> behavior should be changed.
> >
> > The trove-config becomes core functionality specific only.
>
> Its fine for it to be in the config or the heat templates… im not sure it
> matters. what i would like to see is that specific thing to each service be
> in their own config group in the configuration.
>
> [mysql]
> mount_point=/var/lib/mysql
> …
> [redis]
> volume_support=False
> …..
>
> and so on.
>
> ___
> 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] Remove vim modelines?

Since the beginning of OpenStack we have had vim modelines all over the
codebase, but after seeing this patch
https://review.opeenstack.org/#/c/50891/I
took a further look into vim modelines and think we should remove
them.
Before going any further, I should point out these lines don't bother me
too much but I figured if we could get consensus, then we could shrink our
codebase by a little bit.

Sidenote: This discussion is being moved to the mailing list because it 'would
be better to have a mailing list thread about this rather than bits and
pieces of discussion in gerrit' as this change requires multiple patches.
https://review.openstack.org/#/c/51295/.

Why remove them?

* Modelines aren't supported by default in debian or ubuntu due to security
reasons: https://wiki.python.org/moin/Vim
* Having modelines for vim means if someone wants we should support
modelines for emacs (
http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables)
etc. as well. And having a bunch of headers for different editors in each
file seems like extra overhead.
* There are other ways of making sure tabstop is set correctly for python
files, see https://wiki.python.org/moin/Vim. I am a vIm user myself and
have never used modelines.
* We have vim modelines in only 828 out of 1213 python files in nova (68%),
so if anyone is using modelines today, then it only works 68% of the time
in nova
* Why have the same config 828 times for one repo alone? This violates the
DRY principle (Don't Repeat Yourself).

Related Patches:
https://review.openstack.org/#/c/51295/
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z

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

[openstack-dev] Cinder: create volume hold 'error' state.

2013-10-24 Thread ifzing

Hi all, 


I want create volume in horizon, but it report "error" msg.
And I have following  action，
1. stop_service tgt
2. mv  /etc/init/tgt.conf  /etc/init/tgt.conf.disabled
3. restart_service iscsitarget


And /var/log/cinder/* log is:
->
cinder-api.log:2013-10-24 20:24:20DEBUG [cinder.service] publish_errors : 
False
cinder-api.log:2013-10-24 20:24:20DEBUG [cinder.service] 
fatal_exception_format_errors : False
cinder-api.log:2013-10-24 20:24:48AUDIT [cinder.api.v1.volumes] 
vol={'volume_metadata': [], 'availability_zone': u'nova', 'terminated_at': 
None, 'updated_at': datetime.datetime(2013, 10, 24, 12, 24, 45), 'snapshot_id': 
None, 'ec2_id': None, 'mountpoint': None, 'deleted_at': None, 'id': 
u'7ebff319-838a-4f09-807b-372be8b26c13', 'size': 1L, 'user_id': 
u'90b47b1766924e078ca9fc03e5153fd0', 'attach_time': None, 
'display_description': u'', 'project_id': u'f822eef7155046a68d20d71f3c37ac43', 
'launched_at': None, 'scheduled_at': datetime.datetime(2013, 10, 24, 12, 24, 
45), 'status': u'error', 'volume_type_id': None, 'deleted': False, 
'provider_location': None, 'volume_glance_metadata': [], 'host': 
u'SDE-main-controller', 'source_volid': None, 'provider_auth': None, 
'display_name': u'12', 'instance_uuid': None, 'created_at': 
datetime.datetime(2013, 10, 24, 12, 24, 44), 'attach_status': u'detached', 
'volume_type': None}
cinder-scheduler.log:2013-10-24 20:24:20DEBUG [cinder.service] 
publish_errors : False
cinder-scheduler.log:2013-10-24 20:24:20DEBUG [cinder.service] 
fatal_exception_format_errors : False
cinder-volume.log:2013-10-24 20:24:45ERROR [cinder.volume.manager] volume 
volume-7ebff319-838a-4f09-807b-372be8b26c13: create failed
cinder-volume.log:2013-10-24 20:24:45ERROR 
[cinder.openstack.common.rpc.amqp] Exception during message handling
cinder-volume.log:LOG.error(_("volume %s: create failed"), 
volume_ref['name'])
cinder-volume.log:ProcessExecutionError: Unexpected error while running command.
->


Any body meet the same state?
or, Any one have resolved it?


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

Re: [openstack-dev] [Climate] Weekly IRC team meeting

2013-10-24 Thread Swann Croiset


+1

Le 24/10/2013 09:45, Sylvain Bauza a écrit :

Hi all,

Climate is growing and time is coming for having a weekly meeting in 
between all of us.
There is a huge number of reviews in progress, and at least the first 
agenda will be triaging those, making sure they are either coming to 
trunk as soon as possible, or splitted into smaller chunks of code.


The Icehouse summit is also coming, and I would like to take 
opportunity to discuss about any topics we could raise during the Summit.


Is Mondays 10:00am UTC [1] a convenient time for you ?
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=10&day=28&hour=10&min=0&sec=0&p1=195&p2=166

-Sylvain



--
Swann Croiset

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

Re: [openstack-dev] [Nova] Blueprint review process

On Wed, Oct 23, 2013 at 4:33 PM, Russell Bryant  wrote:

> Greetings,
>
> At the last Nova meeting we started talking about some updates to the
> Nova blueprint process for the Icehouse cycle.  I had hoped we could
> talk about and finalize this in a Nova design summit session on "Nova
> Project Structure and Process" [1], but I think we need to push forward
> on finalizing this as soon as possible so that it doesn't block current
> work being done.
>
> Here is a first cut at the process.  Let me know what you think is
> missing or should change.  I'll get the result of this thread posted on
> the wiki.
>
> 1) Proposing a Blueprint
>
> Proposing a blueprint for Nova is not much different than other
> projects.  You should follow the instructions here:
>
> https://wiki.openstack.org/wiki/Blueprints
>
> The particular important step that seems to be missed by most is:
>
> "Once it is ready for PTL review, you should set:
>
> Milestone: Which part of the release cycle you think your work will be
> proposed for merging."
>
> That is really important.  Due to the volume of Nova blueprints, it
> probably will not be seen until you do this.
>
> 2) Blueprint Review Team
>
> Ensuring blueprints get reviewed is one of the responsibilities of the
> PTL.  However, due to the volume of Nova blueprints, it's not practical
> for me to do it alone.  A team of people (nova-drivers) [2], a subset of
> nova-core, will be doing blueprint reviews.
>
> By having more people reviewing blueprints, we can do a more thorough
> job and have a higher quality result.
>
> Note that even though there is a nova-drivers team, *everyone* is
> encouraged to participate in the review process by providing feedback on
> the mailing list.
>
> 3) Blueprint Review Criteria
>
> Here are some things that the team reviewing blueprints should look for:
>
> The blueprint ...
>
>  - is assigned to the person signing up to do the work
>
>  - has been targeted to the milestone when the code is
>planned to be completed
>
>  - is an appropriate feature for Nova.  This means it fits with the
>vision for Nova and OpenStack overall.  This is obviously very
>subjective, but the result should represent consensus.
>
>  - includes enough detail to be able to complete an initial design
>review before approving the blueprint. In many cases, the design
>review may result in a discussion on the mailing list to work
>through details. A link to this discussion should be left in the
>whiteboard of the blueprint for reference.  This initial design
>review should be completed before the blueprint is approved.
>
>  - includes information that describes the user impact (or lack of).
>Between the blueprint and text that comes with the DocImpact flag [3]
>in commits, the docs team should have *everything* they need to
>thoroughly document the feature.
>
> Once the review has been complete, the blueprint should be marked as
> approved and the priority should be set.  A set priority is how we know
> from the blueprint list which ones have already been reviewed.
>
> 4) Blueprint Prioritization
>
> I would like to do a better job of using priorities in Icehouse.  The
> priority field services a couple of purposes:
>
>   - helps reviewers prioritize their time
>
>   - helps set expectations for the submitter for how reviewing this
> work stacks up against other things
>
> In the last meeting we discussed an idea that I think is worth trying at
> least for icehouse-1 to see if we like it or not.  The idea is that
> *every* blueprint starts out at a Low priority, which means "best
> effort, but no promises".  For a blueprint to get prioritized higher, it
> should have 2 nova-core members signed up to review the resulting code.
>
> If we do this, I suspect we may end up with more blueprints at Low, but
> I also think we'll end up with a more realistic list of blueprints.  The
> reality is if a feature doesn't have reviewers agreeing to do the
> review, it really is in a "best effort, but no promises" situation.
>
> 5) Blueprint Fall Cleaning
>
> Finally, it's about time we do some cleaning of the blueprint backlog.
> There are a bunch not currently being worked on.  I propose that we
> close out all blueprints not targeted at a release milestone by November
> 22 (2 weeks after the end of the design summit), with the exception of
> anything just recently filed and still being drafted.
>
>
++ to the entire process, two comments though.

* It would be great to get this into a wiki for future reference
* We shouldn't merge patches with un-approved blueprints. And when that
happens having a wiki page to point to would be great.


>
> [1] http://summit.openstack.org/cfp/details/341
> [2] https://launchpad.net/~nova-drivers/+members#active
> [3]
> http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-de

Re: [openstack-dev] RFC - Icehouse logging harmonization