Re: [openstack-dev] [tricircle] virtual design summit for Newton

[Shinobu Kinjo]

Hi Team,

There was no enough time to discuss all topics in the meeting today. 
I wrote up what we discussed. Please make sure what need to be done and add 
anything if I've missed.

Cheers,
Shinobu

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

Sent: Friday, April 29, 2016 10:59:48 AM
Subject: Re: [openstack-dev] [tricircle] virtual design summit for Newton



repost for reminder 

From: joehuang 
Sent: 26 April 2016 11:40 
To: OpenStack Development Mailing List (not for usage questions) 
Subject: [openstack-dev][tricircle] virtual design summit for Newton 



Hello, 



Most of our team members in Tricircle are not able to attend the OpenStack 
Austin summit, so we have to have a virtual design summit: 



One etherpad is opened for the topics to be discussed for the Newton design 
summit, please list the topics you want to discuss in the etherpad: 



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



The date and time to have this virtual design summit will be at UTC 2:00am on 
Friday ( Beijing Time 10:00am) Apr. 29. ( Austin time: 9:00pm Apr.28 ) 



To make Tricircle fully follow OpenStack projects open source development, I 
think we need to apply Tricircle as TC approved big tent project in Newton, so 
this is also one important topic to be discussed. 



Any suggestion are welcome. 



Best Regards 

Chaoyi Huang ( joehuang ) 

From: joehuang 
Sent: 19 April 2016 16:33 
To: OpenStack Development Mailing List (not for usage questions) 
Subject: [openstack-dev] [tricircle]weekly meeting of Apr. 19 



This week we will discuss the object operation not implemented . 



IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every 
Wednesday starting from UTC 13:00. 



Agenda: 

# object operation not implemented 

# tempest test 

# Reliable aync. Job – items left 

# Link: https://etherpad.openstack.org/p/TricircleToDo 



If you have other topics to be discussed in the weekly meeting, please reply 
the mail. 



Best Regards 

Chaoyi Huang ( Joe Huang ) 



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

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

Re: [openstack-dev] [nova] Distributed Database

[Clint Byrum]

Excerpts from Mike Bayer's message of 2016-04-28 22:16:54 -0500:
> 
> On 04/28/2016 08:25 PM, Edward Leafe wrote:
> 
> > Your own tests showed that a single RDBMS instance doesn’t even break a 
> > sweat
> > under your test loads. I don’t see why we need to shard it in the first
> > place, especially if in doing so we add another layer of complexity and
> > another dependency in order to compensate for that choice. Cells are a 
> > useful
> > concept, but this proposed implementation is adding way too much complexity
> > and debt to make it worthwhile.
> 
> now that is a question I have also.  Horizontal sharding is usually for 
> the case where you need to store say, 10B rows, and you'd like to split 
> it up among different silos.  Nothing that I've seen about Nova suggests 
> this is a system with any large data requirements, or even medium size 
> data (a few million rows in relational databases is nothing).I 
> didn't have the impression that this was the rationale behind Cells, it 
> seems like this is more of some kind of logical separation of some kind 
> that somehow suits some environments (but I don't know how). 
> Certainly, if you're proposing a single large namespace of data across a 
> partition of nonrelational databases, and then the data size itself is 
> not that large, as long as "a single namespace" is appropriate then 
> there's no reason to break out of more than one MySQL database.  There's 
> not much reason to transparently shard unless you are concerned about 
> adding limitless storage capacity.   The Cells sharding seems to be 
> intentionally explicit and non-transparent.
> 

There's a bit more to it than the number of rows. There's also a desire
to limit failure domains. IMO, that is entirely unfounded, as I've run
thousands of servers that depended on a single pair of MySQL servers
using simple DRBD and pacemaker with a floating IP for failover. This
is the main reason MySQL is a thing... it can handle 100,000 concurrent
connections just fine, and the ecosystem around detecting and handling
failure/maintenance is mature.

The whole cells conversation, IMO, stems from the way we use RabbitMQ.
We should just stop doing that. I know as I move forward with our scaling
efforts, I'll be trying several RPC drivers and none of them will go
through RabbitMQ.

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

[openstack-dev] [Nova][Cinder] Additional notes on Nova and Cinder volume managment

[John Griffith]

Hey Everyone,

I've spent a bit more time thinking through some of what we talked about in
todays session.  I wanted to summarize some things, clarify a couple points
and also add some details that I've been thinking about.

Etherpad seemed like a more collaborative way to go than super long email
message, so if you're interested have a look and provide input:

https://etherpad.openstack.org/p/cinder-nova-volume-attach-change-proposal

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

Re: [openstack-dev] [nova] Distributed Database

[Mike Bayer]

On 04/28/2016 08:25 PM, Edward Leafe wrote:


Your own tests showed that a single RDBMS instance doesn’t even break a sweat
under your test loads. I don’t see why we need to shard it in the first
place, especially if in doing so we add another layer of complexity and
another dependency in order to compensate for that choice. Cells are a useful
concept, but this proposed implementation is adding way too much complexity
and debt to make it worthwhile.


now that is a question I have also.  Horizontal sharding is usually for 
the case where you need to store say, 10B rows, and you'd like to split 
it up among different silos.  Nothing that I've seen about Nova suggests 
this is a system with any large data requirements, or even medium size 
data (a few million rows in relational databases is nothing).I 
didn't have the impression that this was the rationale behind Cells, it 
seems like this is more of some kind of logical separation of some kind 
that somehow suits some environments (but I don't know how). 
Certainly, if you're proposing a single large namespace of data across a 
partition of nonrelational databases, and then the data size itself is 
not that large, as long as "a single namespace" is appropriate then 
there's no reason to break out of more than one MySQL database.  There's 
not much reason to transparently shard unless you are concerned about 
adding limitless storage capacity.   The Cells sharding seems to be 
intentionally explicit and non-transparent.






-- Ed Leafe





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



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

Re: [openstack-dev] [kolla] Deploying kolla from a container?

[Jamie Hannaford]

Okay, that makes sense. For a normal Ubuntu VM (in my case on Rackspace cloud), 
what would the networking configuration look like? Usually eth0 is the 
interface for the public internet, eth1 is servicenet, and I have eth2 as an 
arbitrary neutron private network.


For the `network_interface` config value I used eth2 and for 
`kolla_internal_vip_address` a free VIP on its subnet - does that sound right?


For `neutron_external_interface`, it says in your dev guide that you can use a 
veth pair when there's only a single public interface on a machine, which is 
the case here. Is there any documentation available for how to do that?


Jamie



From: Michal Jastrzebski 
Sent: 28 April 2016 04:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Deploying kolla from a container?


Hey,

So privileged containers are required by stuff like libvirt, and there isn't 
much we can do about it. Shared /run is required by openvswitch afair. We 
didn't try to run Kolla with swarm, but I'm afraid that privileged container 
and network host are unfortunately a must. OpenStack wasn't really build to be 
run in containers, so we had to make sacrifices here and there. We are 
experimenting with kubernates now, as it supports both priv containers and net 
host.

Let me know what if I can be any help.


Michal

On Apr 27, 2016 5:27 PM, "Jamie Hannaford" 
> wrote:

Hi,


Is it possible to deploy Kolla from a container rather than an ubuntu/centos 
VM? I have a Swarm cluster, so I don't really want to leave that ecosystem and 
start creating other cloud resources.


I got quite far with the dev guide, but the step which seems to throw a spanner 
in the works is setting the ?MountFlags. You recommend either systemd (15.04+) 
or `mount --make-shared /run` (14.04), both of which require a container 
running in privileged mode, which I can't do on my swarm cluster. Is there any 
workaround here?


Alternatively, is it possible to run a privileged container locally in 
virtualbox and have it deploy to a remote Swarm cluster?


Any advice you have here would be really appreciated. Kolla looks like a great 
project!


Jamie



Rackspace International GmbH a company registered in the Canton of Zurich, 
Switzerland (company identification number CH-020.4.047.077-1) whose registered 
office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace 
International GmbH privacy policy can be viewed at 
www.rackspace.co.uk/legal/swiss-privacy-policy
 - This e-mail message may contain confidential or privileged information 
intended for the recipient. Any dissemination, distribution or copying of the 
enclosed material is prohibited. If you receive this transmission in error, 
please notify us immediately by e-mail at 
ab...@rackspace.com and delete the original 
message. Your cooperation is appreciated.

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

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

Re: [openstack-dev] [tricircle] virtual design summit for Newton

[joehuang]

repost for reminder


From: joehuang
Sent: 26 April 2016 11:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev][tricircle] virtual design summit for Newton


Hello,



Most of our team members in Tricircle are not able to attend the OpenStack 
Austin summit, so we have to have a virtual design summit:



One etherpad is opened for the topics to be discussed for the Newton design 
summit, please list the topics you want to discuss in the etherpad:



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



The date and time to have this virtual design summit will be at UTC 2:00am on 
Friday ( Beijing Time 10:00am) Apr. 29. ( Austin time: 9:00pm Apr.28 )



To make Tricircle fully follow OpenStack projects open source development, I 
think we need to apply Tricircle as TC approved big tent project in Newton, so 
this is also one important topic to be discussed.



Any suggestion are welcome.



Best Regards

Chaoyi Huang ( joehuang )


From: joehuang
Sent: 19 April 2016 16:33
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle]weekly meeting of Apr. 19

