Re: [openstack-dev] [Openstack] Question regarding Nova in Havana

[Prashant Upadhyaya]

Hi Vish,

Thanks, now one more question -

When I send the request out, I send it to the exchange 'nova' and routing key 
'conductor' (using RabbitMQ), this will take the message to the Nova Conductor 
on the controller, I have been able to do that much.
I do see that there is a 'reply queue' embedded in the above message so 
presumably the Nova Conductor will use that queue to send back the response, is 
that correct ?
If the above is correct, what is the 'exchange' used Nova Conductor to send 
back this response.

Regards
-Prashant


From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: Wednesday, April 16, 2014 10:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Prashant Upadhyaya
Subject: Re: [openstack-dev] [Openstack] Question regarding Nova in Havana

The service reference is created in the start method of the service. This 
happens around line 217 in nova/service.py in the current code. You should be 
able to do something similar by sending a message to service_create on 
conductor. It will return an error if the service already exists. Note you can 
also use service_get_by_args in conductor to see if the service exists.

Vish

On Apr 15, 2014, at 9:22 PM, Swapnil S Kulkarni 
mailto:cools...@gmail.com>> wrote:


Interesting discussion. Forwarding to openstack-dev.

On Wed, Apr 16, 2014 at 9:34 AM, Prashant Upadhyaya 
mailto:prashant.upadhy...@aricent.com>> wrote:
Hi,

I am writing a Compute Node Simulator.
The idea is that I would write a piece of software using C which honors the 
RabbitMQ interface towards the Controller, but will not actually do the real 
thing - everything on the Compute Node will be simulated by my simulator 
software.

The  problem I am facing, that I have not been able to get my simulated CN 
listed in the output of
nova-manage service list

I am on Havana, and my simulator is sending a periodic  'service_update' and 
'compute_node_update' RPC messages to the 'nova' exchange and the 'conductor' 
routing key.
I can manipulate the above messages at will to fool the controller.
(I observe the messages from a real CN and take cues from there to construct a 
fake one from my simulator)

Question is - what causes the controller to add a new Nova Compute in its 
database, is it the 'service_update' RPC or something else.

Hopefully you can help me reverse engineer the interface.

Regards
-Prashant




"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."

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

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



"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] deliver the vm-level HA to improve the business continuity with openstack

[Chris Friesen]

On 04/15/2014 08:33 PM, Jay Pipes wrote:

On Tue, 2014-04-15 at 12:01 +0100, Duncan Thomas wrote:

On 14 April 2014 19:51, James Penick  wrote:

We drive the ³VM=Cattle² message pretty hard. Part of onboarding a
property to our cloud, and allowing them to serve traffic from VMs is
explaining the transient nature of VMs. I broadcast the message that all
compute resources die, and if your day/week/month is ruined because of a
single compute instance going away, then you¹re doing something Very
Wrong. :)


While I agree with the message, if cloud provider A has VM restarts
every hour, and B has restarts every 6 months, all other things being
equal I'm going to go with B.


Pretty sure James wasn't saying that he restarts VMs every hour. The
idea is that applications that run on a utility cloud should be
resilient and take into account failure as an expected part of
operating.


This is certainly true for public utility clouds.  I'd expect any 
application on a public cloud to be cloud-aware.


On the other hand, there are companies that want to use OpenStack for 
private cloud management, and these may be running applications that are 
not cloud-aware. Thay may have been migrated to a private cloud for 
server consolidation, etc. and they're looking for some of the same 
enterprise-type functionality that they can get from vmware but with the 
advantages of free (both beer and speech) software.



Restarts are a pain point for most
systems, requiring data resynchronisation etc, so looking to minimise
them is a good aim as long as it doesn't conflict much with other
concerns...


I'm actually not entirely sure what restarts and data resync have to do
with vm-level HA? What am I missing here?


In some cases if you're doing hot-standby then you can take out the 
active and have the standby take over without needing to restart anything.


Chris

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

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

[Gary Kotton]

+1



On 4/16/14 1:35 AM, "Carl Baldwin"  wrote:

>+1.  I think we'll like this process better.  I hope to have some of
>the first blueprints to propose to the new repository very soon.
>
>On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery 
>wrote:
>> Given the success the Nova team has had in handling reviews using
>> their new nova-specs gerrit repository, I think it makes a lot of
>> sense for Neutron to do the same. With this in mind, I've added
>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
>> this is how Neutron BPs will be handled by the Neutron core team. If
>> you are currently working on a BP or code for Juno which is attached
>> to a BP, please file the BP using the process here [1].
>>
>> Given this is our first attempt at using this for reviews, I
>> anticipate there may be a few hiccups along the way. Please reply on
>> this thread or reach out in #openstack-neutron and we'll sort through
>> whatever issues we find.
>>
>> Thanks!
>> Kyle
>>
>> [1] 
>>https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik
>>i/Blueprints%23Neutron&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NP
>>ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=MyzVItNCAzhBG2AUe%2FpCJRMnHjrDq
>>gITgT1fkxc3s0k%3D%0A&s=caf23da791f6776beb0a12441650f4969ebdd9aa9f35d27f56
>>0ad144c12bf354
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
>>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
>>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=MyzVItNCAzhBG2AUe%
>>2FpCJRMnHjrDqgITgT1fkxc3s0k%3D%0A&s=08c9066de11d376ded51257f7210d3172284f
>>89c5f46cee9e273f10897f52500
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=MyzVItNCAzhBG2AUe%2Fp
>CJRMnHjrDqgITgT1fkxc3s0k%3D%0A&s=08c9066de11d376ded51257f7210d3172284f89c5
>f46cee9e273f10897f52500


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

Re: [openstack-dev] [neutron] Neutron Mid-Cycle Meeting

[Gary Kotton]

Hi,
Any chance of doing this in Europe?
Thanks
Gary

On 4/16/14 4:54 AM, "Kyle Mestery"  wrote:

>Folks:
>
>Given all the talk of mid-cycle meetings, I'd like to propose that we
>do one for Neutron as well. Mark and I talked about this over the past
>few months, and I've mentioned this to a few other people as well. I
>think it would be ideal to get everyone together in the July
>timeframe, but I'd like to hear from others on dates. I've setup an
>etherpad to track the discussion here [1]. Can people weigh in on
>which week works for them? If there are events happening on those
>weeks which would preclude people from attending, I'd also like to
>hear that. I have a proposed location and sponsor, but I'm open to
>hearing other options as well if the proposed location doesn't work
>for anyone.
>
>Thanks!
>Kyle
>
>[1] 
>https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/
>p/neutron-juno-mid-cycle-meeting&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0
>pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=LqFMtBoARpokZvYcobdPZUS
>WSSXtWpWpuVUzqNOIsAo%3D%0A&s=4669e387ed5dc7dd4d1317ee92940dac36eb6b7e53754
>f5d9d7f8e049159a67b
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=LqFMtBoARpokZvYcobdPZ
>USWSSXtWpWpuVUzqNOIsAo%3D%0A&s=a6b2831efac0d6f1d1d23878f9a55c6171f6199c262
>0cf41cdd2b85f774aaf6e


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

Re: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary

[Renat Akhmerov]

Ok, no problem :)

Renat Akhmerov
@ Mirantis Inc.



On 16 Apr 2014, at 12:43, Joshua Harlow  wrote:

> I have stricken the word "micro" and "language" from my vocabulary. Begone 
> evil demons!! Haha :)
> 
> Sent from my really tiny device...
> 
> On Apr 15, 2014, at 10:35 PM, "Renat Akhmerov"  wrote:
> 
>> On 16 Apr 2014, at 00:18, Joshua Harlow  wrote:
>> 
>>> Decider sounds like it could work also as a name, although it seems from 
>>> dataflow like work its called a switch or gate, either or I guess.
>> 
>> That’s fine. It doesn’t matter too much to me personally.
>> 
>>> As far as the micro-language:
>>> 
>>> So there are typically 2 types of DSL's that occur, internal and external.
>>> 
>>> An internal DSL is like 
>>> http://martinfowler.com/bliki/InternalDslStyle.html, taskflow is already a 
>>> micro-DSL internal to python (mistral is an external DSL[1]). To me there 
>>> is a drawback of becoming to much of a DSL (internal or external) in that 
>>> it requires a lot of new learning (imho internal DSLs are easier to pick-up 
>>> since they take advantage of the surrounding languages capabilities, in 
>>> this case python). So that’s what I just want to keep in our minds that we 
>>> need to make it simple *enough*, or we will die a nasty death of complexity 
>>> :-P
>>> 
>>> [1] http://martinfowler.com/bliki/DomainSpecificLanguage.html
>> 
>> Ok, got it. Thanks. I’m just still not sure why you emphasize on that 
>> micro-language thing. IMO terms like that can scary people :) In fact, this 
>> ‘switch’ (or decider, or whatever) is just an additional API which can be 
>> used to alter flow behavior. 
>> 
>> ___
>> 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] [Mistral][TaskFlow] Mistral-TaskFlow Summary

[Joshua Harlow]

I have stricken the word "micro" and "language" from my vocabulary. Begone evil 
demons!! Haha :)

Sent from my really tiny device...

On Apr 15, 2014, at 10:35 PM, "Renat Akhmerov" 
mailto:rakhme...@mirantis.com>> wrote:

On 16 Apr 2014, at 00:18, Joshua Harlow 
mailto:harlo...@yahoo-inc.com>> wrote:

Decider sounds like it could work also as a name, although it seems from 
dataflow like work its called a switch or gate, either or I guess.

That’s fine. It doesn’t matter too much to me personally.

As far as the micro-language:

So there are typically 2 types of DSL's that occur, internal and external.

An internal DSL is like http://martinfowler.com/bliki/InternalDslStyle.html, 
taskflow is already a micro-DSL internal to python (mistral is an external 
DSL[1]). To me there is a drawback of becoming to much of a DSL (internal or 
external) in that it requires a lot of new learning (imho internal DSLs are 
easier to pick-up since they take advantage of the surrounding languages 
capabilities, in this case python). So that’s what I just want to keep in our 
minds that we need to make it simple *enough*, or we will die a nasty death of 
complexity :-P

[1] http://martinfowler.com/bliki/DomainSpecificLanguage.html

Ok, got it. Thanks. I’m just still not sure why you emphasize on that 
micro-language thing. IMO terms like that can scary people :) In fact, this 
‘switch’ (or decider, or whatever) is just an additional API which can be used 
to alter flow behavior.

___
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] [Mistral][TaskFlow] Mistral-TaskFlow Summary

[Renat Akhmerov]

On 16 Apr 2014, at 00:18, Joshua Harlow  wrote:

> Decider sounds like it could work also as a name, although it seems from 
> dataflow like work its called a switch or gate, either or I guess.

That’s fine. It doesn’t matter too much to me personally.

> As far as the micro-language:
> 
> So there are typically 2 types of DSL's that occur, internal and external.
> 
> An internal DSL is like http://martinfowler.com/bliki/InternalDslStyle.html, 
> taskflow is already a micro-DSL internal to python (mistral is an external 
> DSL[1]). To me there is a drawback of becoming to much of a DSL (internal or 
> external) in that it requires a lot of new learning (imho internal DSLs are 
> easier to pick-up since they take advantage of the surrounding languages 
> capabilities, in this case python). So that’s what I just want to keep in our 
> minds that we need to make it simple *enough*, or we will die a nasty death 
> of complexity :-P
> 
> [1] http://martinfowler.com/bliki/DomainSpecificLanguage.html

Ok, got it. Thanks. I’m just still not sure why you emphasize on that 
micro-language thing. IMO terms like that can scary people :) In fact, this 
‘switch’ (or decider, or whatever) is just an additional API which can be used 
to alter flow behavior. 

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

Re: [openstack-dev] [Nova] Thoughts from the PTL -- possible mid cycle meetup dates

[Chris Jones]

Hey

Co-locating still has the option to partially overlap the two sprints.

Cheers,
--
Chris Jones

> On 16 Apr 2014, at 02:38, Michael Still  wrote:
> 
> On Wed, Apr 16, 2014 at 10:01 AM, Robert Collins
>  wrote:
>> On 16 April 2014 11:28, Michael Still  wrote:
 On Wed, Apr 16, 2014 at 7:57 AM, Hugh O. Brock  wrote:
 On Wed, Apr 16, 2014 at 09:30:45AM +1200, Robert Collins wrote:
>>> 
> Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
> don't know if they have space for Nova & TripleO at once, but I'd love
> to get more collaboration time betwixt Nova and TripleO. The TripleO
> midcycle meetups are 'doing' meetings, not planning meetings - but
> plenty of planning does still happen ;)
> 
> Date wise, how about before OSCON ? PyConAU which often gets a heavy
> openstack contingent is august 1-5.
 
 I am sure we have enough space, we would be very happy to host both at
 the same time.
>>> 
>>> I envision "at the same time" being "back to back" to be honest, as I
>>> think running two in parallel would be a bit bonkers.
>> 
>> I can't travel for a single 2 week trip - my daughter doesn't cope
>> super well with me being gone, and I don't want to subject her to a 2
>> week trip. Doing a 2-or-3 day meetup for TripleO is pointless IMO -
>> folk spend a day getting there in the first place.
>> 
>> Last cycle TripleO and Ironic co-located and it was productive for all 
>> involved.
> 
> This may mean that co-locating is an idea which doesn't work out.
> 
> Based on the way the last nova meetup went, there will be little time
> to dig into the deeper specifics of tripleo (ironic especially) if its
> in time that's also allocated to other nova discussion -- I think the
> absolute longest we spent on a single topic last time was in the order
> of a couple of hours. The nova meetup also wasn't a hackfest -- it was
> more about design review and progress tracking, and I think that was a
> model that worked well for us.
> 
> I see a need for a lot of sync between ironic and nova for Juno,
> mostly around the replacement of the baremetal driver. Perhaps instead
> we should go back to trying to have these events separately, and try
> and get a few key nova people to the the tripleo meetup.
> 
> 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] [neutron][chaining][policy] Port-oriented Network service chaining

[balaj...@freescale.com]

Hi Carlos,

IMHO, Neutron port abstraction for traffic steering API will be good option. 
Based on the Flows (SFC) created for SFC, we may need to have the frame-work 
which will take care of creating the OVS flows on the compute nodes for the 
SFC-Flows created.

We are interested in participating and contributing this BP and Framework.

Regards,
Balaji.P

From: Carlos Gonçalves [mailto:m...@cgoncalves.pt]
Sent: Wednesday, April 16, 2014 12:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][chaining][policy] Port-oriented Network 
service chaining

Hi Kanzhe,

First off, thank you for showing interest in discussing this proposal!

I'm not fully sure if I understood your point. Could you elaborate a bit more 
on the L1, L2, L3 part?

Regarding the traffic steering API, as I see it the Neutron port is the virtual 
counterpart of the network interface and would allow L1, L2 and L3 steering 
within OpenStack.  Within a single OpenStack deployment I think the Neutron 
port abstraction might be enough. Nevertheless in the API data model proposal 
we have the service function end
point abstraction which can (eventually) be mapped to something else than a 
Neutron port (e.g., remote IP).

Thanks,
Carlos Goncalves

On 15 Apr 2014, at 02:07, Kanzhe Jiang 
mailto:kan...@gmail.com>> wrote:


Hi Carlos,

This is Kanzhe. We discussed your port-based SFC on the Neutron advanced 
service IRC.
I would like to reach out to you to discuss a bit more.

As you know, Neutron port is a logic abstraction for network interfaces with a 
MAC and IP address. However, network services could be used at different 
layers, L3, L2, or L1. In L3 case, each service interface could be easily 
mapped to a Neutron port. However, in the other two cases, there won't be a 
corresponding Neutron port. In your proposal, you mentioned DPI service. What 
is your thought?

Neutron doesn't have traffic steering API. Is Neutron port the right 
abstraction to introduce traffic steering API? Or May Neutron need separate 
abstraction for such?

Love to discuss more!
Kanzhe

On Tue, Mar 25, 2014 at 3:59 PM, Carlos Gonçalves 
mailto:m...@cgoncalves.pt>> wrote:
Hi,

Most of the advanced services and group policy sub-team members who attended 
last week's meeting should remember I promised to start a drafting proposal 
regarding network service chaining. This week I got to start writing a document 
which is accessible here: 
https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU

It should not be considered a formal blueprint as it yet requires large 
discussion from the community wrt the validation (or sanity if you will) of the 
proposed idea.

I will be joining the advanced service IRC meeting tomorrow, and the group 
policy IRC meeting thursday, making myself available to answer any questions 
you may have. In the meantime you can also start discussing in this email 
thread or commenting in the document.

Thanks,
Carlos Goncalves


___
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] Neutron BP review process for Juno

[Sumit Naiksatam]

What's the convention for adding images to the patch? The following
directory structure seemed logical to me (but the current UT will not
allow it):

specs/juno//.rst
specs/juno//images/.png

Thanks,
~Sumit.



On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin  wrote:
> +1.  I think we'll like this process better.  I hope to have some of
> the first blueprints to propose to the new repository very soon.
>
> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery  
> wrote:
>> Given the success the Nova team has had in handling reviews using
>> their new nova-specs gerrit repository, I think it makes a lot of
>> sense for Neutron to do the same. With this in mind, I've added
>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
>> this is how Neutron BPs will be handled by the Neutron core team. If
>> you are currently working on a BP or code for Juno which is attached
>> to a BP, please file the BP using the process here [1].
>>
>> Given this is our first attempt at using this for reviews, I
>> anticipate there may be a few hiccups along the way. Please reply on
>> this thread or reach out in #openstack-neutron and we'll sort through
>> whatever issues we find.
>>
>> Thanks!
>> Kyle
>>
>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Openstack] Question regarding Nova in Havana

[Vishvananda Ishaya]

The service reference is created in the start method of the service. This 
happens around line 217 in nova/service.py in the current code. You should be 
able to do something similar by sending a message to service_create on 
conductor. It will return an error if the service already exists. Note you can 
also use service_get_by_args in conductor to see if the service exists.

Vish

On Apr 15, 2014, at 9:22 PM, Swapnil S Kulkarni  wrote:

> Interesting discussion. Forwarding to openstack-dev.
> 
> 
> On Wed, Apr 16, 2014 at 9:34 AM, Prashant Upadhyaya 
>  wrote:
> Hi,
> 
>  
> 
> I am writing a Compute Node Simulator.
> 
> The idea is that I would write a piece of software using C which honors the 
> RabbitMQ interface towards the Controller, but will not actually do the real 
> thing – everything on the Compute Node will be simulated by my simulator 
> software.
> 
>  
> 
> The  problem I am facing, that I have not been able to get my simulated CN 
> listed in the output of
> 
> nova-manage service list
> 
>  
> 
> I am on Havana, and my simulator is sending a periodic  ‘service_update’ and 
> ‘compute_node_update’ RPC messages to the ‘nova’ exchange and the ‘conductor’ 
> routing key.
> 
> I can manipulate the above messages at will to fool the controller.
> 
> (I observe the messages from a real CN and take cues from there to construct 
> a fake one from my simulator)
> 
>  
> 
> Question is – what causes the controller to add a new Nova Compute in its 
> database, is it the ‘service_update’ RPC or something else.
> 
>  
> 
> Hopefully you can help me reverse engineer the interface.
> 
>  
> 
> Regards
> 
> -Prashant
> 
>  
> 
>  
> 
> 
> 
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely 
> for the use of the individual to whom it is addressed. It may contain 
> privileged or confidential information and should not be circulated or used 
> for any purpose other than for what it is intended. If you have received this 
> message in error, please notify the originator immediately. If you are not 
> the intended recipient, you are notified that you are strictly prohibited 
> from using, copying, altering, or disclosing the contents of this message. 
> Aricent accepts no responsibility for loss or damage arising from the use of 
> the information transmitted by this email including damage from virus."
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> ___
> 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] [Openstack] Question regarding Nova in Havana

[Swapnil S Kulkarni]

Interesting discussion. Forwarding to openstack-dev.


On Wed, Apr 16, 2014 at 9:34 AM, Prashant Upadhyaya <
prashant.upadhy...@aricent.com> wrote:

>  Hi,
>
>
>
> I am writing a Compute Node Simulator.
>
> The idea is that I would write a piece of software using C which honors
> the RabbitMQ interface towards the Controller, but will not actually do the
> real thing - everything on the Compute Node will be simulated by my
> simulator software.
>
>
>
> The  problem I am facing, that I have not been able to get my simulated CN
> listed in the output of
>
> nova-manage service list
>
>
>
> I am on Havana, and my simulator is sending a periodic  'service_update'
> and 'compute_node_update' RPC messages to the 'nova' exchange and the
> 'conductor' routing key.
>
> I can manipulate the above messages at will to fool the controller.
>
> (I observe the messages from a real CN and take cues from there to
> construct a fake one from my simulator)
>
>
>
> Question is - what causes the controller to add a new Nova Compute in its
> database, is it the 'service_update' RPC or something else.
>
>
>
> Hopefully you can help me reverse engineer the interface.
>
>
>
> Regards
>
> -Prashant
>
>
>
>
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Default paths in os-*-config projects

