Re: [openstack-dev] [Heat] Multi region support for Heat

[Steve Baker]

On 07/23/2013 10:46 AM, Angus Salkeld wrote:
> On 22/07/13 16:52 +0200, Bartosz Górski wrote:
>> Hi folks,
>>
>> I would like to start a discussion about the blueprint I raised about
>> multi region support.
>> I would like to get feedback from you. If something is not clear or
>> you have questions do not hesitate to ask.
>> Please let me know what you think.
>>
>> Blueprint:
>> https://blueprints.launchpad.net/heat/+spec/multi-region-support
>>
>> Wikipage:
>> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
>>
>
> What immediatley looks odd to me is you have a MultiCloud Heat talking
> to other Heat's in each region. This seems like unneccessary
> complexity to me.
> I would have expected one Heat to do this job.

It should be possible to achieve this with a single Heat installation -
that would make the architecture much simpler.

I've been thinking about this recently and can see a more generic case
than multi-region.

Currently a stack is launched into a single cloud, into a context which
includes:
- keystone endpoint
- tenant/project
- user credentials

If this context was represented as a template resource (and also
specified a region), then other resources could specify which context to
provision within.

This is more generic than multi-region because some contexts can have
completely different keystone endpoints (multi-cloud), or can have the
same endpoint & region and only differ in the credentials or tenant.

This could also fulfill requirements such as these
https://lists.launchpad.net/openstack/msg25031.html

So I would modify your blueprint template examples in the following way:
- assume the new HOT template work will provide something that will make
those Mappings sections unnecessary
- Create a new resource OS::Cloud::Context with properties for keystone
endpoint, tenant, credentials and region.
- Allow all other resources to optionally specify a context (instead of
RegionName)
- in the implementation, give the resource the appropriate instance of
OpenStackClients which matches the requested context

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

[openstack-dev] Scheduler sub-group meeting agenda 7/23

[Dugger, Donald D]

Looks like some interesting threads started up on the mailing list that we can 
talk about if people are available:

1)  Ceilometer vs. Nova metrics collector
2)  A simple way to improve Nova scheduler
3)  Multiple active scheduler policies/drivers

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786



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

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

[Alex Glikson]

Russell Bryant  wrote on 23/07/2013 01:04:24 AM:
> > [1] 
https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
> > [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies
> > [3] https://review.openstack.org/#/c/37407/
> 
> Thanks for bringing this up.  I do have some comments.

Thanks for the comments. See below.

> 
> The current design shows 2 different use cases for how a scheduling
> policy would be chosen.
> 
> #1 - policy associated with a host aggregate
> 
> This seems very odd to me.  Scheduling policy is what chooses hosts, so
> having a subset of hosts specify which policy to use seems backwards.

This is not what we had in mind. Host aggregate is selected based on 
policy passed in the request (hint, extra spec, or whatever -- see below) 
and 'policy' attribute of the aggregate -- possibly in conjunction with 
'regular' aggregate filtering. And not the other way around. Maybe the 
design document is not clear enough about this point.

> #2 - via a scheduler hint
> 
> It also seems odd to have the user specifying scheduling policy.  This
> seems like something that should be completely hidden from the user.
> 
> How about just making the scheduling policy choice as simple as an item
> in the flavor extra specs?

This is certainly an option. It would be just another implementation of 
the policy selection interface (implemented using filters). In fact, we 
already have it implemented -- just thought that explicit hint could be 
more straightforward to start with. Will include the implementation based 
on flavor extra spec in the next commit.

> The design also shows some example configuration.  It shows a global set
> of enabled scheduler filters, and then policy specific tweaks of filter
> config (CPU allocation ratio in the example).  I would expect to be able
> to set a scheduling policy specific list of scheduler filters and
> weights, as well.

This is certainly supported. Just didn't want to complicate the example 
too much. It could be even a different driver, assuming that the driver 
complies with the 'policy' attribute of the aggregates -- which is 
achieved by PolicyFilter in FilterScheduler. We plan to make other drivers 
'policy-aware' in a future patch, leveraging the new db method that 
returns hosts belonging to aggregates with compatible policies.

Hope this clarifies the concerns.

Regards,
Alex

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

Re: [openstack-dev] [neutron] Configuration file generator

[Zhongyue Luo]

On Tue, Jul 23, 2013 at 6:55 AM, Emilien Macchi  wrote:

>  Also for your information,
>
> I created a bug : https://bugs.launchpad.net/neutron/+bug/1199963
> and a first patchset for generating the new configuration file with Oslo
> config scripts :
> https://review.openstack.org/#/c/36546/
>
> Emilien Macchi
> 
> # OpenStack Engineer
> // eNovance Inc.  http://enovance.com
> // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80
> // 10 rue de la Victoire 75009 Paris
>
> On 07/22/2013 06:34 PM, Julien Danjou wrote:
>
> Hi there,
>
> I've been working on the changes that would need to be done to make the
> default config generator work for Neutron.
>
> However, the current default config generator doesn't support the
> possibility to generate different configuration files (e.g. one per
> service/plugin). I can imagine two options:
>
> a. move every options in oslo.config.cfg.CONF, moving the plugins into
>their own section rather than in their own file, register all options
>at module-level, avoiding duplicate options.
>
> b. enhance config.generator to generate a config file from a particular
>object (not always olso.config.cfg.CONF like it's done currently).
>That means Neutron should evolve to provide a global CONF object per
>plugin at least.
>
>
Actually the current generator script looks for an instance or a list of
instances of classes which are inherited from cfg.Opt. For example, if
module a.py has

_opt = cfg.StrOpt(a)
_opts = [
cfg.IntOpt(b),
cfg.BoolOpt(c),
]

Then the generator.py catches _opt and _opts and prints the config info
onto the config file.
The group info of a particular option is searched in oslo.config.cfg.CONF.

>
> Option a. is how all other OpenStack projects¹ are working so far.
> Option b. requires a bit more work on both side.
>
> Is there any particular way you guys see things?
>
> IMO, we shouldn't change how Neutron uses its config files due to
backwards compatibility issues. I was thinking of each project having a
openstack-config.conf file (like openstack-common.conf) which contains the
mapping of options to config file names.
Then the generator.py will load the openstack-config.conf file and generate
config files accordingly. An exception will be raised If an option is
neglected in openstack-config.conf

But whatever path we take, it would be hard to land a perfect solution
within Havana. So I suggest we first stick with neutron.conf.sample for now.

>
> ¹  nova, ceilometer and heat at least for now
>
>
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://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
>
>


-- 
*Intel SSG/STOD/DCST/CIT*
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
China
+862161166500
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] There are no OpenStack talks submitted to XenCon, CFP ends this week

[Coby Randquist]

Speaking of deafening silence…

We launched the CFP for OpenStack on Ales http://openstack.onales.com and
have only received a handful of proposals so far.  The event is September
30 and October 1, 2013.  CFP is set to close August 15.




On Mon, Jul 22, 2013 at 7:39 PM, Michael Still  wrote:

> On Tue, Jul 23, 2013 at 5:19 AM, Atwood, Mark  wrote:
> > Hi!
> >
> > While I was at the Community Leadership Summit conference this weekend,
> I met the community manager for the Xen hypervisor project.  He told me
> that there are *no* OpenStack talks submitted to the upcoming XenCon
> conference.
> >
> > The CFP closes this Friday.
> >
> > Allow me to suggest that any of us who have something to say about Xen
> in Nova in OpenStack, submit papers.
>
> Mark -- I can't see an obvious URL for the CFP. Can you chase down the
> community manager and ask what it is?
>
> Michael
>
>
> --
> Rackspace Australia
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] There are no OpenStack talks submitted to XenCon, CFP ends this week

[Michael Still]

On Tue, Jul 23, 2013 at 5:19 AM, Atwood, Mark  wrote:
> Hi!
>
> While I was at the Community Leadership Summit conference this weekend, I met 
> the community manager for the Xen hypervisor project.  He told me that there 
> are *no* OpenStack talks submitted to the upcoming XenCon conference.
>
> The CFP closes this Friday.
>
> Allow me to suggest that any of us who have something to say about Xen in 
> Nova in OpenStack, submit papers.

Mark -- I can't see an obvious URL for the CFP. Can you chase down the
community manager and ask what it is?

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] There are no OpenStack talks submitted to XenCon, CFP ends this week

[Joshua McKenty]

Sounds like a deafening silence.

--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Jul 22, 2013, at 12:19 PM, "Atwood, Mark"  wrote:

> Hi!
> 
> While I was at the Community Leadership Summit conference this weekend, I met 
> the community manager for the Xen hypervisor project.  He told me that there 
> are *no* OpenStack talks submitted to the upcoming XenCon conference.
> 
> The CFP closes this Friday.
> 
> Allow me to suggest that any of us who have something to say about Xen in 
> Nova in OpenStack, submit papers.
> 
> Thanks!
> 
> ..m
> 
> -- 
> Mark Atwood 
> Director - Open Source Engagement for HP Cloud Services and OpenStack
> +1-206-473-7118
> 
> 
> 
> ___
> 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] [vmware] VMwareAPI sub-team status update 2013-07-22

[Shawn Hartsock]

** No meeting this week **

I have a conflict and can't run the meeting this week. We'll be back 
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130731T1700

Two of us ran into a problem with an odd pep8 failure:
> E: nova.conf.sample is not up to date, please run 
> tools/conf/generate_sample.sh

Yaguang Tang gave the work around:
"nova.conf.sample is not up to date, please run tools/conf/generate_sample.sh 
,then resubmit."

I've put all these reviews under the "re-work" section. Hopefully this is 
simple and we can fix them this week.

Blueprints targeted for Havana-3:
* https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy - 
nova.conf.sample out of date
* 
https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service
 - needs review

New Blueprint:
* https://blueprints.launchpad.net/nova/+spec/vmware-configuration-section

Needs one more +2 / Approve button:
* https://review.openstack.org/#/c/33504/
* https://review.openstack.org/#/c/36411/

Ready for core-reviewer:
* https://review.openstack.org/#/c/33100/

Needs VMware API expert review (no human reviews):
* https://review.openstack.org/#/c/30282/
* https://review.openstack.org/#/c/30628/
* https://review.openstack.org/#/c/32695/
* https://review.openstack.org/#/c/37389/
* https://review.openstack.org/#/c/37539/

Work/re-work in progress:
* https://review.openstack.org/#/c/30822/ - weird Jenkins issue, fault is not 
in the patch
* https://review.openstack.org/#/c/37819/ - weird Jenkins issue, fault is not 
in the patch
* https://review.openstack.org/#/c/34189/ - in danger of becoming "abandoned"

Needs help/discussion (has a -1):
* https://review.openstack.org/#/c/34685/
* https://review.openstack.org/#/c/34685/

Meeting info:
* https://wiki.openstack.org/wiki/Meetings/VMwareAPI

# Shawn Hartsock

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

Re: [openstack-dev] [neutron] Neutron Network Statistics

[Nachi Ueno]

Hi Mellquist

I'm also interested in the feature.
Could you write some blueprint for proposal?

(May be havana is overloaded, so it will go to icehouse)

Best
Nachi


2013/7/22 Mellquist, Peter :
> Hi!
>
>
>
> I am interested to know if the topic of surfacing networking statistics
> through the Neutron APIs has been discussed and if there are any existing
> blueprints working on this feature?  Specifically,  the current APIs,
> https://wiki.openstack.org/wiki/Neutron/APIv2-specification, do not support
> reading network counters typically available through SNMP. I think these
> ‘/stats’ would prove to be quite valuable for performance and fault
> monitoring. If I am a Openstack / Neutron tenant and I have created my own
> networks, how can I see performance and faults?
>
>
>
> Examples,
>
> GET /networks/{network_id}/stats
>
> GET/subnets/{subnet-id}/stats
>
> GET   /floatingips/{floatingip_id}/stats
>
>
>
> Status  : [up,down,error]
>
> Usage   : [sum of Tx and Rx packets]
>
> ReceivedRate: [Rate of data received in kB/sec]
>
> TransmittedRate : [Rate of data transmitted in kB/sec]
>
> PacketTx: [total # of packets transmitted since reset]
>
> PacketRx: [total # of packets received in since reset]
>
> Etc …
>
>
>
>
>
> Thanks,
>
> Peter.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [neutron] Neutron Network Statistics

[Mellquist, Peter]

Hi!

I am interested to know if the topic of surfacing networking statistics through 
the Neutron APIs has been discussed and if there are any existing blueprints 
working on this feature?  Specifically,  the current APIs, 
https://wiki.openstack.org/wiki/Neutron/APIv2-specification, do not support 
reading network counters typically available through SNMP. I think these 
'/stats' would prove to be quite valuable for performance and fault monitoring. 
If I am a Openstack / Neutron tenant and I have created my own networks, how 
can I see performance and faults?

Examples,
GET /networks/{network_id}/stats
GET/subnets/{subnet-id}/stats
GET   /floatingips/{floatingip_id}/stats

Status  : [up,down,error]
Usage   : [sum of Tx and Rx packets]
ReceivedRate: [Rate of data received in kB/sec]
TransmittedRate : [Rate of data transmitted in kB/sec]
PacketTx: [total # of packets transmitted since reset]
PacketRx: [total # of packets received in since reset]
Etc ...


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

Re: [openstack-dev] [keystone] Split the Identity Backend blueprint

[Adam Young]

On 07/22/2013 07:43 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) 
wrote:


Adam,

You wrote:

[identity]

 driver = keystone.identity.backends.ldap.Identity

[assignment]

driver = keystone.assignment.backends.sql.Identity

Did you mean to write:

[assignment]

driver = keystone.assignment.backends.sql.Assignment


Yes, that was a mistake on my part.  Sorry


Mark

*From:*Adam Young [mailto:ayo...@redhat.com]
*Sent:* Monday, July 22, 2013 12:50 PM
*To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis)
*Cc:* Dolph Mathews; OpenStack Development Mailing List
*Subject:* Re: [keystone] Split the Identity Backend blueprint

On 07/22/2013 01:38 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) 
wrote:


Hello,

I have been reading source code in an attempt to figure out how to
use the new split backend feature, specifically how to split the
identity data between an ldap server and the standard Keystone sql
database. However, I haven't been able to figure it out quite yet.
Does someone have some examples of this new feature in action? Is
there another configuration file that is required?

[identity]

driver = driver = keystone.identity.backends.sql.Identity

[assignment]

driver = ???

[ldap]

Quite a few options

Regards,

Mark Miller


RIght now the only support split approach is LDAP for Identity, SQL 
for assignments.


[identity]

 driver = keystone.identity.backends.ldap.Identity

[assignment]

driver = keystone.assignment.backends.sql.Identity



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

[openstack-dev] [ceilometer] [horizon] Python client uncapping, currently blocking issues

[Sean Dague]

A couple weeks ago after a really *fun* night we started down this road 
of uncapping all the python clients to ensure that we're actually 
testing the git clients in the gate. We're close, but we need the help 
of the horizon and ceilometerclient teams to get us there:


1) we need a rebase on this patch for Horizon - 
https://review.openstack.org/#/c/36897/