This week we will discuss the object operation not implemented.

IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every 
Wednesday starting from UTC 13:00.

Agenda:
# object operation not implemented
# tempest test
# Reliable aync. Job – items left
# Link: https://etherpad.openstack.org/p/TricircleToDo

If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi Huang ( Joe Huang )

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

Re: [openstack-dev] [nova] Distributed Database

[Edward Leafe]

On Apr 28, 2016, at 5:35 PM, Clint Byrum  wrote:

> - Vitess [2] is a proven technology that serves _every_ request to
>  Youtube, and provides a familiar SQL interface with sharding built
>  in. Shard by project ID and you can just use regular index semantics.
>  Or if that's unacceptable (IMO it's fine since Vitess provides enough
>  redundancy that one shard has plenty of failure-domain reliability),
>  you can also use the built-in Hadoop support they have for doing
>  exactly what has been described (merge sorting the result of cross-cell
>  queries).

Thanks for that reference. I hadn’t heard of Vitess before, but it looks pretty 
capable.

> So, I have to ask, why is cells v2 being pushed so hard without looking
> outside OpenStack for actual existing solutions, which, IMO, are
> _numerous_, battle hardened, and simpler than cells.

Cells are a great concept, but of course the devil is in the implementation. So 
if having cells is an advantage (and that is a separate discussion that already 
seems settled), then we should focus on the best way to implement it for 
(short-term) efficiency and (long-term) maintainability.

-- Ed Leafe






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

[openstack-dev] [nova] Should be instance_dir in all nova compute node same ?

[Eli Qiao]

hi team,

Is there any require that all compute node's instance_dir should be same?

I recently get an issue while doing live migration with migrateToURI3 
method of libvirt python interface, if
source and dest host are configured with difference instance_dir, 
migration will fail since migrateToURI3

requires a new xml, but we don't modified the instance_dir of dest xml.

I reported a bug on [1]_ , would like to get confirmation before spend 
effort working on it.


[1] https://bugs.launchpad.net/nova/+bug/1576245

Thanks.

--

Best Regards, Eli Qiao (乔立勇)
Intel OTC China

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

Re: [openstack-dev] [nova] Distributed Database

[Edward Leafe]

On Apr 28, 2016, at 1:09 PM, Jay Pipes  wrote:

> nova list as an admin (or any user frankly) should be a proxy call to Project 
> Searchlight and elasticsearch.
> 
> elasticsearch is a great interface for this kind of operation. We should use 
> it.

Oh, that’s great! A Java-based dependency! I’m *sure* that there will be no 
objection to that.

> The Cells architecture, which allows the operator to both scale the message 
> queue *and* limit the scope of failure domains, is a good one. Having a 
> database that stores only the local (to the cell) information is perfectly 
> fine given the top-level API database's index/mapping tables. Where this 
> design has short-comings, as Ed and others point out, are things like doing 
> list operations across dozens of separate cells. So, let's not use the Nova 
> database for that and instead use a solution that works very well for it: 
> Project Searchlight.

What I’m hearing is: let’s shard the database along a random line that 
seriously impacts performance, and then add another layer to help mitigate the 
performance impact of that decision.

> And for those that have small clouds and/or don't want/need to install 
> elasticsearch, OK, cool, stick with a single cell and a single RDBMS instance.

Your own tests showed that a single RDBMS instance doesn’t even break a sweat 
under your test loads. I don’t see why we need to shard it in the first place, 
especially if in doing so we add another layer of complexity and another 
dependency in order to compensate for that choice. Cells are a useful concept, 
but this proposed implementation is adding way too much complexity and debt to 
make it worthwhile.


-- Ed Leafe





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

Re: [openstack-dev] [heat]informal meetup during summit

[Rico Lin]

*Tomorrow 10:00 am at alta's cafe*

See you guys have there:)

http://altascafe.com/

map

On Apr 25, 2016 8:11 PM, "Steve Baker"  wrote:

> We are now at Terry black's BBQ now for anyone who wants to join usThanks
> for organising Rico! See you when you get there.
>
> - ZB
>
>
> On 22/04/16 20:01, Rico Lin wrote:
> > Let's settle down on with
> >
> > A meet up on Monday night 7:00pm
> > At continentalclub
> > <
> http://www.google.com/url?q=http%3A%2F%2Fcontinentalclub.com=D=1=AFQjCNGirvAgZuZhxVEzHb7bFZU_fShJQw
> >
> > address : 1315 S Congress Ave
> > Austin, TX 78704 http://continentalclub.com
> > <
> http://www.google.com/url?q=http%3A%2F%2Fcontinentalclub.com=D=1=AFQjCNGirvAgZuZhxVEzHb7bFZU_fShJQw
> >
> > And
> > Friday morning 10:00 venue:TBD
> >
> > Is the time and venue find with everyone?
> >
> > Everyone are welcome :)
> > Feel free to let me know if you're coming, just for easy pre-booking
> > purpose:)
> >
> > On Apr 22, 2016 12:13 AM, "Zane Bitter"  > > wrote:
> >
> > On 20/04/16 13:00, Rico Lin wrote:
> >
> > Hi team
> > Let plan for more informal meetup(relax) time! Let all heaters
> > and any
> > other projects can have fun and chance for technical discussions
> > together.
> >
> > After discuss in meeting, we will have a pre-meetup-meetup on
> Friday
> > morning to have a cup of cafe or some food. Would like to ask if
> > anyone
> > knows any nice place for this meetup?:)
> >
> >
> > According to
> > https://www.openstack.org/summit/austin-2016/guide-to-austin/ if we
> > line up at Franklin's at 7am then we can be eating barbeque by 11
> > and still make it back in time for the afternoon meetup :))
> >
> > Also open for other chance for all can go out for a nice dinner
> and
> > beer. Right now seems maybe Monday or Friday night could be the
> best
> > candidate for this wonderful task, what all think about this? :)
> >
> >
> > +1. I'll be around on Friday, but I imagine a few people will be
> > leaving so Monday is probably better.
> >
> > cheers,
> > Zane.
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Social at the summit

[Zhou, Han]

When I went there I didn't see any of our folks so I went to another
dinner. Have fun!

On Thursday, April 28, 2016, Nate Johnston  wrote:

> A few of us made it in, but the number that they can for is probably only
> one or two more.
>
> --N.
>
> On Thursday, April 28, 2016, Kyle Mestery  > wrote:
>
>> Folks, unfortunately this will have to be postponed. I was too busy doing
>> a standup routine with Armando to find another place. Apologies.
>>
>> Thanks,
>> Kyle
>>
>> On Apr 28, 2016, at 12:02 PM, Darek Smigiel 
>> wrote:
>>
>> Unfortunately, I’ve got response from Bangers, that they’re fully booked
>> for Today
>>
>> "Thank you for your interest in hosting a business dinner with us at
>> Banger's tonight. Unfortunately we are booked with reservations this
>> evening, so I am unable to accommodate your request. I wish you all the
>> best in finding the perfect venue for your event.”
>>
>> Are we trying to find some other spot, or just keep Bangers and we will
>> see?
>>
>> Darek
>>
>> On Apr 26, 2016, at 8:27 PM, Kyle Mestery  wrote:
>>
>> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a
>> reservation but it should be able to hold 50+ people. See y'all at 6PM
>> Thursday!
>>
>> Kyle
>>
>> On Apr 25, 2016, at 1:07 PM, Kyle Mestery  wrote:
>>
>> OK, there is enough interest, I'll find a place on 6th Street for us
>> and get a reservation for Thursday around 7 or so.
>>
>> Thanks folks!
>>
>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
>> +1 :)
>>
>> Han Zhou
>> Irc: zhouhan
>>
>>
>> On Monday, April 25, 2016, Korzeniewski, Artur
>>  wrote:
>>
>>
>> Sign me up :)
>>
>> Artur
>> IRC: korzen
>>
>> -Original Message-
>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>> Sent: Monday, April 25, 2016 7:19 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>
>> Count me in!
>> Will be good to meet all you guys!
>>
>> Darek (dasm) Smigiel
>>
>> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>>  wrote:
>>
>>
>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
>> wrote:
>>
>> WAT???
>>
>> It was never supposed to be core only. Everyone is welcome!
>>
>>
>> +2
>>
>> irony intended.
>>
>> Socials are not controlled by gerrit ACLs.  :-)
>>
>> doug
>>
>>
>> Sent from my iPhone
>>
>> On 25 Apr 2016, at 11:56, Edgar Magana 
>> wrote:
>>
>> Would you extend it to ex-cores?
>>
>> Edgar
>>
>>
>>
>>
>> On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
>>
>> Ihar, Henry and I were talking and we thought Thursday night makes
>> sense for a Neutron social in Austin. If others agree, reply on this
>> thread
>> and we'll find a place.
>>
>> Thanks!
>> Kyle
>>
>> ___
>> ___ OpenStack Development Mailing List (not for usage
>> questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>> __ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>>  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> 

Re: [openstack-dev] [kolla][ssecurity] Threat Analysis Design Session

[Rob C]

As per today's session (Thursday) the Anchor Threat Analysis blog post now
has added sequence diagram goodness!

https://openstack-security.github.io/threatanalysis/2016/02/07/anchorTA.html

Cheers
-Rob

On Sat, Apr 16, 2016 at 1:19 PM, Steven Dake (stdake) 
wrote:

> Hey Folks,
>
> I've scheduled the Threat Analysis Design session on Thursday 11:50-12:30
> in room MR415A.  This slot was the best slot I could find that didn't
> conflict with any security projects.
>
> If the security team has a conflict  with this slot that I didn't see or
> am unaware of, please speak up so I can have it corrected in the main
> schedule.  Our schedule is here:
>
> https://etherpad.openstack.org/p/kolla-newton-summit
>
> Thanks!
> -steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Social at the summit

[Nate Johnston]

A few of us made it in, but the number that they can for is probably only
one or two more.

--N.

On Thursday, April 28, 2016, Kyle Mestery  wrote:

> Folks, unfortunately this will have to be postponed. I was too busy doing
> a standup routine with Armando to find another place. Apologies.
>
> Thanks,
> Kyle
>
> On Apr 28, 2016, at 12:02 PM, Darek Smigiel  > wrote:
>
> Unfortunately, I’ve got response from Bangers, that they’re fully booked
> for Today
>
> "Thank you for your interest in hosting a business dinner with us at
> Banger's tonight. Unfortunately we are booked with reservations this
> evening, so I am unable to accommodate your request. I wish you all the
> best in finding the perfect venue for your event.”
>
> Are we trying to find some other spot, or just keep Bangers and we will
> see?
>
> Darek
>
> On Apr 26, 2016, at 8:27 PM, Kyle Mestery  > wrote:
>
> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a
> reservation but it should be able to hold 50+ people. See y'all at 6PM
> Thursday!
>
> Kyle
>
> On Apr 25, 2016, at 1:07 PM, Kyle Mestery  > wrote:
>
> OK, there is enough interest, I'll find a place on 6th Street for us
> and get a reservation for Thursday around 7 or so.
>
> Thanks folks!
>
> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  > wrote:
> +1 :)
>
> Han Zhou
> Irc: zhouhan
>
>
> On Monday, April 25, 2016, Korzeniewski, Artur
>  > wrote:
>
>
> Sign me up :)
>
> Artur
> IRC: korzen
>
> -Original Message-
> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com
> ]
> Sent: Monday, April 25, 2016 7:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
>  >
> Subject: Re: [openstack-dev] [neutron] Social at the summit
>
> Count me in!
> Will be good to meet all you guys!
>
> Darek (dasm) Smigiel
>
> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>  > wrote:
>
>
> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka  >
> wrote:
>
> WAT???
>
> It was never supposed to be core only. Everyone is welcome!
>
>
> +2
>
> irony intended.
>
> Socials are not controlled by gerrit ACLs.  :-)
>
> doug
>
>
> Sent from my iPhone
>
> On 25 Apr 2016, at 11:56, Edgar Magana  >
> wrote:
>
> Would you extend it to ex-cores?
>
> Edgar
>
>
>
>
> On 4/25/16, 10:55 AM, "Kyle Mestery"  > wrote:
>
> Ihar, Henry and I were talking and we thought Thursday night makes
> sense for a Neutron social in Austin. If others agree, reply on this thread
> and we'll find a place.
>
> Thanks!
> Kyle
>
> ___
> ___ OpenStack Development Mailing List (not for usage
> questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org
> 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> 
> __ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org
> 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _
> _ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org
> 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org
> 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [neutron] Social at the summit

[Kyle Mestery]

Folks, unfortunately this will have to be postponed. I was too busy doing a 
standup routine with Armando to find another place. Apologies.

Thanks,
Kyle

> On Apr 28, 2016, at 12:02 PM, Darek Smigiel  wrote:
> 
> Unfortunately, I’ve got response from Bangers, that they’re fully booked for 
> Today
> 
> "Thank you for your interest in hosting a business dinner with us at Banger's 
> tonight. Unfortunately we are booked with reservations this evening, so I am 
> unable to accommodate your request. I wish you all the best in finding the 
> perfect venue for your event.”
> 
> Are we trying to find some other spot, or just keep Bangers and we will see?
> 
> Darek
> 
>> On Apr 26, 2016, at 8:27 PM, Kyle Mestery  wrote:
>> 
>> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a 
>> reservation but it should be able to hold 50+ people. See y'all at 6PM 
>> Thursday!
>> 
>> Kyle
>> 
>>> On Apr 25, 2016, at 1:07 PM, Kyle Mestery  wrote:
>>> 
>>> OK, there is enough interest, I'll find a place on 6th Street for us
>>> and get a reservation for Thursday around 7 or so.
>>> 
>>> Thanks folks!
>>> 
 On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
 +1 :)
 
 Han Zhou
 Irc: zhouhan
 
 
 On Monday, April 25, 2016, Korzeniewski, Artur
  wrote:
> 
> Sign me up :)
> 
> Artur
> IRC: korzen
> 
> -Original Message-
> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
> Sent: Monday, April 25, 2016 7:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [neutron] Social at the summit
> 
> Count me in!
> Will be good to meet all you guys!
> 
> Darek (dasm) Smigiel
> 
>> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>>  wrote:
>> 
>> 
>>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
>>> wrote:
>>> 
>>> WAT???
>>> 
>>> It was never supposed to be core only. Everyone is welcome!
>> 
>> +2
>> 
>> irony intended.
>> 
>> Socials are not controlled by gerrit ACLs.  :-)
>> 
>> doug
>> 
>>> 
>>> Sent from my iPhone
>>> 
 On 25 Apr 2016, at 11:56, Edgar Magana 
 wrote:
 
 Would you extend it to ex-cores?
 
 Edgar
 
 
 
 