[Clint Byrum]

Excerpts from Steve Baker's message of 2014-04-15 16:30:32 -0700:
> On 15/04/14 13:30, Clint Byrum wrote:
> > Excerpts from Ben Nemec's message of 2014-04-14 15:41:23 -0700:
> >> Right now the os-*-config projects default to looking for their files in 
> >> /opt/stack, with an override env var provided for other locations.  For 
> >> packaging purposes it would be nice if they defaulted to a more 
> >> FHS-compliant location like /var/lib.  For devtest we could either 
> >> override the env var or simply install the appropriate files to /var/lib.
> >>
> >> This was discussed briefly in IRC and everyone seemed to be onboard with 
> >> the change, but Robert wanted to run it by the list before we make any 
> >> changes.  If anyone objects to changing the default, please reply here. 
> >>   I'll take silence as agreement with the move. :-)
> >>
> > +1 from me for doing FHS compliance. :)
> >
> > /var/lib is not actually FHS compliant as it is for "Variable state
> > information". os-collect-config does have such things, and does use
> > /var/lib. But os-refresh-config reads executables and os-apply-config
> > reads templates, neither of which will ever be "variable state
> > information".
> >
> > /usr/share would be the right place, as it is "Architecture independent
> > data". I suppose if somebody wants to compile a C program as an o-r-c
> > script we could rethink that, but I'd just suggest they drop it in a bin
> > dir and exec it from a one line shell script in the /usr/share.
> >
> > So anyway, I suggest:
> >
> > /usr/share/os-apply-config/templates
> > /usr/share/os-refresh-config/scripts
> >
> > With the usual hierarchy underneath.
> +1, but might I suggest the orc location be:
> /usr/libexec/os-refresh-config/*.d
> 

Good catch. I had not read the latest draft of FHS 3.0, and indeed
libexec is included. Seems daft to base on 2.3 if 3.0 is likely to be
released this summer.

> > We'll need to continue to support the non-FHS paths for at least a few
> > releases as well.
> >
> Instead of supporting both paths, how about the orc and oac elements set
> OS_REFRESH_CONFIG_BASE_DIR and OS_CONFIG_APPLIER_TEMPLATES to
> /opt/stack/... until tripleo is ready to switch? With some prep changes
> it should be possible to make the flag-day change to require only
> changing the value of these env vars in tripleo-image-templates.
> 

I'm not worried about TripleO. I'm worried about all the other users who
may be relying on the old defaults. I think the proper way to handle it
is something like this:

if os.path.exists(old_templates_dir):
logger.warn("%s is deprecated. Please use %s" % (old_templates_dir, 
new_templates_dir))
templates_dir = merge_dirs(old_templates_dir, new_templates_dir)

We may be an 0.x release, but I think this is straight forward enough
to support being gentle with any users we don't know about.

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

[openstack-dev] TC candidacy

[Joe Gordon]

Hi All,

I'd like to announce my candidacy for the Technical Committee election.

About Me
--

I work full time on OpenStack on behalf of HP. And am part of nova-core,
nova-specs-core, hacking-core and elastic-recheck-core. Some of my more
visible accomplishments outside my involvement in nova are:

- Creating hacking [0][1] to more efficiently use reviewers time by
automating the tedious job of checking style.

- Starting elastic-recheck [2][3] to help us better track and triage race
conditions.

- Helping Unwedge the gate right before the release of Havana [4].

- Writing several gating jobs: large-ops, neutron-large-ops and nova’s
partial-ncpu. partial-ncpu is nova’s gating test to make sure we support
 doing a rolling upgrade of compute nodes (so a Havana nova-compute should
work with an Icehouse cloud).



My Platform

--


I think the Icehouse TC has done a wonderful job and has an impressive list
of accomplishments [4], and I would like to see the TC do more of the same
at an accelerated pace. Given the scale of OpenStack today I don’t think
sitting on the TC should be a two hour a week job. Note: I am not pushing
for more frequent meetings, but rather more ‘homework.’ Two hours a week
was fine when OpenStack had 3 integrated projects, but not so much now that
we are at 11 integrated projects. Besides just doing more of the same, here
are a few specific areas where I think the TC can be improved:

- Make the mid-cycle incubation status reviews [6] more thorough, and
extend them to projects that are planning on filing for incubation. We
don’t want a repeat of what happened this past cycle where a project passed
its mid-cycle incubation status review [6], only to hit significant issues
in its graduation request [7]. - TC members who are not too familiar with
the project in question should do the gap analysis instead of a member of
that project. A fresh pair of eyes is always a good thing, and this will
help increase cross project feedback.



Thank you for your consideration.


Best,

Joe



[0] http://git.openstack.org/cgit/openstack-dev/hacking

[1] http://docs.openstack.org/developer/hacking/

[2] http://git.openstack.org/cgit/openstack-infra/elastic-recheck/

[3] http://status.openstack.org/elastic-recheck/

[4]
http://lists.openstack.org/pipermail/openstack-dev/2013-November/020280.html
[5]
http://lists.openstack.org/pipermail/openstack-dev/2014-April/032576.html[6]
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-01-21-20.03.html[7]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030638.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Request for Input on multi-domain identifiers.

[Adam Young]

As we get closer to the summit, I'd like to make sure we have resolution 
on one of the most critical issues in Keystone.  How to deal with users 
coming out of multiple data sources.


The issue is that a userid out of one domain must fill two requirements:

1. one userid cannot conflict with a userid from any other domain
2. we must be able to map from the userid back to the domain backend 
that issued it.


We are trying to avoid an approach where we shadow the LDAP or Federated 
identity provider data in a SQL backend specific to Keystone.  That kind 
of data duplication has a host of problems we would rather not have to 
address.  Instead, we need to come up with a way to layer on the User ID 
scheme on top of the data from LDAP.


I suspect the scheme is going to end up being something like:

user the same field for username an userid.

The actual userid value will be composed of two parts.  One will be the 
username from LDAP, the other will be assigned by Keystone based on the 
domain id.  The last instalment we had a suggestion that looked like:


ayoung@@redhat.

The @@ is to make sure we don;t trip over some place that decided to use 
email address, but still gives a separator character that is URL safe.


There is some concern with the length of the field.  Most of the 
services have userid as 64chars long, and we are pushing to syncronize 
all the projects on that length.  UUIDs ar 32 chars long, and Nova was 
the last to assume that as userid was a UUID.  Still, we can't go beyond 
the 64 char limit without some pain.


One question is whether we are stuck with requirement 2.  For example, 
if we said that a user login was always done with:  domain name and 
username, we would never have to look up a user by pure userid.


If we can loosen up on the "map userid back to domain" requirement, we 
can  get away with something more like  sha256("%s%S" %(username, 
domain_name))  for the userid.  This has the benefit of looking just 
like a UUID and fitting into the same size filed in the databases.


Resolving this issue is key to both Multiple LDAP and Federation.


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

Re: [openstack-dev] deliver the vm-level HA to improve the business continuity with openstack

[Jay Pipes]

On Tue, 2014-04-15 at 12:01 +0100, Duncan Thomas wrote:
> On 14 April 2014 19:51, James Penick  wrote:
> > We drive the ³VM=Cattle² message pretty hard. Part of onboarding a
> > property to our cloud, and allowing them to serve traffic from VMs is
> > explaining the transient nature of VMs. I broadcast the message that all
> > compute resources die, and if your day/week/month is ruined because of a
> > single compute instance going away, then you¹re doing something Very
> > Wrong. :)
> 
> While I agree with the message, if cloud provider A has VM restarts
> every hour, and B has restarts every 6 months, all other things being
> equal I'm going to go with B.

Pretty sure James wasn't saying that he restarts VMs every hour. The
idea is that applications that run on a utility cloud should be
resilient and take into account failure as an expected part of
operating.

> Restarts are a pain point for most
> systems, requiring data resynchronisation etc, so looking to minimise
> them is a good aim as long as it doesn't conflict much with other
> concerns...

I'm actually not entirely sure what restarts and data resync have to do
with vm-level HA? What am I missing here?

Best,
jay


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

[openstack-dev] 【openstack-dev】【nova】discussion about add support to SSD ephemeral storage

[Yuzhou (C)]

Hi Daniel,

 Thanks for your comments about this 
BP：https://review.openstack.org/#/c/83727/
 
 My initial thoughts is to do little changes then get better performance of 
guest vm. So it is a bit too narrowly focused.

 After review SSD use case, I totally agree with your comments. I think if 
I want to implement the broader picture, there are many work items that need to 
do.

1. Add support to create flavor with SSD ephemeral storage.
 The cloud adminstrator create the flavor that indicate which backend 
should be used per instance. e.g.
  nova flavor-key m1.ssd set quota:ephemeral_storage_type=ssd 
(root_disk ephemeral_disk and swap_disk are placed onto 
a ssd)
 Or more fine grained, e.g.
  nova flavor-key m1.ssd set quota:root_disk_type=ssd
  nova flavor-key m1.ssd set quota:ephemeral_disk_type=hd
  nova flavor-key m1.ssd set quota:swap_disk_type=ssd
(root_disk and swap_disk are placed onto a ssd, 
ephemeral_disk is placed onto a harddisk)

2. When config nova,the deployer of openstack configure 

e.g.
 if libvirt_image_type=default (local disk)
  ephemeral_storage_pools=, 
 if  libvirt_image_type=RBD
   ephemeral_storage_pools=rdb1,rdb2

3. According to  ephemeral storage type in compute host, nova-scheduler select 
compute node to create VM.

4. Assume  that ssd mount on  ,hd mount on , and assume that the 
end user select the flavor with ssd ephemeral storage, when creating VM,  
nova-compute place root_disk/ephemeral_disk /swap_disk onto .

My description about  broader picture  is right or not?

Welcome for your more comments!

Thanks.

Zhou Yu

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

[openstack-dev] [neutron] Neutron Mid-Cycle Meeting

[Kyle Mestery]

Folks:

Given all the talk of mid-cycle meetings, I'd like to propose that we
do one for Neutron as well. Mark and I talked about this over the past
few months, and I've mentioned this to a few other people as well. I
think it would be ideal to get everyone together in the July
timeframe, but I'd like to hear from others on dates. I've setup an
etherpad to track the discussion here [1]. Can people weigh in on
which week works for them? If there are events happening on those
weeks which would preclude people from attending, I'd also like to
hear that. I have a proposed location and sponsor, but I'm open to
hearing other options as well if the proposed location doesn't work
for anyone.

Thanks!
Kyle

[1] https://etherpad.openstack.org/p/neutron-juno-mid-cycle-meeting

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

Re: [openstack-dev] [Nova] Thoughts from the PTL -- possible mid cycle meetup dates

[Michael Still]

On Wed, Apr 16, 2014 at 10:01 AM, Robert Collins
 wrote:
> On 16 April 2014 11:28, Michael Still  wrote:
>> On Wed, Apr 16, 2014 at 7:57 AM, Hugh O. Brock  wrote:
>>> On Wed, Apr 16, 2014 at 09:30:45AM +1200, Robert Collins wrote:
>>
 Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
 don't know if they have space for Nova & TripleO at once, but I'd love
 to get more collaboration time betwixt Nova and TripleO. The TripleO
 midcycle meetups are 'doing' meetings, not planning meetings - but
 plenty of planning does still happen ;)

 Date wise, how about before OSCON ? PyConAU which often gets a heavy
 openstack contingent is august 1-5.
>>>
>>> I am sure we have enough space, we would be very happy to host both at
>>> the same time.
>>
>> I envision "at the same time" being "back to back" to be honest, as I
>> think running two in parallel would be a bit bonkers.
>
> I can't travel for a single 2 week trip - my daughter doesn't cope
> super well with me being gone, and I don't want to subject her to a 2
> week trip. Doing a 2-or-3 day meetup for TripleO is pointless IMO -
> folk spend a day getting there in the first place.
>
> Last cycle TripleO and Ironic co-located and it was productive for all 
> involved.

This may mean that co-locating is an idea which doesn't work out.

Based on the way the last nova meetup went, there will be little time
to dig into the deeper specifics of tripleo (ironic especially) if its
in time that's also allocated to other nova discussion -- I think the
absolute longest we spent on a single topic last time was in the order
of a couple of hours. The nova meetup also wasn't a hackfest -- it was
more about design review and progress tracking, and I think that was a
model that worked well for us.

I see a need for a lot of sync between ironic and nova for Juno,
mostly around the replacement of the baremetal driver. Perhaps instead
we should go back to trying to have these events separately, and try
and get a few key nova people to the the tripleo meetup.

Michael

-- 
Rackspace Australia

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

[openstack-dev] AUTO: Alon Marx is out of the office (returning 04/20/2014)

[Alon Marx]

I am out of the office until 04/20/2014.

I will be out of the office August 9 to August 12. I will have no email
connectivity and no phone connectivity.
For any urgent matters please contact Ohad Atia.


Note: This is an automated response to your message  "OpenStack-dev Digest,
Vol 24, Issue 44" sent on 16/04/2014 0:14:16.

This is the only notification you will receive while this person is away.


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

Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

[Brandon Logan]

Hi Stephen,
Jorge, Myself, and our team having been collaborating drafting a revision of 
the API.  We should be able to put it up on the wiki most likely tomorrow but 
possibly Thursday.  We definitely prefer to get it out tomorrow, though.  It is 
definitely something we'd like everyone to pick apart and come up with how it 
may break use cases and also how it may break the rule of it being too 
specific.  We're definitely keeping all of that in mind but different 
experienced sets of eyes will always come up with some flaws and things we 
didn't think about.

Thanks,
Brandon Logan

From: Eugene Nikanorov [enikano...@mirantis.com]
Sent: Tuesday, April 15, 2014 7:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision 
progress

Hi Stephen,

Thanks for a good summary. Some comments inline.


On Tue, Apr 15, 2014 at 5:20 AM, Stephen Balukoff 
mailto:sbaluk...@bluebox.net>> wrote:

So! On this front:

1. Does is make sense to keep filling out use cases in Samuel's document above? 
I can think of several more use cases that our customers actually use on our 
current deployments which aren't considered in the 8 cases in Samuel's document 
thus far. Plus nobody has create any use cases from the cloud operator 
perspective yet.

I treat Sam's doc as a source of use cases to triage API proposals. If you 
think you have use cases that don't fit into existing API or into proposed API, 
they should certainly be brought to attention.


2. It looks like we've started to get real-world data on Load Balancer features 
in use in the real world. If you've not added your organization's data, please 
be sure to do so soon so we can make informed decisions about product 
direction. On this front, when will we be making these decisions?
I'd say we have two kinds of features - one kind is features that affect or 
even define the object model and API.
Other kind are features that are implementable within existing/proposed API or 
require slight changes/evolution.
First kind is the priority: while some of such features may or may not be 
implemented in some particular release, we need to implement proper 
infrastructure for them (API, obj model)

Oleg Bondarev (he's neutron core) and me are planning and mostly interested to 
work on implementing generic stuff like API/obj model and adopt haproxy driver 
to it. So our goal is to make implementation of particular features simpler for 
contributors and also make sure that proposed design fits in general lbaas 
architecture. I believe that everyone who wants to see certain feature may 
start working on it - propose design, participate in discussions and start 
actually writing the code.



3. Jorge-- I know an action item from the last meeting was to draft a revision 
of the API (probably starting from something similar to the Atlas API). Have 
you had a chance to get started on this, and are you open for collaboration on 
this document at this time? Alternatively, I'd be happy to take a stab at it 
this week (though I'm not very familiar with the Atlas API-- so my proposal 
might not look all that similar).

+1, i'd like to see something as well.


What format or template should we be following to create the API documentation? 
 (I see this here:  
http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html  
but this seems like it might be a little heavy for an API draft that is likely 
to get altered significantly, especially given how this discussion has gone 
thus far. :/ )

Agree, that's too heavy for API sketch. I think a set of resources with some 
attributes plus a few cli calls is what could show the picture.

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

Re: [openstack-dev] [Murano] Working in devstack?

[Mark Kirkwood]

Thanks...yes, I'd not realized that running ./stack.sh again would 
unpatch my murano-api/setup.sh! Rerunning the db setup as you suggested 
gives me the tables. I didn't do it in as tidy a manner as yours however :-)


$ export OS_USERNAME=admin
$ export OS_PASSWORD=swordfish
$ export OS_TENANT_NAME=demo
$ export OS_AUTH_URL=http://host:5000/v2.0/
$ murano-manage --config-file /etc/murano/murano-api.conf db-sync

Cheers

Mark

On 16/04/14 11:23, Georgy Okrokvertskhov wrote:

Hi Mark,

Thank you for a detailed report. As I know Murano team is working on fixing
devstack scripts.

As for DB setup it should be done by a command: tox -evenv -- murano-manage
--config-file etc/murano/murano-api.conf db-sync

It works in my testing environment.

Thanks
Georgy


On Tue, Apr 15, 2014 at 4:11 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:


Hi all,

There is some interest here in making use of Murano for Samba ADDC a
service...so we've been (attempting) to get it up and running in devstack.
In the process I've managed to get myself confused about the correct
instructions for doing this:

- the docs suggest http://murano-docs.github.io/latest/getting-started/
content/ch04s03.html
- the project provides murano-deployment/devstack-scripts/README.rst)

...which are markedly different approaches (it *looks* like the project
README.rst is out of date, as it the scripts it runs try to get
heat-horizon from repos that do not exist anymore). If this approach is not
longer workable, we should really remove (or correct these instructions).

So following http://murano-docs.github.io/latest/getting-started/
content/ch04s03.html inside a Ubuntu 12.04 VM I stumbled into a few bugs:

- several missing deps in various murano-*/requirements.txt (see attached)
- typo in /murano-api/setup.sh (db_sync vs db-sync)

Fixing these seems to get most things going (some tabs crash with missing
tables, so I need to dig a bit more to find where they get created...).

Any pointers/etc would be much appreciated!

Cheers

Mark


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






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


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

Re: [openstack-dev] [Nova] Thoughts from the PTL -- possible mid cycle meetup dates

[Robert Collins]

On 16 April 2014 11:28, Michael Still  wrote:
> On Wed, Apr 16, 2014 at 7:57 AM, Hugh O. Brock  wrote:
>> On Wed, Apr 16, 2014 at 09:30:45AM +1200, Robert Collins wrote:
>
>>> Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
>>> don't know if they have space for Nova & TripleO at once, but I'd love
>>> to get more collaboration time betwixt Nova and TripleO. The TripleO
>>> midcycle meetups are 'doing' meetings, not planning meetings - but
>>> plenty of planning does still happen ;)
>>>
>>> Date wise, how about before OSCON ? PyConAU which often gets a heavy
>>> openstack contingent is august 1-5.
>>
>> I am sure we have enough space, we would be very happy to host both at
>> the same time.
>
> I envision "at the same time" being "back to back" to be honest, as I
> think running two in parallel would be a bit bonkers.

I can't travel for a single 2 week trip - my daughter doesn't cope
super well with me being gone, and I don't want to subject her to a 2
week trip. Doing a 2-or-3 day meetup for TripleO is pointless IMO -
folk spend a day getting there in the first place.

Last cycle TripleO and Ironic co-located and it was productive for all involved.

> I'm now sitting on a list of about four or five offered venues, with
> no plan for how to select which one to use. Perhaps what we should do
> is pick the dates, then ask each venue if they're available in that
> window, and then come up with some way to select from the remaining
> venues.
>
> I deeply appreciate all the offers of hosting -- its a great way for
> companies to contribute to OpenStack, and makes a real difference to
> our ability to deliver great software. Perhaps what we should do with
> the venues that offer and don't get selected is keep them on a list of
> venues to use for future meetups? That will make those meetups easier
> to organise, and recognises the kind offers from the venues.


Not a bad idea ;)

-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] [infra] Basic zuul startup question: "Private key file is encrypted"

[Jeremy Stanley]

On 2014-04-15 23:24:31 + (+), Jeremy Stanley wrote:
[...]
> You'll need to strip the encryption from it with something like...
> 
> ssh-keygen -p -f ~/.ssh/id_dsa
[...]

Or more likely, since the patents on RSA expired about 14 years
ago...

ssh-keygen -p -f ~/.ssh/id_rsa

-- 
Jeremy Stanley

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

Re: [openstack-dev] [heat] computed package names?

[Steven Dake]

On 04/15/2014 03:45 PM, Zane Bitter wrote:

On 15/04/14 17:59, Mike Spreitzer wrote:

Clint Byrum  wrote on 04/15/2014 05:17:21 PM:
 > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:
 >
 > > FWIW, in the short term I'm not aware of any issue with installing
 > > mariadb in Fedora 17/18, provided that mysql is not installed
first. And
 > > in fact they're both EOL anyway, so we should probably migrate 
all the

 > > templates to Fedora 20 and mariadb.
 >