2) we need a python-ceilometerclient release, as ceilometer uses 
python-ceilometerclient (for unit tests) which means we can't bump 
ceilometer client (https://review.openstack.org/#/c/36905/) until it's done.


After which we should have a clean gate, and we can look at enforcing 
behavior in it.


Would really appreciate help by the horizon and ceilometer teams to get 
this sorted shortly.


-Sean

--
Sean Dague
http://dague.net

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

Re: [openstack-dev] A simple way to improve nova scheduler

[Joshua Harlow]

An interesting idea, I'm not sure how useful it is but it could be.

If you think of the compute node capability information as an 'event stream' 
then you could imagine using something like apache flume 
(http://flume.apache.org/) or storm (http://storm-project.net/) to be able to 
sit on this stream and perform real-time analytics of said stream to update how 
scheduling can be performed. Maybe the MQ or ceilometer can be the same 
'stream' source but it doesn't seem like it is needed to 'tie' the impl to 
those methods. If you consider compute nodes as producers of said data and then 
hook a real-time processing engine on-top that can adjust some scheduling 
database used by a scheduler then it seems like u could vary how often compute 
nodes produce said stream info, where and how said stream info is stored and 
analyzed which will allow you to then adjust how 'real-time' you want said 
compute scheduling capability information to be up to date.

Just seems that real-time processing  is a similar model as what is needed here.

Maybe something like that is where this should end up?

-Josh

From: Joe Gordon mailto:joe.gord...@gmail.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 22, 2013 3:47 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] A simple way to improve nova scheduler




On Mon, Jul 22, 2013 at 5:16 AM, Boris Pavlovic 
mailto:bo...@pavlovic.me>> wrote:
Joe,

>> Speaking of Chris Beherns  "Relying on anything but the DB for current 
>> memory free, etc, is just too laggy… so we need to stick with it, IMO." 
>> http://lists.openstack.org/pipermail/openstack-dev/2013-June/010485.html

It doesn't scale, use tons of resources, works slow and is hard to extend.
Also the mechanism of getting free and used memory is done by virt layer.
And only thing that could be laggy is rpc (but it is used also by compute node 
update)

You say it doesn't scale and uses tons of resources can you show to reproduce 
your findings.  Also just because the current implementation of the scheduler 
is non-optimal doesn't mean the no DB is the only solution, I am interested in 
seeing other possible solutions before going down such a drastically different 
road (no-db).  Such as pushing more of the logic into the DB and not searching 
through all compute nodes in python space or looking at removing the periodic 
updates all  together or ???.



>> * How do you bring a new scheduler up in an existing deployment and make it 
>> get the full state of the system?

You should wait for a one periodic task time. And you will get full information 
about all compute nodes.

sure, that may work we need to add logic in to handle this.


>> *  Broadcasting RPC updates from compute nodes to the scheduler means every 
>> scheduler has to process  the same RPC message.  And if a deployment hits 
>> the point where the number of compute updates is consuming 99 percent of the 
>> scheduler's time just adding another scheduler won't fix anything as it will 
>> get bombarded too.


If we are speaking about numbers. You are able to see our doc, where they are 
counted.
If we have 10k nodes it will make only 150rpc calls/sec (which means nothing 
for cpu). By the way we way we will remove 150 calls/s from conductor. One more 
thing currently in 10nodes deployment I think we will spend almost all time fro 
waiting DB (compute_nodes_get_all()). And also when we are calling this method 
in this moment we should process all data for 60 sec. (So in this case in 
numbers we are doing on scheduler side 60*request_pro_sec of our approach. 
Which means if we get more then 1 request pro sec we will do more CPU load.)

There are deployments in production (bluehost) that are already bigger then 10k 
nodes, AFAIK the last numbers I heard were 16k nodes and they didn't use our 
scheduler at all. So a better upper limit would be something like 30k nodes.  
At that scale we get 500 RPC broadcasts per second (assuming 60 second periodic 
update) from periodic updates, plus updates from state changes.  If we assume 
only 1% of compute nodes have instances that are changing state that is an 
additional 300 RPC broadcasts to the schedulers per second.  So now we have 800 
per second.  How many RPC updates (from compute node to scheduler) per second 
can a single python thread handle without DB access? With DB Access?

As for your second point, I don't follow can you elaborate.






>> Also OpenStack is already deeply invested in using the central DB model for 
>> the state of the 'world' and while I am not against changing that, I think 
>> we should evaluate that switch in a larger context.

Step by step. As first step we could just remove compute_node_get_all method. 
Which will make our openstack much scalable and fast.

Yes, step by step is how to fix something.  But before going in this direction 
it is worth a larger discussi

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

[Joe Gordon]

On Mon, Jul 22, 2013 at 3:04 PM, Russell Bryant  wrote:

> On 07/22/2013 05:15 PM, Alex Glikson wrote:
> > Dear all,
> >
> > Following the initial discussions at the last design summit, we have
> > published the design [2] and the first take on the implementation [3] of
> > the blueprint adding support for multiple active scheduler
> > policies/drivers [1].
> > In a nutshell, the idea is to allow overriding the 'default' scheduler
> > configuration parameters (driver, filters, their configuration
> > parameters, etc) for particular host aggregates. The 'policies' are
> > introduced as sections in nova.conf, and each host aggregate can have a
> > key-value specifying the policy (by name).
> >
> > Comments on design or implementation are welcome!
> >
> > Thanks,
> > Alex
> >
> >
> > [1]
> https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
> > [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies
> > [3] https://review.openstack.org/#/c/37407/
>
> Thanks for bringing this up.  I do have some comments.
>
> The current design shows 2 different use cases for how a scheduling
> policy would be chosen.
>
> #1 - policy associated with a host aggregate
>
> This seems very odd to me.  Scheduling policy is what chooses hosts, so
> having a subset of hosts specify which policy to use seems backwards.
>
> #2 - via a scheduler hint
>
> It also seems odd to have the user specifying scheduling policy.  This
> seems like something that should be completely hidden from the user.
>
> How about just making the scheduling policy choice as simple as an item
> in the flavor extra specs?
>

++, IMHO we already reveal too much scheduling information to the user via
are current set of scheduler hints.


>
> The design also shows some example configuration.  It shows a global set
> of enabled scheduler filters, and then policy specific tweaks of filter
> config (CPU allocation ratio in the example).  I would expect to be able
> to set a scheduling policy specific list of scheduler filters and
> weights, as well.
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] A simple way to improve nova scheduler

[Joe Gordon]

On Mon, Jul 22, 2013 at 5:16 AM, Boris Pavlovic  wrote:

> Joe,
>
> >> Speaking of Chris Beherns  "Relying on anything but the DB for current
> memory free, etc, is just too laggy… so we need to stick with it, IMO."
> http://lists.openstack.org/pipermail/openstack-dev/2013-June/010485.html
>
> It doesn't scale, use tons of resources, works slow and is hard to extend.
> Also the mechanism of getting free and used memory is done by virt layer.
> And only thing that could be laggy is rpc (but it is used also by compute
> node update)
>

You say it doesn't scale and uses tons of resources can you show to
reproduce your findings.  Also just because the current implementation of
the scheduler is non-optimal doesn't mean the no DB is the only solution, I
am interested in seeing other possible solutions before going down such a
drastically different road (no-db).  Such as pushing more of the logic into
the DB and not searching through all compute nodes in python space or
looking at removing the periodic updates all  together or ???.


>
>
> >> * How do you bring a new scheduler up in an existing deployment and
> make it get the full state of the system?
>
> You should wait for a one periodic task time. And you will get full
> information about all compute nodes.
>

sure, that may work we need to add logic in to handle this.


> >> *  Broadcasting RPC updates from compute nodes to the scheduler means
> every scheduler has to process  the same RPC message.  And if a deployment
> hits the point where the number of compute updates is consuming 99 percent
> of the scheduler's time just adding another scheduler won't fix anything as
> it will get bombarded too.
>
>
> If we are speaking about numbers. You are able to see our doc, where they
> are counted.
> If we have 10k nodes it will make only 150rpc calls/sec (which means
> nothing for cpu). By the way we way we will remove 150 calls/s from
> conductor. One more thing currently in 10nodes deployment I think we will
> spend almost all time fro waiting DB (compute_nodes_get_all()). And also
> when we are calling this method in this moment we should process all data
> for 60 sec. (So in this case in numbers we are doing on scheduler side
> 60*request_pro_sec of our approach. Which means if we get more then 1
> request pro sec we will do more CPU load.)
>

There are deployments in production (bluehost) that are already bigger then
10k nodes, AFAIK the last numbers I heard were 16k nodes and they didn't
use our scheduler at all. So a better upper limit would be something like
30k nodes.  At that scale we get 500 RPC broadcasts per second (assuming 60
second periodic update) from periodic updates, plus updates from state
changes.  If we assume only 1% of compute nodes have instances that are
changing state that is an additional 300 RPC broadcasts to the schedulers
per second.  So now we have 800 per second.  How many RPC updates (from
compute node to scheduler) per second can a single python thread handle
without DB access? With DB Access?

As for your second point, I don't follow can you elaborate.





>
>
> >> Also OpenStack is already deeply invested in using the central DB model
> for the state of the 'world' and while I am not against changing that, I
> think we should evaluate that switch in a larger context.
>
> Step by step. As first step we could just remove compute_node_get_all
> method. Which will make our openstack much scalable and fast.
>

Yes, step by step is how to fix something.  But before going in this
direction it is worth a larger discussion of how we *want* things to look
and in what direction we should be moving in.  If we want to use this
model, we should consider where else it can help,  other repercussions etc.


>
> By the way see one more time answers on your comments in doc.
>
> Best regards,
> Boris Pavlovic
>
> Mirantis Inc.
>
>
>
>
>
> On Sat, Jul 20, 2013 at 3:14 AM, Joe Gordon  wrote:
>
>>
>>
>>
>> On Fri, Jul 19, 2013 at 3:13 PM, Sandy Walsh 
>> wrote:
>>
>>>
>>>
>>> On 07/19/2013 05:36 PM, Boris Pavlovic wrote:
>>> > Sandy,
>>> >
>>> > I don't think that we have such problems here.
>>> > Because scheduler doesn't pool compute_nodes.
>>> > The situation is another compute_nodes notify scheduler about their
>>> > state. (instead of updating their state in DB)
>>> >
>>> > So for example if scheduler send request to compute_node, compute_node
>>> > is able to run rpc call to schedulers immediately (not after 60sec).
>>> >
>>> > So there is almost no races.
>>>
>>> There are races that occur between the eventlet request threads. This is
>>> why the scheduler has been switched to single threaded and we can only
>>> run one scheduler.
>>>
>>> This problem may have been eliminated with the work that Chris Behrens
>>> and Brian Elliott were doing, but I'm not sure.
>>>
>>
>>
>> Speaking of Chris Beherns  "Relying on anything but the DB for current
>> memory free, etc, is just too laggy… so we need to stick with it, IMO."
>> http://lists.openstack

Re: [openstack-dev] [neutron] Configuration file generator

[Emilien Macchi]

Also for your information,

I created a bug : https://bugs.launchpad.net/neutron/+bug/1199963
and a first patchset for generating the new configuration file with Oslo
config scripts :
https://review.openstack.org/#/c/36546/

Emilien Macchi

# OpenStack Engineer
// eNovance Inc.  http://enovance.com
// ? emil...@enovance.com ? +33 (0)1 49 70 99 80
// 10 rue de la Victoire 75009 Paris

On 07/22/2013 06:34 PM, Julien Danjou wrote:
> Hi there,
>
> I've been working on the changes that would need to be done to make the
> default config generator work for Neutron.
>
> However, the current default config generator doesn't support the
> possibility to generate different configuration files (e.g. one per
> service/plugin). I can imagine two options:
>
> a. move every options in oslo.config.cfg.CONF, moving the plugins into
>their own section rather than in their own file, register all options
>at module-level, avoiding duplicate options.
>
> b. enhance config.generator to generate a config file from a particular
>object (not always olso.config.cfg.CONF like it's done currently).
>That means Neutron should evolve to provide a global CONF object per
>plugin at least.
>
> Option a. is how all other OpenStack projects¹ are working so far.
> Option b. requires a bit more work on both side.
>
> Is there any particular way you guys see things?
>
>
> ¹  nova, ceilometer and heat at least for now
>
>
>
> ___
> 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] [Heat] Multi region support for Heat

[Angus Salkeld]

On 22/07/13 16:52 +0200, Bartosz Górski wrote:

Hi folks,

I would like to start a discussion about the blueprint I raised about 
multi region support.
I would like to get feedback from you. If something is not clear or 
you have questions do not hesitate to ask.

Please let me know what you think.

Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support

Wikipage: 
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat



What immediatley looks odd to me is you have a MultiCloud Heat talking
to other Heat's in each region. This seems like unneccessary complexity to me.
I would have expected one Heat to do this job.

-Angus
 


Thanks,
Bartosz

___
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] support for multiple active scheduler policies/drivers

[Russell Bryant]

On 07/22/2013 05:15 PM, Alex Glikson wrote:
> Dear all,
> 
> Following the initial discussions at the last design summit, we have
> published the design [2] and the first take on the implementation [3] of
> the blueprint adding support for multiple active scheduler
> policies/drivers [1].
> In a nutshell, the idea is to allow overriding the 'default' scheduler
> configuration parameters (driver, filters, their configuration
> parameters, etc) for particular host aggregates. The 'policies' are
> introduced as sections in nova.conf, and each host aggregate can have a
> key-value specifying the policy (by name).
> 
> Comments on design or implementation are welcome!
> 
> Thanks,
> Alex
> 
> 
> [1] https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
> [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies
> [3] https://review.openstack.org/#/c/37407/

Thanks for bringing this up.  I do have some comments.

The current design shows 2 different use cases for how a scheduling
policy would be chosen.

#1 - policy associated with a host aggregate

This seems very odd to me.  Scheduling policy is what chooses hosts, so
having a subset of hosts specify which policy to use seems backwards.

#2 - via a scheduler hint

It also seems odd to have the user specifying scheduling policy.  This
seems like something that should be completely hidden from the user.

How about just making the scheduling policy choice as simple as an item
in the flavor extra specs?

The design also shows some example configuration.  It shows a global set
of enabled scheduler filters, and then policy specific tweaks of filter
config (CPU allocation ratio in the example).  I would expect to be able
to set a scheduling policy specific list of scheduler filters and
weights, as well.

-- 
Russell Bryant

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

Re: [openstack-dev] The PCI support blueprint

[Bhandaru, Malini K]

Ian, your suggestion of retrieving changes since a timestamp is good.  When a 
scheduler first comes online (in an HA context), it requests compute node 
status providing Null for timestamp to retrieve everything.

It also paves the way for full in memory record of all compute node status 
because it requires that each scheduler keep a copy of the status.

The Scheduler could retrieve status every second or whenever it gets a new VM 
request. Under heavy load, that is frequent requests, the timestamps would be 
closer and hopefully fewer changes being returned. We may want to make the 
frequency of polling a configurable item
to tune .. too infrequent means payload large (no worse than today's full 
load), too often may  be moot.

Regards
Malini


-Original Message-
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] 
Sent: Monday, July 22, 2013 1:56 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] The PCI support blueprint