> On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
> 
> Ihar, Henry and I were talking and we thought Thursday night makes
> sense for a Neutron social in Austin. If others agree, reply on this 
> thread
> and we'll find a place.
> 
> Thanks!
> Kyle
> 
> ___
> ___ OpenStack Development Mailing List (not for usage
> questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __ OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> _
>>> _ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> __
>>  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 

Re: [openstack-dev] [neutron] [qos] gathering Friday 9:30

[reedip banerjee]

Yup,+1
On Apr 29, 2016 04:19, "Shaughnessy, David" 
wrote:

> Sounds good, +1.
>
>
>
> *From:* Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
> *Sent:* Thursday, April 28, 2016 11:03 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; Nate Johnston <
> nate_johns...@cable.comcast.com>; Margaret Frances <
> margaret_fran...@cable.comcast.com>; Shaughnessy, David <
> david.shaughne...@intel.com>; irenab@gmail.com; Moshe Levi <
> mosh...@mellanox.com>; reedi...@gmail.com
> *Subject:* [neutron] [qos] gathering Friday 9:30
>
>
>
> Does governors ballroom in Hilton sound ok?
>
> We can move to somewhere else if necessary.
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [qos] gathering Friday 9:30

[Shaughnessy, David]

Sounds good, +1.

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Thursday, April 28, 2016 11:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
; Nate Johnston 
; Margaret Frances 
; Shaughnessy, David 
; irenab@gmail.com; Moshe Levi 
; reedi...@gmail.com
Subject: [neutron] [qos] gathering Friday 9:30


Does governors ballroom in Hilton sound ok?

We can move to somewhere else if necessary.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Distributed Database

[Clint Byrum]

Excerpts from Jay Pipes's message of 2016-04-28 13:09:29 -0500:
> On 04/28/2016 08:44 AM, Edward Leafe wrote:
> > On Apr 24, 2016, at 3:28 PM, Robert Collins  
> > wrote:
> >> For instance, the things I think are essential for a distributed
> >> database based datastore:
> >> - good single-machine developer story. Must not need a physical
> >> cluster to hack on OpenStack
> >> - deal gracefully with single node/rack/site failures (when deployed
> >> appropriately) - allow limiting failure domain impact
> >> - straightforward programming model: wrong uses should be obvious to 
> >> reviewers
> >> - low latency performance with big datasets: e.g. nova list as an
> >> admin should be able to get the Nth page as rapidly as the 2nd or 3rd.
> 
> nova list as an admin (or any user frankly) should be a proxy call to 
> Project Searchlight and elasticsearch.
> 
> elasticsearch is a great interface for this kind of operation. We should 
> use it.
> 
> The Cells architecture, which allows the operator to both scale the 
> message queue *and* limit the scope of failure domains, is a good one. 
> Having a database that stores only the local (to the cell) information 
> is perfectly fine given the top-level API database's index/mapping 
> tables. Where this design has short-comings, as Ed and others point out, 
> are things like doing list operations across dozens of separate cells. 
> So, let's not use the Nova database for that and instead use a solution 
> that works very well for it: Project Searchlight.
> 
> And for those that have small clouds and/or don't want/need to install 
> elasticsearch, OK, cool, stick with a single cell and a single RDBMS 
> instance.
> 


Why are we inventing more things in OpenStack?

- 0MQ allows decentralized RPC and exists today! There's very little
  need for RabbitMQ sharding if it is just handling notifications,
  but if that's a concern, Kafka is also available in oslo.messaging
  and scales out naturally.
  - And now AMQP 1.0 / proton has a legitimate contender for an
alternative to 0MQ with the dispatch-router approach [1]
  - Or, crazy idea, we could just make RPC happen over http(s).

- Vitess [2] is a proven technology that serves _every_ request to
  Youtube, and provides a familiar SQL interface with sharding built
  in. Shard by project ID and you can just use regular index semantics.
  Or if that's unacceptable (IMO it's fine since Vitess provides enough
  redundancy that one shard has plenty of failure-domain reliability),
  you can also use the built-in Hadoop support they have for doing
  exactly what has been described (merge sorting the result of cross-cell
  queries).

- If we adopted those, the only reason for cells would be to allow
  setting up new batches of hosts to pre-test before unleashing the
  world on them.  Except, we could do that with host aggregates and
  permissions that hide/expose the right flavors for testing.


So, I have to ask, why is cells v2 being pushed so hard without looking
outside OpenStack for actual existing solutions, which, IMO, are
_numerous_, battle hardened, and simpler than cells.

[1] http://qpid.apache.org/components/dispatch-router/
[2] http://vitess.io/

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

[openstack-dev] [neutron] [qos] gathering Friday 9:30

[Miguel Angel Ajo Pelayo]

Does governors ballroom in Hilton sound ok?

We can move to somewhere else if necessary.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove] notes from first two days of Trove design summit sessions

[Amrith Kumar]

Here are my notes from the first two days of the Trove design summit
sessions. I will send another tomorrow after we finish the contributor
meetup.

Action items will follow tomorrow.

Thanks,

-amrith



Python3 support

- make python34 a voting test in the gate (was already done, so no
  action required)

- peterstac to ensure that trove-dashboard is python3 enabled and
  enable python34 gate changes in trove-dashboard


Multiple datastores with a single manager

etherpad: trove-newton-summit-multiple-datastores

- needs more discussion


Management client and openstack client

- add quota support through the management client (for now). this is
  trove-manage; add the ability to do quota management through
  trove-manage


Trove upgrades

etherpad: trove-newton-summit-trove-upgrades
spec: https://review.openstack.org/#/c/302416/

- the team was in agreement with the proposal that has been up for
  review.

- pete mackinnon had a specific request that some thought and research
  be put into the area of how nova rebuild may fail, and how a user
  would have to recover from this.


Extend backend persistent storage

etherpad: trove-newton-summit-extensible-backend-storage
spec: https://review.openstack.org/#/c/302952/

- the team was in agreement with the proposal that has been up for
  review.

- need to investigate supporting replicated volumes for DR and
  restoring a new database instance from a volume replica. This
  workflow is not currently possible.


Trove container support

etherpad: trove-newton-summit-container
spec: https://review.openstack.org/307883

- rather than having trove integrate with magnum, we agreed that in
  the short term we would provide containers through the nova lxc or
  lxd drivers

- the spec will need to be rewritten to reflect this, and to identify
  the work involved in doing that

- in the future, trove will have to realize how it will deal with
  clouds where this solution would not work. for example, clouds that
  run kubernetes on native bare metal and don't have nova.


Snapshot as a backup strategy

etherpad: trove-newton-summit-snapshot-as-a-backup-strategy
spec: https://review.openstack.org/#/c/306620/

- the team was in agreement with the proposal that was up for review,
  in principle. some changes are required such as to deal with
  quiescing the database.

- there was discussion of whether the operation of taking the snapshot
  would be taken by the guest agent or the task manager and the
  consensus was that the task manager should be the one generating the
  snapshot.

- it was recommended that the task manager should make a synchronous
  call to the task manager to quiesce the database, and to release it
  after the snapshot was taken. this would avoid the asynchronous
  mechanism based on cast().

- there are two operations here that could cause an interruption in
  service of the database and these relate to the period of time when
  the database is quiesced. it is possible that the operation to
  quiesce the database may take a while to happen (for example if
  there is a long running transaction going on). this could cause the
  call() from the task manager to timeout. Similarly once the database
  is quiesced, the snapshot may take a while. It was suggested that
  there should be mechanisms to place limits on how long either of
  these can take.

- it should be configurable to determine where the snapshot will get
  stored; if we have to actually stream it somewhere. this is not
  necessarily the case for all storage solutions.

- point in time rollback is not a deliverable of this project.


Make it easier to build guest images

etherpad: trove-newton-summit-easier-to-build-images
spec: https://review.openstack.org/#/c/295274/

- the consensus was that we should create a new repository (named
  something like trove-image-builder) and pick up all the elements
  from trove-integration and move them here