The last time I tried F17 images, the database installation step failed 
miserably because of problems in the base distribution.



 > +1 for that.

I count 22 templates in heat-templates that are written to support
Fedora, Ubuntu, and RHEL; is MariaDB available in those?  I do not see
it in Ubuntu 12.10, for example.


I imagine it's a problem for RHEL (can RHEL 7 just get released 
already?). Ubuntu is not an issue though, unless they have adopted yum 
while I was not looking.


Checking a random sample, they only includes "yum" and "systemd" 
sections (no "apt" or "sysvinit") in the metadata, so the purported 
support for Ubuntu 10.04 is just due to copy-paste and isn't actually 
implemented.


There is, I thought, one template that does actually support Ubuntu. 
Stuff in the "F17" directory is there for a reason.


The only rational reason for having the F17 directory is because nobody 
has done the work of porting these templates to F20.  That work needs to 
be done before we can remove the F17 directory permanently :)


Regards,
-steve


- ZB

___
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] [tripleo] Default paths in os-*-config projects

[Steve Baker]

On 15/04/14 13:30, Clint Byrum wrote:
> Excerpts from Ben Nemec's message of 2014-04-14 15:41:23 -0700:
>> Right now the os-*-config projects default to looking for their files in 
>> /opt/stack, with an override env var provided for other locations.  For 
>> packaging purposes it would be nice if they defaulted to a more 
>> FHS-compliant location like /var/lib.  For devtest we could either 
>> override the env var or simply install the appropriate files to /var/lib.
>>
>> This was discussed briefly in IRC and everyone seemed to be onboard with 
>> the change, but Robert wanted to run it by the list before we make any 
>> changes.  If anyone objects to changing the default, please reply here. 
>>   I'll take silence as agreement with the move. :-)
>>
> +1 from me for doing FHS compliance. :)
>
> /var/lib is not actually FHS compliant as it is for "Variable state
> information". os-collect-config does have such things, and does use
> /var/lib. But os-refresh-config reads executables and os-apply-config
> reads templates, neither of which will ever be "variable state
> information".
>
> /usr/share would be the right place, as it is "Architecture independent
> data". I suppose if somebody wants to compile a C program as an o-r-c
> script we could rethink that, but I'd just suggest they drop it in a bin
> dir and exec it from a one line shell script in the /usr/share.
>
> So anyway, I suggest:
>
> /usr/share/os-apply-config/templates
> /usr/share/os-refresh-config/scripts
>
> With the usual hierarchy underneath.
+1, but might I suggest the orc location be:
/usr/libexec/os-refresh-config/*.d

> We'll need to continue to support the non-FHS paths for at least a few
> releases as well.
>
Instead of supporting both paths, how about the orc and oac elements set
OS_REFRESH_CONFIG_BASE_DIR and OS_CONFIG_APPLIER_TEMPLATES to
/opt/stack/... until tripleo is ready to switch? With some prep changes
it should be possible to make the flag-day change to require only
changing the value of these env vars in tripleo-image-templates.

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

Re: [openstack-dev] [Nova] Thoughts from the PTL -- possible mid cycle meetup dates

[Michael Still]

On Wed, Apr 16, 2014 at 7:57 AM, Hugh O. Brock  wrote:
> On Wed, Apr 16, 2014 at 09:30:45AM +1200, Robert Collins wrote:

>> Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
>> don't know if they have space for Nova & TripleO at once, but I'd love
>> to get more collaboration time betwixt Nova and TripleO. The TripleO
>> midcycle meetups are 'doing' meetings, not planning meetings - but
>> plenty of planning does still happen ;)
>>
>> Date wise, how about before OSCON ? PyConAU which often gets a heavy
>> openstack contingent is august 1-5.
>
> I am sure we have enough space, we would be very happy to host both at
> the same time.

I envision "at the same time" being "back to back" to be honest, as I
think running two in parallel would be a bit bonkers.

I'm now sitting on a list of about four or five offered venues, with
no plan for how to select which one to use. Perhaps what we should do
is pick the dates, then ask each venue if they're available in that
window, and then come up with some way to select from the remaining
venues.

I deeply appreciate all the offers of hosting -- its a great way for
companies to contribute to OpenStack, and makes a real difference to
our ability to deliver great software. Perhaps what we should do with
the venues that offer and don't get selected is keep them on a list of
venues to use for future meetups? That will make those meetups easier
to organise, and recognises the kind offers from the venues.

Cheers,
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] Thoughts from the PTL -- possible mid cycle meetup dates

[Michael Still]

On Wed, Apr 16, 2014 at 7:30 AM, Robert Collins
 wrote:

>> * a mid cycle meetup. I think the Icehouse meetup was a great success,
>> and I'd like to see us do this again in Juno. I'd also like to get the
>> location and venue nailed down as early as possible, so that people
>> who have complex travel approval processes have a chance to get travel
>> sorted out. I think its pretty much a foregone conclusion this meetup
>> will be somewhere in the continental US. If you're interested in
>> hosting a meetup in approximately August, please mail me privately so
>> we can chat.
>
> Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
> don't know if they have space for Nova & TripleO at once, but I'd love
> to get more collaboration time betwixt Nova and TripleO. The TripleO
> midcycle meetups are 'doing' meetings, not planning meetings - but
> plenty of planning does still happen ;)
>
> Date wise, how about before OSCON ? PyConAU which often gets a heavy
> openstack contingent is august 1-5.

I started building an etherpad to show clashes and possible weeks. Its at:

https://etherpad.openstack.org/p/juno-nova-midcycle-options

The biggest problem is that I don't know the dates for the milestones
in the Juno release yet, so I don't know how to align with those. I'd
be interested in crowd sourcing a list of possible clashes so that I
don't have to guess what conferences attendees go to.

The problem with July is that its very close to the summit (six weeks
gap), and that feels like we might not have had enough time to get
into the real meat of the release. Again though, I'd rather we get a
consensus here instead of dictating.

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] [infra] Basic zuul startup question: "Private key file is encrypted"

[Jeremy Stanley]

On 2014-04-15 18:00:07 + (+), Dane Leblanc (leblancd) wrote:
[...]
> PasswordRequiredException: Private key file is encrypted
[...]

A fairly straightforward error--your SSH key is encrypted with a
passphrase and zuul is thus unable to use it. You'll need to strip
the encryption from it with something like...

ssh-keygen -p -f ~/.ssh/id_dsa

(enter the old passphrase when prompted, and just don't enter
anything when prompted for a new passphrase)
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Murano] Working in devstack?

[Georgy Okrokvertskhov]

Hi Mark,

Thank you for a detailed report. As I know Murano team is working on fixing
devstack scripts.

As for DB setup it should be done by a command: tox -evenv -- murano-manage
--config-file etc/murano/murano-api.conf db-sync

It works in my testing environment.

Thanks
Georgy


On Tue, Apr 15, 2014 at 4:11 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:

> Hi all,
>
> There is some interest here in making use of Murano for Samba ADDC a
> service...so we've been (attempting) to get it up and running in devstack.
> In the process I've managed to get myself confused about the correct
> instructions for doing this:
>
> - the docs suggest http://murano-docs.github.io/latest/getting-started/
> content/ch04s03.html
> - the project provides murano-deployment/devstack-scripts/README.rst)
>
> ...which are markedly different approaches (it *looks* like the project
> README.rst is out of date, as it the scripts it runs try to get
> heat-horizon from repos that do not exist anymore). If this approach is not
> longer workable, we should really remove (or correct these instructions).
>
> So following http://murano-docs.github.io/latest/getting-started/
> content/ch04s03.html inside a Ubuntu 12.04 VM I stumbled into a few bugs:
>
> - several missing deps in various murano-*/requirements.txt (see attached)
> - typo in /murano-api/setup.sh (db_sync vs db-sync)
>
> Fixing these seems to get most things going (some tabs crash with missing
> tables, so I need to dig a bit more to find where they get created...).
>
> Any pointers/etc would be much appreciated!
>
> Cheers
>
> Mark
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Murano] Working in devstack?

[Mark Kirkwood]

Hi all,

There is some interest here in making use of Murano for Samba ADDC a 
service...so we've been (attempting) to get it up and running in 
devstack. In the process I've managed to get myself confused about the 
correct instructions for doing this:


- the docs suggest 
http://murano-docs.github.io/latest/getting-started/content/ch04s03.html

- the project provides murano-deployment/devstack-scripts/README.rst)

...which are markedly different approaches (it *looks* like the project 
README.rst is out of date, as it the scripts it runs try to get 
heat-horizon from repos that do not exist anymore). If this approach is 
not longer workable, we should really remove (or correct these 
instructions).


So following 
http://murano-docs.github.io/latest/getting-started/content/ch04s03.html 
inside a Ubuntu 12.04 VM I stumbled into a few bugs:


- several missing deps in various murano-*/requirements.txt (see attached)
- typo in /murano-api/setup.sh (db_sync vs db-sync)

Fixing these seems to get most things going (some tabs crash with 
missing tables, so I need to dig a bit more to find where they get 
created...).


Any pointers/etc would be much appreciated!

Cheers

Mark

Getting Murano to run in devstack
=

$ git clone https://github.com/openstack-dev/devstack.git
$ cd devstack
$ cat local.conf
[[local|localrc]]
ADMIN_PASSWORD=swordfish
MYSQL_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=servicetoken

$ ./stack.sh
$ ./unstack.sh
$ sudo apt-get purge apache2# make sure default site does not linger

$ mv files/images ~ # save images!