On 22 July 2013 21:08, Boris Pavlovic  wrote:
> Ian,
>
> I don't like to write anything personally.
> But I have to write some facts:
>
> 1) I see tons of hands and only 2 solutions my and one more that is 
> based on code.
> 2) My code was published before session (18. Apr 2013)
> 3) Blueprints from summit were published (03. Mar 2013)
> 4) My Blueprints were published (25. May 2013)
> 5) Patches based on my patch were published only (5. Jul 2013)

Absolutely.  Your patch and our organisation crossed in the mail, and everyone 
held off work on this because you were working on this.
That's perfectly normal, just unfortunate, and I'm grateful for your work on 
this, not pointing fingers.

> After making investigations and tests we found that one of the reason 
> why scheduler works slow and has problems with scalability is work with DB.
> JOINS are pretty unscalable and slow thing and if we add one more JOIN 
> that is required by PCI passthrough we will get much worse situation.

Your current PCI passthrough design adds a new database that stores every PCI 
device in the cluster, and you're thinking of crossing that with the compute 
node and its friends.  That's certainly unscalable.

I think the issue here is, in fact, more that you're storing every PCI device.  
The scheduler doesn't care.  In most cases, devices are equivalent, so instead 
of storing 1024 devices you can store one single row in the stats table saying 
pci_device_class_networkcard = 1024.  There may be a handful of these classes, 
but there won't be
1024 of them per cluster node.  The compute node can take any one of the PCI 
devices in that class and use it - the scheduler should neither know nor care.

This drastically reduces the transfer of information from the compute node to 
host and also reduces the amount of data you need to store in the database - 
and the scheduler DB doesn't need changing at all.

This seems like a much more low impact approach for now - it doesn't change the 
database at all and it and doesn't add much to the scheduling problem (indeed, 
no overhead at all for the non-PCI users) until we solve the scalability issues 
you're talking about at some later date.

For what it's worth, one way of doing that without drastic database design 
would be to pass compute_node_get_all a timestamp, return only stats updated 
since that timestamp, return a new timestamp, and merge that in with what the 
scheduler already knows about.  There's some refinement to that - since 
timestamps are not reliable clocks in databases - but it reduces the flow of 
data from the DB file substantially and works with an eventually consistent 
system.
(Truthfully, I prefer your in-memory-store idea, there's nothing about these 
stats that really needs to survive a reboot of the control node, but this might 
be a quick fix.)
--
Ian.

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

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

[openstack-dev] [Nova] support for multiple active scheduler policies/drivers

[Alex Glikson]

Dear all,

Following the initial discussions at the last design summit, we have 
published the design [2] and the first take on the implementation [3] of 
the blueprint adding support for multiple active scheduler 
policies/drivers [1]. 
In a nutshell, the idea is to allow overriding the 'default' scheduler 
configuration parameters (driver, filters, their configuration parameters, 
etc) for particular host aggregates. The 'policies' are introduced as 
sections in nova.conf, and each host aggregate can have a key-value 
specifying the policy (by name).

Comments on design or implementation are welcome!

Thanks,
Alex


[1] https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
[2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies
[3] https://review.openstack.org/#/c/37407/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The PCI support blueprint

[Ian Wells]

On 22 July 2013 21:08, Boris Pavlovic  wrote:
> Ian,
>
> I don't like to write anything personally.
> But I have to write some facts:
>
> 1) I see tons of hands and only 2 solutions my and one more that is based on
> code.
> 2) My code was published before session (18. Apr 2013)
> 3) Blueprints from summit were published (03. Mar 2013)
> 4) My Blueprints were published (25. May 2013)
> 5) Patches based on my patch were published only (5. Jul 2013)

Absolutely.  Your patch and our organisation crossed in the mail, and
everyone held off work on this because you were working on this.
That's perfectly normal, just unfortunate, and I'm grateful for your
work on this, not pointing fingers.

> After making investigations and tests we found that one of the reason why
> scheduler works slow and has problems with scalability is work with DB.
> JOINS are pretty unscalable and slow thing and if we add one more JOIN that
> is required by PCI passthrough we will get much worse situation.

Your current PCI passthrough design adds a new database that stores
every PCI device in the cluster, and you're thinking of crossing that
with the compute node and its friends.  That's certainly unscalable.

I think the issue here is, in fact, more that you're storing every PCI
device.  The scheduler doesn't care.  In most cases, devices are
equivalent, so instead of storing 1024 devices you can store one
single row in the stats table saying pci_device_class_networkcard =
1024.  There may be a handful of these classes, but there won't be
1024 of them per cluster node.  The compute node can take any one of
the PCI devices in that class and use it - the scheduler should
neither know nor care.

This drastically reduces the transfer of information from the compute
node to host and also reduces the amount of data you need to store in
the database - and the scheduler DB doesn't need changing at all.

This seems like a much more low impact approach for now - it doesn't
change the database at all and it and doesn't add much to the
scheduling problem (indeed, no overhead at all for the non-PCI users)
until we solve the scalability issues you're talking about at some
later date.

For what it's worth, one way of doing that without drastic database
design would be to pass compute_node_get_all a timestamp, return only
stats updated since that timestamp, return a new timestamp, and merge
that in with what the scheduler already knows about.  There's some
refinement to that - since timestamps are not reliable clocks in
databases - but it reduces the flow of data from the DB file
substantially and works with an eventually consistent system.
(Truthfully, I prefer your in-memory-store idea, there's nothing about
these stats that really needs to survive a reboot of the control node,
but this might be a quick fix.)
-- 
Ian.

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

[openstack-dev] minutes from OpenStack Deployment meeting 20130722

[Robert Collins]

08:47 <@openstack> Meeting ended Mon Jul 22 20:47:18 2013 UTC.
Information about MeetBot at
   http://wiki.debian.org/MeetBot . (v 0.1.4)
08:47 <@openstack> Minutes:

http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-07-22-20.01.html
08:47 -!- esker [~es...@nat-216-240-30-23.netapp.com] has quit [Remote
host closed the connection]
08:47 <@openstack> Minutes (text):

http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-07-22-20.01.txt
08:47 <@openstack> Log:

http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-07-22-20.01.log.html


Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services

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

Re: [openstack-dev] [barbican]

[Jarret Raim]

I'm the product owner for Barbican at Rackspace. I'll take a shot an answering 
your questions.

> 1. What is the state of the project, is it in the state where it can be 
> utilized in production deployments?

We currently in active development and pushing for our 1.0 release for Havana. 
As to production deployments, the answer right now is none. We are currently 
working on enabling Barbican to use hardware security modules for key storage. 
Once this code is complete, we should be close to a place where the first 
production deployment is feasible. At Rack, we are building out the 
infrastructure to do so and I hope to have good news once we get towards the 
Summit.

> 2. Dose Barbican is an implementation of 
> https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the 
> correct design/BP resource on which Barbican is based on.

We are inspired by the blueprint you linked. That blueprint was a bit more 
limited than we were planning and we have changed quite a bit. For a more 
detailed version, you can find lots of documentation on our wiki here:

https://github.com/cloudkeep/barbican/wiki/Blueprint:-Technical-Approach
https://github.com/cloudkeep/barbican
https://github.com/cloudkeep/barbican/wiki

> 3. Is it KMIP (KMIP 1.1 spec 
> https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what 
> are the plans any initiative so far?

Not right now. As I mentioned in a previous email (I'll copy the contents 
below), KMIP is not the greatest protocol for this use case. Our current plans 
are to expose the Barbican API to all consumers. This is a standard OpenStack 
API using ReST / JSON, authing through keystone, etc. If there is enough 
interest, I am planning on supporting KMIP inside Barbican to talk to various 
HSM type providers. This would most likely not be exposed to customers.

I haven't heard from anyone who needs KMIP support at this point. Mostly the 
questions have just been whether we are planning on supporting it. If you have 
a strong use case as to why you want / need it, I'd love to hear it. You can 
respond here or reach out to me at 
jarret.r...@rackspace.com

Thanks,
Jarret


Here is the previous email relating to KMIP for additional reading:

I'm not sure that I agree with this direction. In our investigation, KMIP is a 
problematic protocol for several reasons:

  *   We haven't found an implementation of KMIP for Python. (Let us know if 
there is one!)
  *   Support for KMIP by HSM vendors is limited.
  *   We haven't found software implementations of KMIP suitable for use as an 
HSM replacement. (e.g. Most deployers wanting to use KMIP would have to spend a 
rather large amount of money to purchase HSMs)
  *   From our research, the KMIP spec and implementations seem to lack support 
for multi-tenancy. This makes managing keys for thousands of users difficult or 
impossible.
The goal for the Barbican system is to provide key management for OpenStack. It 
uses the standard interaction mechanisms for OpenStack, namely ReST and JSON. 
We integrate with keystone and will provide common features like usage events, 
role-based access control, fine grained control, policy support, client libs, 
Celiometer support, Horizon support and other things expected of an OpenStack 
service. If every product is forced to implement KMIP, these features would 
most likely not be provided by whatever vendor is used for the Key Manager. 
Additionally, as mentioned in the blueprint, I have concerns that vendor 
specific data will be leaked into the rest of OpenStack for things like key 
identifiers, authentication and the like.

I would propose that rather than each product implement KMIP support, we 
implement KMIP support into Barbican. This will allow the products to speak 
ReST / JSON using our client libraries just like any other OpenStack system and 
Barbican will take care of being a good OpenStack citizen. On the backend, 
Barbican will support the use of KMIP to talk to whatever device the provider 
wishes to deploy. We will also support other interaction mechanisms including 
PKCS through OpenSSH, a development implementation and a fully free and open 
source software implementation. This also allows some advanced uses cases 
including federation. Federation will allow customers of public clouds like 
Rackspace's to maintain custody of their keys while still being able to 
delegate their use to the Cloud for specific tasks.

I've been asked about KMIP support at the Summit and by several of Rackspace's 
partners. I was planning on getting to it at some point, probably after 
Icehouse. This is mostly due to the fact that we didn't find a suitable KMIP 
implementation for Python so it looks like we'd have to write one. If there is 
interest from people to create that implementation, we'd be happy to help do 
the work to integrate it into Barbican.

We just released our M2 milestone and we are on track for our 1.0 release for 
Ha

Re: [openstack-dev] Change in openstack/neutron[master]: Add method to get iptables traffic counters

[Brian Haley]

Sylvain,

Something like this would require no marking:

# iptables -N test2
# iptables -N test3
# iptables -A test3
# iptables -A test2 -d 9.9.9.9/32 -j RETURN
# iptables -A test2 -d 10.10.10.10/32 -j RETURN
# iptables -A test2 -j test3
# iptables -A OUTPUT -j test2

# ping -I eth0 -r 9.9.9.9
PING 9.9.9.9 (9.9.9.9) from 16.1.1.40 eth0: 56(84) bytes of data.
^C
--- 9.9.9.9 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms

# iptables-save -c | grep test
:test2 - [0:0]
:test3 - [0:0]
[3198:403274] -A OUTPUT -j test2
[2:168] -A test2 -d 9.9.9.9/32 -j RETURN
[0:0] -A test2 -d 10.10.10.10/32 -j RETURN
[3196:403106] -A test2 -j test3
[3196:403106] -A test3

# iptables -L test2 -v -x -n
Chain test2 (1 references)
pkts  bytes target prot opt in out source
destination
   2  168 RETURN all  --  *  *   0.0.0.0/0
9.9.9.9
   00 RETURN all  --  *  *   0.0.0.0/0
10.10.10.10
3182   401554 test3  all  --  *  *   0.0.0.0/0
0.0.0.0/0

> iptables -L test3 -v -x -n
Chain test3 (1 references)
pkts  bytes target prot opt in out source
destination
3182   401554all  --  *  *   0.0.0.0/0
0.0.0.0/0

And I seems similar to your cut/paste from below.

Thoughts?

-Brian

On 07/22/2013 03:55 AM, Sylvain Afchain wrote:
> Hi Brian,
> 
> Thanks for your reply.
> 
>> 1. This isn't something a tenant should be able to do, so should be 
>> admin-only,
>> correct?
> 
> Correct.
> 
>> 2. I think it would be useful for an admin to be able to add metering rules 
>> for
>> all tenants with a single command.  This gets back to wanting to pre-seed an 
>> ini
>> file with a set of subnets, then add/subtract from it later without 
>> restarting
>> the daemon.
> 
> I agree with you, could be a future enhancement.
> 
>> 3. I think it would be better if you didn't mark the packets, for performance
>> reasons.  If you were marking them on input to be matched by something on 
>> output
>> I'd feel different, but for just counting bytes we should be able to do it
>> another way.  I can get back to you next week on figuring this out.
> 
> Ok, I'll take a look too.
> 
> Thanks.
> 
> Sylvain.
> 
> - Original Message -
> From: "Brian Haley" 
> To: "Sylvain Afchain" 
> Cc: openstack-dev@lists.openstack.org
> Sent: Friday, July 19, 2013 11:47:41 PM
> Subject: Re: Change in openstack/neutron[master]: Add method to get iptables 
> traffic counters
> 
> Hi Sylvain,
> 
> Sorry for the slow reply, I'll have to look closer next week, but I did have
> some comments.
> 
> 1. This isn't something a tenant should be able to do, so should be 
> admin-only,
> correct?
> 
> 2. I think it would be useful for an admin to be able to add metering rules 
> for
> all tenants with a single command.  This gets back to wanting to pre-seed an 
> ini
> file with a set of subnets, then add/subtract from it later without restarting
> the daemon.
> 
> 3. I think it would be better if you didn't mark the packets, for performance
> reasons.  If you were marking them on input to be matched by something on 
> output
> I'd feel different, but for just counting bytes we should be able to do it
> another way.  I can get back to you next week on figuring this out.
> 
> Thanks,
> 
> -Brian
> 
> On 07/18/2013 04:29 AM, Sylvain Afchain wrote:
>> Hi Brian,
>>
>> For iptables rules, see below
>>
>> Yes the only way to setup metering labels/rules is the neutronclient. I 
>> agree with you about the future
>> enhancement.
>>
>> Regards,
>>
>> Sylvain
>>
>> - Original Message -
>> From: "Brian Haley" 
>> To: "Sylvain Afchain" 
>> Cc: openstack-dev@lists.openstack.org
>> Sent: Thursday, July 18, 2013 4:58:26 AM
>> Subject: Re: Change in openstack/neutron[master]: Add method to get iptables 
>> traffic counters
>>
>>> Hi Sylvain,
>>>
>>> I think I've caught-up with all your reviews, but I still did have some
>>> questions on the iptables rules, below.
>>>
>>> One other question, and maybe it's simply a future enhancement, but is the 
>>> only
>>> way to setup these meters using neutronclient?  I think being able to 
>>> specify
>>> these in an .ini file would be good as well, which is something I'd want to 
>>> do
>>> as a provider, such that they're always there, and actually not visible to 
>>> the
>>> tenant.
>>>
>>> On 07/11/2013 10:04 AM, Sylvain Afchain wrote:
 Hi Brian,

 You're right It could be easier with your approach to get and keep the 
 traffic counters.

 I will add a new method to get the details of traffic counters of a chain.
 https://review.openstack.org/35624

 Thoughts?

 Regards,

 Sylvain.

 - Original Message -
 From: "Sylvain Afchain" 
 To: "Brian Haley" 
 Cc: openstack-dev@lists.openstack.org
 Sent: Thursday, July 11, 2013 11:19:39 AM
 Subject: Re: Change in openstack/neutron[master]: Add method to 