- we need to write a new element to install the guestagent code into
  the image

- we need to write a image-builder script that would do the moral
  equivalent of redstack build-image

- that script/tool should allow for creation of both
  development/testing images and images that a customer could use.

- [amrith] to send a note to the ML with the [dib] in the subject line
  and keep the dib folks informed if there are real problems that we
  face with the tool

- pete mackinnon will be working to update and provide elements with
  dib that will generate database images for some databases and
  operating system (CentOS 7)

- there was no consensus on whether the future should be dib based or
  libvirt-customize based

- there was a concern that if we ended up with a different tool in the
  future, there would end up being duplication and redundancy in the
  image-builder tool

- once we get the elements out of trove-integration, if there's not
  much left there we can move it to the trove project and get rid of
  trove-integration altogether.

[openstack-dev] [Cinder] Summit Social

[Sean McGinnis]

The Cinder team (and friends) will be getting together for an informal
outing tonight.

The plan is to meet at Easy Tiger at 6 tonight:

http://easytigeraustin.com/

All are welcome!

Sean (smcginnis)

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

Re: [openstack-dev] [Cinder] Newton Midcycle Planning

[Sean McGinnis]

The results are in!

We took a look at the SurveyMonkey results today, and we have now
formally set the dates and locations for the Cinder Newtone midcycle.

All are welcome and encouraged to attend!

https://etherpad.openstack.org/p/newton-cinder-midcycle

Sean (smcginnis)

On Tue, Apr 12, 2016 at 09:05:18AM -0500, Sean McGinnis wrote:
> Hey Cinder team (and those interested),
> 
> We've had a few informal conversations on the channel and in meetings,
> but wanted to capture some things here and spread awareness.
> 
> I think it would be good to start planning for our Newton midcycle.
> These have been incredibly productive in the past (at least in my
> opinion) so I'd like to get it on the schedule so folks can start
> planning for it.
> 
> For Mitaka we held our midcycle in the R-10 week. That seemed to work
> out pretty well, but I also think it might be useful to hold it a little
> earlier in the cycle to keep some momentum going and make sure things
> stay pretty focused for the rest of the cycle.
> 
> For reference, here is the current release schedule for Newton:
> 
> http://releases.openstack.org/newton/schedule.html
> 
> R-10 puts us in the last week of July.
> 
> I would have a conflict R-16, R-15. We probably want to avoid US
> Independence Day R-13, and milestone weeks R-18 and R12.
> 
> So potential weeks look like:
> 
> * R-17
> * R-14
> * R-11
> * R-10
> * R-9
> 
> Nova is in the process of figuring out their date. If we have that, it
> would be good to try to avoid an overlap there. Our linked midcycle
> session worked out well, but probably better if they don't conflict.
> 
> We also need to work out locations. Anyone able and willing to host,
> just let me know. We need a facility with wifi, able to hold ~30-40
> people, wifi, close to an airport. And wifi.

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

Re: [openstack-dev] [nova] Distributed Database

[Jay Pipes]

On 04/28/2016 08:44 AM, Edward Leafe wrote:

On Apr 24, 2016, at 3:28 PM, Robert Collins  wrote:

For instance, the things I think are essential for a distributed
database based datastore:
- good single-machine developer story. Must not need a physical
cluster to hack on OpenStack
- deal gracefully with single node/rack/site failures (when deployed
appropriately) - allow limiting failure domain impact
- straightforward programming model: wrong uses should be obvious to reviewers
- low latency performance with big datasets: e.g. nova list as an
admin should be able to get the Nth page as rapidly as the 2nd or 3rd.


nova list as an admin (or any user frankly) should be a proxy call to 
Project Searchlight and elasticsearch.


elasticsearch is a great interface for this kind of operation. We should 
use it.


The Cells architecture, which allows the operator to both scale the 
message queue *and* limit the scope of failure domains, is a good one. 
Having a database that stores only the local (to the cell) information 
is perfectly fine given the top-level API database's index/mapping 
tables. Where this design has short-comings, as Ed and others point out, 
are things like doing list operations across dozens of separate cells. 
So, let's not use the Nova database for that and instead use a solution 
that works very well for it: Project Searchlight.


And for those that have small clouds and/or don't want/need to install 
elasticsearch, OK, cool, stick with a single cell and a single RDBMS 
instance.


Best,
-jay

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

[openstack-dev] [neutron][taas] TaaS meetup in Austin

[Anil Rao]

Hi,

The TaaS team is planning to meet on Friday morning (29th Apr) in the Design 
Summit area to discuss project status, pending issues and new work items. 
Anyone interested in the project is welcome to join.

We will send out the time and location as soon as there is an agreement.

Regards,
Anil

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

[openstack-dev] Mitaka - OVS Firewall Driver, not working = OVSFWPortNotFound

[Martinx - ジェームズ]

Guys,

 I'm trying to enable OVS Firewall Driver in my Cloud Env but, it is not
working...

 I'm trying to replace the following line (openvswitch_agent.ini config
across the cloud):

---
 firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
---

 By this:

---
 firewall_driver = openvswitch
---

 But it does not work in a multi-node env (all-in-one looks good).

 I'm seeing the following error on Neutron OpenvSwitch Agents, while trying
to launch Instances:

 "OVSFWPortNotFound" Port "is not managed by this agent"

 Full log putput:

 http://paste.openstack.org/show/495252/

 The result is that instances are inaccessible from its Floating IP.
Rolling back to OVSHybrid, all goo again.

 What am I missing?

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

Re: [openstack-dev] [neutron] Social at the summit

[Darek Smigiel]

Unfortunately, I’ve got response from Bangers, that they’re fully booked for 
Today

"Thank you for your interest in hosting a business dinner with us at Banger's 
tonight. Unfortunately we are booked with reservations this evening, so I am 
unable to accommodate your request. I wish you all the best in finding the 
perfect venue for your event.”

Are we trying to find some other spot, or just keep Bangers and we will see?

Darek

> On Apr 26, 2016, at 8:27 PM, Kyle Mestery  wrote:
> 
> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a reservation 
> but it should be able to hold 50+ people. See y'all at 6PM Thursday!
> 
> Kyle
> 
>> On Apr 25, 2016, at 1:07 PM, Kyle Mestery  wrote:
>> 
>> OK, there is enough interest, I'll find a place on 6th Street for us
>> and get a reservation for Thursday around 7 or so.
>> 
>> Thanks folks!
>> 
>>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
>>> +1 :)
>>> 
>>> Han Zhou
>>> Irc: zhouhan
>>> 
>>> 
>>> On Monday, April 25, 2016, Korzeniewski, Artur
>>>  wrote:
 
 Sign me up :)
 
 Artur
 IRC: korzen
 
 -Original Message-
 From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
 Sent: Monday, April 25, 2016 7:19 PM
 To: OpenStack Development Mailing List (not for usage questions)
 
 Subject: Re: [openstack-dev] [neutron] Social at the summit
 
 Count me in!
 Will be good to meet all you guys!
 
 Darek (dasm) Smigiel
 
> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>  wrote:
> 
> 
>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
>> wrote:
>> 
>> WAT???
>> 
>> It was never supposed to be core only. Everyone is welcome!
> 
> +2
> 
> irony intended.
> 
> Socials are not controlled by gerrit ACLs.  :-)
> 
> doug
> 
>> 
>> Sent from my iPhone
>> 
>>> On 25 Apr 2016, at 11:56, Edgar Magana 
>>> wrote:
>>> 
>>> Would you extend it to ex-cores?
>>> 
>>> Edgar
>>> 
>>> 
>>> 
>>> 
 On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
 
 Ihar, Henry and I were talking and we thought Thursday night makes
 sense for a Neutron social in Austin. If others agree, reply on this 
 thread
 and we'll find a place.
 
 Thanks!
 Kyle
 
 ___
 ___ OpenStack Development Mailing List (not for usage
 questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> __ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [nova] Distributed Database

[Mike Bayer]

On 04/28/2016 08:44 AM, Edward Leafe wrote:

On Apr 24, 2016, at 3:28 PM, Robert Collins  wrote:


For instance, the things I think are essential for a distributed
database based datastore:
- good single-machine developer story. Must not need a physical
cluster to hack on OpenStack
- deal gracefully with single node/rack/site failures (when deployed
appropriately) - allow limiting failure domain impact
- straightforward programming model: wrong uses should be obvious to reviewers
- low latency performance with big datasets: e.g. nova list as an
admin should be able to get the Nth page as rapidly as the 2nd or 3rd.
- code to deliver that should be (approximately) no worse than the current code


Agree on all of these points, as well as the rest of your post.

After several hallway track discussions, as well as yesterday’s Cells V2 
discussion, I’ve written a follow-up post:

http://blog.leafe.com/index.php/2016/04/28/fragmented-data/

Feedback, of course, is welcomed!



Regarding ROME [1], I've taken a look at its source code and while it is 
certainly interesting, I wouldn't recommend lifting and moving all of 
Nova's database infrastructure onto it as a dependency within the near 
term, as the state of this code is very immature.  SQLAlchemy itself was 
once immature as well, so there is no sin here, but that was eleven 
years ago.


The internals here are not only highly dependent on SQLAlchemy internals 
(pinned at the 0.9 series which is obsolete), it is using these APIs in 
a very brittle and non-performant way [2].  In this code example, the 
internal elements of SQLAlchemy expression objects are repeatedly run 
through str() which on each call runs a full string compilation step in 
order to test for what their actual type is.  It can't be overstated how 
inappropriate this approach is and the author of the library would have 
benefited from reaching out to me in order to get some guidance on the 
correct way to introspect SQLAlchemy expression objects.  Basic Python 
idioms like type checking also seem to be misunderstood [3].


I don't think anyone denies that Nova can use any kind of database 
backend but the point was raised that to start from scratch with an 
entirely new database approach is an enormous job.   If the first step 
of that job is in fact "port SQLAlchemy and the relational model to 
Redis", that makes the job extremely more involved and I'd disagree with 
your post's assertion that "It's not too late" if this is the case. 
If the admission of ROME for Nova is that the relational model is in 
fact necessary for Nova, then that disqualifies NoSQL databases out of 
the gate - it's one thing to lament that MySQL is not as "distributed" 
out of the box as a NoSQL database, but it's another to lament that 
non-relational databases are not in fact relational.


[1] https://github.com/BeyondTheClouds/rome

[2] 
https://github.com/BeyondTheClouds/rome/blob/master/lib/rome/core/expression/expression.py#L172


[3] 
https://github.com/BeyondTheClouds/rome/blob/master/lib/rome/core/expression/expression.py#L102





-- Ed Leafe






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



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

[openstack-dev] [Openstack-operators] [OpenStack-Ansible] Mitaka Upgrade

[Wade Holler]

Hi All,

If this is RTFM please point me there and I apologize.

If not:

We are testing the Liberty to Mitaka transition with OSAD.  Could someone
please advise if these were the correct general steps.

osad multinode (VMs/instances inside a osad cloud) built with latest 12.X
liberty osad
1. save off config files: openstack_user_config.yml, user_variables,yml,
...hostname..., inventory,  etc.
2. rm -rf /etc/openstack_deploy; rm -rf /opt/openstack-ansible
3. git clone -b stable/mitaka 
4. copy config files back in place
5. ./scripts/bootstrap-ansible.sh
6. openstack-ansible setup-everything.yml

That is the process we ran and it appears to have went well after adding
the "-e rabbit_upgrade=true" flag.

Only straggler process that I found so far was a neutron-ns-metadata-proxy
that was still running 12.X liberty code.  restarted the container and it
didn't start again, but the 13.X mitaka version is running ( and was before
shutdown ).

Is this the correct upgrade process or are there other steps / approaches
that should be taken ?

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

Re: [openstack-dev] Question about OpenStack Code of Conduct

[Mike Perez]

On 17:54 Apr 21, Adrian Otto wrote:
> Below is an excerpt from:
> https://www.openstack.org/legal/community-code-of-conduct/
> 
> "When we disagree, we consult
> others. Disagreements, both social and technical, happen all the time and the
> OpenStack community is no exception. It is important that we resolve
> disagreements and differing views constructively and with the help of the
> community and community processes. We have the Technical Board, the User
> Committee, and a series of other governance bodies which help to decide the
> right course for OpenStack. There are also Project Core Teams and Project
> Technical Leads, who may be able to help us figure out the best direction for
> OpenStack. When our goals differ dramatically, we encourage the creation of
> alternative implementations, so that the community can test new ideas and
> contribute to the discussion.”
> 
> Does the “Technical Board” mentioned above mean “Technical Committee” or
> “Foundation board of directors”? It is not clear to me when consulting our
> list of governance bodies[1]. It’s mentioned along with the “User Committee”,
> so I think the text actually meant “Technical Committee”. Who can clarify
> this ambiguity?

It is the technical committee. An update to clarify this will be made shortly.

-- 
Mike Perez

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

[openstack-dev] [Docs] Installation Guide Plans for Newton

[Lana Brindley]

Greetings from Austin!

Yesterday we held the Install Guide planning workgroup. It was a full room, 
with some very robust discussion, and I want to thank everyone for 
participating and sharing their thoughts on this matter. We have some solid 
goals to achieve for Newton now.

The etherpad with the discussion is here: 
https://etherpad.openstack.org/p/austin-docs-workgroup-install

The original spec to create a way for projects to publish Instal Guides has now 
been merged, thanks to consensus being achieved at the Design Summit session, 
and a few minor edits: https://review.openstack.org/#/c/301284/ We can now 
begin work on this.

There is a new spec up to cover the remainder of the work to be done on the 
existing Install Guide: https://review.openstack.org/#/c/310588 This still 
needs some iterations to get it into shape (including determining the name we 
are going to use for the Install Guide). So, patches welcome.

Again, thank you to all the many people who attended the session, and those who 
have found me this week and discussed the future of the Install Guide. I'm 
confident that this plan has broad acceptance, is achievable during the Newton 
cycle, and it moves the documentation project forward.

Feedback is, as always, very welcome.

Lana


-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

[openstack-dev] [Manila] Design summit etherpads

[Ben Swartzlander]

Here at the design summit I've been asked a few times where the 
etherpads are. Here is a link to the top level page for design summit 
etherpads:


https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Manila

-Ben

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

Re: [openstack-dev] [Cinder] The way to get traces of compiling fails when cinder service restarts

[Jay S. Bryant]

Jun-ha,

Do you have 'verbose = true' and 'debug = true' set in 
/etc/cinder/cinder.conf ?


If not, try setting those options and restarting your services.

Jay

On 04/28/2016 01:20 AM, 박준하 wrote:


Hi all,

I’m a beginner of Openstack.

I tried to modified some sources in Cinder directories for studying 
and restart services such as cinder-api, cinder-volume, cinder-scheduler.