$ cd
$ git clone https://github.com/stackforge/murano-deployment.git
$ cp -r murano-deployment/devstack-integration/* devstack/
$ cd devstack 
$ cp single-node.local.conf local.conf
$ vi local.conf # set HOST_IP
$ ./stack.sh


Bugs


1/ Several missing pip requirements:

This necessitates re-running ./stack.sh several times and correcting
the errors below one by one (sigh, there is hopefully a better way)

$ tail /opt/stack/murano-api/requirements.txt
yaql

$ tail /opt/stack/murano-conductor/requirements.txt
jsonpath
celery

$ tail /opt/stack/murano-repository/test-requirements.txt
flask-testing

$ tail /opt/stack/murano-dashboard/requirements.txt
bunch

2/ Missing directory

$ mkdir /etc/tgt


3/ Missing tables

No tables in murano db's
(error is install script)

$ vi /opt/stack/murano-api/setup.sh # db_sync -> db-sync
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Thoughts from the PTL

[Jeremy Stanley]

On 2014-04-16 09:30:45 +1200 (+1200), Robert Collins wrote:
> Redhat offered to host the next TripleO midcycle meetup in Raleigh,
[...]

Neat--I live in that town! We definitely need more OpenStack
happening in it. ;)
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Hello Stackers!

I just finished the OpenStack IPv6 Quick Guide, it is hosted here:


Ultimate OpenStack IceHouse Guide - ML2 Flat Network - IPv6-Friendly:

https://gist.github.com/tmartinx/9177697


Almost everything is working with IPv6, including OpenStack Management
(APIs / Endpoints) and, of course, the Instances. Only NoVNC (TCP port
6080) and Metadata isn't working with IPv6 (yet).

Also, the IPv6 configuration is static, no auto-configuration right now.

My idea is to enable SLAAC on this environment, so, there will be no need
for static IPs and manual intervention. I think we're almost there! What do
you guys think?

BTW, sorry about tons of e-mails I sent before, I'll not do that again.

Cheers!
Thiago


On 12 April 2014 04:09, Martinx - ジェームズ  wrote:

> BTW, I think that the following patches are also important / relevant to
> begin with:
>
> ---
> 4. Two Attributes Proposal to Control IPv6 RA Announcement and Address
> Assignment
>https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
>Patchset: Create new IPv6 attributes for Subnets.
> https://review.openstack.org/#/c/52983/
>Patchset: Add support to DHCP agent for BP ipv6-two-attributes.
> https://review.openstack.org/70649
>Patchset: Calculate stateless IPv6 address.
> https://review.openstack.org/56184
>Patchset: Permit ICMPv6 RAs only from known routers.
> https://review.openstack.org/#/c/72252/
> ...
> 8. Provider Networking - upstream SLAAC support
> https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac
>Patchset: Ensure that that all fixed ips for a port belong to a
> subnet using DHCP. https://review.openstack.org/#/c/64578/
> ---
>
> But I'm not sure about the easiest path we can follow... From what I'm
> seeing, Neutron just needs to calculate Instance's IPv6 address based on
> SLAAC, then Instance's IPv6 address will match (Neutron <-> upstream
> SLAAC), in the end of the day.
>
> Also, review 72252 is very important!
>
> Regards,
> Thiago
>
>
> On 12 April 2014 01:34, Martinx - ジェームズ  wrote:
>
>> Cool! Instance shows an IPv6 address and it clearly isn't generated by
>> EUI-64 (SLAAC) but, at least, I can use static IPv6!  YAY!
>>
>> ---
>> root@controller:~# nova list
>>
>> +--+--+++-+---+
>> | ID   | Name | Status | Task State |
>> Power State | Networks  |
>>
>> +--+--+++-+---+
>> | 1654644d-6d52-4760-b147-4b88769a6fc2 | trusty-2 | ACTIVE | -  |
>> Running | sharednet1=10.33.14.23, 2001:1291:2bf:fffb::3 |
>>
>> +--+--+++-+---+
>>
>> root@controller:~# ssh -i ~/xxx.pem ubuntu@10.33.14.23
>>
>> ubuntu@trusty-2:~$ sudo ip -6 a a 2001:1291:2bf:fffb::3/64 dev eth0
>>
>> ubuntu@trusty-2:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1
>>
>> ubuntu@trusty-2:~$ ping6 -c 1 google.com
>> PING google.com(2800:3f0:4004:801::100e) 56 data bytes
>> 64 bytes from 2800:3f0:4004:801::100e: icmp_seq=1 ttl=54 time=49.6 ms
>>
>> --- google.com ping statistics ---
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 49.646/49.646/49.646/0.000 ms
>> ---
>>
>> IPv6 up and running and OpenStack is aware of both IPv4 and IPv6
>> instance's addresses! Security Group is also taking care of ip6tables.
>>
>> I'm pretty sure that if I start radvd on upstream router right now, all
>> instances will generate its own IPv6 based on their respective MAC address.
>> But then, the IPv6 will differ from what OpenStack "thinks" that each
>> instance have.
>>
>> So many e-mails, sorry BTW! :-P
>>
>> Best,
>> Thiago
>>
>> On 12 April 2014 01:11, Martinx - ジェームズ wrote:
>>
>>> In fact, neutron accepted the following command:
>>>
>>> ---
>>> root@controller:~# neutron subnet-create --ip-version 6 --disable-dhcp
>>> --tenant-id 5e0106fa81104c5cbe21e1ccc9eb1a36 sharednet1
>>> 2001:1291:2bf:fffb::/64
>>> Created a new subnet:
>>>
>>> +--+-+
>>> | Field| Value
>>> |
>>>
>>> +--+-+
>>> | allocation_pools | {"start": "2001:1291:2bf:fffb::2", "end":
>>> "2001:1291:2bf:fffb::::fffe"} |
>>> | cidr | 2001:1291:2bf:fffb::/64
>>> |
>>> | dns_nameservers  |
>>> |
>>> | enable_dhcp  | False
>>> |
>>> | gateway_ip   | 2001:1291:2bf:fffb::1
>>> |
>>> | host_rout

Re: [openstack-dev] [heat] computed package names?

[Zane Bitter]

On 15/04/14 17:59, Mike Spreitzer wrote:

Clint Byrum  wrote on 04/15/2014 05:17:21 PM:
 > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:
 >
 > > FWIW, in the short term I'm not aware of any issue with installing
 > > mariadb in Fedora 17/18, provided that mysql is not installed
first. And
 > > in fact they're both EOL anyway, so we should probably migrate all the
 > > templates to Fedora 20 and mariadb.
 >
 > +1 for that.

I count 22 templates in heat-templates that are written to support
Fedora, Ubuntu, and RHEL; is MariaDB available in those?  I do not see
it in Ubuntu 12.10, for example.


I imagine it's a problem for RHEL (can RHEL 7 just get released 
already?). Ubuntu is not an issue though, unless they have adopted yum 
while I was not looking.


Checking a random sample, they only includes "yum" and "systemd" 
sections (no "apt" or "sysvinit") in the metadata, so the purported 
support for Ubuntu 10.04 is just due to copy-paste and isn't actually 
implemented.


There is, I thought, one template that does actually support Ubuntu. 
Stuff in the "F17" directory is there for a reason.


- ZB

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

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

[Ruslan Kamaldinov]

Update:
Stan filed a blueprint [0] for type interfaces in HOT.


I would like to outline the current vision of Murano Application format, to
make sure we're all on the same page. We had a valuable discussion in several
MLs and we also had a lot of discussions between Murano team members. As a
result of these discussion we see the following plan for Murano:

* Adopt TOSCA for application definition in Murano. Work with TOSCA committee
* Utilize Heat as much as possible. Participate in discussions and
  implementations for hooks mechanism in Heat. Participate in HOT format
  discussions
* Adopt Mistral DSL for workflow management. Find a way to compose Heat
  templates and Mistral DSL
* Keep MuranoPL engine in the source tree to take care of all the features we
  need for our users until those features are implemented on top things
  described above

Murano, Heat teams, please let me know if this plan sounds sane to you.

[0] https://blueprints.launchpad.net/heat/+spec/interface-types

Thanks,
Ruslan

On Sat, Apr 5, 2014 at 12:25 PM, Thomas Spatzier
 wrote:
> Clint Byrum  wrote on 04/04/2014 19:05:04:
>> From: Clint Byrum 
>> To: openstack-dev 
>> Date: 04/04/2014 19:06
>> Subject: Re: [openstack-dev] [Heat] [Murano] [Solum] applications inthe
> cloud
>>
>> Excerpts from Stan Lagun's message of 2014-04-04 02:54:05 -0700:
>> > Hi Steve, Thomas
>> >
>> > I'm glad the discussion is so constructive!
>> >
>> > If we add type interfaces to HOT this may do the job.
>> > Applications in AppCatalog need to be portable across OpenStack clouds.
>> > Thus if we use some globally-unique type naming system applications
> could
>> > identify their dependencies in unambiguous way.
>> >
>> > We also would need to establish relations between between interfaces.
>> > Suppose there is My::Something::Database interface and 7 compatible
>> > materializations:
>> > My::Something::TroveMySQL
>> > My::Something::GaleraMySQL
>> > My::Something::PostgreSQL
>> > My::Something::OracleDB
>> > My::Something::MariaDB
>> > My::Something::MongoDB
>> > My::Something::HBase
>> >
>> > There are apps that (say SQLAlchemy-based apps) are fine with any
>> > relational DB. In that case all templates except for MongoDB and HBase
>> > should be matched. There are apps that design to work with MySQL only.
> In
>> > that case only TroveMySQL, GaleraMySQL and MariaDB should be matched.
> There
>> > are application who uses PL/SQL and thus require OracleDB (there can be
>> > several Oracle implementations as well). There are also applications
>> > (Marconi and Ceilometer are good example) that can use both some SQL
> and
>> > NoSQL databases. So conformance to Database interface is not enough and
>> > some sort of interface hierarchy required.
>>
>> IMO that is not really true and trying to stick all these databases into
>> one "SQL database" interface is not a use case I'm interested in
>> pursuing.
>>
>> Far more interesting is having each one be its own interface which apps
>> can assert that they support or not.
>
> Agree, this looks like a feasible goal and would already bring some value
> add in that one could look up appropriate provider templates instead of
> having to explicitly link them in environments.
> Doing too much of inheritance sounds interesting at first glance but
> burries a lot of complexity.
>
>>
>> >
>> > Another thing that we need to consider is that even compatible
>> > implementations may have different set of parameters. For example
>> > clustered-HA PostgreSQL implementation may require additional
> parameters
>> > besides those needed for plain single instance variant. Template that
>> > consumes *any* PostgreSQL will not be aware of those additional
> parameters.
>> > Thus they need to be dynamically added to environment's input
> parameters
>> > and resource consumer to be patched to pass those parameters to actual
>> > implementation
>> >
>>
>> I think this is a middleware pipe-dream and the devil is in the details.
>>
>> Just give users the ability to be specific, and then generic patterns
>> will arise from those later on.
>>
>> I'd rather see a focus on namespacing and relative composition, so that
>> providers of the same type that actually do use the same interface but
>> are alternate implementations will be able to be consumed. So for
> instance
>> there is the non-Neutron LBaaS and the Neutron LBaaS, and both have their
>> merits for operators, but are basically identical from an application
>> standpoint. That seems a better guiding use case than different
> databases.
>>
>> ___
>> 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 l

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

[Carl Baldwin]

+1.  I think we'll like this process better.  I hope to have some of
the first blueprints to propose to the new repository very soon.

On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery  wrote:
> Given the success the Nova team has had in handling reviews using
> their new nova-specs gerrit repository, I think it makes a lot of
> sense for Neutron to do the same. With this in mind, I've added
> instructions to the BP wiki [1] for how to do. Going forward in Juno,
> this is how Neutron BPs will be handled by the Neutron core team. If
> you are currently working on a BP or code for Juno which is attached
> to a BP, please file the BP using the process here [1].
>
> Given this is our first attempt at using this for reviews, I
> anticipate there may be a few hiccups along the way. Please reply on
> this thread or reach out in #openstack-neutron and we'll sort through
> whatever issues we find.
>
> Thanks!
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
> ___
> 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] Re: deliver the vm-level HA to improve the business continuity with openstack

[Zane Bitter]

On 15/04/14 06:16, Qiming Teng wrote:

3) Can/should we do the VM HA orchestration in Heat?

My perception is that it can be done in Heat, based on my limited
understandig of how Heat works.  It may imply some requirements to other
projects (e.g.  nova, cinder, neutron ...) as well, though Heat should be
the orchestrator.

What do we need then?

   - A resource type for VM groups/clusters, for the redundant
 provisioning.  VMs in the group can be identical instances, managed
 by a Pacemaker setup among the VMs, just like a WatchRule in Heat can
 be controlled by Ceilometer.


Heat is not a catch-all place to put features that need co-ordination 
amongst projects; Heat provides a declarative way of interacting with 
existing OpenStack APIs. So if you have another OpenStack API for VM 
groups/clusters we can add a resource type to talk to it.


All of the cases where we have attempted to implement missing parts of 
OpenStack (autoscaling, HARestarter) directly in Heat have turned out to 
be giant headaches. We have a lot of work still ahead to split 
autoscaling out of the Heat engine and give it its own API. 
HARestarter's days, as Steve mentioned, are numbered. I'd like to avoid 
taking any similar shortcuts in future.


cheers,
Zane.

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

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

[Nachi Ueno]

+10 !

2014-04-15 15:07 GMT-07:00 Kyle Mestery :
> Given the success the Nova team has had in handling reviews using
> their new nova-specs gerrit repository, I think it makes a lot of
> sense for Neutron to do the same. With this in mind, I've added
> instructions to the BP wiki [1] for how to do. Going forward in Juno,
> this is how Neutron BPs will be handled by the Neutron core team. If
> you are currently working on a BP or code for Juno which is attached
> to a BP, please file the BP using the process here [1].
>
> Given this is our first attempt at using this for reviews, I
> anticipate there may be a few hiccups along the way. Please reply on
> this thread or reach out in #openstack-neutron and we'll sort through
> whatever issues we find.
>
> Thanks!
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
> ___
> 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] computed package names?

[Clint Byrum]

Excerpts from Mike Spreitzer's message of 2014-04-15 14:59:50 -0700:
> Clint Byrum  wrote on 04/15/2014 05:17:21 PM:
> 
> > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:
> 
> > > Yes, that _kind_ of thing. But I don't see much point in having an 
> > > AWS::CloudFormation::Init section that isn't compatible with 
> > > CloudFormation's definition of it. We already have some native 
> > > in-instance tools (e.g. os-apply-config) that can probably handle this 
> 
> > > better.
> > > 
> > 
> > os-apply-config wouldn't really be what you want. It is specifically
> > only intended for translating communication values into configuration.
> > Package installation is not handled.
> > 
> > We don't have a native declarative post-boot package installation
> > tool that can be expressed this way. If you must do vanilla images +
> > customization, I think cfn-init is generally fine. This particular case,
> > however, shows a place where they abused the mapping json type pretty
> > badly. I think it would make sense to have a native OS::Heat::Init
> > section that takes the package name as a value or something.
> > 
> > > FWIW, in the short term I'm not aware of any issue with installing 
> > > mariadb in Fedora 17/18, provided that mysql is not installed first. 
> And 
> > > in fact they're both EOL anyway, so we should probably migrate all the 
> 
> > > templates to Fedora 20 and mariadb.
> > 
> > +1 for that.
> 
> I count 22 templates in heat-templates that are written to support Fedora, 
> Ubuntu, and RHEL; is MariaDB available in those?  I do not see it in 
> Ubuntu 12.10, for example.
> 

No, MariaDB might be in Ubuntu 14.04.. haven't checked, but mysql is
still the recommended one.

> Those templates support ubuntu 10.  Just 10!  It will probably be easiest 
> to add Ubuntu 12 (as in 12.04 LTS) and 14 (as in 14.04 LTS).
> 

Ubuntu 10.04 has just 1 year of support left. Time to start migrating!
:)

> Yes, I can see how OS::Heat::Init makes sense.  But is this just the first 
> thing on a long list?  Would it be better to have a static intrinsic that 
> is like Python's dict(iterable of iterable)->dictionary function?
> 

Yes I don't know what the python thing you're referring to is.

Yes, it is the first in the list of things we'd change while creating
a native format. Though another option is to just adopt external tools
like puppet/chef/salt to do this. We creates os-*-config in TripleO so
we didn't have to pick a religion and so that we could do "the unix way"
and make tools that only do one thing. However, for template examples,
it might be a little easier to accept one religion, er, tool, in one
template, and another tool in a different template.

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

Re: [openstack-dev] [heat] computed package names?

[Mike Spreitzer]

Mike Spreitzer/Watson/IBM@IBMUS wrote on 04/15/2014 05:59:50 PM:

> Yes, I can see how OS::Heat::Init makes sense.  But is this just the
> first thing on a long list?  Would it be better to have a static 
> intrinsic that is like Python's dict(iterable of 
> iterable)->dictionary function? 

.. and I see now that we do: Fn::MemberListToMap
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Neutron BP review process for Juno

[Kyle Mestery]

Given the success the Nova team has had in handling reviews using
their new nova-specs gerrit repository, I think it makes a lot of
sense for Neutron to do the same. With this in mind, I've added
instructions to the BP wiki [1] for how to do. Going forward in Juno,
this is how Neutron BPs will be handled by the Neutron core team. If
you are currently working on a BP or code for Juno which is attached
to a BP, please file the BP using the process here [1].

Given this is our first attempt at using this for reviews, I
anticipate there may be a few hiccups along the way. Please reply on
this thread or reach out in #openstack-neutron and we'll sort through
whatever issues we find.

Thanks!
Kyle

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

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

Re: [openstack-dev] [nova] [neutron] Gerrit spec reviews

[Michael Still]

On Wed, Apr 16, 2014 at 7:31 AM, Russell Bryant  wrote:
> On 04/15/2014 05:14 PM, Kyle Mestery wrote:

>> 2. Nova has a subset of the core-team which can actually approve BPs,
>> is this correct?
>
> Correct.  The team is nova-drivers [1].  This is the team that assisted
> me with the blueprint review process last cycle, as well.  My plan was
> to continue to manage the team sort of like we manage nova-core: update
> with new members after they gained trust from the others after
> demonstrating dedication and high review quality.  Going forward, I
> defer to the Juno PTL on any changes that may be made here.

I agree with this plan. I also think that given nova-specs is so new,
the first couple of iterations of updates to nova-drivers might be
quite rapid. We probably have enough data already to know who is
engaging with this process and isn't part of nova-drivers. That will
drive the first update to nova-drivers.

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] [heat] computed package names?

[Mike Spreitzer]

Clint Byrum  wrote on 04/15/2014 05:17:21 PM:


> Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:

> > Yes, that _kind_ of thing. But I don't see much point in having an 
> > AWS::CloudFormation::Init section that isn't compatible with 
> > CloudFormation's definition of it. We already have some native 
> > in-instance tools (e.g. os-apply-config) that can probably handle this 

> > better.
> > 
> 
> os-apply-config wouldn't really be what you want. It is specifically
> only intended for translating communication values into configuration.
> Package installation is not handled.
> 
> We don't have a native declarative post-boot package installation
> tool that can be expressed this way. If you must do vanilla images +
> customization, I think cfn-init is generally fine. This particular case,
> however, shows a place where they abused the mapping json type pretty
> badly. I think it would make sense to have a native OS::Heat::Init
> section that takes the package name as a value or something.
> 
> > FWIW, in the short term I'm not aware of any issue with installing 
> > mariadb in Fedora 17/18, provided that mysql is not installed first. 
And 
> > in fact they're both EOL anyway, so we should probably migrate all the 

> > templates to Fedora 20 and mariadb.
> 
> +1 for that.

I count 22 templates in heat-templates that are written to support Fedora, 
Ubuntu, and RHEL; is MariaDB available in those?  I do not see it in 
Ubuntu 12.10, for example.

Those templates support ubuntu 10.  Just 10!  It will probably be easiest 
to add Ubuntu 12 (as in 12.04 LTS) and 14 (as in 14.04 LTS).

Yes, I can see how OS::Heat::Init makes sense.  But is this just the first 
thing on a long list?  Would it be better to have a static intrinsic that 
is like Python's dict(iterable of iterable)->dictionary function?

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

Re: [openstack-dev] [Nova] Thoughts from the PTL

[Hugh O. Brock]

On Wed, Apr 16, 2014 at 09:30:45AM +1200, Robert Collins wrote:
> On 14 April 2014 16:58, Michael Still  wrote:
> > First off, thanks for electing me as the Nova PTL for Juno. I find the
> > outcome of the election both flattering and daunting. I'd like to
> > thank Dan and John for running as PTL candidates as well -- I strongly
> > believe that a solid democratic process is part of what makes
> > OpenStack so successful, and that isn't possible without people being
> > will to stand up during the election cycle.
> 
> +1 - me too, it was great to see James Slagle stand up and volunteer this 
> cycle.
> 
> > * a mid cycle meetup. I think the Icehouse meetup was a great success,
> > and I'd like to see us do this again in Juno. I'd also like to get the
> > location and venue nailed down as early as possible, so that people
> > who have complex travel approval processes have a chance to get travel
> > sorted out. I think its pretty much a foregone conclusion this meetup
> > will be somewhere in the continental US. If you're interested in
> > hosting a meetup in approximately August, please mail me privately so
> > we can chat.
> 
> Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
> don't know if they have space for Nova & TripleO at once, but I'd love
> to get more collaboration time betwixt Nova and TripleO. The TripleO
> midcycle meetups are 'doing' meetings, not planning meetings - but
> plenty of planning does still happen ;)
> 
> Date wise, how about before OSCON ? PyConAU which often gets a heavy
> openstack contingent is august 1-5.

I am sure we have enough space, we would be very happy to host both at
the same time.

--Hugh


-- 
== Hugh Brock, hbr...@redhat.com   ==
== Senior Engineering Manager, Cloud Engineering   ==
== Tuskar: Elastic Scaling for OpenStack   ==
== http://github.com/tuskar==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey

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

Re: [openstack-dev] [TripleO] reviewer update march [additional cores]

[Robert Collins]

This has been actioned. Welcome!

-Rob

On 8 April 2014 11:50, Robert Collins  wrote:
> tl;dr: 3 more core members to propose:
> bnemec
> greghaynes
> jdon
>
>
> On 4 April 2014 08:55, Chris Jones  wrote:
>> Hi
>>
>> +1 for your proposed -core changes.
>>
>> Re your question about whether we should retroactively apply the 3-a-day
>> rule to the 3 month review stats, my suggestion would be a qualified no.
>>
>> I think we've established an agile approach to the member list of -core, so
>> if there are a one or two people who we would have added to -core before the
>> goalposts moved, I'd say look at their review quality. If they're showing
>> the right stuff, let's get them in and helping. If they don't feel our new
>> goalposts are achievable with their workload, they'll fall out again
>> naturally before long.
>
> So I've actioned the prior vote.
>
> I said: "Bnemec, jdob, greg etc - good stuff, I value your reviews
> already, but..."
>
> So... looking at a few things - long period of reviews:
> 60 days:
> |greghaynes   | 1210  22  99   0   081.8% |
> 14 ( 11.6%)  |
> |  bnemec | 1160  38  78   0   067.2% |
> 10 (  8.6%)  |
> |   jdob  |  870  15  72   0   082.8% |
> 4 (  4.6%)  |
>
> 90 days:
>
> |  bnemec | 1450  40 105   0   072.4% |
> 17 ( 11.7%)  |
> |greghaynes   | 1420  23 119   0   083.8% |
> 22 ( 15.5%)  |
> |   jdob  | 1060  17  89   0   084.0% |
> 7 (  6.6%)  |
>
> Ben's reviews are thorough, he reviews across all contributors, he
> shows good depth of knowledge and awareness across tripleo, and is
> sensitive to the pragmatic balance between 'right' and 'good enough'.
> I'm delighted to support him for core now.
>
> Greg is very active, reviewing across all contributors with pretty
> good knowledge and awareness. I'd like to see a little more contextual
> awareness though - theres a few (but not many) reviews where looking
> at how the big picture of things fitting together more would have been
> beneficial. *however*, I think that's a room-to-improve issue vs
> not-good-enough-for-core - to me it makes sense to propose him for
> core too.
>
> Jay's reviews are also very good and consistent, somewhere between
> Greg and Ben in terms of bigger-context awareness - so another
> definite +1 from me.
>
> -Rob
>
>
>
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud



-- 
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] [Nova] Cancelling the nova meeting for this week

[Michael Still]

Hi.

Easter is this coming weekend for many countries, so many people are
going to be away or at least winding down for the long weekend.

Let's skip the nova meeting this week and let people have a bit of a break.

Thanks,
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] [TripleO][design] review based conceptual design process

[Robert Collins]

On 16 April 2014 09:15, James Slagle  wrote:
> On Tue, Apr 15, 2014 at 2:44 PM, Robert Collins
>  wrote:
>> I've been watching the nova process, and I think its working out well
>> - it certainly addresses:
>>  - making design work visible
>>  - being able to tell who has had input
>>  - and providing clear feedback to the designers
>>
>> I'd like to do the same thing for TripleO this cycle..
>>
>> I'm thinking we can just add docs to incubator, since thats already a
>> repository separate to our production code - what do folk think?
>
> +1 from me.
>
> Think I'd prefer a separate repo for tripleo-specs though.
>
> One thing that I don't think I saw called out specifically in the
> nova-specs thread was about keeping these spec and design documents
> updated. I'm guessing the plan around that would just be to submit
> updates in gerrit as patches, and then we can all review the updates
> as well. I think it's important that we try to keep them up to date
> and accurate as possible.

So with the consistent 'and lets have a specs repo' response - cool.
Can I get a volunteer to get it setup, please?

-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] Thoughts from the PTL

[Robert Collins]

On 14 April 2014 16:58, Michael Still  wrote:
> First off, thanks for electing me as the Nova PTL for Juno. I find the
> outcome of the election both flattering and daunting. I'd like to
> thank Dan and John for running as PTL candidates as well -- I strongly
> believe that a solid democratic process is part of what makes
> OpenStack so successful, and that isn't possible without people being
> will to stand up during the election cycle.

+1 - me too, it was great to see James Slagle stand up and volunteer this cycle.

> * a mid cycle meetup. I think the Icehouse meetup was a great success,
> and I'd like to see us do this again in Juno. I'd also like to get the
> location and venue nailed down as early as possible, so that people
> who have complex travel approval processes have a chance to get travel
> sorted out. I think its pretty much a foregone conclusion this meetup
> will be somewhere in the continental US. If you're interested in
> hosting a meetup in approximately August, please mail me privately so
> we can chat.

Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
don't know if they have space for Nova & TripleO at once, but I'd love
to get more collaboration time betwixt Nova and TripleO. The TripleO
midcycle meetups are 'doing' meetings, not planning meetings - but
plenty of planning does still happen ;)

Date wise, how about before OSCON ? PyConAU which often gets a heavy
openstack contingent is august 1-5.

-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] [neutron] Gerrit spec reviews

[Kyle Mestery]

Thanks Solly, and I agree on the benefits here, which is why Neutron
is moving to the same process as Nova for these BP reviews.

Thanks,
Kyle

On Tue, Apr 15, 2014 at 4:24 PM, Solly Ross  wrote:
> This page actually has most of the answers on it: 
> https://wiki.openstack.org/wiki/Blueprints#Nova
>
> 1: The time limit is one release: "at the end of each release, non-completed 
> specs will be removed"
> 2: The "nova-drivers" team approves specs
> 3: No, it's not required to have a summit session. Something like that would 
> be problematic, as
>blueprints could be proposed after summit.
>
> Hope that helps.  IMHO, the nova-specs gerrit repository is a great way to 
> review
> blueprints.  I'm really liking it so far.
>
> Best Regards,
> Solly Ross
>
> - Original Message -
> From: "Kyle Mestery" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Tuesday, April 15, 2014 5:14:14 PM
> Subject: [openstack-dev] [nova] [neutron] Gerrit spec reviews
>
> Hi Nova developers:
>
> I have a question around the new nova-specs gerrit repository. We're
> implementing the same thing in Neutron for Juno (I'm hoping to make
> this live tomorrow), but I had a few quick questions so I can build on
> your experience with this so far:
>
> 1. Did you implement any sort of time limit on BPs in review? Mostly
> around trying to triage the BPs as they come in.
> 2. Nova has a subset of the core-team which can actually approve BPs,
> is this correct?
> 3. For all BPs submitted using the new procedure, is it required to
> submit a Summit session?
>
> Any guidance appreciated here!
>
> Thanks,
> Kyle
>
> ___
> 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] [nova] [neutron] Gerrit spec reviews

[Russell Bryant]

On 04/15/2014 05:14 PM, Kyle Mestery wrote:
> Hi Nova developers:
> 
> I have a question around the new nova-specs gerrit repository. We're
> implementing the same thing in Neutron for Juno (I'm hoping to make
> this live tomorrow), but I had a few quick questions so I can build on
> your experience with this so far:
> 
> 1. Did you implement any sort of time limit on BPs in review? Mostly
> around trying to triage the BPs as they come in.

No limits yet other than the organic limits of how fast we can get
through them.

> 2. Nova has a subset of the core-team which can actually approve BPs,
> is this correct?

Correct.  The team is nova-drivers [1].  This is the team that assisted
me with the blueprint review process last cycle, as well.  My plan was
to continue to manage the team sort of like we manage nova-core: update
with new members after they gained trust from the others after
demonstrating dedication and high review quality.  Going forward, I
defer to the Juno PTL on any changes that may be made here.

> 3. For all BPs submitted using the new procedure, is it required to
> submit a Summit session?

No.  More details of the process on [2].

[1] https://launchpad.net/~nova-drivers/+members#active
[2] https://wiki.openstack.org/wiki/Blueprints#Creation

-- 
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] [neutron] Gerrit spec reviews

[Solly Ross]

This page actually has most of the answers on it: 
https://wiki.openstack.org/wiki/Blueprints#Nova

1: The time limit is one release: "at the end of each release, non-completed 
specs will be removed"
2: The "nova-drivers" team approves specs
3: No, it's not required to have a summit session. Something like that would be 
problematic, as
   blueprints could be proposed after summit.

Hope that helps.  IMHO, the nova-specs gerrit repository is a great way to 
review
blueprints.  I'm really liking it so far.

Best Regards,
Solly Ross

- Original Message -
From: "Kyle Mestery" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Tuesday, April 15, 2014 5:14:14 PM
Subject: [openstack-dev] [nova] [neutron] Gerrit spec reviews

Hi Nova developers:

I have a question around the new nova-specs gerrit repository. We're
implementing the same thing in Neutron for Juno (I'm hoping to make
this live tomorrow), but I had a few quick questions so I can build on
your experience with this so far:

1. Did you implement any sort of time limit on BPs in review? Mostly
around trying to triage the BPs as they come in.
2. Nova has a subset of the core-team which can actually approve BPs,
is this correct?
3. For all BPs submitted using the new procedure, is it required to
submit a Summit session?

Any guidance appreciated here!

Thanks,
Kyle

___
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] computed package names?

[Clint Byrum]

Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:
> On 15/04/14 15:57, Mike Spreitzer wrote:
> > Zane Bitter  wrote on 04/15/2014 03:29:03 PM:
> >
> >  > On 15/04/14 14:31, Mike Spreitzer wrote:
> >  > > It appears that in Fedora 19 and 20 the Wordpress examples need to
> >  > > install different packages than in every other release (see my
> > debugging
> >  > > in https://review.openstack.org/#/c/87065/).  I just got a complaint
> >  > > from Heat validation that I can't do this:
> >  > >
> >  > >  "AWS::CloudFormation::Init" : {
> >  > >"config" : {
> >  > >  "packages" : {
> >  > >"yum" : {
> >  > > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> >  > > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
> > "client" ] }
> >  > > : [],
> >  > > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> >  > > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
> > "server" ] }
> >  > > : [],
> >  > >
> >  >
> >  > .. in
> >  > JSON a property name cannot be an object ...
> >
> > Ah, right.  So what would be the simplest way to enable this use case?
> >   Perhaps a generalization of AWS::CloudFormation::Init that allows the
> > package names to be objects (that evaluate to strings, of course)?
> >   Maybe allow, e.g., "yum" to be associated with not a map but rather a
> > list of pairs (2-element lists)?
> 
> Yes, that _kind_ of thing. But I don't see much point in having an 
> AWS::CloudFormation::Init section that isn't compatible with 
> CloudFormation's definition of it. We already have some native 
> in-instance tools (e.g. os-apply-config) that can probably handle this 
> better.
> 

os-apply-config wouldn't really be what you want. It is specifically
only intended for translating communication values into configuration.
Package installation is not handled.

We don't have a native declarative post-boot package installation
tool that can be expressed this way. If you must do vanilla images +
customization, I think cfn-init is generally fine. This particular case,
however, shows a place where they abused the mapping json type pretty
badly. I think it would make sense to have a native OS::Heat::Init
section that takes the package name as a value or something.

> FWIW, in the short term I'm not aware of any issue with installing 
> mariadb in Fedora 17/18, provided that mysql is not installed first. And 
> in fact they're both EOL anyway, so we should probably migrate all the 
> templates to Fedora 20 and mariadb.

+1 for that.

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

Re: [openstack-dev] [TripleO][design] review based conceptual design process

[James Slagle]

On Tue, Apr 15, 2014 at 2:44 PM, Robert Collins
 wrote:
> I've been watching the nova process, and I think its working out well
> - it certainly addresses:
>  - making design work visible
>  - being able to tell who has had input
>  - and providing clear feedback to the designers
>
> I'd like to do the same thing for TripleO this cycle..
>
> I'm thinking we can just add docs to incubator, since thats already a
> repository separate to our production code - what do folk think?

+1 from me.

Think I'd prefer a separate repo for tripleo-specs though.

One thing that I don't think I saw called out specifically in the
nova-specs thread was about keeping these spec and design documents
updated. I'm guessing the plan around that would just be to submit
updates in gerrit as patches, and then we can all review the updates
as well. I think it's important that we try to keep them up to date
and accurate as possible.

-- 
-- James Slagle
--

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

[openstack-dev] [nova] [neutron] Gerrit spec reviews

[Kyle Mestery]

Hi Nova developers:

I have a question around the new nova-specs gerrit repository. We're
implementing the same thing in Neutron for Juno (I'm hoping to make
this live tomorrow), but I had a few quick questions so I can build on
your experience with this so far:

1. Did you implement any sort of time limit on BPs in review? Mostly
around trying to triage the BPs as they come in.
2. Nova has a subset of the core-team which can actually approve BPs,
is this correct?
3. For all BPs submitted using the new procedure, is it required to
submit a Summit session?

Any guidance appreciated here!

Thanks,
Kyle

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

[openstack-dev] [Neutron] Provider Framework and Flavor Framework

[Eugene Nikanorov]

Hi folks,

In Icehouse there were attempts to apply Provider Framework ('Service Type
Framework') approach to VPN and Firewall services.
Initially Provider Framework was created as a simplistic approach of
allowing user to choose service implementation.
That approach definitely didn't account for public cloud case where users
should not be aware of underlying implementation, while being able to
request capabilities or a SLA.

However, Provider Framework consists of two parts:
1) API part.
That's just 'provider' attribute of the main resource of the service plus a
REST call to fetch available providers for a service

2) Dispatching part
That's a DB table that keeps mapping between resource and implementing
provider/driver.
With this mapping it's possible to dispatch a REST call to the particular
driver that is implementing the service.

As we are moving to better API and user experience, we may want to drop the
first part, which makes the framework "non-public-cloud-friendly" but the
second part will remain if we ever want to support more then one driver
simultaneously.

Flavor framework proposes choosing implementation based on capabilities,
but the result of the choice (e.g. scheduling) is still a mapping between
resource and the driver.
So the second part is still needed for the Flavor Framework.

I think it's a good time to continue the discussion on Flavor and Provider
Frameworks.

Some references:
1. Flavor Framework description
https://wiki.openstack.org/wiki/Neutron/FlavorFramework
2. Flavor Framework PoC/example code https://review.openstack.org/#/c/83055/
3. FWaaS integration with Provider framework:
https://review.openstack.org/#/c/60699/
4. VPNaaS integration with Provider framework:
https://review.openstack.org/#/c/41827/

I'd like to see the work on (3) and (4) continued, considering Provider
Framework is a basis for Flavor Framework.

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

Re: [openstack-dev] [Nova][Neutron] API inconsistencies with security groups

[Joe Gordon]

On Sun, Apr 6, 2014 at 6:06 AM, Christopher Yeoh  wrote:

> On Sat, Apr 5, 2014 at 10:17 PM, Joshua Hesketh <
> joshua.hesk...@rackspace.com> wrote:
>
>> Hi Chris,
>>
>> Thanks for your input.
>>
>>
>> On 4/5/14 9:56 PM, Christopher Yeoh wrote:
>>
>>> On Sat, 5 Apr 2014 15:16:33 +1100
>>> Joshua Hesketh  wrote:
>>>
 I'm moving a conversation that has begun on a review to this mailing
 list as it is perhaps systematic of a larger issue regarding API
 compatibility (specifically between neutron and nova-networking).
 Unfortunately these are areas I don't have much experience with so
 I'm hoping to gain some clarity here.

 There is a bug in nova where launching an instance with a given
 security group is case-insensitive for nova-networks but
 case-sensitive for neutron. This highlights inconsistencies but I
 also think this is a legitimate bug[0]. Specifically the 'nova boot'
 command accepts the incorrectly cased security- group but the
 instance enters an error state as it has been unable to boot it.
 There is an inherent mistake here where the initial check approves
 the security-group name but when it comes time to assign the security
 group (at the scheduler level) it fails.

 I think this should be fixed but then the nova CLI behaves
 differently with different tasks. For example, `nova
 secgroup-add-rule` is case sensitive. So in reality it is unclear if
 security groups should, or should not, be case sensitive. The API
 implies that they should not. The CLI has methods where some are and
 some are not.

 I've addressed the initial bug as a patch to the neutron driver[1]
 and also amended the case-sensitive lookup in the
 python-novaclient[2] but both reviews are being held up by this issue.

 I guess the questions are:
- are people aware of this inconsistency?
- is there some documentation on the inconsistencies?
- is a fix of this nature considered an API compatibility break?
- and what are the expectations (in terms of case-sensitivity)?

>>> I don't know the history behind making security group names case
>>> insensitive for nova-network, but without that knowledge it seems a
>>> little odd to me. The Nova API is in general case sensitive - with the
>>> exception of when you supply types  - eg True/False, Enabled/Disabled.
>>>
>>> If someone thinks there's a good reason for having it case insensitive
>>> then I'd like to hear what that is. But otherwise in an ideal world I
>>> think they should be case sensitive.
>>>
>>> Working with what we have however, I think it would also be bad if
>>> using the neutron API directly security group were case sensitive but
>>> talking to it via Nova it was case insensitive. Put this down as one of
>>> the risks of doing proxying type work in Nova.
>>>
>>> I think the proposed patches are backwards incompatible API changes.
>>>
>>
>> I agree that changing the python-novaclient[2] is new functionality and
>> perhaps
>> more controversial, but it is not directly related to an API change. The
>> change I proposed to nova[1] stops the scheduler from getting stuck when
>> it
>> tries to launch an instance with an already accepted security group.
>>
>> Perhaps the fix here should be that the nova API never accepted the
>> security
>> group to begin with. However, that would be an API change. The change I've
>> proposed at the moment stops instances from entering an error state, but
>> it
>> doesn't do anything to help with the inconsistencies.
>>
>>
> So if Nova can detect earlier on in the process that an instance launch is
> definitely going to fail because the security group is invalid then I think
> its ok to return an error to the user earlier rather than return success
> and have it fail later on anyway.
>

So this changes the behavior for nova-network users.

I don't really see any easy way out of this one, besides thorough
documentation of the issue.


>
> > That's likely true. However I would appreciate reviews on 77347 with the
> above
>
>> in mind.
>>
>>
>
> I might be misunderstanding exactly what is going on here, but I'll
> comment directly on the 77347.
>
> Regards,
>
> Chris
>
> ___
> 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] Re: deliver the vm-level HA to improve the business continuity with openstack

[Sylvain Bauza]

Hi Steven et al.


2014-04-15 17:01 GMT+02:00 Steven Dake :

>
>>  Qiming,
>
> If you read my original post on this thread, it outlines the current
> heat-core thinking, which is to reduce the scope of this resource from the
> Heat resources since it describes a workflow rather then an orchestrated
> thing (a Noun).
>
> A good framework for HA already exists for HA in the HARestarter resource.
>  It incorporates HA escalation, which is a critical feature of any HA
> system.  The fundamental problem with HARestarter is that is in the wrong
> project.
>
> Long term, HA, if desired, should be part of taskflow, though, because its
> a verb, and verbs don't belong as heat orchestrated resources.
>
> How we get from here to there is left as an exercise to the reader ;-)
>
> Regards
> -steve
>
>

>From my POV, I can consider that the HA feature would be something like
AutoScaling in Heat, meaning it would involve multiple stakeholders :
 - Ceilometer for aggregating metrics from hosts and raising an Alarm which
will trigger a WebHook corresponding to the faulty resource
 - Heat for declaring all HA policies within a template and creating
appropriate Ceilometer Alarms
 - the service behind the Webhook for executing the remediation actions
(Heat) which would call the appropriate services (eg. Nova)
 - eg. Nova to perform live migrations of the instances if possible, or
evacuate

I don't know if Taskflow would be necessary for doing the logic here,
that's more likely a placement issue than a workflow issue, as it requires
to schedule new resources but can only be made on a per-resource basis
(Nova instances, Cinder volumes, etc.). Taskflow would here be helpful for
having a all-or-one logic in case of the migration untl the scheduling
would be holistic.

Of course, in a far far away galaxy, we could consider having one global
Scheduler for placement decisions that Heat could query for live migrating
resources, but I'm still dreaming...

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

Re: [openstack-dev] [heat] computed package names?

[Zane Bitter]

On 15/04/14 15:57, Mike Spreitzer wrote:

Zane Bitter  wrote on 04/15/2014 03:29:03 PM:

 > On 15/04/14 14:31, Mike Spreitzer wrote:
 > > It appears that in Fedora 19 and 20 the Wordpress examples need to
 > > install different packages than in every other release (see my
debugging
 > > in https://review.openstack.org/#/c/87065/).  I just got a complaint
 > > from Heat validation that I can't do this:
 > >
 > >  "AWS::CloudFormation::Init" : {
 > >"config" : {
 > >  "packages" : {
 > >"yum" : {
 > > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
 > > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
"client" ] }
 > > : [],
 > > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
 > > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] },
"server" ] }
 > > : [],
 > >
 >
 > .. in
 > JSON a property name cannot be an object ...

Ah, right.  So what would be the simplest way to enable this use case?
  Perhaps a generalization of AWS::CloudFormation::Init that allows the
package names to be objects (that evaluate to strings, of course)?
  Maybe allow, e.g., "yum" to be associated with not a map but rather a
list of pairs (2-element lists)?


Yes, that _kind_ of thing. But I don't see much point in having an 
AWS::CloudFormation::Init section that isn't compatible with 
CloudFormation's definition of it. We already have some native 
in-instance tools (e.g. os-apply-config) that can probably handle this 
better.


FWIW, in the short term I'm not aware of any issue with installing 
mariadb in Fedora 17/18, provided that mysql is not installed first. And 
in fact they're both EOL anyway, so we should probably migrate all the 
templates to Fedora 20 and mariadb.


cheers,
Zane.

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

Re: [openstack-dev] Vagrant Devstack projects - time to consolidate?

[Joe Gordon]

On Fri, Apr 11, 2014 at 11:24 AM, Sean Dague  wrote:

> On 04/11/2014 11:38 AM, Greg Lucas wrote:
> > Sean Dague wrote:
> >> Maybe it would be good to get an ad-hoc IRC meeting together to figure
> >> out what the must have features are that inspired everyone to write
> >> these. If we can come up with a way to overlap those all sanely, moving
> >> to stackforge and doing this via gerrit would be something I'd be into.
> >
> > This is a good idea, I've definitely stumbled across lots of GitHub
> > projects, blog posts, etc that overlap here.
> >
> > Folks seem to have a strong preference for provisioner so it may makes
> > sense to support several. We can put together a Vagrantfile that allows
> > you to choose a provisioner while maintaining a common machine
> > configuration (using --provision-with or using env variables and loading
> > in additional rb files, etc).
>
> Honestly, multi provisioner support is something I think shouldn't be
> done. That's realistically where I become uninterested in spending
> effort here. Puppet is needed if we want to be able to replicate
> devstack-gate locally (which is one of the reasons I started writing this).
>
> Being opinionated is good when it comes to providing tools to make
> things easy to onboard people. The provisioner in infra is puppet.
> Learning puppet lets you contribute to the rest of the openstack infra,
> and I expect to consume some piece of that in this process. I get that
> leaves other efforts out in the cold, but the tradeoff in the other
> direction I don't think is worth it.
>
> The place I think plugability makes sense is in virt backends. I'd
> honestly love to be able to do nested kvm for performance reasons, or an
> openstack cloud for dogfooding reasons.
>


I originally cobbled together  https://github.com/jogo/DevstackUp  to run
devstack locally as there were no good alternatives at the time.  I would
be really happy to see a vagrant devstack runner that looks more like how
infra does it.

One of my biggest issues with running devstack in vagrant is how slow it is
to set everything up, there are a lot of packages to install. Hopefully
with one consolidated devstack vagrant we can address this.


On a related note, I have stopped using vagrant and just use nova on a
public cloud.


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

[openstack-dev] [Ceilometer] Icehouse RC3 available

[Thierry Carrez]

Hello everyone,

One misnamed meter was discovered in Ceilometer release candidate
testing. Rather than having to support this misnamed meter in the
Icehouse final release, we decided to respin a new release candidate to
include the renamed meter in the final Icehouse release. You can find a
link to the bug and the RC3 source tarball at:

https://launchpad.net/ceilometer/icehouse/icehouse-rc3

Unless release-critical regressions are found that warrant a new
release candidate respin, this RC3 will be formally released as part of
the 2014.1 final version on Thursday. Last minute testing is therefore
strongly encouraged on this tarball !

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/ceilometer/tree/milestone-proposed

If you find an issue that could be considered release-critical and
justify a release candidate respin, please file it at:

https://bugs.launchpad.net/ceilometer/+filebug

and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.

Regards,

-- 
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] Vagrant Devstack projects - time to consolidate?

[Joe Gordon]

On Fri, Apr 11, 2014 at 8:40 AM, Anne Gentle  wrote:

> I'd love to see consolidation as I've tried to keep up nova dev docs for
> example, and with all the options it's tough to test and maintain one for
> docs. Go for it.
>

Nova isn't the only project that uses devstack, so shouldn't docs on how to
set up devstack live at http://devstack.org/ or where ever the official
docs for devstack are?


>
>
> On Fri, Apr 11, 2014 at 9:34 AM, Collins, Sean <
> sean_colli...@cable.comcast.com> wrote:
>
>> Hi,
>>
>> I've noticed a proliferation of Vagrant projects that are popping up, is
>> there any interest from other authors in trying to consolidate?
>>
>> https://github.com/bcwaldon/vagrant_devstack
>>
>> https://github.com/sdague/devstack-vagrant
>>
>> http://openstack.prov12n.com/how-to-make-a-lot-of-devstack-with-vagrant/
>>
>> https://github.com/jogo/DevstackUp
>>
>> https://github.com/search?q=vagrant+devstack&ref=cmdform
>>
>> --
>> Sean M. Collins
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Thoughts from the PTL

[Michael Still]

On Mon, Apr 14, 2014 at 7:06 PM, Stefano Maffulli  wrote:
> On 04/14/2014 06:58 AM, Michael Still wrote:
>> First off, thanks for electing me as the Nova PTL for Juno.
>
> Congratulations Michael.
>
>> * I promised to look at mentoring newcomers. The first step there is
>> working out how to identify what newcomers to mentor, and who mentors
>> them.
>
> I'm very interested in the mentoring topic, too. As many may know, the
> Foundation will host an Upstream Training session in Atlanta. This is
> first attempt at formalizing the process to become a *good* contributor
> to OpenStack. Mentorship is a crucial part of that training, which is
> made of in-person classes and online mentorship (before and after the
> in-person training).
>
> OpenStack project has also two other programs where mentorship is
> crucial: Outreach Program for Women (it's been running for almost 2
> years now) and we added also Google Summer of Code. Mentoring is now
> becoming "a thing we do" among the other things we do.
>
> I think the easy "targets" to mentor are Upstream students, OPW and GSoC
> candidates.  I'd be happy to have a session at the summit about this.

Sounds good to me. The goal here from the nova side is to have nova be
a fun project to contribute to so that we don't shed the developers we
need to sustain our growth over time. Adding new developers is
important because people do leave nova in a natural process of moving
onto other problems, so we need to be growing new developers to
replace attrition.

I'm intending to drop in on the Upstream University stuff happening
the weekend before the summit and see if there's any way I can help.

Cheers,
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] [tripleo] /bin/bash vs. /bin/sh

[Ben Nemec]

On 04/15/2014 02:44 PM, Clint Byrum wrote:

Excerpts from Ben Nemec's message of 2014-04-14 09:26:17 -0700:

tldr: I propose we use bash explicitly for all diskimage-builder scripts
(at least for the short-term - see details below).

This is something that was raised on my linting changes to enable set -o
pipefail.  That is a bash-ism, so it could break in the
diskimage-builder scripts that are run using /bin/sh.  Two possible
fixes for that: switch to /bin/bash, or don't use -o pipefail



What about this:

if ! [ "$SHEBANG" = "#!/bin/bash" ] ; then
   report_warning Non bash shebang, skipping script lint
fi


I was thinking along the same lines, although at least for the moment I 
would like to leave the +x check enabled for all shebangs since it still 
doesn't make sense to have a shebang without +x.





But I think this raises a bigger question - does diskimage-builder
require bash?  If so, I think we should just add a rule to enforce that
/bin/bash is the shell used for everything.  I know we have a bunch of
bash-isms in the code already, so at least in the short-term I think
this is probably the way to go, so we can get the benefits of things
like -o pipefail and lose the ambiguity we have right now.  For
reference, a quick grep of the diskimage-builder source shows we have
150 scripts using bash explicitly and only 24 that are plain sh, so
making the code truly shell-agnostic is likely to be a significant
amount of work.


Yes, diskimage-builder is bash, not posix shell. We're not masochists.
;)



In the long run it might be nice to have cross-shell compatibility, but
if we're going to do that I think we need a couple of things: 1) Someone
to do the work (I don't have a particular need to run dib in not-bash,
so I'm not signing up for that :-) 2) Testing in other shells -
obviously just changing /bin/bash to /bin/sh doesn't mean we actually
support anything but bash.  We really need to be gating on other shells
if we're going to make a significant effort to support them.  It's not
good to ask reviewers to try to catch every bash-ism proposed in a
change.  This also relates to some of the unit testing work that is
going on right now too - if we had better unit test coverage of the
scripts we would be able to do this more easily.



I suggest that diskimage-builder's included elements should be /bin/bash
only. When we have an element linting tool, non bash shebangs should be
warnings we should enforce "no warnings". For t-i-e, we can strive for
no warnings, but that would be a stretch goal and may involve refining
the warnings.


This doesn't seem to be a problem in dib - almost everything was 
explicitly bash already, and the scripts that weren't are pretty trivial.


The ramdisk init script remains a thorn in my side for this though - 
based on our conversation last Friday we don't want that to have the 
same set -eu behavior as the other scripts (since init failing causes a 
kernel panic), and based on Chris's comment in 
http://lists.openstack.org/pipermail/openstack-dev/2014-April/032753.html we 
don't even want that to be explicitly a bash script, except that it is 
today.  So I think we need an exception mechanism like the pep8 #noqa 
tag (or something similar) to note that init should basically be ignored 
by the lint checks since it needs to violate most of the current ones.


For the moment, I'm thinking I'll silently ignore /bin/sh scripts, 
convert init to be one of those, and work on the warning/exception 
mechanism in the future.


-Ben

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

Re: [openstack-dev] [TripleO][design] review based conceptual design process

[Jay Dobies]

+1, I think it's a better medium for conversations than blueprints or wikis.

I'm also +1 to a tripleo-specs repo, but that's less me having a problem 
with using incubator and more my OCD.


On 04/15/2014 03:43 PM, Monty Taylor wrote:

On 04/15/2014 11:44 AM, Robert Collins wrote:

I've been watching the nova process, and I think its working out well
- it certainly addresses:
  - making design work visible
  - being able to tell who has had input
  - and providing clear feedback to the designers

I'd like to do the same thing for TripleO this cycle..


++


I'm thinking we can just add docs to incubator, since thats already a
repository separate to our production code - what do folk think?


In the current nova-specs thread on the ML, Tim Bell says:

"I think that there is also a need to verify the user story aspect. One
of the great things with the ability to subscribe to nova-specs is that
the community can give input early, when we can check on the need and
the approach. I know from the CERN team how the requirements need to be
reviewed early, not after the code has been written."

Which is great. I'm mentioning it because he calls out the ability to
subscribe to nova-specs.

I think if you put them in incubator, then people who are wanting to
fill a role like Tim - subscribing as an operator and validating user
stories - might be a bit muddied by patches to other thigns. (although
thanks for having a thought about less repos :) )

So I'd just vote, for whatever my vote is worth, for a tripleo-specs repo.

Monty

___
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] Meeting Tuesday April 15th at 19:00 UTC

[Elizabeth Krumbach Joseph]

On Mon, Apr 14, 2014 at 8:02 AM, Elizabeth Krumbach Joseph
 wrote:
> Hi everyone,
>
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting tomorrow, Tuesday April 15th, at 19:00 UTC in
> #openstack-meeting

Meeting logs and minutes:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-04-15-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-04-15-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-04-15-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

Re: [openstack-dev] [heat] computed package names?

[Mike Spreitzer]

Zane Bitter  wrote on 04/15/2014 03:29:03 PM:

> On 15/04/14 14:31, Mike Spreitzer wrote:
> > It appears that in Fedora 19 and 20 the Wordpress examples need to
> > install different packages than in every other release (see my 
debugging
> > in https://review.openstack.org/#/c/87065/).  I just got a complaint
> > from Heat validation that I can't do this:
> >
> >  "AWS::CloudFormation::Init" : {
> >"config" : {
> >  "packages" : {
> >"yum" : {
> > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "client" ] 
}
> > : [],
> > { "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
> > "Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "server" ] 
}
> > : [],
> >
> 
> .. in 
> JSON a property name cannot be an object ...

Ah, right.  So what would be the simplest way to enable this use case? 
Perhaps a generalization of AWS::CloudFormation::Init that allows the 
package names to be objects (that evaluate to strings, of course)?  Maybe 
allow, e.g., "yum" to be associated with not a map but rather a list of 
pairs (2-element lists)?

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

Re: [openstack-dev] [TripleO][design] review based conceptual design process

[Ben Nemec]

On 04/15/2014 01:44 PM, Robert Collins wrote:

I've been watching the nova process, and I think its working out well
- it certainly addresses:
  - making design work visible
  - being able to tell who has had input
  - and providing clear feedback to the designers

I'd like to do the same thing for TripleO this cycle..

I'm thinking we can just add docs to incubator, since thats already a
repository separate to our production code - what do folk think?

-Rob



+1 from me.  We've also been planning to adopt this for Oslo.

For anyone who hasn't been following the Nova discussion, here's a link 
to the original proposal: 
http://lists.openstack.org/pipermail/openstack-dev/2014-March/029232.html


There's also the more recent thread Monty referenced: 
http://lists.openstack.org/pipermail/openstack-dev/2014-April/032753.html


-Ben

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

Re: [openstack-dev] nova-specs

[Matt Van Winkle]

Exactly.  Even if operators/users only comment with a +0, it's already
flushed out a lot of good details on several blueprints.

Thanks!
Matt


On 4/15/14 2:38 PM, "Tim Bell"  wrote:

>
>+2
>
>I think that there is also a need to verify the user story aspect. One of
>the great things with the ability to subscribe to nova-specs is that the
>community can give input early, when we can check on the need and the
>approach. I know from the CERN team how the requirements need to be
>reviewed early, not after the code has been written.
>
>Tim
>
>-Original Message-
>From: Solly Ross [mailto:sr...@redhat.com]
>Sent: 15 April 2014 21:16
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Nova] nova-specs
>
>Just wanted to confirm what Sean said -- as someone who just joined the
>OpenStack community last year, going to implement a vaguely worded
>blueprint and then having the code review be derailed with people saying
>"well, you probably should be using this completely different design" is
>fairly frustrating.  While you come to anticipate certain changes, IMHO
>it's definitely much better to decide on the design *before* you start
>coding, that way code reviews can focus on the code, and you don't have
>to completely rewrite patches as much.
>
>Best Regards,
>Solly Ross
>
>- Original Message -
>From: "Sean Dague" 
>To: openstack-dev@lists.openstack.org
>Sent: Tuesday, April 15, 2014 1:45:16 PM
>Subject: Re: [openstack-dev] [Nova] nova-specs
>
>On 04/15/2014 11:42 AM, Russell Bryant wrote:
>> On 04/15/2014 11:01 AM, Brian Elliott wrote:
 * specs review. The new blueprint process is a work of genius, and I
 think its already working better than what we've had in previous
 releases. However, there are a lot of blueprints there in review,
 and we need to focus on making sure these get looked at sooner
 rather than later. I'd especially like to encourage operators to
 take a look at blueprints relevant to their interests. Phil Day from
 HP has been doing a really good job at this, and I'd like to see more
of it.
>>>
>>> I have mixed feelings about the nova-specs repo.  I dig the open
>>>collaboration of the blueprints process, but I also think there is a
>>>danger of getting too process-oriented here.  Are these design
>>>documents expected to call out every detail of a feature?  Ideally, I¹d
>>>like to see only very high level documentation in the specs repo.
>>>Basically, the spec could include just enough detail for people to
>>>agree that they think a feature is worth inclusion.  More detailed
>>>discussion could remain on the code reviews since they are the actual
>>>end work product.
>> 
>> There is a balance to be found here.  The benefit of doing more review
>> earlier is to change direction as necessary when it's *much* easier to
>> do so.  It's a lot more time consuming to do re-work after code has
>> been written, than re-work in a spec.
>> 
>> Yes, it's more up front work, but I think it will speed up the process
>> overall.  It means we're much more in agreement and on the same page
>> before code even shows up.  That's huge.
>> 
>> One of the big problems we've had in code review is the amount of
>> churn and re-work required.  That is killing our throughput in code
>>review.
>> If we can do more up front work that will reduce re-work later, it's
>> going to be a *huge* help to our primary project bottleneck: the code
>> review queue.
>
>I think the previous process is a huge demotivator to contributors, when
>they file a blueprint with minimal info, it gets approved, they spend
>months working on it, and only at the end of the process does the idea
>get dug into enough for people to realize that it's not what anyone wants.
>
>At that point people are so invested in the time they spent on this
>feature that turning that conversation productive is really hard.
>
>Catching more of these up front and being more explicit about what Nova
>wants in a cycle is goodness.
>
>   -Sean
>
>--
>Sean Dague
>Samsung Research America
>s...@dague.net / sean.da...@samsung.com
>http://dague.net
>
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh

[Clint Byrum]

Excerpts from Ghe Rivero's message of 2014-04-15 04:31:19 -0700:
> +1 to use bash as the default shell. So far, all major distros use bash
> as the default one (except Debian which uses dash).
> An about rewriting the code in Python, I agree that shell is complicated
> for large programs, but writing anything command oriented in other than
> shell is a nightmare. But there are some parts that can benefit from that.
> 

Side note, Ubuntu uses dash as /bin/sh.

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

Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh

[Clint Byrum]

Excerpts from Ben Nemec's message of 2014-04-14 09:26:17 -0700:
> tldr: I propose we use bash explicitly for all diskimage-builder scripts 
> (at least for the short-term - see details below).
> 
> This is something that was raised on my linting changes to enable set -o 
> pipefail.  That is a bash-ism, so it could break in the 
> diskimage-builder scripts that are run using /bin/sh.  Two possible 
> fixes for that: switch to /bin/bash, or don't use -o pipefail
>

What about this:

if ! [ "$SHEBANG" = "#!/bin/bash" ] ; then
  report_warning Non bash shebang, skipping script lint
fi

> But I think this raises a bigger question - does diskimage-builder 
> require bash?  If so, I think we should just add a rule to enforce that 
> /bin/bash is the shell used for everything.  I know we have a bunch of 
> bash-isms in the code already, so at least in the short-term I think 
> this is probably the way to go, so we can get the benefits of things 
> like -o pipefail and lose the ambiguity we have right now.  For 
> reference, a quick grep of the diskimage-builder source shows we have 
> 150 scripts using bash explicitly and only 24 that are plain sh, so 
> making the code truly shell-agnostic is likely to be a significant 
> amount of work.

Yes, diskimage-builder is bash, not posix shell. We're not masochists.
;)

> 
> In the long run it might be nice to have cross-shell compatibility, but 
> if we're going to do that I think we need a couple of things: 1) Someone 
> to do the work (I don't have a particular need to run dib in not-bash, 
> so I'm not signing up for that :-) 2) Testing in other shells - 
> obviously just changing /bin/bash to /bin/sh doesn't mean we actually 
> support anything but bash.  We really need to be gating on other shells 
> if we're going to make a significant effort to support them.  It's not 
> good to ask reviewers to try to catch every bash-ism proposed in a 
> change.  This also relates to some of the unit testing work that is 
> going on right now too - if we had better unit test coverage of the 
> scripts we would be able to do this more easily.
>

I suggest that diskimage-builder's included elements should be /bin/bash
only. When we have an element linting tool, non bash shebangs should be
warnings we should enforce "no warnings". For t-i-e, we can strive for
no warnings, but that would be a stretch goal and may involve refining
the warnings.

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

Re: [openstack-dev] [TripleO][design] review based conceptual design process

[Monty Taylor]

On 04/15/2014 11:44 AM, Robert Collins wrote:

I've been watching the nova process, and I think its working out well
- it certainly addresses:
  - making design work visible
  - being able to tell who has had input
  - and providing clear feedback to the designers

I'd like to do the same thing for TripleO this cycle..


++


I'm thinking we can just add docs to incubator, since thats already a
repository separate to our production code - what do folk think?


In the current nova-specs thread on the ML, Tim Bell says:

"I think that there is also a need to verify the user story aspect. One 
of the great things with the ability to subscribe to nova-specs is that 
the community can give input early, when we can check on the need and 
the approach. I know from the CERN team how the requirements need to be 
reviewed early, not after the code has been written."


Which is great. I'm mentioning it because he calls out the ability to 
subscribe to nova-specs.


I think if you put them in incubator, then people who are wanting to 
fill a role like Tim - subscribing as an operator and validating user 
stories - might be a bit muddied by patches to other thigns. (although 
thanks for having a thought about less repos :) )


So I'd just vote, for whatever my vote is worth, for a tripleo-specs repo.

Monty

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

Re: [openstack-dev] nova-specs

[Tim Bell]

+2

I think that there is also a need to verify the user story aspect. One of the 
great things with the ability to subscribe to nova-specs is that the community 
can give input early, when we can check on the need and the approach. I know 
from the CERN team how the requirements need to be reviewed early, not after 
the code has been written.

Tim

-Original Message-
From: Solly Ross [mailto:sr...@redhat.com] 
Sent: 15 April 2014 21:16
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] nova-specs

Just wanted to confirm what Sean said -- as someone who just joined the 
OpenStack community last year, going to implement a vaguely worded blueprint 
and then having the code review be derailed with people saying "well, you 
probably should be using this completely different design" is fairly 
frustrating.  While you come to anticipate certain changes, IMHO it's 
definitely much better to decide on the design *before* you start coding, that 
way code reviews can focus on the code, and you don't have to completely 
rewrite patches as much.

Best Regards,
Solly Ross

- Original Message -
From: "Sean Dague" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, April 15, 2014 1:45:16 PM
Subject: Re: [openstack-dev] [Nova] nova-specs

On 04/15/2014 11:42 AM, Russell Bryant wrote:
> On 04/15/2014 11:01 AM, Brian Elliott wrote:
>>> * specs review. The new blueprint process is a work of genius, and I 
>>> think its already working better than what we've had in previous 
>>> releases. However, there are a lot of blueprints there in review, 
>>> and we need to focus on making sure these get looked at sooner 
>>> rather than later. I'd especially like to encourage operators to 
>>> take a look at blueprints relevant to their interests. Phil Day from 
>>> HP has been doing a really good job at this, and I'd like to see more of it.
>>
>> I have mixed feelings about the nova-specs repo.  I dig the open 
>> collaboration of the blueprints process, but I also think there is a danger 
>> of getting too process-oriented here.  Are these design documents expected 
>> to call out every detail of a feature?  Ideally, I’d like to see only very 
>> high level documentation in the specs repo.  Basically, the spec could 
>> include just enough detail for people to agree that they think a feature is 
>> worth inclusion.  More detailed discussion could remain on the code reviews 
>> since they are the actual end work product.
> 
> There is a balance to be found here.  The benefit of doing more review 
> earlier is to change direction as necessary when it's *much* easier to 
> do so.  It's a lot more time consuming to do re-work after code has 
> been written, than re-work in a spec.
> 
> Yes, it's more up front work, but I think it will speed up the process 
> overall.  It means we're much more in agreement and on the same page 
> before code even shows up.  That's huge.
> 
> One of the big problems we've had in code review is the amount of 
> churn and re-work required.  That is killing our throughput in code review.
> If we can do more up front work that will reduce re-work later, it's 
> going to be a *huge* help to our primary project bottleneck: the code 
> review queue.

I think the previous process is a huge demotivator to contributors, when they 
file a blueprint with minimal info, it gets approved, they spend months working 
on it, and only at the end of the process does the idea get dug into enough for 
people to realize that it's not what anyone wants.

At that point people are so invested in the time they spent on this feature 
that turning that conversation productive is really hard.

Catching more of these up front and being more explicit about what Nova wants 
in a cycle is goodness.

-Sean

--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net


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

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

Re: [openstack-dev] [heat] computed package names?

[Zane Bitter]

On 15/04/14 14:31, Mike Spreitzer wrote:

It appears that in Fedora 19 and 20 the Wordpress examples need to
install different packages than in every other release (see my debugging
in https://review.openstack.org/#/c/87065/).  I just got a complaint
from Heat validation that I can't do this:

 "AWS::CloudFormation::Init" : {
   "config" : {
 "packages" : {
   "yum" : {
{ "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
"Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "client" ] }
: [],
{ "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [
"Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "server" ] }
: [],

because "expecting property name" at the place where the first {
"Fn::FindInMap" ... } appears.  Am I understanding this right?  Is there
a workable way to solve this problem?


The formatting of that config section is somewhat bizarre, and 
unfortunately leaves no workable way to solve this problem because in 
JSON a property name cannot be an object just as in Python a dict key 
cannot be a dict.


cheers,
Zane.

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

Re: [openstack-dev] [Nova] nova-specs

[Solly Ross]

Just wanted to confirm what Sean said -- as someone who just joined the 
OpenStack community last
year, going to implement a vaguely worded blueprint and then having the code 
review be derailed
with people saying "well, you probably should be using this completely 
different design" is fairly
frustrating.  While you come to anticipate certain changes, IMHO it's 
definitely much better to decide
on the design *before* you start coding, that way code reviews can focus on the 
code, and you don't have
to completely rewrite patches as much.

Best Regards,
Solly Ross

- Original Message -
From: "Sean Dague" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, April 15, 2014 1:45:16 PM
Subject: Re: [openstack-dev] [Nova] nova-specs

On 04/15/2014 11:42 AM, Russell Bryant wrote:
> On 04/15/2014 11:01 AM, Brian Elliott wrote:
>>> * specs review. The new blueprint process is a work of genius, and I
>>> think its already working better than what we've had in previous
>>> releases. However, there are a lot of blueprints there in review, and
>>> we need to focus on making sure these get looked at sooner rather than
>>> later. I'd especially like to encourage operators to take a look at
>>> blueprints relevant to their interests. Phil Day from HP has been
>>> doing a really good job at this, and I'd like to see more of it.
>>
>> I have mixed feelings about the nova-specs repo.  I dig the open 
>> collaboration of the blueprints process, but I also think there is a danger 
>> of getting too process-oriented here.  Are these design documents expected 
>> to call out every detail of a feature?  Ideally, I’d like to see only very 
>> high level documentation in the specs repo.  Basically, the spec could 
>> include just enough detail for people to agree that they think a feature is 
>> worth inclusion.  More detailed discussion could remain on the code reviews 
>> since they are the actual end work product.
> 
> There is a balance to be found here.  The benefit of doing more review
> earlier is to change direction as necessary when it's *much* easier to
> do so.  It's a lot more time consuming to do re-work after code has been
> written, than re-work in a spec.
> 
> Yes, it's more up front work, but I think it will speed up the process
> overall.  It means we're much more in agreement and on the same page
> before code even shows up.  That's huge.
> 
> One of the big problems we've had in code review is the amount of churn
> and re-work required.  That is killing our throughput in code review.
> If we can do more up front work that will reduce re-work later, it's
> going to be a *huge* help to our primary project bottleneck: the code
> review queue.

I think the previous process is a huge demotivator to contributors, when
they file a blueprint with minimal info, it gets approved, they spend
months working on it, and only at the end of the process does the idea
get dug into enough for people to realize that it's not what anyone wants.

At that point people are so invested in the time they spent on this
feature that turning that conversation productive is really hard.

Catching more of these up front and being more explicit about what Nova
wants in a cycle is goodness.

-Sean

-- 
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net


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

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

Re: [openstack-dev] [neutron][chaining][policy] Port-oriented Network service chaining

[Carlos Gonçalves]

Hi Kanzhe,

First off, thank you for showing interest in discussing this proposal!

I’m not fully sure if I understood your point. Could you elaborate a bit more 
on the L1, L2, L3 part?

Regarding the traffic steering API, as I see it the Neutron port is the virtual 
counterpart of the network interface and would allow L1, L2 and L3 steering 
within OpenStack.  Within a single OpenStack deployment I think the Neutron 
port abstraction might be enough. Nevertheless in the API data model proposal 
we have the service function end
point abstraction which can (eventually) be mapped to something else than a 
Neutron port (e.g., remote IP).

Thanks,
Carlos Goncalves

On 15 Apr 2014, at 02:07, Kanzhe Jiang  wrote:

> Hi Carlos,
> 
> This is Kanzhe. We discussed your port-based SFC on the Neutron advanced 
> service IRC.
> I would like to reach out to you to discuss a bit more.
> 
> As you know, Neutron port is a logic abstraction for network interfaces with 
> a MAC and IP address. However, network services could be used at different 
> layers, L3, L2, or L1. In L3 case, each service interface could be easily 
> mapped to a Neutron port. However, in the other two cases, there won't be a 
> corresponding Neutron port. In your proposal, you mentioned DPI service. What 
> is your thought?
> 
> Neutron doesn't have traffic steering API. Is Neutron port the right 
> abstraction to introduce traffic steering API? Or May Neutron need separate 
> abstraction for such?
> 
> Love to discuss more!
> Kanzhe
> 
> 
> On Tue, Mar 25, 2014 at 3:59 PM, Carlos Gonçalves  wrote:
> Hi,
> 
> Most of the advanced services and group policy sub-team members who attended 
> last week’s meeting should remember I promised to start a drafting proposal 
> regarding network service chaining. This week I got to start writing a 
> document which is accessible here: 
> https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU
> 
> It should not be considered a formal blueprint as it yet requires large 
> discussion from the community wrt the validation (or sanity if you will) of 
> the proposed idea.
> 
> I will be joining the advanced service IRC meeting tomorrow, and the group 
> policy IRC meeting thursday, making myself available to answer any questions 
> you may have. In the meantime you can also start discussing in this email 
> thread or commenting in the document.
> 
> Thanks,
> Carlos Goncalves
> 
> 
> ___
> 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] TC candidacy

[Tristan Cacqueray]

confirmed

On 04/15/2014 08:45 PM, Vishvananda Ishaya wrote:
> Hello all,
> 
> I’d like to announce my candidacy for the Technical Committee election.
> 
> I was one of the original authors of the Nova project and served as
> its PTL for the first two years that the position existed. I have also
> been on the Technical Comittee since its inception. I was also recently
> elected to the OpenStack Board. In my day job I am  the Chief Technical
> Officer for Nebula, a startup focused on bringing OpenStack to the
> Enterprise.
> 
> My role in OpenStack has changed over time from being one of the top
> code contributors to more leadership and planning. I helped start both
> Cinder and Devstack. I’m on the stable-backports committee, and I’m
> currently working on an effort to bring Hierarchical Multitenancy to
> all of the OpenStack Projects. I also spend a lot of my time dealing
> with my companies customers, which are real operators and users of
> OpenStack.
> 
> I think there are two major governance issues that need to be addressed
> in OpenStack. We’ve started having these discussions in both the Board
> and the Technical Committee, but some more effort is needed to drive
> them home.
> 
> 1. Stop the kitchen-sink approach. We are adding new projects like mad
> and in order to keep the quality of the integrated release high, we have
> to raise the bar to be come integrated. We made some changes over the
> past few months here.
> 2. Better product management. This was a topic of discussion at the
> last board meeting and one we hope to continue at the joint meeting in
> Atlanta. We have a bit of a whole across openstack that is filled in
> most organizations by a product management team. We need to be more
> conscious of release quality and addressing customer issues. It isn’t
> exactly clear how something like this should happen in Open Source,
> but it is something we should try to address.
> 
> I hope to be able to continue to address these issues on the Technical
> Committee and provide some much-needed understanding from the “old-days”
> of OpenStack. It is often helpful to know where you came from in order
> see the best direction to go next.
> 
> Thanks,
> Vish Ishaya
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




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

Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh

[Chmouel Boudjnah]

FWIW: we are using bash in devstack if we were going to try to make it
POSIX bourne shell (or whatever /bin/sh is) it would have been a huge pain.


On Tue, Apr 15, 2014 at 1:25 PM, Dougal Matthews  wrote:

> Another +1 for using bash. Sounds like an easy win.
>
>
> On 15/04/14 12:31, Ghe Rivero wrote:
>
>> +1 to use bash as the default shell. So far, all major distros use bash
>> as the default one (except Debian which uses dash).
>> An about rewriting the code in Python, I agree that shell is complicated
>> for large programs, but writing anything command oriented in other than
>> shell is a nightmare. But there are some parts that can benefit from that.
>>
>> Ghe Rivero
>>
>> On 04/15/2014 11:05 AM, Chris Jones wrote:
>>
>>> Hi
>>>
>>> On 15 April 2014 09:14, Daniel P. Berrange >> > wrote:
>>>
>>> I supose that rewriting the code to be in Python is out of the
>>> question ?  IMHO shell is just a terrible language for doing any
>>> program that is remotely complicated (ie longer than 10 lines of
>>>
>>>
>>> I don't think it's out of the question - where something makes sense
>>> to switch to Python, that would seem like a worthwhile thing to be
>>> doing. I do think it's a different question though - we can quickly
>>> flip things from /bin/sh to /bin/bash without affecting their
>>> suitability for replacement with python.
>>>
>>> --
>>> Cheers,
>>>
>>> Chris
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] TC candidacy

[Vishvananda Ishaya]

Hello all,

I’d like to announce my candidacy for the Technical Committee election.

I was one of the original authors of the Nova project and served as
its PTL for the first two years that the position existed. I have also
been on the Technical Comittee since its inception. I was also recently
elected to the OpenStack Board. In my day job I am  the Chief Technical
Officer for Nebula, a startup focused on bringing OpenStack to the
Enterprise.

My role in OpenStack has changed over time from being one of the top
code contributors to more leadership and planning. I helped start both
Cinder and Devstack. I’m on the stable-backports committee, and I’m
currently working on an effort to bring Hierarchical Multitenancy to
all of the OpenStack Projects. I also spend a lot of my time dealing
with my companies customers, which are real operators and users of
OpenStack.

I think there are two major governance issues that need to be addressed
in OpenStack. We’ve started having these discussions in both the Board
and the Technical Committee, but some more effort is needed to drive
them home.

1. Stop the kitchen-sink approach. We are adding new projects like mad
and in order to keep the quality of the integrated release high, we have
to raise the bar to be come integrated. We made some changes over the
past few months here.
2. Better product management. This was a topic of discussion at the
last board meeting and one we hope to continue at the joint meeting in
Atlanta. We have a bit of a whole across openstack that is filled in
most organizations by a product management team. We need to be more
conscious of release quality and addressing customer issues. It isn’t
exactly clear how something like this should happen in Open Source,
but it is something we should try to address.

I hope to be able to continue to address these issues on the Technical
Committee and provide some much-needed understanding from the “old-days”
of OpenStack. It is often helpful to know where you came from in order
see the best direction to go next.

Thanks,
Vish Ishaya


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

[openstack-dev] [TripleO][design] review based conceptual design process

[Robert Collins]

I've been watching the nova process, and I think its working out well
- it certainly addresses:
 - making design work visible
 - being able to tell who has had input
 - and providing clear feedback to the designers

I'd like to do the same thing for TripleO this cycle..

I'm thinking we can just add docs to incubator, since thats already a
repository separate to our production code - what do folk think?

-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] [heat] computed package names?

[Mike Spreitzer]

It appears that in Fedora 19 and 20 the Wordpress examples need to install 
different packages than in every other release (see my debugging in 
https://review.openstack.org/#/c/87065/).  I just got a complaint from 
Heat validation that I can't do this:

"AWS::CloudFormation::Init" : {
  "config" : {
"packages" : {
  "yum" : {
{ "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [ 
"Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "client" ] } : 
[],
{ "Fn::FindInMap" : [ "Pkgset2Pkgs", { "Fn::FindInMap" : [ 
"Distro2Pkgset", { "Ref" : "LinuxDistribution" }, "db" ] }, "server" ] } : 
[],

because "expecting property name" at the place where the first { 
"Fn::FindInMap" ... } appears.  Am I understanding this right?  Is there a 
workable way to solve this problem?

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

[openstack-dev] [infra] Basic zuul startup question: "Private key file is encrypted"

[Dane Leblanc (leblancd)]

I'm trying to modify a 3rd party test setup to use zuul, but I'm seeing the 
following error when I start up the zuul server:

===
2014-04-15 09:09:18,910 ERROR gerrit.GerritWatcher: Exception on ssh event 
stream:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/zuul/lib/gerrit.py", line 64, in 
_run
key_filename=self.keyfile)
  File "/usr/local/lib/python2.7/dist-packages/paramiko/client.py", line 342, 
in connect
self._auth(username, password, pkey, key_filenames, allow_agent, 
look_for_keys)
  File "/usr/local/lib/python2.7/dist-packages/paramiko/client.py", line 533, 
in _auth
raise saved_exception
PasswordRequiredException: Private key file is encrypted
===

Here is my zuul config file (/etc/zuul/zuul.conf):

===
[gearman]
server=127.0.0.1

[gearman_server]
start=true
log_config=/etc/zuul/gearman-logging.conf

[gerrit]
server=review.openstack.org
user=zuul
sshkey=/var/lib/zuul/.ssh/id_rsa
#user=jenkins
#sshkey=/var/lib/jenkins/.ssh/id_rsa
#user=cisco_neutron_ci
#sshkey=/home/cisco_neutron_ci/.ssh/id_rsa

[zuul]
layout_config=/etc/zuul/layout.yaml
log_config=/etc/zuul/logging.conf
state_dir=/var/lib/zuul
git_dir=/var/lib/zuul/git
push_change_refs=false
url_pattern=http://128.107.233.28:8080/job/(job.name)/(build.number)
status_url=http://status.openstack.org/zuul/
job_name_in_report=true
zuul_url=https://review.openstack.org
===

I've tried using various users for the zuul-to-gerrit connection (zuul, 
jenkins, and our corporate gerrit account username).

Is there something basic that I'm missing in the config?

Appreciate any help,
Dane

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

Re: [openstack-dev] [Nova] nova-specs

[Sean Dague]

On 04/15/2014 11:42 AM, Russell Bryant wrote:
> On 04/15/2014 11:01 AM, Brian Elliott wrote:
>>> * specs review. The new blueprint process is a work of genius, and I
>>> think its already working better than what we've had in previous
>>> releases. However, there are a lot of blueprints there in review, and
>>> we need to focus on making sure these get looked at sooner rather than
>>> later. I'd especially like to encourage operators to take a look at
>>> blueprints relevant to their interests. Phil Day from HP has been
>>> doing a really good job at this, and I'd like to see more of it.
>>
>> I have mixed feelings about the nova-specs repo.  I dig the open 
>> collaboration of the blueprints process, but I also think there is a danger 
>> of getting too process-oriented here.  Are these design documents expected 
>> to call out every detail of a feature?  Ideally, I’d like to see only very 
>> high level documentation in the specs repo.  Basically, the spec could 
>> include just enough detail for people to agree that they think a feature is 
>> worth inclusion.  More detailed discussion could remain on the code reviews 
>> since they are the actual end work product.
> 
> There is a balance to be found here.  The benefit of doing more review
> earlier is to change direction as necessary when it's *much* easier to
> do so.  It's a lot more time consuming to do re-work after code has been
> written, than re-work in a spec.
> 
> Yes, it's more up front work, but I think it will speed up the process
> overall.  It means we're much more in agreement and on the same page
> before code even shows up.  That's huge.
> 
> One of the big problems we've had in code review is the amount of churn
> and re-work required.  That is killing our throughput in code review.
> If we can do more up front work that will reduce re-work later, it's
> going to be a *huge* help to our primary project bottleneck: the code
> review queue.

I think the previous process is a huge demotivator to contributors, when
they file a blueprint with minimal info, it gets approved, they spend
months working on it, and only at the end of the process does the idea
get dug into enough for people to realize that it's not what anyone wants.

At that point people are so invested in the time they spent on this
feature that turning that conversation productive is really hard.

Catching more of these up front and being more explicit about what Nova
wants in a cycle is goodness.

-Sean

-- 
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net



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

Re: [openstack-dev] [Neutron] Migrations, service plugins and Grenade jobs

[Mark McClain]

On Apr 14, 2014, at 11:54 AM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:


1) Specify that all migrations must run for every plugin (*) unless they are 
really introducing schemas which are specific to a particular technology (such 
as uuid mappings between neutron and backed)

This approach will probably ensure all the important migrations are executed.
However, it is not back portable, unless deployers decide to tear down and 
rebuild their databases from scratch, which is unlikely to happen.

To this aim "recovery" scripts might be provided to sync up the schema state of 
specific service plugins with the current alembic migration registered in the 
neutron database; or appropriate migrations can be added in the path to fix 
database schemas.

(*) Neutron does not address, and probably never will address, switching from 
plugin "a" to "b" for a given service (e.g.: core features).

This option has several additional problems because of the way plugins/drivers 
are conditionally imported and packaged.  As a result, auto generation of 
schema (inadvertent drop for schema) or even validation of existing models vs 
the the migration will fail because models are not imported unless part of the 
configuration.

mark

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

Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh

[Dougal Matthews]

Another +1 for using bash. Sounds like an easy win.

On 15/04/14 12:31, Ghe Rivero wrote:

+1 to use bash as the default shell. So far, all major distros use bash
as the default one (except Debian which uses dash).
An about rewriting the code in Python, I agree that shell is complicated
for large programs, but writing anything command oriented in other than
shell is a nightmare. But there are some parts that can benefit from that.

Ghe Rivero

On 04/15/2014 11:05 AM, Chris Jones wrote:

Hi

On 15 April 2014 09:14, Daniel P. Berrange mailto:berra...@redhat.com>> wrote:

I supose that rewriting the code to be in Python is out of the
question ?  IMHO shell is just a terrible language for doing any
program that is remotely complicated (ie longer than 10 lines of


I don't think it's out of the question - where something makes sense
to switch to Python, that would seem like a worthwhile thing to be
doing. I do think it's a different question though - we can quickly
flip things from /bin/sh to /bin/bash without affecting their
suitability for replacement with python.

--
Cheers,

Chris


___
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] [mistral] [taskflow] Mistral TaskFlow integration summary

[Joshua Harlow]

Well Ivan afaik is thinking through it, but being a community project its not 
exactly easy to put estimations or timelines on things (I don't control Ivan, 
or others).

Likely faster if u guys want to get involved.

-Josh

From: Renat Akhmerov mailto:rakhme...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 15, 2014 at 12:35 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [mistral] [taskflow] Mistral TaskFlow integration 
summary


On 15 Apr 2014, at 11:13, Joshua Harlow 
mailto:harlo...@yahoo-inc.com>> wrote:

Sure, its not the fully complete lazy_engine, but piece by piece we can get 
there.

Did you make any estimations when it could happen? :)

Of course code/contributions are welcome, as such things will benefit more than 
just mistral, but openstack as a whole :-)

OK.

From: Kirill Izotov mailto:enyk...@stackstorm.com>>
The whole idea of sub-flows within the scope of direct conditional transitions 
is a bit unclear to me (and probably us all) at the moment, though I'm trying 
to rely on them only as a means to lesser the complexity.

Yes, eventually it’s for reducing complexity. I would just add that it opens 
wide range of opportunities like:

  *   ability to combine multiple physically independent workflows
  *   reusability (using one workflow as a part of another)
  *   isolation (different namespaces for data flow contexts etc)

Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary

[Joshua Harlow]

I think we agree on the lazy execution model. At least at a high-level, I'd 
rather not agree on the API's that are exactly exposed until there is an 
implementation since I've found that agreeing to any type of API's before there 
is the needed groundwork to make it happen is pretty useless and a waste of 
energy on everyones part.

Decider sounds like it could work also as a name, although it seems from 
dataflow like work its called a switch or gate, either or I guess.

As far as the micro-language:

So there are typically 2 types of DSL's that occur, internal and external.

An internal DSL is like http://martinfowler.com/bliki/InternalDslStyle.html, 
taskflow is already a micro-DSL internal to python (mistral is an external 
DSL[1]). To me there is a drawback of becoming to much of a DSL (internal or 
external) in that it requires a lot of new learning (imho internal DSLs are 
easier to pick-up since they take advantage of the surrounding languages 
capabilities, in this case python). So that’s what I just want to keep in our 
minds that we need to make it simple *enough*, or we will die a nasty death of 
complexity :-P

[1] http://martinfowler.com/bliki/DomainSpecificLanguage.html

From: Renat Akhmerov mailto:rakhme...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 15, 2014 at 12:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary

Some notes:

  *   Even though we use YAQL now our design is flexible enough to plug other 
ELs in.
  *   If it tells you something in Amazon SWF a component that makes a decision 
about a further route is called Decider.
  *   This discussion about conditionals is surely important but it doesn’t 
matter too much if we don’t agree on that lazy execution model.

Of course I'm trying to make the above not be its own micro-language as much as 
possible (a switch object starts to act like one, sadly).

Why do you think it’s going to be a micro-language?

[1] http://www.cs.cmu.edu/~aldrich/papers/onward2009-concurrency.pdf
[2] 
http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/DataFlowProgrammingLanguages.pdf

Cool, thanks!

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

[openstack-dev] [Neutron][IPv6] Meeting Minutes

[Collins, Sean]

Meeting minutes:

http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-04-15-14.00.html

See you next week!

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

Re: [openstack-dev] [OpenStack-Infra] [3rd party testing] Atlanta meetup for 3rd party testing?

[Anita Kuno]

On 04/15/2014 12:34 PM, Kurt Taylor wrote:
> 
> Anita Kuno  wrote on 04/15/2014 09:41:17 AM:
>> On 04/15/2014 10:20 AM, Kurt Taylor wrote:
>>>
>>>
>>> Sorry if you get this twice.
>>>
>>> Since summit is approaching quickly, I wanted to see if anyone had
> interest
>>> in forming a meetup for 3rd party testing. This would be a group for
>>> helping the project cores by helping ourselves and hopefully improving
>>> overall CI rollout.
>>>
>>> Some topics to discuss:  I'd at least like to get a standard tag that
> would
>>> help with email filtering, but we could also build a FAQ and
> documentation
>>> contributions to improve the content of the 3rd party testing. We could
>>> also document different use cases and best practices for each on how
>>> different testers solved problems they encountered for their
> environment. I
>>> don't know how long we would be able to meet, so this may just be an
>>> organizational meeting, focusing on how to best share this info.
>>>
>>> I started an etherpad for discussion topics and eventual agenda here:
>>> https://etherpad.openstack.org/p/3rdPartyTesting
>>>
>>> I have not worked out all the details for when and where to meet, but I
>>> would be happy to set it up and facilitate the discussion. I wanted to
> see
>>> if there was any interest before I took it any further.
>>>
>>> Any interest?
> 
>>>
>> There is a summit design session proposed to address this:
>> http://summit.openstack.org/cfp/details/59
>>
>> Entitled: Improving Third Party Testing
>>
>> If you would like to add the information you would like to cover as a
>> comment to the proposal that would help ensure the content gets covered.
> 
> Thanks for your response. I did not know about this and I am glad this is
> proposed. It was my intention originally to propose this type of
> discussion, but after bringing this up in -infra, it was not something the
> team wanted to discuss in a design session. They suggested a BOF or meetup
> at the infra table in developer's lounge. I do not know yet if that
> location is still a possibility or not, as I indicated in my email.
> 
>>
>> Since the purpose of the design summit is to cover material like this, I
>> encourage people to get familiar with the summit sessions that are
>> already proposed: http://summit.openstack.org/ and to propose sessions
>> that you would like covered if you don't see a current proposal for your
>> topic of interest.
>>
>> Since most of what I saw in the Neutron design summit sessions last year
>> is counter to how most other programs use their design summit sessions,
>> I encourage you to consider using the design summit session format.
>> Neutron design summit sessions end up being more like conference
>> presentations and that is not what the design summit was meant to be at
> all.
>>
>> Design summit sessions are meant to be group discussion chaired by
>> either the proposer of the session or someone else but equally discussed
>> by all participants. They are not meant to be a presentation with a
>> passive audience.
> 
> Yes, I am very familiar with UDS-style design summits and have lead several
> design sessions in the past on other projects. I think this is a big factor
> in the enormous success of the OpenStack project.
> 
> There is probably some overlap in the proposed design session and the
> meetup. But, I actually see the meetup as more of a organizational meeting
> to pull together the developers with experience in CI to share ideas and
> how we got past the problems we found.
> 
> Maybe we can wait for the outcome of the session discussion and determine
> next steps after summit?
I can get behind that direction.

Yes it feels like mid-cycle meetups are getting to be more and more
important. Let's bring our ideas to the summit session (hoping it gets a
slot) and continue the discussion afterwards.

Thanks Kurt,
Anita.
> 
> Thanks again!
> 
> Kurt Taylor (krtaylor)
> OpenStack Development Lead - PowerKVM CI
> IBM Linux Technology Center
> 
> 
> 
> ___
> 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] Hyper-V Meeting Minutes

[Joe Gordon]

Is there a plan to get Hyper-V CI working better? It looks like it is
failing significantly more frequently then Jenkins.

http://www.rcbops.com/gerrit/reports/nova-cireport.html


On Tue, Apr 15, 2014 at 9:25 AM, Peter Pouliot wrote:

>  Hi Everyone,
> Here are the minutes from today’s Hyper-V Meeting.
>
>  Minutes:
> http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.html
> Minutes (text):
> http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.txt
> Log:
> http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.log.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] [3rd party testing] Atlanta meetup for 3rd party testing?

[Kurt Taylor]

Anita Kuno  wrote on 04/15/2014 09:41:17 AM:
> On 04/15/2014 10:20 AM, Kurt Taylor wrote:
> >
> >
> > Sorry if you get this twice.
> >
> > Since summit is approaching quickly, I wanted to see if anyone had
interest
> > in forming a meetup for 3rd party testing. This would be a group for
> > helping the project cores by helping ourselves and hopefully improving
> > overall CI rollout.
> >
> > Some topics to discuss:  I'd at least like to get a standard tag that
would
> > help with email filtering, but we could also build a FAQ and
documentation
> > contributions to improve the content of the 3rd party testing. We could
> > also document different use cases and best practices for each on how
> > different testers solved problems they encountered for their
environment. I
> > don't know how long we would be able to meet, so this may just be an
> > organizational meeting, focusing on how to best share this info.
> >
> > I started an etherpad for discussion topics and eventual agenda here:
> > https://etherpad.openstack.org/p/3rdPartyTesting
> >
> > I have not worked out all the details for when and where to meet, but I
> > would be happy to set it up and facilitate the discussion. I wanted to
see
> > if there was any interest before I took it any further.
> >
> > Any interest?

> >
> There is a summit design session proposed to address this:
> http://summit.openstack.org/cfp/details/59
>
> Entitled: Improving Third Party Testing
>
> If you would like to add the information you would like to cover as a
> comment to the proposal that would help ensure the content gets covered.

Thanks for your response. I did not know about this and I am glad this is
proposed. It was my intention originally to propose this type of
discussion, but after bringing this up in -infra, it was not something the
team wanted to discuss in a design session. They suggested a BOF or meetup
at the infra table in developer's lounge. I do not know yet if that
location is still a possibility or not, as I indicated in my email.

>
> Since the purpose of the design summit is to cover material like this, I
> encourage people to get familiar with the summit sessions that are
> already proposed: http://summit.openstack.org/ and to propose sessions
> that you would like covered if you don't see a current proposal for your
> topic of interest.
>
> Since most of what I saw in the Neutron design summit sessions last year
> is counter to how most other programs use their design summit sessions,
> I encourage you to consider using the design summit session format.
> Neutron design summit sessions end up being more like conference
> presentations and that is not what the design summit was meant to be at
all.
>
> Design summit sessions are meant to be group discussion chaired by
> either the proposer of the session or someone else but equally discussed
> by all participants. They are not meant to be a presentation with a
> passive audience.

Yes, I am very familiar with UDS-style design summits and have lead several
design sessions in the past on other projects. I think this is a big factor
in the enormous success of the OpenStack project.

There is probably some overlap in the proposed design session and the
meetup. But, I actually see the meetup as more of a organizational meeting
to pull together the developers with experience in CI to share ideas and
how we got past the problems we found.

Maybe we can wait for the outcome of the session discussion and determine
next steps after summit?

Thanks again!

Kurt Taylor (krtaylor)
OpenStack Development Lead - PowerKVM CI
IBM Linux Technology Center___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Hyper-V Meeting Minutes

[Peter Pouliot]

Hi Everyone,
Here are the minutes from today’s Hyper-V Meeting.

Minutes:
http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.txt
Log:
http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.log.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Neutron Migrations, service plugins and Grenade jobs

[Amir Sadoughi]

I know alembic is designed to be global, but could we extend it to track 
multiple histories for a given database. In other words, various branches for 
different namespaces on a single database. Would this feature ameliorate the 
issues?

Amir

On Apr 15, 2014, at 8:24 AM, Kyle Mestery 
mailto:mest...@noironetworks.com>> wrote:

On Tue, Apr 15, 2014 at 7:03 AM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:
Thanks Anna.

I've been following the issue so far, but I am happy to hand it over to you.
I think the problem assessment is complete, but if you have more questions
ping me on IRC.

Regarding the solution, I think we already have a fairly wide consensus on
the approach.
There are however a few details to discuss:
- Conflicting schemas. For instance two migrations for two distinct plugins
might create tables with the same name but different columns.
 We first need to look at existing migrations to verify where this
condition occurs, and then study a solution case by case.
- Logic for "corrective" migrations. For instance a corrective migration for
569e98a8132b_metering is needed. However, such corrective migration should
have logic for understanding whether the original migration has been
executed or not.
- Corrective actions for corrupted schemas. This would be the case, for
instance, of somebody which enables metering while the database is at a
migration rev higher than the one when metering was introduced.

I reckon it might be the case of putting together a specification and push
it to the newly created neutron-specs repo, assuming that we feel confident
enough to start using this new process (Kyle and Mark might chime in on this
point). Also, I would like to see this work completed by Juno-1, which I
reckon is a reasonable target.

I'm working to get this new specification approval process ready,
hopefully by later
today. Once this is done, I agree with Salvatore, pushing a gerrit
review with the
specification for this work will be the right approach.

Of course I'm available for discussing design, implementation, reviewing and
writing code.

Thanks to Anna and Salvatore for taking this up!

Kyle

Salvatore



On 15 April 2014 12:44, Anna Kamyshnikova 
mailto:akamyshnik...@mirantis.com>>
wrote:

Hello everyone!

I would like to try to solve this problem. I registered blueprint on this
topic
https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations
and I'm going to experiment with options to solve this. I'm welcome any
suggestions and ready to talk about it via IRC (akamyshnikova).

Regards
Ann


On Mon, Apr 14, 2014 at 9:39 PM, Sean Dague  wrote:

On 04/14/2014 12:46 PM, Eugene Nikanorov wrote:
Hi Salvatore,

The described problem could be even worse if vendor drivers are
considered.
Doesn't #1 require that all DB tables are named differently? Otherwise
it seems that user can't be sure in DB schema even if all tables are
present.

I think the big part of the problem is that we need to support both
online and offline migrations. Without the latter things could be a
little bit simpler.

Also it seems to me that problem statement should be changed to the
following:
One need to migrate from (Config1, MigrationID1) to (Config2,
MigrationID2), and currently our code only accounts for MigrationIDs.
We may consider amending DB with configuration metadata, at least that
will allow to run migration code with full knowledge of what happened
before (if online mode is considered).
In offline mode that will require providing old and current
configurations.

That was just thinking aloud, no concrete proposals yet.

The root issue really is Migrations *must* be global, and config
invariant. That's the design point in both sqlalchemy-migrate and
alembic. The fact that there is one global migrations table per
database, with a single value in it, is indicative of this fact.

I think that design point got lost somewhere along the way, and folks
assumed migrations were just a way to change schemas. They are much more
constrained than that.

It does also sound like the data model is going to need some serious
reconsidering given what's allowed to be changed at the plugin or vendor
driver model. Contrast this with Nova, were virt drivers don't get to
define persistant data that's unique to them (only generic data that
they fit into the grander nova model).

The one time we had a driver which needed persistent data (baremetal) it
managed it's own database entirely.

   -Sean

--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net


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



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



___
OpenStack-dev mailing l

Re: [openstack-dev] [Fuel] Code merge policy

[Dmitry Pyzhov]

So every developer should manually mark every such review as WIP? And
remove this flag only when everyone agreed to merge? This will require
additional actions in 50% of fuel-web and 100% of fuel-main reviews.
Developers make mistakes too.

Let's just be more accurate.


On Tue, Apr 15, 2014 at 6:41 PM, Mike Scherbakov
wrote:

> Humans make mistakes... all the time. Let's think how we can automate this
> to have appropriate Jenkins check. In this particular case, we could do the
> following:
> a) make it "work in progress" if we still unsure on some deps
> b) can we have smoke test which would check that master node builds, and
> simplest deploy passes? This needs to be run only if there are changes
> discovered in ISO build script (including mirror changes), and puppet
> manifests which deploy master node
>
>
>
> On Tue, Apr 15, 2014 at 3:49 PM, Dmitry Pyzhov wrote:
>
>> Guys,
>>
>> We have big and complicated structure of the project. And part of our
>> patchsets require additional actions before merge. Sometimes we need
>> approve from testers, sometimes we need merge requests in several repos at
>> the same time, sometimes we need updates of rpm repositories before merge.
>>
>> We have informal rule: invite all the required persons to the review. And
>> core reviewer does not merge code if part of +1's are missed. Sad, but this
>> rule is not obvious.
>>
>> This informal rule became even more strict when we need update of rpm/deb
>> repositories, because OSCI changes should be accomplished right before
>> merge. For such reviews we ask OSCI team to do changes, checks and merge.
>>
>> https://review.openstack.org/#/c/86001/ This particular request requires
>> check of our 4.1.1 rpm/deb repositories status. Thats why Roman Vyalov is
>> added as reviewer.
>>
>> I don't like over-bureaucracy. My suggestion is simple: take into account
>> reviewers status and do not merge if unsure.
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
> ___
> 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] nova-specs

[Russell Bryant]

On 04/15/2014 11:01 AM, Brian Elliott wrote:
>> * specs review. The new blueprint process is a work of genius, and I
>> think its already working better than what we've had in previous
>> releases. However, there are a lot of blueprints there in review, and
>> we need to focus on making sure these get looked at sooner rather than
>> later. I'd especially like to encourage operators to take a look at
>> blueprints relevant to their interests. Phil Day from HP has been
>> doing a really good job at this, and I'd like to see more of it.
> 
> I have mixed feelings about the nova-specs repo.  I dig the open 
> collaboration of the blueprints process, but I also think there is a danger 
> of getting too process-oriented here.  Are these design documents expected to 
> call out every detail of a feature?  Ideally, I’d like to see only very high 
> level documentation in the specs repo.  Basically, the spec could include 
> just enough detail for people to agree that they think a feature is worth 
> inclusion.  More detailed discussion could remain on the code reviews since 
> they are the actual end work product.

There is a balance to be found here.  The benefit of doing more review
earlier is to change direction as necessary when it's *much* easier to
do so.  It's a lot more time consuming to do re-work after code has been
written, than re-work in a spec.

Yes, it's more up front work, but I think it will speed up the process
overall.  It means we're much more in agreement and on the same page
before code even shows up.  That's huge.

One of the big problems we've had in code review is the amount of churn
and re-work required.  That is killing our throughput in code review.
If we can do more up front work that will reduce re-work later, it's
going to be a *huge* help to our primary project bottleneck: the code
review queue.

-- 
Russell Bryant

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

Re: [openstack-dev] [heat][nova]dynamic scheduling

[Steven Dake]

On 04/15/2014 06:03 AM, Jiangying (Jenny) wrote:


Sorry, I'm not quite clear about it yet.

I'm trying to find a way that heat controls the flow but not the nova 
scheduler.


Heat doesn't control flow.  Heat expects a scheduler is built into 
whatever service it is consuming for resource management, if the 
resource is constrained for some reason (such as limited memory, disk, 
cpu resources available for consumption).  This is why something like a 
storage system (cinder) has a scheduler, and Heat does not.


It makes zero sense to add scheduling to Heat - since the projects that 
Heat consumes are in much better position to make decisions about which 
resources get scheduled when and where.


Regards
-steve


*???:*Henrique Truta [mailto:henriquecostatr...@gmail.com]
*:*2014?4?14?21:39
*???:*OpenStack Development Mailing List (not for usage questions)
*??:*Re: [openstack-dev] [heat][nova]dynamic scheduling

Hello!

I'm currently investigating both of these features you have mentioned, 
specifically on the NEAT[1] and GANTT[2] projects, as you might see on 
the last week discussion.


Do you have any further ideas about how and why this would work with Heat?

Thanks,

Henrique

[1] http://openstack-neat.org/ 
[2] https://github.com/openstack/gantt

2014-04-13 22:53 GMT-03:00 Jiangying (Jenny) 
mailto:jenny.jiangy...@huawei.com>>:


Hi,

there has been a heated discussion about dynamic scheduling last 
week.(http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg21644.html)


I am also interested in this topic. We believe that dynamic scheduling 
consists of two parts: balancing computing capacity and optimizing 
power consumption.


For balancing computing capacity, the ceilometer periodically monitors 
distribution and usage of CPU and memory resources for hosts and 
virtual machines. Based on the information, the scheduler calculates 
the current system standard deviation metric and determines the system 
imbalance by comparing it to the target. To resolve the imbalance, the 
scheduler gives the suitable virtual machine migration suggestions to 
nova. In this way, the dynamic scheduling achieves higher 
consolidation ratios and deliver optimized performance for the virtual 
machines.


For optimizing power consumption, we attempt to keep the resource 
utilization of each host within a specified target range. The 
scheduler evaluates if the goal can be reached by balancing the system 
workloads. If the resource utilization of a host remains below the 
target, the scheduler calls nova to power off some hosts. Conversely 
the scheduler powers on hosts to absorb the additional workloads. Thus 
optimizing power consumption offers an optimum mix of resource 
availability and power savings.


As Chen CH Ji said, "nova is a cloud solution that aim to control 
virtual / real machine lifecycle management the dynamic scheduling 
mechanism is something like optimization of the cloud resource". We 
think implementing the dynamic scheduling with heat may be a good attempt.


Do you have any comments?

Thanks,

Jenny


___
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] [Nova] Thoughts from the PTL

[Brian Elliott]

On Apr 13, 2014, at 11:58 PM, Michael Still  wrote:

> First off, thanks for electing me as the Nova PTL for Juno. I find the
> outcome of the election both flattering and daunting. I'd like to
> thank Dan and John for running as PTL candidates as well -- I strongly
> believe that a solid democratic process is part of what makes
> OpenStack so successful, and that isn't possible without people being
> will to stand up during the election cycle.

Congrats!

> 
> I'm hoping to send out regular emails to this list with my thoughts
> about our current position in the release process. Its early in the
> cycle, so the ideas here aren't fully formed yet -- however I'd rather
> get feedback early and often, in case I'm off on the wrong path. What
> am I thinking about at the moment? The following things:
> 
> * a mid cycle meetup. I think the Icehouse meetup was a great success,
> and I'd like to see us do this again in Juno. I'd also like to get the
> location and venue nailed down as early as possible, so that people
> who have complex travel approval processes have a chance to get travel
> sorted out. I think its pretty much a foregone conclusion this meetup
> will be somewhere in the continental US. If you're interested in
> hosting a meetup in approximately August, please mail me privately so
> we can chat.

Yeah this was a great opportunity to collaborate and keep the project pointed 
in the right direction during Icehouse.

> 
> * specs review. The new blueprint process is a work of genius, and I
> think its already working better than what we've had in previous
> releases. However, there are a lot of blueprints there in review, and
> we need to focus on making sure these get looked at sooner rather than
> later. I'd especially like to encourage operators to take a look at
> blueprints relevant to their interests. Phil Day from HP has been
> doing a really good job at this, and I'd like to see more of it.

I have mixed feelings about the nova-specs repo.  I dig the open collaboration 
of the blueprints process, but I also think there is a danger of getting too 
process-oriented here.  Are these design documents expected to call out every 
detail of a feature?  Ideally, I’d like to see only very high level 
documentation in the specs repo.  Basically, the spec could include just enough 
detail for people to agree that they think a feature is worth inclusion.  More 
detailed discussion could remain on the code reviews since they are the actual 
end work product.

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

Re: [openstack-dev] [heat] Re: deliver the vm-level HA to improve the business continuity with openstack

[Steven Dake]

On 04/15/2014 03:16 AM, Qiming Teng wrote:

What I saw in this thread are several topics:

1) Is VM HA really relevant (in a cloud)?

This is the most difficult question to answer, because it really depends
on who you are talking to, who are the user community you are facing.
IMHO, for most web-based applications that are born to run on cloud,
maybe certain level of business resiliency has already been built into
the code, so the application or service can live happily when VMs come
and go.

For traditional business applications, the scenario may be quite
different.  These apps are migrated to cloud for reasons like cost
savings, server consolidation, etc..  Quite some companies are
evaluating OpenStack for their "private cloud" -- which is a weird term,
IMHO.

In addition to this, while we are looking into the 'utility' vision of
cloud, we can still ask ourselves: a) can we survive one month of power
outage or water outage, though there are abundant supply elsewhere on
this
planet? b) what are the costs we need to pay if we eventually make it?
c) do we want to pay for this?

My personal experience is that our customers really want this feature
(VM HA) for their private clouds.  The question they asked us was:

"
   Does OpenStack support VM HA?  Maybe not for all VMS...
   We know we can have that using vSphere, Azure, or CloudStack...
"


2) Where is the best location to provide VM HA?

Suppose that we do feel the need to support VM HA, then the questions
following this would 'where' and 'how'.

Considering that a VM is not merely a bundle of compute processes, it is
actually a virtual execution environment that consumes resources like
storage and network bandwidth besides processor cycles, Nova may be NOT
the ideal location to deal with this cross-cutting concern.

High availability involves redundant resource provisioning, effective
failure detection and appropriate fail-over policies, including fencing.
Imposing all these requirements on Nova is impractical.  We may need to
consider whether VM HA, if ever implemented/supported, should be part of
the orchestration service, aka Heat.


3) Can/should we do the VM HA orchestration in Heat?

My perception is that it can be done in Heat, based on my limited
understandig of how Heat works.  It may imply some requirements to other
projects (e.g.  nova, cinder, neutron ...) as well, though Heat should be
the orchestrator.

What do we need then?

   - A resource type for VM groups/clusters, for the redundant
 provisioning.  VMs in the group can be identical instances, managed
 by a Pacemaker setup among the VMs, just like a WatchRule in Heat can
 be controlled by Ceilometer.

 Another way to do this is to have the VMs monitored via heartbeat
 messages sent by Nova (if possible/needed), or some services injected
 into the VMs (consider what cfn-hup, cfn-signal does today).

 However, the VM group/cluster can decide how to react to a VM online
 /offline signal.  It may choose to a) restart the VM in-place; b)
 remote-restart (aka evacuate) the VM somewhere else; c) live/cold
 migrate the VM to other nodes.

 The policies can be out sourced to other plugins considering that
 global load-balancing or power management requirements.  But that is an
 advanced feature that warrants another blueprint.

   - Some fencing support from nova, cinder, neutron to shoot the bad VMs
 in the head so a VM that cannot be reached is guarantteed to be cleanly
 killed.

   - VM failure detectors that can reliably tell whether a VM has failed.
 Sometimes a VM that failed the expected performance goal should be
 treated as failed as well, if we really want to be strict on this.

 A failure detector can reside inside Nova, as what has been done for
 the 'service groups' there.  It can reside inside a VM, as a service
 istalled there, sending out heatbeat messages (before the battery runs
 out, :))

   - A generic signaling mechanism that allows a secure message delivery
 back to Heat indicating that a VM is alive or dead.

My current understanding is that we may avoid complicated task-flow
here.

Regards,
   - Qiming


Qiming,

If you read my original post on this thread, it outlines the current 
heat-core thinking, which is to reduce the scope of this resource from 
the Heat resources since it describes a workflow rather then an 
orchestrated thing (a Noun).


A good framework for HA already exists for HA in the HARestarter 
resource.  It incorporates HA escalation, which is a critical feature of 
any HA system.  The fundamental problem with HARestarter is that is in 
the wrong project.


Long term, HA, if desired, should be part of taskflow, though, because 
its a verb, and verbs don't belong as heat orchestrated resources.


How we get from here to there is left as an exercise to the reader ;-)

Regards
-steve


For the most part we've been trying to encourage projects that want to
control VMs to

Re: [openstack-dev] [Fuel] Rabbit in HA mode for Glance

[Vladimir Kuklin]

Ilya, here is link to the bug created:

https://bugs.launchpad.net/fuel/+bug/1308104


On Sun, Apr 13, 2014 at 8:53 AM, Vladimir Kuklin wrote:

> Ilya, thank you for pointing this out. Obviously we will add it into fuel
> manifests.
> 10 апр. 2014 г. 19:43 пользователь "Ilya Shakhat" 
> написал:
>
>> Hi,
>>
>> Recently Glance switched to oslo.messaging library and as benefit got
>> support of HA for Rabbit queues (parameter 'rabbit_ha_queues'). There
>> are similar parameters in other projects (Nova, Heat, Ceilometer) and they
>> are configured in corresponding manifest files. Are there plans to add the
>> same into Glance manifests?
>>
>> Thanks,
>> Ilya
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Code merge policy

[Mike Scherbakov]

Humans make mistakes... all the time. Let's think how we can automate this
to have appropriate Jenkins check. In this particular case, we could do the
following:
a) make it "work in progress" if we still unsure on some deps
b) can we have smoke test which would check that master node builds, and
simplest deploy passes? This needs to be run only if there are changes
discovered in ISO build script (including mirror changes), and puppet
manifests which deploy master node



On Tue, Apr 15, 2014 at 3:49 PM, Dmitry Pyzhov  wrote:

> Guys,
>
> We have big and complicated structure of the project. And part of our
> patchsets require additional actions before merge. Sometimes we need
> approve from testers, sometimes we need merge requests in several repos at
> the same time, sometimes we need updates of rpm repositories before merge.
>
> We have informal rule: invite all the required persons to the review. And
> core reviewer does not merge code if part of +1's are missed. Sad, but this
> rule is not obvious.
>
> This informal rule became even more strict when we need update of rpm/deb
> repositories, because OSCI changes should be accomplished right before
> merge. For such reviews we ask OSCI team to do changes, checks and merge.
>
> https://review.openstack.org/#/c/86001/ This particular request requires
> check of our 4.1.1 rpm/deb repositories status. Thats why Roman Vyalov is
> added as reviewer.
>
> I don't like over-bureaucracy. My suggestion is simple: take into account
> reviewers status and do not merge if unsure.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [OpenStack-Infra] [3rd party testing] Atlanta meetup for 3rd party testing?

[Anita Kuno]

On 04/15/2014 10:20 AM, Kurt Taylor wrote:
> 
> 
> Sorry if you get this twice.
> 
> Since summit is approaching quickly, I wanted to see if anyone had interest
> in forming a meetup for 3rd party testing. This would be a group for
> helping the project cores by helping ourselves and hopefully improving
> overall CI rollout.
> 
> Some topics to discuss:  I'd at least like to get a standard tag that would
> help with email filtering, but we could also build a FAQ and documentation
> contributions to improve the content of the 3rd party testing. We could
> also document different use cases and best practices for each on how
> different testers solved problems they encountered for their environment. I
> don't know how long we would be able to meet, so this may just be an
> organizational meeting, focusing on how to best share this info.
> 
> I started an etherpad for discussion topics and eventual agenda here:
> https://etherpad.openstack.org/p/3rdPartyTesting
> 
> I have not worked out all the details for when and where to meet, but I
> would be happy to set it up and facilitate the discussion. I wanted to see
> if there was any interest before I took it any further.
> 
> Any interest?
> 
> Kurt Taylor (krtaylor)
> OpenStack Development Lead - PowerKVM CI
> IBM Linux Technology Center
> 
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
There is a summit design session proposed to address this:
http://summit.openstack.org/cfp/details/59

Entitled: Improving Third Party Testing

If you would like to add the information you would like to cover as a
comment to the proposal that would help ensure the content gets covered.

Since the purpose of the design summit is to cover material like this, I
encourage people to get familiar with the summit sessions that are
already proposed: http://summit.openstack.org/ and to propose sessions
that you would like covered if you don't see a current proposal for your
topic of interest.

Since most of what I saw in the Neutron design summit sessions last year
is counter to how most other programs use their design summit sessions,
I encourage you to consider using the design summit session format.
Neutron design summit sessions end up being more like conference
presentations and that is not what the design summit was meant to be at all.

Design summit sessions are meant to be group discussion chaired by
either the proposer of the session or someone else but equally discussed
by all participants. They are not meant to be a presentation with a
passive audience.

Using the design summit sessions as they are intended to be used would
be more advantageous for the community then trying to schedule a meetup
that might be a splintering off of the design summit sessions. If this
direction is unsatisfactory for your needs after it is tried, please be
sure to attend the summit wrapup design session and express your
perspective so it can be included in future summit planning.

Thanks,
Anita.

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