Re: [openstack-dev] The PCI support blueprint

[Boris Pavlovic]

Hi one more time.

I will refactor DB layer tomorrow. As I said I don't want to be a block.


Best regards,
Boris Pavlovic
---
Mirantis Inc.





On Mon, Jul 22, 2013 at 11:08 PM, Boris Pavlovic  wrote:

> Ian,
>
> I don't like to write anything personally.
> But I have to write some facts:
>
> 1) I see tons of hands and only 2 solutions my and one more that is based
> on code.
> 2) My code was published before session (18. Apr 2013)
> 3) Blueprints from summit were published (03. Mar 2013)
> 4) My Blueprints were published (25. May 2013)
> 5) Patches based on my patch were published only (5. Jul 2013)
>
>
> 2 All,
>
> I don't won't to hide anything from community, cores or PTLs. I have only
> one goal and it is to make OpenStack better.
>
> Recently I get new task on my job: Scalability/Performance and Benchmarks
>
> So with my colleagues we started investigating some code around scheduler.
> (Jiang sorry for lag in 2 weeks)
>
> After making investigations and tests we found that one of the reason why
> scheduler works slow and has problems with scalability is work with DB.
> JOINS are pretty unscalable and slow thing and if we add one more JOIN
> that is required by PCI passthrough we will get much worse situation.
>
> We started investigating how to solve two competing things: Scalability vs
> Flexibility
> About flexibility:
> I don't think that our current scheduler is handy, I have to add 800 lines
> of code just to be able to use list of JSON objects in scheduler as one
> more resource (with complex structure). If we don't use new table we should
> use some kind of key/value, and if we use a lot of key/values we will get
> problems with performance and scalability or if we store in one key/value
> we will get another problem with races and tons of dirty code. So we will
> get the same problems in future. Also using of resources from different
> providers (such as cinder) are pretty hard tasks.
>
> So Alexey K., Alexei O. and me found a way to make our scheduler work
> without DB with pretty small changes in current solution.
> New approach allows us in the same time to have scalability and
> flexibility.
> What means scalability: "We don't need to store anything about PCI devices
> in DB". And should just add some small extra code in resource tracker.
>
> I understand that it is too late to implement such things in H-3 (I
> absolutely agree with Russell). (Even if they require just 100-150 lines of
> code.)
>
> So if we implement solution based on my current code, after improving
> scheduler we should:
> 1) remove absolutly DB layer
> 2) 100% replace compute.api layer
> 3) partial replace scheduler layer
> 4) change compute.manager
> And only libvirt (that should be improved) and auto discovering will be
> untouched (but they are not enough reviewed in this moment) will be
> untouched.
>
>
> So I really don't understand why we should hurry up. Why we are not able
> firstly to:
> 1) Prepare patches around improving scheduler (before summit)
> 2) Prepare all things that will be untouched (libvirt/auto discovering)
> (before summit)
> 3) Speak about all this stuff one more time on summit
> 4) Improve and implement all these work in I-1 ?
> 5) Test and improve it during I-2 and I-3.
>
> I think that it will be much better for OpenStack code at all.
>
> If Russell and other cores would like to implement current PCI passthrough
> approach anyway.
> I won't block anything and tomorrow at evening will be finished DB layer
>
>
> Best regards,
> Boris Pavlovic
> ---
> Mirantis Inc.
>
>
>
>
> On Mon, Jul 22, 2013 at 8:49 PM, Ian Wells  wrote:
>
>> Per the last summit, there are many interested parties waiting on PCI
>> support.  Boris (who unfortunately waasn't there) jumped in with an
>> implementation before the rest of us could get a blueprint up, but I
>> suspect he's been stretched rather thinly and progress has been much
>> slower than I was hoping it would be.  There are many willing hands
>> happy to take this work on; perhaps it's time we did, so that we can
>> get something in before Havana.
>>
>> I'm sure we could use a better scheduler.  I don't think that actually
>> affects most of the implementation of passthough and I don't think we
>> should tie the two together.  "The perfect is the enemy of the good."
>>
>> And as far as the quantity of data passed back - we've discussed
>> before that it would be nice (for visibility purposes) to be able to
>> see an itemised list of all of the allocated and unallocated PCI
>> resources in the database.  There could be quite a lot per host (256
>> per card x say 10 cards depending on your hardware).  But passing that
>> itemised list back is somewhat of a luxury - in practice, what you
>> need for scheduling is merely a list of categories of card (those
>> pools where any one of the PCI cards in the pool would do) and counts.
>>  The compute node should be choosing a card from the pool in any case.
>>  The scheduler need only find a machine with cards avail

Re: [openstack-dev] [keystone] Split the Identity Backend blueprint

[Adam Young]

On 07/22/2013 01:38 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) 
wrote:


Hello,

I have been reading source code in an attempt to figure out how to use 
the new split backend feature, specifically how to split the identity 
data between an ldap server and the standard Keystone sql database. 
However, I haven't been able to figure it out quite yet. Does someone 
have some examples of this new feature in action? Is there another 
configuration file that is required?


[identity]

driver = driver = keystone.identity.backends.sql.Identity

[assignment]

driver = ???

[ldap]

Quite a few options

Regards,

Mark Miller



RIght now the only support split approach is LDAP for Identity, SQL for 
assignments.


[identity]

 driver = keystone.identity.backends.ldap.Identity

[assignment]

driver = keystone.assignment.backends.sql.Identity

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

[openstack-dev] [nova] Multiple interfaces, same network

[Ian Wells]

A while back (just before the summit, as I recall), there was a patch
submitted to remove the constraints on being able to connect multiple
interfaces of the same VM to the same Neutron network. [1]

It was unclear at the time whether this is a bug being fixed or a
feature being added, which rather stalled the discussion, along with
several 'eww, why would you do this' comments.  To that end, I've
added a blueprint to make the feature request [2], and I'd like to
bring the discussion here as to whether it's productive to do.

Personally, I want it because I want to simulate physical networks -
where it's perfectly legitimate to connect one machine to the same
network twice.  I can't simulate those networks without this feature.
I would argue that this makes people's lives easier in certain awkward
situations - if they have a VM configured to use two ports they can
use both ports on the same network if they wish - and is a low risk
change which should just work (something we can prove out with
adequate tests).  It also only affects anyone who actually tries to
connect one VM to the same network twice - that is, making the change
has no effect on the configurations that work today.
-- 
Ian.

[1] https://review.openstack.org/#/c/26370
[2] https://blueprints.launchpad.net/nova/+spec/two-vifs-one-net

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

[openstack-dev] There are no OpenStack talks submitted to XenCon, CFP ends this week

[Atwood, Mark]

Hi!

While I was at the Community Leadership Summit conference this weekend, I met 
the community manager for the Xen hypervisor project.  He told me that there 
are *no* OpenStack talks submitted to the upcoming XenCon conference.

The CFP closes this Friday.

Allow me to suggest that any of us who have something to say about Xen in Nova 
in OpenStack, submit papers.

Thanks!

..m

-- 
Mark Atwood 
Director - Open Source Engagement for HP Cloud Services and OpenStack
+1-206-473-7118



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

Re: [openstack-dev] The PCI support blueprint

[Boris Pavlovic]

Ian,

I don't like to write anything personally.
But I have to write some facts:

1) I see tons of hands and only 2 solutions my and one more that is based
on code.
2) My code was published before session (18. Apr 2013)
3) Blueprints from summit were published (03. Mar 2013)
4) My Blueprints were published (25. May 2013)
5) Patches based on my patch were published only (5. Jul 2013)


2 All,

I don't won't to hide anything from community, cores or PTLs. I have only
one goal and it is to make OpenStack better.

Recently I get new task on my job: Scalability/Performance and Benchmarks

So with my colleagues we started investigating some code around scheduler.
(Jiang sorry for lag in 2 weeks)

After making investigations and tests we found that one of the reason why
scheduler works slow and has problems with scalability is work with DB.
JOINS are pretty unscalable and slow thing and if we add one more JOIN that
is required by PCI passthrough we will get much worse situation.

We started investigating how to solve two competing things: Scalability vs
Flexibility
About flexibility:
I don't think that our current scheduler is handy, I have to add 800 lines
of code just to be able to use list of JSON objects in scheduler as one
more resource (with complex structure). If we don't use new table we should
use some kind of key/value, and if we use a lot of key/values we will get
problems with performance and scalability or if we store in one key/value
we will get another problem with races and tons of dirty code. So we will
get the same problems in future. Also using of resources from different
providers (such as cinder) are pretty hard tasks.

So Alexey K., Alexei O. and me found a way to make our scheduler work
without DB with pretty small changes in current solution.
New approach allows us in the same time to have scalability and
flexibility.
What means scalability: "We don't need to store anything about PCI devices
in DB". And should just add some small extra code in resource tracker.

I understand that it is too late to implement such things in H-3 (I
absolutely agree with Russell). (Even if they require just 100-150 lines of
code.)

So if we implement solution based on my current code, after improving
scheduler we should:
1) remove absolutly DB layer
2) 100% replace compute.api layer
3) partial replace scheduler layer
4) change compute.manager
And only libvirt (that should be improved) and auto discovering will be
untouched (but they are not enough reviewed in this moment) will be
untouched.


So I really don't understand why we should hurry up. Why we are not able
firstly to:
1) Prepare patches around improving scheduler (before summit)
2) Prepare all things that will be untouched (libvirt/auto discovering)
(before summit)
3) Speak about all this stuff one more time on summit
4) Improve and implement all these work in I-1 ?
5) Test and improve it during I-2 and I-3.

I think that it will be much better for OpenStack code at all.

If Russell and other cores would like to implement current PCI passthrough
approach anyway.
I won't block anything and tomorrow at evening will be finished DB layer


Best regards,
Boris Pavlovic
---
Mirantis Inc.




On Mon, Jul 22, 2013 at 8:49 PM, Ian Wells  wrote:

> Per the last summit, there are many interested parties waiting on PCI
> support.  Boris (who unfortunately waasn't there) jumped in with an
> implementation before the rest of us could get a blueprint up, but I
> suspect he's been stretched rather thinly and progress has been much
> slower than I was hoping it would be.  There are many willing hands
> happy to take this work on; perhaps it's time we did, so that we can
> get something in before Havana.
>
> I'm sure we could use a better scheduler.  I don't think that actually
> affects most of the implementation of passthough and I don't think we
> should tie the two together.  "The perfect is the enemy of the good."
>
> And as far as the quantity of data passed back - we've discussed
> before that it would be nice (for visibility purposes) to be able to
> see an itemised list of all of the allocated and unallocated PCI
> resources in the database.  There could be quite a lot per host (256
> per card x say 10 cards depending on your hardware).  But passing that
> itemised list back is somewhat of a luxury - in practice, what you
> need for scheduling is merely a list of categories of card (those
> pools where any one of the PCI cards in the pool would do) and counts.
>  The compute node should be choosing a card from the pool in any case.
>  The scheduler need only find a machine with cards available.
>
> I'm not totally convinced that passing back the itemised list is
> necessarily a problem, but in any case we can make the decision one
> way or the other, take on the risk if we like, and get the code
> written - if it turns out not to be scalable then we can fix *that* in
> the next release, but at least we'll have something to play with in
> the meantime.  Delaying

Re: [openstack-dev] [Nova] havana-3 reality check and deadlines

[Joshua Harlow]

Thx for helping corral it all russell :)

Sent from my really tiny device...

On Jul 22, 2013, at 11:03 AM, "Russell Bryant"  wrote:

> Greetings,
> 
> havana-1: 16 blueprints implemented
> havana-2: 25 blueprints implemented
> havana-3: currently 96 blueprints targeted [1]
> 
> The number of blueprints targeted at havana-3 is completely unrealistic.
> As a result, there are number of important points and actions we need
> to take:
> 
> * If you have a havana-3 blueprint, please review it and make sure the
> status is accurate and that you still intend to deliver it.  If not,
> please change the milestone to "next" or ping someone in nova-drivers
> [2] to do it.
> 
> * Earlier in the cycle we discussed a deadline for when patches must be
> submitted to make the feature freeze [3].  We also re-visited the topic
> in our last Nova meeting.  This deadline is August 21 (2 weeks before
> feature freeze) and it *will* be enforced.
> 
> * To nova-core: we need to do our best to prioritize our review time in
> havana-3, to make sure we get the most important stuff reviewed and merged.
> 
> * To everyone, I'm sorry, but some stuff that is ready on time probably
> won't make it.  That's the risk of delivering toward the end of the
> development cycle.  To have the best chance, get your code up for review
> *ASAP*.
> 
> * I will be regularly working on pruning this list.  Please come talk to
> me if you think there is a blueprint we should discuss deferring.
> 
> Let me know if you have any comments or questions.
> 
> Thanks,
> 
> [1] https://launchpad.net/nova/+milestone/havana-3
> [2] https://launchpad.net/~nova-drivers/+members#active
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2013-April/007823.html
> 
> -- 
> Russell Bryant
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Nova] havana-3 reality check and deadlines

[Russell Bryant]

Greetings,

havana-1: 16 blueprints implemented
havana-2: 25 blueprints implemented
havana-3: currently 96 blueprints targeted [1]

The number of blueprints targeted at havana-3 is completely unrealistic.
 As a result, there are number of important points and actions we need
to take:

* If you have a havana-3 blueprint, please review it and make sure the
status is accurate and that you still intend to deliver it.  If not,
please change the milestone to "next" or ping someone in nova-drivers
[2] to do it.

* Earlier in the cycle we discussed a deadline for when patches must be
submitted to make the feature freeze [3].  We also re-visited the topic
in our last Nova meeting.  This deadline is August 21 (2 weeks before
feature freeze) and it *will* be enforced.

* To nova-core: we need to do our best to prioritize our review time in
havana-3, to make sure we get the most important stuff reviewed and merged.

* To everyone, I'm sorry, but some stuff that is ready on time probably
won't make it.  That's the risk of delivering toward the end of the
development cycle.  To have the best chance, get your code up for review
*ASAP*.