But, I could not discover any compile error on ‘/var/log/*’

I want to watch compile errors with python Traceback.

Is there the best way to debugging on service level?

Thanks

Jun-ha Park

Dept. Cloud Technology group. KINX corp. , Korea



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


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

Re: [openstack-dev] [nova] Distributed Database

[Edward Leafe]

On Apr 24, 2016, at 3:28 PM, Robert Collins  wrote:

> For instance, the things I think are essential for a distributed
> database based datastore:
> - good single-machine developer story. Must not need a physical
> cluster to hack on OpenStack
> - deal gracefully with single node/rack/site failures (when deployed
> appropriately) - allow limiting failure domain impact
> - straightforward programming model: wrong uses should be obvious to reviewers
> - low latency performance with big datasets: e.g. nova list as an
> admin should be able to get the Nth page as rapidly as the 2nd or 3rd.
> - code to deliver that should be (approximately) no worse than the current 
> code

Agree on all of these points, as well as the rest of your post.

After several hallway track discussions, as well as yesterday’s Cells V2 
discussion, I’ve written a follow-up post: 

http://blog.leafe.com/index.php/2016/04/28/fragmented-data/

Feedback, of course, is welcomed!


-- Ed Leafe






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

Re: [openstack-dev] Lookig for suggessions on a new module "cloudlet" in OprnStack under bigtent

[lebre . adrien]

Hi Prakash, 

Maybe you can give a look at the Massively Distributed Group that aims to 
investigate how OpenStack can address the Fog/Edge Computing use-case. The 
inaugural meeting was two days ago: 

Overview
https://etherpad.openstack.org/p/massively-distributed-clouds-overview

Austin meeting
https://etherpad.openstack.org/p/massively-distributed-clouds-inaugural-meeting

If I remind your presentation correctly, there are several connection 
opportunities. 

BR,  
Adrien

- Mail original -
> De: "prakash RAMCHANDRAN" 
> À: openstack-dev@lists.openstack.org
> Envoyé: Jeudi 28 Avril 2016 11:19:54
> Objet: [openstack-dev] Lookig for suggessions on a new module "cloudlet" in 
> OprnStack under bigtent
> 
> 
> 
> 
> Hi all,
> 
> 
> Having attempted to introduce Cloudlet API in Nova for Liberty and
> later trying to bring use case to Product Working Group (PWG) it
> appears we need volunteers and advisors who can help get us a new
> project in Openstack. Any past PTLs who can steer this efforts are
> welcome too to look at this new opportunity to lead and guide us. I
> am open to leading it but would like prople with better skills and
> experience in OpenStack to drive it.
> 
> 
> 
> Driving Cloudlet into Openstack » OpenStack Open Source Cloud
> Computing Software
> 
> 
> 
>   
> 
>   Driving Cloudlet into Openstack » OpenStack Open Source 
> Cloud
>   Computing Sof...
> 
>   
> 
> 
> I am still hopeful in meeting PWG team and let me know the etherpad
> where I can try put my request for Edge cloud or cloudlet before
> coming Friday.
> 
> 
> Thanks
> Prakash
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] Lookig for suggessions on a new module "cloudlet" in OprnStack under bigtent

[prakash RAMCHANDRAN]

Hi all,
Having attempted to introduce Cloudlet API in Nova for Liberty and later trying 
to bring use case to Product Working Group (PWG) it appears we need volunteers 
and advisors who can help get us a new project in Openstack. Any past PTLs who 
can steer this efforts are welcome too to look at this new opportunity to lead 
and guide us. I am open to leading it but would like prople with better skills 
and experience in OpenStack to drive it.

Driving Cloudlet into Openstack » OpenStack Open Source Cloud Computing Software

  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Driving Cloudlet into Openstack » OpenStack Open Source Cloud Computing Sof...
   |   |

  |

  |

 
I am still hopeful in meeting PWG team and let me know the etherpad where I can 
try put my request for Edge cloud or cloudlet before coming Friday.
ThanksPrakash

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

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

[Eli Qiao]

hi Mike

Can you please also consider the effect to do rebuild/resize a bay if 
you want to support more than 1 nova flavor?


There are some discussion while in Austin summit, check 
https://etherpad.openstack.org/p/newton-magnum-bays-lifecycle-operations


Thanks
Eli.

On 2016年04月28日 16:52, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) wrote:


Hi Kai Qiang,

Thanks for your comments,  your consideration is very comprehensive, I 
think it is a good way to implement this feature.


Regards

Mike

Date: Wed, 27 Apr 2016 17:38:32 +0800

From: "Kai Qiang Wu" 

To: "OpenStack Development Mailing List \(not for usage questions\)"



Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to

provision minion nodes

Message-ID: <201604271004.u3ra49v4008...@d23av04.au.ibm.com>

Content-Type: text/plain; charset="gb2312"

Hi Mike,

Since right now, we have also support bay-update (node_count)

I am thinking the following case:

1>  baymodel-create have default flavor, and extra labels specify 
the(other


node flavors) requirements,

if (other node flavors) count <= bay(node_count), the extra nodes would be

created use default flavor

if (other node flavors) count  > bay(node_count), it should pop error,

since it not quite clear why flavor to use

2> magnum bay-update k8sbay replace node_count < existed node_count,  it

should be OK. same as old behavior

 if node_count > existed node_count, all new nodes would use default

flavor_id, (if not, we need to find what's the better policy to handle

that)

Refer:

https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst

What do you think ?

Thanks

Best Wishes,



Kai Qiang Wu (???  Kennan?

IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com

Tel: 86-10-82451647

Address: Building 28(Ring Building), ZhongGuanCun Software Park,

 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China

100193



Follow your heart. You are miracle!

From:"Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)" 

To: "openstack-dev@lists.openstack.org"



Date: 27/04/2016 03:10 pm

Subject:   Re: [openstack-dev] [Magnum] Magnum supports 2 
Nova flavor to


provision minion nodes

Hi Hong bin,

Thanks very much. It?s good suggestion, I think it is a good way by using

labels for extra flavors. But I notice that there is not the ?node-count

parameter in baymodel.

So I think it doesn?t need specify minion-flavor-0 counts by ?node-count.

We can specify all of the flavor id and count ratio in the labels. It will

check the minion node count with this ratio of labels when creating magnum

bay that specified total minion node count . If the node-count in 
baycreate


doesn?t match with the flavor ratio, it will return the ratio match error

message.   If there is not the multi-flavor-ratio key in lables, it will

just use  minion-flavor-0  to create 10 minion nodes.

$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0

--labels multi-

flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2

$  magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 10

Do you think about it?

> -Original Message-

> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]

> Sent: April-26-16 3:01 AM

> To: openstack-dev@lists.openstack.org

> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to

> provision minion nodes

>

> Hi Hongbin, Ricardo

> This is mike, I am working with Gary now.

> Thanks for Ricardo's good suggestion. I have tried the "map/index"

> method ,  we can use it to passed the minion_flavor_map and the index

> into the minion cluster stack. It does work well.

> I think we can update magnum baymodel-create to set the N minion

> flavors in the minion_flavor_map and assign minion counts for each

> flavor.

> For example :

> magnum baymodel-create --name k8s-bay-model  --flavor-id minion-flavor-

> 0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3 types flavor

The suggested approach seems to break the existing behaviour. I think 
it is


better to support this feature in a backward-compatible way. How about

using labels:

$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0

--node-count 3 --labels

extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2

> minion node and total minion nodes count is 10. The magnum baymode.py

> will parse  this  dictionary and pass them to the heat template

> parameters minion_flavor_map, minion_flavor_count_map. Then the heat

> stack will work well.

>

> kubecluster-fedora-ironic.yaml

> parameters:

>   minion_flavor_map:

> type: json

> default:

>   '0': 

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

[Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)]

Hi Kai Qiang,

Thanks for your comments,  your consideration is very comprehensive, I think it 
is a good way to implement this feature.

Regards
Mike




Date: Wed, 27 Apr 2016 17:38:32 +0800

From: "Kai Qiang Wu" 

To: "OpenStack Development Mailing List \(not for usage questions\)"



Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to

provision minion nodes

Message-ID: <201604271004.u3ra49v4008...@d23av04.au.ibm.com>

Content-Type: text/plain; charset="gb2312"



Hi Mike,



Since right now, we have also support bay-update (node_count)



I am thinking the following case:



1>  baymodel-create have default flavor, and extra labels specify the(other

node flavors) requirements,



if (other node flavors) count <= bay(node_count), the extra nodes would be

created use default flavor



if (other node flavors) count  > bay(node_count), it should pop error,

since it not quite clear why flavor to use



2> magnum bay-update k8sbay replace node_count < existed node_count,  it

should be OK. same as old behavior

 if node_count > existed node_count, all new nodes would use default

flavor_id, (if not, we need to find what's the better policy to handle

that)



Refer:

https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst











What do you think ?







Thanks





Best Wishes,



Kai Qiang Wu (???  Kennan?

IBM China System and Technology Lab, Beijing



E-mail: wk...@cn.ibm.com

Tel: 86-10-82451647

Address: Building 28(Ring Building), ZhongGuanCun Software Park,

 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China

100193



Follow your heart. You are miracle!







From:"Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)" 

To:  "openstack-dev@lists.openstack.org"



Date: 27/04/2016 03:10 pm

Subject:   Re: [openstack-dev] [Magnum] Magnum supports 2 Nova 
flavor to

provision minion nodes







Hi Hong bin,

Thanks very much. It?s good suggestion, I think it is a good way by using

labels for extra flavors. But I notice that there is not the ?node-count

parameter in baymodel.

So I think it doesn?t need specify minion-flavor-0 counts by ?node-count.

We can specify all of the flavor id and count ratio in the labels. It will

check the minion node count with this ratio of labels when creating magnum

bay that specified total minion node count . If the node-count in baycreate

doesn?t match with the flavor ratio, it will return the ratio match error

message.   If there is not the multi-flavor-ratio key in lables, it will

just use  minion-flavor-0  to create 10 minion nodes.

$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0

--labels multi-

flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2

$  magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 10

Do you think about it?



> -Original Message-

> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]

> Sent: April-26-16 3:01 AM

> To: openstack-dev@lists.openstack.org

> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to

> provision minion nodes

>

> Hi Hongbin, Ricardo

> This is mike, I am working with Gary now.

> Thanks for Ricardo's good suggestion. I have tried the "map/index"

> method ,  we can use it to passed the minion_flavor_map and the index

> into the minion cluster stack. It does work well.

> I think we can update magnum baymodel-create to set the N minion

> flavors in the minion_flavor_map and assign minion counts for each

> flavor.

> For example :

> magnum baymodel-create --name k8s-bay-model  --flavor-id minion-flavor-

> 0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3 types flavor



The suggested approach seems to break the existing behaviour. I think it is

better to support this feature in a backward-compatible way. How about

using labels:



$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0

--node-count 3 --labels

extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2



> minion node and total minion nodes  count is 10. The magnum baymode.py

> will parse  this  dictionary and pass them to the heat template

> parameters minion_flavor_map, minion_flavor_count_map. Then the heat

> stack will work well.

>

> kubecluster-fedora-ironic.yaml

> parameters:

>   minion_flavor_map:

> type: json

> default:

>   '0': minion-flavor-0

>   '1': minion-flavor-1

>   '2': minion-flavor-2

>

>   minion_flavor_count_map:

> type: json

> default:

>   '0': 3

>   '1': 5

>   '2': 2

>

> resources:

> kube_minions_flavors:

> type: 

[openstack-dev] [neutron][sfc] Is there a bug in networking-sfc?

[张广明]

Hi Cathy and other guys
 I am a beginner that use networking-sfc. I create a port-chain-list
that want to steer a flow that is  from public-net to private-net  to SF
node.  The DVR is enable in my test environment.
The test result is the flow was steered from destination node  to SF node
and return to the destination  node rightly, but the flow was match the
classify rule again,so the flow can not to be send to
the destination VM.
  In networking-sfc agent code . there is a
function update_src_node_flow_rules  that create a normal flow to handle
this case. But in networking-sfc ovs dirver code,
_update_src_node_flowrules  can't
call ask_agent_to_update_src_node_flow_rules to notify agent to
exec update_src_node_flow_rules. The reason is  the function
 _get_portchain_src_node_flowrule return None. In  function
_get_portchain_src_node_flowrule , the check
that was marked red is not right in this  case.


def _get_portchain_src_node_flowrule(self, node,
 add_fc_ids=None, del_fc_ids=None):
try:
add_fc_rt = []
del_fc_rt = []

if add_fc_ids:
for fc in self._get_fcs_by_ids(add_fc_ids):
if not fc.get('logical_source_port', None):
add_fc_rt.append(fc)

if del_fc_ids:
for fc in self._get_fcs_by_ids(del_fc_ids):
if not fc.get('logical_source_port', None):
del_fc_rt.append(fc)

if not add_fc_rt and not del_fc_rt:
return None

return self._build_portchain_flowrule_body_without_port(
node, add_fc_rt, del_fc_rt)
except Exception as e:
LOG.exception(e)
LOG.error(_LE("_get_portchain_src_node_flowrule failed"))


  Is it a bug or my configure is wrong?



root@rg1-com01 ~]# neutron  flow-classifier-show
 4542a747-b205-41ff-970c-1ea11fa956fc
++--+
| Field  | Value|
++--+
| description|  |
| destination_ip_prefix  | 192.168.1.0/24   |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype  | IPv4 |
| id | 4542a747-b205-41ff-970c-1ea11fa956fc |
| l7_parameters  | {}   |
| logical_destination_port   |  |
| logical_source_port| f18895cf-6c4b-495a-8bd5-e8f12ae86541 |
| name   | FC-F3|
| protocol   |  |
| source_ip_prefix   | 192.168.200.0/24 |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id  | 02e5a953a113479388103c585f5b5ae1 |
++--+

the original flow  is 192.168.200.2 to 192.168.200.202 floatingip(
192.168.1.202  private ip)
logical_source_port  is  fg-xxx interface in namespace fip.

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

Re: [openstack-dev] [Cinder] The way to get traces of compiling fails when cinder service restarts

[Chinmaya Bharadwaj]

hi,

Try running it  on the  foreground, instead as a background service.

Something like :

/usr/local/bin/cinder-volume --config-file /etc/cinder/cinder.conf




#Chinmaya

On 28 April 2016 at 11:50, 박준하  wrote:

> Hi all,
>
>
>
> I’m a beginner of Openstack.
>
> I tried to modified some sources in Cinder directories for studying and
> restart services such as cinder-api, cinder-volume, cinder-scheduler.
>
> But, I could not discover any compile error on ‘/var/log/*’
>
> I want to watch compile errors with python Traceback.
>
> Is there the best way to debugging on service level?
>
>
>
> Thanks
>
>
>
> Jun-ha Park
>
> Dept. Cloud Technology group. KINX corp. , Korea
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] How to paginate Data Table to display only 5 rows every page ?

[Timur Sufiev]

Yes, you can maintain a downstream fork if you wish.
On Thu, 28 Apr 2016 at 05:34, 严超  wrote:

> Can we hard code only one table to 5 rows limit default ? And leave other
> tables not touched.
> Thank you very much !
>
> 严超 于2016年4月28日周四 上午6:58写道：
>
>> Oh, sorry, I mean, can we hard code only one table to 5 rows default ?
>> And leave others not touched.
>> Thank you very much !
>>
>> *Best Regards！*
>>
>>
>> *Chao Yan--About me ： http://about.me/chao_yan
>> *
>>
>> *My twitter： @yanchao727 *
>> *My Weibo： http://weibo.com/herewearenow *
>> *--*
>>
>> 2016-04-28 1:51 GMT+08:00 Timur Sufiev :
>>
>>> Definitely, yes
>>>
>>> See how it's done for Images:
>>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/images/views.py#L35
>>>
>>> Also, limit of items per table page is set in User Settings
>>> (->Settings at top right corner of the dashboard), it's not
>>> hard-coded. Once you set it, all tables which support pagination (see the
>>> pattern above) display the specified number of items per page.
>>>
>>> On Wed, Apr 27, 2016 at 1:00 PM 严超  wrote:
>>>
 Hi, Everyone:
 Is there a possible way to paginate DataTable to display only 5
 rows every page ?
 I'm very grateful for reply.

 *Best Regards！*


 *Chao Yan--About me ： http://about.me/chao_yan
 *

 *My twitter： @yanchao727 *
 *My Weibo： http://weibo.com/herewearenow
 **--*

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

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

[openstack-dev] [Cinder] The way to get traces of compiling fails when cinder service restarts

[박준하]

Hi all,

 

I’m a beginner of Openstack.

I tried to modified some sources in Cinder directories for studying and
restart services such as cinder-api, cinder-volume, cinder-scheduler. 

But, I could not discover any compile error on ‘/var/log/*’ 

I want to watch compile errors with python Traceback.

Is there the best way to debugging on service level?

 

Thanks

 

Jun-ha Park

Dept. Cloud Technology group. KINX corp. , Korea

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