* I will be regularly working on pruning this list.  Please come talk to
me if you think there is a blueprint we should discuss deferring.

Let me know if you have any comments or questions.

Thanks,

[1] https://launchpad.net/nova/+milestone/havana-3
[2] https://launchpad.net/~nova-drivers/+members#active
[3]
http://lists.openstack.org/pipermail/openstack-dev/2013-April/007823.html

-- 
Russell Bryant

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

Re: [openstack-dev] [Swift] erasure codes, digging deeper

[John Dickinson]

On Jul 22, 2013, at 9:34 AM, David Hadas  wrote:

> Hi, 
> 
> In Portland, we discussed a somewhat related issue of having multiple 
> replication levels in one Swift cluster. 
> It may be that a provider would not wish to expose the use of EC or the level 
> of replication used. For example a provider may offer a predefined set of 
> services such as "Gold", "Silver" and "Bronze", "Aluminum" which a user can 
> choose from. The provider may decide how each level is implemented (As a 
> silly example: Gold is 4 way replication, Silver is a 3 way replication, 
> Bronze is EC, Aluminum is single replica without EC). 
> 
> Does it make sense to consider EC as an implementation of a certain service 
> level (the same as for example the choice of the number of replicas)? 

yes, that's actually exactly what I'm thinking.

> 
> Now we are back to the question of what is the right unit in which we define 
> this 'level of service' ("Gold", "Silver"...).
> Should the level of service be defined when the account is created or should 
> we allow a user to state:
> "I would like to have a container with Gold to keep my work, Bronze to keep 
> my family pictures and videos and Aluminum to keep a copy of all my music 
> files".
> 
> If we choose to enable container service levels, we need to enable billing 
> per level of service such that a single account could be billed for the 
> actual use it has done per each level of service. Maybe we even need to have 
> all statistics gathered to be grouped by service level.
> I am not sure if we can escape that even with account service levels. 

Either on the account or container level, the billing number generator will 
need to correlate particular bytes with a particular service level. That would 
be in ceilometer, slogging, or whatever other people are using.


> 
> DH
> 
> On Thu, Jul 18, 2013 at 9:37 PM, John Dickinson  wrote:
> Yes, and I'd imagine that the normal default would be for replicated data.
> 
> Moving the granularity from a container to account-based, as Chmouel and 
> Chuck said, is interesting too.
> 
> --John
> 
> On Jul 18, 2013, at 11:32 AM, Christian Schwede  wrote:
> 
> > A solution to this might be to set the default policy as a configuration
> > setting in the proxy. If you want a replicated swift cluster just allow
> > this policy in the proxy and set it to default. The same for EC cluster,
> > just set the allowed policy to EC. If you want both (and let your users
> > decide which policy to use) simply configure a list of allowed policies
> > with the first one in the list as the default policy in case they don't
> > set a policy during container creation.
> >
> > Am 18.07.13 20:15, schrieb Chuck Thier:
> >> I think you are missing the point.  What I'm talking about is who
> >> chooses what data is EC and what is not.  The point that I am trying to
> >> make is that the operators of swift clusters should decide what data is
> >> EC, not the clients/users.  How the data is stored should be totally
> >> transparent to the user.
> >>
> >> Now if we want to down the road offer user defined classes of storage
> >> (like how S3 does reduced redundancy), I'm cool with that, just that it
> >> should be orthogonal to the implementation of EC.
> >>
> >> --
> >> Chuck
> >>
> >>
> >> On Thu, Jul 18, 2013 at 12:57 PM, John Dickinson  >> > wrote:
> >>
> >>Are you talking about the parameters for EC or the fact that
> >>something is erasure coded vs replicated?
> >>
> >>For the first, that's exactly what we're thinking: a deployer sets
> >>up one (or more) policies and calls them Alice, Bob, or whatever,
> >>and then the API client can set that on a particular container.
> >>
> >>This allows users who know what they are doing (ie those who know
> >>the tradeoffs and their data characteristics) to make good choices.
> >>It also allows deployers who want to have an automatic policy to set
> >>one up to migrate data.
> >>
> >>For example, a deployer may choose to run a migrator process that
> >>moved certain data from replicated to EC containers over time (and
> >>drops a manifest file in the replicated tier to point to the EC data
> >>so that the URL still works).
> >>
> >>Like existing features in Swift (eg large objects), this gives users
> >>the ability to flexibly store their data with a nice interface yet
> >>still have the ability to get at some of the pokey bits underneath.
> >>
> >>--John
> >>
> >>
> >>
> >>On Jul 18, 2013, at 10:31 AM, Chuck Thier  >>> wrote:
> >>
> >>> I'm with Chmouel though.  It seems to me that EC policy should be
> >>chosen by the provider and not the client.  For public storage
> >>clouds, I don't think you can make the assumption that all
> >>users/clients will understand the storage/latency tradeoffs and
> >>benefits.
> >>>
> >>>
> >>> On Thu, Jul 18, 2013 at 8:11 AM, John Dickinson  >>

Re: [openstack-dev] A simple way to improve nova scheduler

[Russell Bryant]

On 07/22/2013 12:51 PM, John Garbutt wrote:
> On 22 July 2013 13:23, Boris Pavlovic  wrote:
>> I see only one race condition. (in current solution we have the same
>> situtaiton)
>> Between request to compute node and data is updated in DB, we could use
>> wrong state of compute node.
>> By the way it is fixed by retry.
> 
> This race turns out to be a big deal when there are bursts of VM.start 
> requests.
> 
> I am currently thinking about ways we can look to eliminate this one.
> Hoping to have a design summit session on that.

Cool.  In addition to retries, it's somewhat mitigated by using the
scheduler_host_subset_size to reduce the chance that multiple schedulers
choose the same host.

# New instances will be scheduled on a host chosen randomly
# from a subset of the N best hosts. This property defines the
# subset size that a host is chosen from. A value of 1 chooses
# the first host returned by the weighing functions. This
# value must be at least 1. Any value less than 1 will be
# ignored, and 1 will be used instead (integer value)
#scheduler_host_subset_size=1

-- 
Russell Bryant

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

Re: [openstack-dev] [Swift] erasure codes, digging deeper

[Luse, Paul E]

I think most folks are on the same page wrt EC being consider a "level" or 
"storage policy" as we've been discussing in other forums.  I saw the previous 
note on account versus container and was actually thinking it made more sense 
to me at least to enable billing per container as opposed to trying to shoehorn 
attribute of a set of data (like a storage policy) to and account so I like 
where you're going w/the suggestion.  I'm not even sure we need to answer the 
detailed question of what defines these levels, or storage policies, only that 
the design allows for their efficient use and flexible definitions.

Thx
Paul

From: David Hadas [mailto:david.ha...@gmail.com]
Sent: Monday, July 22, 2013 9:35 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Swift] erasure codes, digging deeper

Hi,

In Portland, we discussed a somewhat related issue of having multiple 
replication levels in one Swift cluster.
It may be that a provider would not wish to expose the use of EC or the level 
of replication used. For example a provider may offer a predefined set of 
services such as "Gold", "Silver" and "Bronze", "Aluminum" which a user can 
choose from. The provider may decide how each level is implemented (As a silly 
example: Gold is 4 way replication, Silver is a 3 way replication, Bronze is 
EC, Aluminum is single replica without EC).

Does it make sense to consider EC as an implementation of a certain service 
level (the same as for example the choice of the number of replicas)?

Now we are back to the question of what is the right unit in which we define 
this 'level of service' ("Gold", "Silver"...).
Should the level of service be defined when the account is created or should we 
allow a user to state:
"I would like to have a container with Gold to keep my work, Bronze to keep my 
family pictures and videos and Aluminum to keep a copy of all my music files".

If we choose to enable container service levels, we need to enable billing per 
level of service such that a single account could be billed for the actual use 
it has done per each level of service. Maybe we even need to have all 
statistics gathered to be grouped by service level.
I am not sure if we can escape that even with account service levels.

DH
On Thu, Jul 18, 2013 at 9:37 PM, John Dickinson 
mailto:m...@not.mn>> wrote:
Yes, and I'd imagine that the normal default would be for replicated data.

Moving the granularity from a container to account-based, as Chmouel and Chuck 
said, is interesting too.

--John

On Jul 18, 2013, at 11:32 AM, Christian Schwede 
mailto:i...@cschwede.de>> wrote:

> A solution to this might be to set the default policy as a configuration
> setting in the proxy. If you want a replicated swift cluster just allow
> this policy in the proxy and set it to default. The same for EC cluster,
> just set the allowed policy to EC. If you want both (and let your users
> decide which policy to use) simply configure a list of allowed policies
> with the first one in the list as the default policy in case they don't
> set a policy during container creation.
>
> Am 18.07.13 20:15, schrieb Chuck Thier:
>> I think you are missing the point.  What I'm talking about is who
>> chooses what data is EC and what is not.  The point that I am trying to
>> make is that the operators of swift clusters should decide what data is
>> EC, not the clients/users.  How the data is stored should be totally
>> transparent to the user.
>>
>> Now if we want to down the road offer user defined classes of storage
>> (like how S3 does reduced redundancy), I'm cool with that, just that it
>> should be orthogonal to the implementation of EC.
>>
>> --
>> Chuck
>>
>>
>> On Thu, Jul 18, 2013 at 12:57 PM, John Dickinson 
>> mailto:m...@not.mn>
>> >> wrote:
>>
>>Are you talking about the parameters for EC or the fact that
>>something is erasure coded vs replicated?
>>
>>For the first, that's exactly what we're thinking: a deployer sets
>>up one (or more) policies and calls them Alice, Bob, or whatever,
>>and then the API client can set that on a particular container.
>>
>>This allows users who know what they are doing (ie those who know
>>the tradeoffs and their data characteristics) to make good choices.
>>It also allows deployers who want to have an automatic policy to set
>>one up to migrate data.
>>
>>For example, a deployer may choose to run a migrator process that
>>moved certain data from replicated to EC containers over time (and
>>drops a manifest file in the replicated tier to point to the EC data
>>so that the URL still works).
>>
>>Like existing features in Swift (eg large objects), this gives users
>>the ability to flexibly store their data with a nice interface yet
>>still have the ability to get at some of the pokey bits underneath.
>>
>>--John
>>
>>
>>
>>On Jul 18, 2013, at 10:31 AM, Chuck Thier 
>> mailto:cth...@gmail.c

[openstack-dev] [barbican]

[Tiwari, Arvind]

Hi All,

I am following Barbican project and I have some question around it, I would 
appreciate if someone  can answer them or point me to the correct resource


1.   What is the state of the project, is it in the state where it can be 
utilized in production deployments?

2.Dose Barbican is an implementation of 
https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the 
correct design/BP resource on which Barbican is based on.

3.Is it KMIP (KMIP 1.1 spec 
https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are 
the plans any initiative so far?


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

Re: [openstack-dev] A simple way to improve nova scheduler

[John Garbutt]

On 22 July 2013 13:23, Boris Pavlovic  wrote:
> I see only one race condition. (in current solution we have the same
> situtaiton)
> Between request to compute node and data is updated in DB, we could use
> wrong state of compute node.
> By the way it is fixed by retry.

This race turns out to be a big deal when there are bursts of VM.start requests.

I am currently thinking about ways we can look to eliminate this one.
Hoping to have a design summit session on that.

John

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

[openstack-dev] DevStack deployment issue

[Denis Makogon]

There is bug in requests package versions. Current version 1.2.3 is stable.
According to pypi, eggs of versions 1.2.1, 1.2.2 are broken. Please fix it
im cinder requirements
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] pip requirements externally host (evil evil stab stab stab)

[Alex Gaynor]

As a heads up I filed bugs with each of these projects (with the exception
of netifaces, which doesn't appear to have a tracker). The dnspython
maintainer has already uploaded the package to PyPi and disabled scraping!

Alex


On Fri, Jul 19, 2013 at 8:04 PM, Monty Taylor  wrote:

> Hey guys!
>
> PyPI is moving towards the world of getting people to stop hosting stuff
> via external links. It's been bad for us in the past and one of the
> reasons for the existence of our mirror. pip 1.4 has an option to
> disallow following external links, and in 1.5 it's going to be the
> default behavior.
>
> Looking forward, we have 5 pip packages that host their stuff
> externally. If we have any pull with their authors, we should get them
> to actually upload stuff to pypi. If we don't, we should strongly
> consider our use of these packages. As soon as pip 1.4 comes out, I
> would like to moving forward restrict the addition of NEW requirements
> that do not host on pypi. (all 5 of these host insecurely as well, fwiw)
>
> The culprits are:
>
> dnspython,lockfile,netifaces,psutil,pysendfile
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The PCI support blueprint

[Ian Wells]

Per the last summit, there are many interested parties waiting on PCI
support.  Boris (who unfortunately waasn't there) jumped in with an
implementation before the rest of us could get a blueprint up, but I
suspect he's been stretched rather thinly and progress has been much
slower than I was hoping it would be.  There are many willing hands
happy to take this work on; perhaps it's time we did, so that we can
get something in before Havana.

I'm sure we could use a better scheduler.  I don't think that actually
affects most of the implementation of passthough and I don't think we
should tie the two together.  "The perfect is the enemy of the good."

And as far as the quantity of data passed back - we've discussed
before that it would be nice (for visibility purposes) to be able to
see an itemised list of all of the allocated and unallocated PCI
resources in the database.  There could be quite a lot per host (256
per card x say 10 cards depending on your hardware).  But passing that
itemised list back is somewhat of a luxury - in practice, what you
need for scheduling is merely a list of categories of card (those
pools where any one of the PCI cards in the pool would do) and counts.
 The compute node should be choosing a card from the pool in any case.
 The scheduler need only find a machine with cards available.

I'm not totally convinced that passing back the itemised list is
necessarily a problem, but in any case we can make the decision one
way or the other, take on the risk if we like, and get the code
written - if it turns out not to be scalable then we can fix *that* in
the next release, but at least we'll have something to play with in
the meantime.  Delaying the whole thing to I is just silly.
-- 
Ian.

On 22 July 2013 17:34, Jiang, Yunhong  wrote:
> As for the scalability issue, boris, are you talking about the VF number 
> issue, i.e. A physical PCI devices can at most have 256 virtual functions?
>
> I think we have discussed this before. We should keep the compute node to 
> manage the same VF functions, so that VFs belongs to the same PF will have 
> only one entry in DB, with a field indicating the number of free VFs. Thus 
> there will be no scalability issue because the number of PCI slot is limited.
>
> We didn't implement this mechanism on current patch set because we agree to 
> make it a  enhancement. If it's really a concern, please raise it and we will 
> enhance our resource tracker for this. That's not complex task.
>
> Thanks
> --jyh
>
>> -Original Message-
>> From: Russell Bryant [mailto:rbry...@redhat.com]
>> Sent: Monday, July 22, 2013 8:22 AM
>> To: Jiang, Yunhong
>> Cc: bo...@pavlovic.me; openstack-dev@lists.openstack.org
>> Subject: Re: The PCI support blueprint
>>
>> On 07/22/2013 11:17 AM, Jiang, Yunhong wrote:
>> > Hi, Boris
>> > I'm a surprised that you want to postpone the PCI support
>> (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base) to I
>> release. You and our team have been working on this for a long time, and
>> the patches has been reviewed several rounds. And we have been waiting
>> for your DB layer patch for two weeks without any update.
>> >
>> > Can you give more reason why it's pushed to I release? If you are out
>> of bandwidth, we are sure to take it and push it to H release!
>> >
>> > Is it because you want to base your DB layer on your 'A simple way to
>> improve nova scheduler'? That really does not make sense to me. Firstly,
>> that proposal is still under early discussion and get several different 
>> voices
>> already, secondly, PCI support is far more than DB layer, it includes
>> resource tracker, scheduler filter, libvirt support enhancement etc. Even if
>> we will change the scheduler that way after I release, we need only
>> change the DB layer, and I don't think that's a big effort!
>>
>> Boris mentioned scalability concerns with the current approach on IRC.
>> I'd like more detail.
>>
>> In general, if we can see a reasonable path to upgrade what we have now
>> to make it better in the future, then we don't need to block it because
>> of that.  If the current approach will result in a large upgrade impact
>> to users to be able to make it better, that would be a reason to hold
>> off.  It also depends on how serious the scalability concerns are.
>>
>> --
>> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [neutron] Configuration file generator

[Julien Danjou]

Hi there,

I've been working on the changes that would need to be done to make the
default config generator work for Neutron.

However, the current default config generator doesn't support the
possibility to generate different configuration files (e.g. one per
service/plugin). I can imagine two options:

a. move every options in oslo.config.cfg.CONF, moving the plugins into
   their own section rather than in their own file, register all options
   at module-level, avoiding duplicate options.

b. enhance config.generator to generate a config file from a particular
   object (not always olso.config.cfg.CONF like it's done currently).
   That means Neutron should evolve to provide a global CONF object per
   plugin at least.

Option a. is how all other OpenStack projects¹ are working so far.
Option b. requires a bit more work on both side.

Is there any particular way you guys see things?


¹  nova, ceilometer and heat at least for now

-- 
Julien Danjou
/* Free Software hacker * freelance consultant
   http://julien.danjou.info */


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

Re: [openstack-dev] The PCI support blueprint

[Russell Bryant]

On 07/22/2013 11:17 AM, Jiang, Yunhong wrote:
> Hi, Boris
>   I'm a surprised that you want to postpone the PCI support 
> (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base) to I 
> release. You and our team have been working on this for a long time, and the 
> patches has been reviewed several rounds. And we have been waiting for your 
> DB layer patch for two weeks without any update.
> 
>   Can you give more reason why it's pushed to I release? If you are out 
> of bandwidth, we are sure to take it and push it to H release!
> 
>   Is it because you want to base your DB layer on your 'A simple way to 
> improve nova scheduler'? That really does not make sense to me. Firstly, that 
> proposal is still under early discussion and get several different voices 
> already, secondly, PCI support is far more than DB layer, it includes 
> resource tracker, scheduler filter, libvirt support enhancement etc. Even if 
> we will change the scheduler that way after I release, we need only change 
> the DB layer, and I don't think that's a big effort!

Boris mentioned scalability concerns with the current approach on IRC.
I'd like more detail.

In general, if we can see a reasonable path to upgrade what we have now
to make it better in the future, then we don't need to block it because
of that.  If the current approach will result in a large upgrade impact
to users to be able to make it better, that would be a reason to hold
off.  It also depends on how serious the scalability concerns are.

-- 
Russell Bryant

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

[openstack-dev] The PCI support blueprint

[Jiang, Yunhong]

Hi, Boris
I'm a surprised that you want to postpone the PCI support 
(https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base) to I 
release. You and our team have been working on this for a long time, and the 
patches has been reviewed several rounds. And we have been waiting for your DB 
layer patch for two weeks without any update.

Can you give more reason why it's pushed to I release? If you are out 
of bandwidth, we are sure to take it and push it to H release!

Is it because you want to base your DB layer on your 'A simple way to 
improve nova scheduler'? That really does not make sense to me. Firstly, that 
proposal is still under early discussion and get several different voices 
already, secondly, PCI support is far more than DB layer, it includes resource 
tracker, scheduler filter, libvirt support enhancement etc. Even if we will 
change the scheduler that way after I release, we need only change the DB 
layer, and I don't think that's a big effort!

Thanks
--jyh

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

Re: [openstack-dev] [Savanna-all] Savanna EDP sequence diagrams added for discussion...

[Alexander Kuznetsov]

I updated the REST API draft -
https://etherpad.openstack.org/savanna_API_draft_EDP_extensions. New
methods related to job source and data discovery components were added;
also the job object was updated.


On Fri, Jul 19, 2013 at 12:26 AM, Trevor McKay  wrote:

> fyi, updates to the diagram based on feedback
>
> On Thu, 2013-07-18 at 13:49 -0400, Trevor McKay wrote:
> > Hi all,
> >
> >   Here is a page to hold sequence diagrams for Savanna EDP,
> > based on current launchpad blueprints.  We thought it might be helpful to
> > create some diagrams for discussion as the component specs are written
> and the
> > API is worked out:
> >
> >   https://wiki.openstack.org/wiki/Savanna/EDP_Sequences
> >
> >   (The main page for EDP is here
> https://wiki.openstack.org/wiki/Savanna/EDP )
> >
> >   There is an initial sequence there, along with a link to the source
> > for generating the PNG with PlantUML.  Feedback would be great, either
> > through IRC, email, comments on the wiki, or by modifying
> > the sequence and/or posting additional sequences.
> >
> >   The sequences can be generated/modified easily with with Plantuml which
> > installs as a single jar file:
> >
> >   http://plantuml.sourceforge.net/download.html
> >
> >   java -jar plantuml.jar
> >
> >   Choose the directory which contains plantuml text files and it will
> > monitor, generate, and update PNGs as you save/modify text files. I
> thought
> > it was broken the first time I ran it because there are no controls :)
> > Very simple.
> >
> > Best,
> >
> > Trevor
> >
> >
>
>
>
> --
> Mailing list: https://launchpad.net/~savanna-all
> Post to : savanna-...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~savanna-all
> More help   : https://help.launchpad.net/ListHelp
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] A simple way to improve nova scheduler

[Jiang, Yunhong]

The thing laggy is, currently resource tracker will update the usage 
information whenever resource changes, not only in periodic tasks. If you 
really want to get the current result with periodic update, you have to do some 
in-memory management and you even need sync between different scheduler 
controller, as stated in  
http://lists.openstack.org/pipermail/openstack-dev/2013-June/010490.html .

-jyh

From: Boris Pavlovic [mailto:bo...@pavlovic.me]
Sent: Monday, July 22, 2013 5:17 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] A simple way to improve nova scheduler

Joe,

>> Speaking of Chris Beherns  "Relying on anything but the DB for current 
>> memory free, etc, is just too laggy... so we need to stick with it, IMO." 
>> http://lists.openstack.org/pipermail/openstack-dev/2013-June/010485.html

It doesn't scale, use tons of resources, works slow and is hard to extend.
Also the mechanism of getting free and used memory is done by virt layer.
And only thing that could be laggy is rpc (but it is used also by compute node 
update)


>> * How do you bring a new scheduler up in an existing deployment and make it 
>> get the full state of the system?

You should wait for a one periodic task time. And you will get full information 
about all compute nodes.

>> *  Broadcasting RPC updates from compute nodes to the scheduler means every 
>> scheduler has to process  the same RPC message.  And if a deployment hits 
>> the point where the number of compute updates is consuming 99 percent of the 
>> scheduler's time just adding another scheduler won't fix anything as it will 
>> get bombarded too.


If we are speaking about numbers. You are able to see our doc, where they are 
counted.
If we have 10k nodes it will make only 150rpc calls/sec (which means nothing 
for cpu). By the way we way we will remove 150 calls/s from conductor. One more 
thing currently in 10nodes deployment I think we will spend almost all time fro 
waiting DB (compute_nodes_get_all()). And also when we are calling this method 
in this moment we should process all data for 60 sec. (So in this case in 
numbers we are doing on scheduler side 60*request_pro_sec of our approach. 
Which means if we get more then 1 request pro sec we will do more CPU load.)


>> Also OpenStack is already deeply invested in using the central DB model for 
>> the state of the 'world' and while I am not against changing that, I think 
>> we should evaluate that switch in a larger context.

Step by step. As first step we could just remove compute_node_get_all method. 
Which will make our openstack much scalable and fast.


By the way see one more time answers on your comments in doc.

Best regards,
Boris Pavlovic

Mirantis Inc.




On Sat, Jul 20, 2013 at 3:14 AM, Joe Gordon 
mailto:joe.gord...@gmail.com>> wrote:


On Fri, Jul 19, 2013 at 3:13 PM, Sandy Walsh 
mailto:sandy.wa...@rackspace.com>> wrote:


On 07/19/2013 05:36 PM, Boris Pavlovic wrote:
> Sandy,
>
> I don't think that we have such problems here.
> Because scheduler doesn't pool compute_nodes.
> The situation is another compute_nodes notify scheduler about their
> state. (instead of updating their state in DB)
>
> So for example if scheduler send request to compute_node, compute_node
> is able to run rpc call to schedulers immediately (not after 60sec).
>
> So there is almost no races.
There are races that occur between the eventlet request threads. This is
why the scheduler has been switched to single threaded and we can only
run one scheduler.

This problem may have been eliminated with the work that Chris Behrens
and Brian Elliott were doing, but I'm not sure.


Speaking of Chris Beherns  "Relying on anything but the DB for current memory 
free, etc, is just too laggy... so we need to stick with it, IMO." 
http://lists.openstack.org/pipermail/openstack-dev/2013-June/010485.html

Although there is some elegance to the proposal here I have some concerns.

If just using RPC broadcasts from compute to schedulers to keep track of 
things, we get two issues:

* How do you bring a new scheduler up in an existing deployment and make it get 
the full state of the system?
* Broadcasting RPC updates from compute nodes to the scheduler means every 
scheduler has to process  the same RPC message.  And if a deployment hits the 
point where the number of compute updates is consuming 99 percent of the 
scheduler's time just adding another scheduler won't fix anything as it will 
get bombarded too.

Also OpenStack is already deeply invested in using the central DB model for the 
state of the 'world' and while I am not against changing that, I think we 
should evaluate that switch in a larger context.



But certainly, the old approach of having the compute node broadcast
status every N seconds is not suitable and was eliminated a long time ago.

>
>
> Best regards,
> Boris Pavlovic
>
> Mirantis Inc.
>
>
>
> On Sat, Jul 20, 2013 at 12:23 AM, Sandy Walsh 
> mailto:sandy.wa...@rackspace.com>
> 

Re: [openstack-dev] [Swift] erasure codes, digging deeper

[David Hadas]

Hi,

In Portland, we discussed a somewhat related issue of having multiple
replication levels in one Swift cluster.
It may be that a provider would not wish to expose the use of EC or the
level of replication used. For example a provider may offer a predefined
set of services such as "Gold", "Silver" and "Bronze", "Aluminum" which a
user can choose from. The provider may decide how each level is implemented
(As a silly example: Gold is 4 way replication, Silver is a 3 way
replication, Bronze is EC, Aluminum is single replica without EC).

Does it make sense to consider EC as an implementation of a certain service
level (the same as for example the choice of the number of replicas)?

Now we are back to the question of what is the right unit in which we
define this 'level of service' ("Gold", "Silver"...).
Should the level of service be defined when the account is created or
should we allow a user to state:
"I would like to have a container with Gold to keep my work, Bronze to keep
my family pictures and videos and Aluminum to keep a copy of all my music
files".

If we choose to enable container service levels, we need to enable billing
per level of service such that a single account could be billed for the
actual use it has done per each level of service. Maybe we even need to
have all statistics gathered to be grouped by service level.
I am not sure if we can escape that even with account service levels.

DH

On Thu, Jul 18, 2013 at 9:37 PM, John Dickinson  wrote:

> Yes, and I'd imagine that the normal default would be for replicated data.
>
> Moving the granularity from a container to account-based, as Chmouel and
> Chuck said, is interesting too.
>
> --John
>
> On Jul 18, 2013, at 11:32 AM, Christian Schwede  wrote:
>
> > A solution to this might be to set the default policy as a configuration
> > setting in the proxy. If you want a replicated swift cluster just allow
> > this policy in the proxy and set it to default. The same for EC cluster,
> > just set the allowed policy to EC. If you want both (and let your users
> > decide which policy to use) simply configure a list of allowed policies
> > with the first one in the list as the default policy in case they don't
> > set a policy during container creation.
> >
> > Am 18.07.13 20:15, schrieb Chuck Thier:
> >> I think you are missing the point.  What I'm talking about is who
> >> chooses what data is EC and what is not.  The point that I am trying to
> >> make is that the operators of swift clusters should decide what data is
> >> EC, not the clients/users.  How the data is stored should be totally
> >> transparent to the user.
> >>
> >> Now if we want to down the road offer user defined classes of storage
> >> (like how S3 does reduced redundancy), I'm cool with that, just that it
> >> should be orthogonal to the implementation of EC.
> >>
> >> --
> >> Chuck
> >>
> >>
> >> On Thu, Jul 18, 2013 at 12:57 PM, John Dickinson  >> > wrote:
> >>
> >>Are you talking about the parameters for EC or the fact that
> >>something is erasure coded vs replicated?
> >>
> >>For the first, that's exactly what we're thinking: a deployer sets
> >>up one (or more) policies and calls them Alice, Bob, or whatever,
> >>and then the API client can set that on a particular container.
> >>
> >>This allows users who know what they are doing (ie those who know
> >>the tradeoffs and their data characteristics) to make good choices.
> >>It also allows deployers who want to have an automatic policy to set
> >>one up to migrate data.
> >>
> >>For example, a deployer may choose to run a migrator process that
> >>moved certain data from replicated to EC containers over time (and
> >>drops a manifest file in the replicated tier to point to the EC data
> >>so that the URL still works).
> >>
> >>Like existing features in Swift (eg large objects), this gives users
> >>the ability to flexibly store their data with a nice interface yet
> >>still have the ability to get at some of the pokey bits underneath.
> >>
> >>--John
> >>
> >>
> >>
> >>On Jul 18, 2013, at 10:31 AM, Chuck Thier  >>> wrote:
> >>
> >>> I'm with Chmouel though.  It seems to me that EC policy should be
> >>chosen by the provider and not the client.  For public storage
> >>clouds, I don't think you can make the assumption that all
> >>users/clients will understand the storage/latency tradeoffs and
> >>benefits.
> >>>
> >>>
> >>> On Thu, Jul 18, 2013 at 8:11 AM, John Dickinson  >>> wrote:
> >>> Check out the slides I linked. The plan is to enable an EC policy
> >>that is then set on a container. A cluster may have a replication
> >>policy and one or more EC policies. Then the user will be able to
> >>choose the policy for a particular container.
> >>>
> >>> --John
> >>>
> >>>
> >>>
> >>>
> >>> On Jul 18, 2013, at 2:50 AM, Chmouel Boudjnah
> >>mailto:chm

Re: [openstack-dev] The PCI support blueprint

[Jiang, Yunhong]

As for the scalability issue, boris, are you talking about the VF number issue, 
i.e. A physical PCI devices can at most have 256 virtual functions? 

I think we have discussed this before. We should keep the compute node to 
manage the same VF functions, so that VFs belongs to the same PF will have only 
one entry in DB, with a field indicating the number of free VFs. Thus there 
will be no scalability issue because the number of PCI slot is limited.

We didn't implement this mechanism on current patch set because we agree to 
make it a  enhancement. If it's really a concern, please raise it and we will 
enhance our resource tracker for this. That's not complex task.

Thanks
--jyh

> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Monday, July 22, 2013 8:22 AM
> To: Jiang, Yunhong
> Cc: bo...@pavlovic.me; openstack-dev@lists.openstack.org
> Subject: Re: The PCI support blueprint
> 
> On 07/22/2013 11:17 AM, Jiang, Yunhong wrote:
> > Hi, Boris
> > I'm a surprised that you want to postpone the PCI support
> (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base) to I
> release. You and our team have been working on this for a long time, and
> the patches has been reviewed several rounds. And we have been waiting
> for your DB layer patch for two weeks without any update.
> >
> > Can you give more reason why it's pushed to I release? If you are out
> of bandwidth, we are sure to take it and push it to H release!
> >
> > Is it because you want to base your DB layer on your 'A simple way to
> improve nova scheduler'? That really does not make sense to me. Firstly,
> that proposal is still under early discussion and get several different voices
> already, secondly, PCI support is far more than DB layer, it includes
> resource tracker, scheduler filter, libvirt support enhancement etc. Even if
> we will change the scheduler that way after I release, we need only
> change the DB layer, and I don't think that's a big effort!
> 
> Boris mentioned scalability concerns with the current approach on IRC.
> I'd like more detail.
> 
> In general, if we can see a reasonable path to upgrade what we have now
> to make it better in the future, then we don't need to block it because
> of that.  If the current approach will result in a large upgrade impact
> to users to be able to make it better, that would be a reason to hold
> off.  It also depends on how serious the scalability concerns are.
> 
> --
> Russell Bryant

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

[openstack-dev] Article on Improving Openstack's Parallel Performance

[Peter Feiner]

Hello,

I've written an article about my ongoing work on improving OpenStack's
parallel performance:

http://blog.gridcentric.com/bid/318277/Boosting-OpenStack-s-Parallel-Performance

The article discusses host configuration changes and patches (upstream
and in progress) that give a 74% speedup in a parallel macro benchmark
(boot 40 instances, ping them, ssh into them, delete them).

This article is a follow up to my presentation at the OpenStack summit
in Portland.

Peter

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

Re: [openstack-dev] A simple way to improve nova scheduler

[Russell Bryant]

On 07/22/2013 10:43 AM, Boris Pavlovic wrote:
> Russell,
> 
> To get information about "all" compute nodes we should wait one periodic
> task (60 seconds by default).
> So starting will take a while.
> 
> But I don't think that this is a big problem:
> 1) if we are already able to wait each time for heavy and long (> few
> seconds) db querie
> 2) if we have more then one scheduler, we are always able to turn and
> change one by one.
> (I don't think that having for 5 minutes old and new schedulers will
> break anything).
> 
> Also as a first step that could be done to speed up scheduler:
> We could just remove db.compute_node_get_all() and send RPC calls
> directly to schedulers. 
> I think that patch-set that change this thing will be pretty small
> (~100-150 lines of code) and doesn't requirers big changes in current
> scheduler implementation. 

In any case, I think it's too late in the Havana cycle to be introducing
a new effort like this.  It will have to wait for Icehouse.  We should
plan to have a design summit session on it, as well.

-- 
Russell Bryant

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

[openstack-dev] [Heat] Multi region support for Heat

[Bartosz Górski]

Hi folks,

I would like to start a discussion about the blueprint I raised about 
multi region support.
I would like to get feedback from you. If something is not clear or you 
have questions do not hesitate to ask.

Please let me know what you think.

Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support

Wikipage: 
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat 



Thanks,
Bartosz

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

Re: [openstack-dev] A simple way to improve nova scheduler

[Boris Pavlovic]

Russell,

To get information about "all" compute nodes we should wait one periodic
task (60 seconds by default).
So starting will take a while.

But I don't think that this is a big problem:
1) if we are already able to wait each time for heavy and long (> few
seconds) db querie
2) if we have more then one scheduler, we are always able to turn and
change one by one.
(I don't think that having for 5 minutes old and new schedulers will break
anything).

Also as a first step that could be done to speed up scheduler:
We could just remove db.compute_node_get_all() and send RPC calls directly
to schedulers.
I think that patch-set that change this thing will be pretty small
(~100-150 lines of code) and doesn't requirers big changes in current
scheduler implementation.


Best regards,
Boris Pavlovic

Mirantis Inc.



On Mon, Jul 22, 2013 at 5:50 PM, Russell Bryant  wrote:

> On 07/22/2013 08:16 AM, Boris Pavlovic wrote:
> >>> * How do you bring a new scheduler up in an existing deployment and
> make it get the full state of the system?
> >
> > You should wait for a one periodic task time. And you will get full
> > information about all compute nodes.
>
> This also affects upgrading a scheduler.  Also consider a continuous
> deployment setup.  Every time you update a scheduler, it's not usable
> for (periodic task interval) seconds/minutes?
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] New DB column or new DB table?

[Wang, Shane]

Daniel raised a good point, I also agreed that is not a good architecture.
Nova can't touch any monitoring stuffs - I don't think that is good.
At least, Ceilometer can be a monitoring hub for external utilities.

On the other hand, for the options Lianhao raised.
Is a query on a DB and a json column faster than the one on two-DB join?
I have no experimental data but I doubt it.

Thanks.
--
Shane

Dan Smith wrote on 2013-07-20:

>> IIUC, Ceilometer is currently a downstream consumer of data from
>> Nova, but no functionality in Nova is a consumer of data from
>> Ceilometer. This is good split from a security separation point of
>> view, since the security of Nova is self-contained in this
>> architecture.
>> 
>> If Nova schedular becomes dependant on data from ceilometer, then now
>> the security of Nova depends on the security of Ceilometer, expanding
>> the attack surface. This is not good architecture IMHO.
> 
> Agreed.
> 
>> At the same time, I hear your concerns about the potential for
>> duplication of stats collection functionality between Nova &
>> Ceilometer. I don't think we neccessarily need to remove 100% of
>> duplication. IMHO probably the key thing is for the virt drivers to
>> expose a standard API for exporting the stats, and make sure that
>> both ceilometer & nova schedular use the same APIs and ideally the
>> same data feed, so we're not invoking the same APIs twice to get the
>> same data.
> 
> I imagine there's quite a bit that could be shared, without dependency
> between the two. Interfaces out of the virt drivers may be one, and the
> code that boils numbers into useful values, as well as perhaps the
> format of the JSON blobs that are getting shoved into the database.
> Perhaps a ceilo-core library with some very simple primitives and
> definitions could be carved out, which both nova and ceilometer could
> import for consistency, without a runtime dependency?
> 
> --Dan
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

[Wang, Shane]

Sandy Walsh wrote on 2013-07-19:

> 
> 
> On 07/19/2013 09:47 AM, Day, Phil wrote:
>>> -Original Message-
>>> From: Sean Dague [mailto:s...@dague.net]
>>> Sent: 19 July 2013 12:04
>>> To: OpenStack Development Mailing List
>>> Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics
>>> collector for scheduling (was: New DB column or new DB table?)
>>> 
>>> On 07/19/2013 06:18 AM, Day, Phil wrote:
 Ceilometer is a great project for taking metrics available in Nova and 
 other
>>> systems and making them available for use by Operations, Billing,
>>> Monitoring, etc - and clearly we should try and avoid having multiple
>>> collectors of the same data.
 
 But making the Nova scheduler dependent on Ceilometer seems to be the
>>> wrong way round to me - scheduling is such a fundamental operation that I
>>> want Nova to be self sufficient in this regard.   In particular I don't 
>>> want the
>>> availability of my core compute platform to be constrained by the 
>>> availability
>>> of my (still evolving) monitoring system.
 
 If Ceilometer can be fed from the data used by the Nova scheduler then
> that's
>>> a good plus - but not the other way round.
>>> 
>>> I assume it would gracefully degrade to the existing static allocators if
>>> something went wrong. If not, well that would be very bad.
>>> 
>>> Ceilometer is an integrated project in Havana. Utilization based
>>> scheduling would be a new feature. I'm not sure why we think that
>>> duplicating the metrics collectors in new code would be less buggy
>>> than working with Ceilometer. Nova depends on external projects all
>>> the time.
>>> 
>>> If we have a concern about robustness here, we should be working as an
>>> overall project to address that.
>>> 
>>> -Sean
>>> 
>> Just to be cleat its about a lot more than just robustness in the code - its 
>> the
> whole architectural pattern of putting Ceilometer at the centre of Nova
> scheduling that concerns me.
>> 
>> As I understand it Celiometer can collect metrics from more than one copy of
> Nova - which is good; I want to run multiple independent copies in different
> regions and I want to have all of my monitoring data going back to one place.
> However that doesn't mean that I now also want all of those independent copies
> of Nova depending on that central monitoring infrastructure for something as
> basic as scheduling.  (I don't want to stop anyone that does either - but I 
> don't
> see why I should be forced down that route).
>> 
>> The original change that sparked this debate came not from anything to do
> with utilisation based scheduling, but the pretty basic and simple desire to 
> add
> new types of consumable resource counters into the scheduler logic in a more
> general way that having to make a DB schema change.  This was generally
> agreed to be a good thing, and it pains me to see that valuable work now 
> blocked
> on what seems to be turning into an strategic discussion around the role of
> Ceilometer (Is it a monitoring tool or a fundamental metric bus, etc).
>> 
>> At the point where Ceilomter can be shown to replace the current scheduler
> resource mgmt code in Nova, then we should be talking about switching to it -
> but in the meantime why can't we continue to have incremental improvements
> in the current Nova code ?
> 
> +1

+1

We can keep discussion to determine R&R for Nova and Ceilometer.
Can we have a decision to make so we can move forward to have incremental 
improvements in Nova?

Thanks.
--
Shane

> 
>> 
>> Cheers
>> Phil
>> 
>> 
>> 
>> ___
>> 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] A simple way to improve nova scheduler

[Russell Bryant]

On 07/22/2013 08:16 AM, Boris Pavlovic wrote:
>>> * How do you bring a new scheduler up in an existing deployment and make it 
>>> get the full state of the system?
> 
> You should wait for a one periodic task time. And you will get full
> information about all compute nodes. 

This also affects upgrading a scheduler.  Also consider a continuous
deployment setup.  Every time you update a scheduler, it's not usable
for (periodic task interval) seconds/minutes?

-- 
Russell Bryant

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

Re: [openstack-dev] A simple way to improve nova scheduler

[Boris Pavlovic]

Sandy,

I see only one race condition. (in current solution we have the same
situtaiton)
Between request to compute node and data is updated in DB, we could use
wrong state of compute node.
By the way it is fixed by retry.

I don't see any new races that are produces by new approach without DB.
Could you say line or method that will produce races?

Best regards,
Boris Pavlovic





On Sat, Jul 20, 2013 at 2:13 AM, Sandy Walsh wrote:

>
>
> On 07/19/2013 05:36 PM, Boris Pavlovic wrote:
> > Sandy,
> >
> > I don't think that we have such problems here.
> > Because scheduler doesn't pool compute_nodes.
> > The situation is another compute_nodes notify scheduler about their
> > state. (instead of updating their state in DB)
> >
> > So for example if scheduler send request to compute_node, compute_node
> > is able to run rpc call to schedulers immediately (not after 60sec).
> >
> > So there is almost no races.
>
> There are races that occur between the eventlet request threads. This is
> why the scheduler has been switched to single threaded and we can only
> run one scheduler.
>
> This problem may have been eliminated with the work that Chris Behrens
> and Brian Elliott were doing, but I'm not sure.
>
> But certainly, the old approach of having the compute node broadcast
> status every N seconds is not suitable and was eliminated a long time ago.
>
> >
> >
> > Best regards,
> > Boris Pavlovic
> >
> > Mirantis Inc.
> >
> >
> >
> > On Sat, Jul 20, 2013 at 12:23 AM, Sandy Walsh  > > wrote:
> >
> >
> >
> > On 07/19/2013 05:01 PM, Boris Pavlovic wrote:
> > > Sandy,
> > >
> > > Hm I don't know that algorithm. But our approach doesn't have
> > > exponential exchange.
> > > I don't think that in 10k nodes cloud we will have a problems with
> 150
> > > RPC call/sec. Even in 100k we will have only 1.5k RPC call/sec.
> > > More then (compute nodes update their state in DB through conductor
> > > which produce the same count of RPC calls).
> > >
> > > So I don't see any explosion here.
> >
> > Sorry, I was commenting on Soren's suggestion from way back
> (essentially
> > listening on a separate exchange for each unique flavor ... so no
> > scheduler was needed at all). It was a great idea, but fell apart
> rather
> > quickly.
> >
> > The existing approach the scheduler takes is expensive (asking the db
> > for state of all hosts) and polling the compute nodes might be
> do-able,
> > but you're still going to have latency problems waiting for the
> > responses (the states are invalid nearly immediately, especially if a
> > fill-first scheduling algorithm is used). We ran into this problem
> > before in an earlier scheduler implementation. The round-tripping
> kills.
> >
> > We have a lot of really great information on Host state in the form
> of
> > notifications right now. I think having a service (or notification
> > driver) listening for these and keeping an the HostState
> incrementally
> > updated (and reported back to all of the schedulers via the fanout
> > queue) would be a better approach.
> >
> > -S
> >
> >
> > >
> > > Best regards,
> > > Boris Pavlovic
> > >
> > > Mirantis Inc.
> > >
> > >
> > > On Fri, Jul 19, 2013 at 11:47 PM, Sandy Walsh
> > mailto:sandy.wa...@rackspace.com>
> > >  > >> wrote:
> > >
> > >
> > >
> > > On 07/19/2013 04:25 PM, Brian Schott wrote:
> > > > I think Soren suggested this way back in Cactus to use MQ
> > for compute
> > > > node state rather than database and it was a good idea then.
> > >
> > > The problem with that approach was the number of queues went
> > exponential
> > > as soon as you went beyond simple flavors. Add Capabilities or
> > other
> > > criteria and you get an explosion of exchanges to listen to.
> > >
> > >
> > >
> > > > On Jul 19, 2013, at 10:52 AM, Boris Pavlovic
> > mailto:bo...@pavlovic.me>
> > > >
> > > > 
> >  > > >
> > > >> Hi all,
> > > >>
> > > >>
> > > >> In Mirantis Alexey Ovtchinnikov and me are working on nova
> > scheduler
> > > >> improvements.
> > > >>
> > > >> As far as we can see the problem, now scheduler has two
> > major issues:
> > > >>
> > > >> 1) Scalability. Factors that contribute to bad scalability
> > are these:
> > > >> *) Each compute node every periodic task interval (60 sec
> > by default)
> > > >> updates resources state in DB.
> > > >> *) On every boot request scheduler has to fetch 

Re: [openstack-dev] A simple way to improve nova scheduler

[Boris Pavlovic]

Joe,

>> Speaking of Chris Beherns  "Relying on anything but the DB for current
memory free, etc, is just too laggy… so we need to stick with it, IMO."
http://lists.openstack.org/pipermail/openstack-dev/2013-June/010485.html

It doesn't scale, use tons of resources, works slow and is hard to extend.
Also the mechanism of getting free and used memory is done by virt layer.
And only thing that could be laggy is rpc (but it is used also by compute
node update)


>> * How do you bring a new scheduler up in an existing deployment and make
it get the full state of the system?

You should wait for a one periodic task time. And you will get full
information about all compute nodes.

>> *  Broadcasting RPC updates from compute nodes to the scheduler means
every scheduler has to process  the same RPC message.  And if a deployment
hits the point where the number of compute updates is consuming 99 percent
of the scheduler's time just adding another scheduler won't fix anything as
it will get bombarded too.


If we are speaking about numbers. You are able to see our doc, where they
are counted.
If we have 10k nodes it will make only 150rpc calls/sec (which means
nothing for cpu). By the way we way we will remove 150 calls/s from
conductor. One more thing currently in 10nodes deployment I think we will
spend almost all time fro waiting DB (compute_nodes_get_all()). And also
when we are calling this method in this moment we should process all data
for 60 sec. (So in this case in numbers we are doing on scheduler side
60*request_pro_sec of our approach. Which means if we get more then 1
request pro sec we will do more CPU load.)


>> Also OpenStack is already deeply invested in using the central DB model
for the state of the 'world' and while I am not against changing that, I
think we should evaluate that switch in a larger context.

Step by step. As first step we could just remove compute_node_get_all
method. Which will make our openstack much scalable and fast.


By the way see one more time answers on your comments in doc.

Best regards,
Boris Pavlovic

Mirantis Inc.





On Sat, Jul 20, 2013 at 3:14 AM, Joe Gordon  wrote:

>
>
>
> On Fri, Jul 19, 2013 at 3:13 PM, Sandy Walsh wrote:
>
>>
>>
>> On 07/19/2013 05:36 PM, Boris Pavlovic wrote:
>> > Sandy,
>> >
>> > I don't think that we have such problems here.
>> > Because scheduler doesn't pool compute_nodes.
>> > The situation is another compute_nodes notify scheduler about their
>> > state. (instead of updating their state in DB)
>> >
>> > So for example if scheduler send request to compute_node, compute_node
>> > is able to run rpc call to schedulers immediately (not after 60sec).
>> >
>> > So there is almost no races.
>>
>> There are races that occur between the eventlet request threads. This is
>> why the scheduler has been switched to single threaded and we can only
>> run one scheduler.
>>
>> This problem may have been eliminated with the work that Chris Behrens
>> and Brian Elliott were doing, but I'm not sure.
>>
>
>
> Speaking of Chris Beherns  "Relying on anything but the DB for current
> memory free, etc, is just too laggy… so we need to stick with it, IMO."
> http://lists.openstack.org/pipermail/openstack-dev/2013-June/010485.html
>
> Although there is some elegance to the proposal here I have some concerns.
>
> If just using RPC broadcasts from compute to schedulers to keep track of
> things, we get two issues:
>
> * How do you bring a new scheduler up in an existing deployment and make
> it get the full state of the system?
> * Broadcasting RPC updates from compute nodes to the scheduler means every
> scheduler has to process  the same RPC message.  And if a deployment hits
> the point where the number of compute updates is consuming 99 percent of
> the scheduler's time just adding another scheduler won't fix anything as it
> will get bombarded too.
>
> Also OpenStack is already deeply invested in using the central DB model
> for the state of the 'world' and while I am not against changing that, I
> think we should evaluate that switch in a larger context.
>
>
>
>>
>> But certainly, the old approach of having the compute node broadcast
>> status every N seconds is not suitable and was eliminated a long time ago.
>>
>> >
>> >
>> > Best regards,
>> > Boris Pavlovic
>> >
>> > Mirantis Inc.
>> >
>> >
>> >
>> > On Sat, Jul 20, 2013 at 12:23 AM, Sandy Walsh <
>> sandy.wa...@rackspace.com
>> > > wrote:
>> >
>> >
>> >
>> > On 07/19/2013 05:01 PM, Boris Pavlovic wrote:
>> > > Sandy,
>> > >
>> > > Hm I don't know that algorithm. But our approach doesn't have
>> > > exponential exchange.
>> > > I don't think that in 10k nodes cloud we will have a problems
>> with 150
>> > > RPC call/sec. Even in 100k we will have only 1.5k RPC call/sec.
>> > > More then (compute nodes update their state in DB through
>> conductor
>> > > which produce the same count of RPC calls).
>> > >
>> > > So I don't see

[openstack-dev] tripleo/incubator now in gerrit

[Robert Collins]

If you were using it from https://github.com/tripleo/incubator, you
should update your remotes to reference
https://github.com/openstack/tripleo-incubator.

I'll get the .gitreview stuff setup shortly.

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services

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

Re: [openstack-dev] pip requirements externally host (evil evil stab stab stab)

[Yoshihiro Kaneko]

Hi Salvatore,

I intend to replace the netifaces module which Ryu agent uses with the
ip_lib module.

Thanks,
Kaneko


2013/7/21 Salvatore Orlando :
> I reckon the netifaces package is only used in Neutron's Ryu plugin.
> At a first glance, it should be possible to replace its current usage with
> the iplib module which has been developed within neutron itself.
>
> Unless we hear otherwise from contributors to the Ryu plugin it is my
> opinion that we should move towards replacing netifaces.
>
> Salvatore
>
>
> On 19 July 2013 20:04, Monty Taylor  wrote:
>>
>> Hey guys!
>>
>> PyPI is moving towards the world of getting people to stop hosting stuff
>> via external links. It's been bad for us in the past and one of the
>> reasons for the existence of our mirror. pip 1.4 has an option to
>> disallow following external links, and in 1.5 it's going to be the
>> default behavior.
>>
>> Looking forward, we have 5 pip packages that host their stuff
>> externally. If we have any pull with their authors, we should get them
>> to actually upload stuff to pypi. If we don't, we should strongly
>> consider our use of these packages. As soon as pip 1.4 comes out, I
>> would like to moving forward restrict the addition of NEW requirements
>> that do not host on pypi. (all 5 of these host insecurely as well, fwiw)
>>
>> The culprits are:
>>
>> dnspython,lockfile,netifaces,psutil,pysendfile
>>
>> ___
>> 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] [Nova][Oslo-incubator] Automatic retry db.api query if database connection lost

[Victor Sergeyev]

Hi All.

There is a blueprint (
https://blueprints.launchpad.net/nova/+spec/db-reconnect) by Devananda van
der Veen, which goal is to implement reconnection to a database and
retrying of the last operation if a db connection fails. I’m working on the
implementation of this BP in oslo-incubator (
https://review.openstack.org/#/c/33831/).

Function _raise_if_db_connection_lost() was added to _wrap_db_error()
decorator defined in openstack/common/db/sqlalchemy/session.py. This
function catches sqlalchemy.exc.OperationalError and finds database error
code in this exception. If this error code is on `database has gone away`
error codes list, this function raises DBConnectionError exception.

Decorator for db.api methods was added to openstack/common/db/api.py.
We can apply this decorator to methods in db.sqlalchemy.api (not to
individual queries).
It catches DBConnectionError exception and retries the last query in a loop
until it succeeds, or until the timeout is reached. The timeout value is
configurable with min, max, and increment options.
We suppose that all db.api methods are executed inside a single
transaction, so retrying the whole method, when a connection is lost,
should be safe.

I would really like to receive some comments about the following
suggestions:

1. I can’t imagine a situation when we lose connection to an SQLite DB.
Also, as far as I know, SQLite is not used in production at the moment, so
we don't handle this case.

2. Please, leave some comments about  `database has gone away` error codes
list in MySQL and PostgreSQL.

3. Johannes Erdfelt suggested that “retrying the whole method, even if it's
in a transaction, is only safe the entire method is idempotent. A method
could execute successfully in the database, but the connection could be
dropped before the final status is sent to the client.”
I agree, that this situation can cause data corruption in a database (e.
g., if we try to insert something to a database), but I’m not sure, how
RDBMS handle this. Also, I haven't succeeded in creation of a functional
test case, that would allow to reproduce the described situation easily.


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

Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

[Julien Danjou]

On Fri, Jul 19 2013, Sean Dague wrote:

> I assume it would gracefully degrade to the existing static allocators if
> something went wrong. If not, well that would be very bad.
>
> Ceilometer is an integrated project in Havana. Utilization based scheduling
> would be a new feature. I'm not sure why we think that duplicating the
> metrics collectors in new code would be less buggy than working with
> Ceilometer. Nova depends on external projects all the time.
>
> If we have a concern about robustness here, we should be working as an
> overall project to address that.

+1

-- 
Julien Danjou
-- Free Software hacker - freelance consultant
-- http://julien.danjou.info


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

Re: [openstack-dev] Change in openstack/neutron[master]: Add method to get iptables traffic counters

[Sylvain Afchain]

Hi Brian,

Thanks for your reply.

> 1. This isn't something a tenant should be able to do, so should be 
> admin-only,
> correct?

Correct.

> 2. I think it would be useful for an admin to be able to add metering rules 
> for
> all tenants with a single command.  This gets back to wanting to pre-seed an 
> ini
> file with a set of subnets, then add/subtract from it later without restarting
> the daemon.

I agree with you, could be a future enhancement.

> 3. I think it would be better if you didn't mark the packets, for performance
> reasons.  If you were marking them on input to be matched by something on 
> output
> I'd feel different, but for just counting bytes we should be able to do it
> another way.  I can get back to you next week on figuring this out.

Ok, I'll take a look too.

Thanks.

Sylvain.

- Original Message -
From: "Brian Haley" 
To: "Sylvain Afchain" 
Cc: openstack-dev@lists.openstack.org
Sent: Friday, July 19, 2013 11:47:41 PM
Subject: Re: Change in openstack/neutron[master]: Add method to get iptables 
traffic counters

Hi Sylvain,

Sorry for the slow reply, I'll have to look closer next week, but I did have
some comments.

1. This isn't something a tenant should be able to do, so should be admin-only,
correct?

2. I think it would be useful for an admin to be able to add metering rules for
all tenants with a single command.  This gets back to wanting to pre-seed an ini
file with a set of subnets, then add/subtract from it later without restarting
the daemon.

3. I think it would be better if you didn't mark the packets, for performance
reasons.  If you were marking them on input to be matched by something on output
I'd feel different, but for just counting bytes we should be able to do it
another way.  I can get back to you next week on figuring this out.

Thanks,

-Brian

On 07/18/2013 04:29 AM, Sylvain Afchain wrote:
> Hi Brian,
> 
> For iptables rules, see below
> 
> Yes the only way to setup metering labels/rules is the neutronclient. I agree 
> with you about the future
> enhancement.
> 
> Regards,
> 
> Sylvain
> 
> - Original Message -
> From: "Brian Haley" 
> To: "Sylvain Afchain" 
> Cc: openstack-dev@lists.openstack.org
> Sent: Thursday, July 18, 2013 4:58:26 AM
> Subject: Re: Change in openstack/neutron[master]: Add method to get iptables 
> traffic counters
> 
>> Hi Sylvain,
>>
>> I think I've caught-up with all your reviews, but I still did have some
>> questions on the iptables rules, below.
>>
>> One other question, and maybe it's simply a future enhancement, but is the 
>> only
>> way to setup these meters using neutronclient?  I think being able to specify
>> these in an .ini file would be good as well, which is something I'd want to 
>> do
>> as a provider, such that they're always there, and actually not visible to 
>> the
>> tenant.
>>
>> On 07/11/2013 10:04 AM, Sylvain Afchain wrote:
>>> Hi Brian,
>>>
>>> You're right It could be easier with your approach to get and keep the 
>>> traffic counters.
>>>
>>> I will add a new method to get the details of traffic counters of a chain.
>>> https://review.openstack.org/35624
>>>
>>> Thoughts?
>>>
>>> Regards,
>>>
>>> Sylvain.
>>>
>>> - Original Message -
>>> From: "Sylvain Afchain" 
>>> To: "Brian Haley" 
>>> Cc: openstack-dev@lists.openstack.org
>>> Sent: Thursday, July 11, 2013 11:19:39 AM
>>> Subject: Re: Change in openstack/neutron[master]: Add method to get 
>>> iptables traffic counters
>>>
>>> Hi Brian,
>>>
>>> First thanks for the reviews and your detailed email.
>>>
>>> Second I will update the blueprint specs. as soon as possible, but for 
>>> example it will look like that:
>>>
>>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>> pkts  bytes target prot opt in out source   
>>> destination 
>>>55   245 metering-r-aef1456343  all  --  *  *   
>>> 0.0.0.0/00.0.0.0/0   /* jump to rules the label aef1456343 */   
>>>  
>>>55   245 metering-r-badf566782  all  --  *  *   
>>> 0.0.0.0/00.0.0.0/0   
> 
>> So are these two used to separate out what you don't want to count from what 
>> you
>> want to count?  Seems the jump to the r-aef1456343 will filter, then the
>> r-badf566782 will count per-subnet?  I'm just trying to understand why you're
>> splitting the two up.
> 
> No here, there are two rules only because there are two labels. In the chain 
> of each 
> label you will find the label's rules. 
> 
>>> Chain metering-l-aef1456343 (1 references)  /* the chain for the label 
>>> aef1456343 */
>>> pkts  bytes target prot opt in out source   
>>> destination 
>>>
>>> Chain metering-l-badf566782 (1 references)  /* the chain for the label 
>>> badf566782 */
>>> pkts  bytes target prot opt in out source   
>>> destination  
> 
>> These two chains aren't really doing anything, and I believe their 
>> packet

[openstack-dev] No Project & release status meeting tomorrow

[Thierry Carrez]

While we all recover from havana-2 and some of us party for the 3rd
OpenStack birthday at OSCON, we'll be skipping the release status
meeting tomorrow at 21:00 UTC.

PTLs should take the extra time to review their havana-3 plans and trim
them to come up with reasonable objectives where appropriate !

Back to our regular schedule next week.

-- 
Thierry Carrez (ttx)

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