date:20151013

On 10/12/2015 03:58 PM, Jeremy Stanley wrote:
> On 2015-10-12 15:40:48 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> Has the infra team ever thought about doing that for (at least) all of
>> the 3rd party libs we use? I'd love to work closer with the infra team
>> to provide them with missing packages they would need, and I'm sure my
>> RPM buddy Haikel would too. This also would help getting our
>> openstack/{deb,rpm}- projects up to speed as well.
> [...]
> 
> Long ago there was an idea that we might somehow be able to
> near-instantly package anything on PyPI and serve RPMs and DEBs of
> it up to CI jobs, but doing that would be a pretty massive (and in
> my opinion very error-prone) undertaking.
> 
> Right now we can take advantage of the fact that the Python
> ecosystem uploads new releases to PyPI as their primary distribution
> channel. By using pip to install dependencies from PyPI in our CI
> system, we can pretty instantly test compatibility of our software
> with new releases of dependencies (much faster that they can get
> properly packaged in distros), and easily test different versions by
> proposing changes to the openstack/requirements repository.

In this particular case (ie: a difficult upstream which makes it
impossible to have the same result with pip and system packages), and
for a package which has a rather stable API, we could make an exception.

For the more general case, I'm not sure we are in such a hurry that we
would need to have updates by the minute. I would accept to commit
myself for a reasonable delay such as 48 hours max until a new
dependency is packaged and available for the infra team to use NEW
packages. For just updates, I'm convince it could be semi-automated
(like for example a proposal bot).

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

2015-10-13 Thread Mike Spreitzer

> From: "Sean M. Collins" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/12/2015 11:34 AM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:
> > ..
> > > > In the section 
> > > > http://docs.openstack.org/developer/devstack/guides/
> > > neutron.html#using-neutron-with-a-single-interface
> > > > there is a helpful display of localrc contents.  It says, among 
other 
> > > > things,
> > > > 
> > > >OVS_PHYSICAL_BRIDGE=br-ex
> > > >PUBLIC_BRIDGE=br-ex
> > > > 
> > > > In the next top-level section, 
> > > > http://docs.openstack.org/developer/devstack/guides/
> > > neutron.html#using-neutron-with-multiple-interfaces
> > > > , there is no display of revised localrc contents and no mention 
of 
> > > > changing either bridge setting.  That is an oversight, right?
> > > 
> > > No, this is deliberate. Each section is meant to be independent, 
since
> > > each networking configuration and corresponding DevStack 
configuration
> > > is different. Of course, this may need to be explicitly stated in 
the
> > > guide, so there is always room for improvement.
> > 
> > I am not quite sure I understand your answer.  Is the intent that I 
can 
> > read only one section, ignore all the others, and that will tell me 
how to 
> > use DevStack to produce that section's configuration?  If so then it 
would 
> > be good if each section had a display of all the necessary localrc 
> > contents.
> 
> Agreed. This is a failure on my part, because I was pasting in only
> parts of my localrc (since it came out of a live lab environment). I've
> started pushing patches to correct this.
> 
> 
> > I have started over, from exactly the picture drawn at the start of 
the 
> > doc.  That has produced a configuration that mostly works.  However, I 

> > tried creating a VM connected to the public network, and that failed 
for 
> > lack of a Neutron DHCP server there.
> 
> The public network is used for floating IPs. The L3 agent creates NAT
> rules to intercept traffic on the public network and NAT it back to a
> guest instance that has the floating IP allocated to it.
> 
> The behavior for when a guest is directly attached to the public
> network, I sort of forget what happens exactly but I do know that it
> doesn't work from experience - most likely because the network is not
> configured as a flat network. It will not receive a DHCP lease from the
> external router.
> 
> > I am going to work out how to change 
> > that, and am willing to contribute an update to this doc.  Would you 
want 
> > that in this section --- in which case this section needs to specify 
that 
> > the provider DOES NOT already have DHCP service on the hardware 
network 
> > --- or as a new section?
> 
> No, I think we should maybe have a warning or something that the
> external network will be used for Floating IPs, and that guest instances
> should not be directly attached to that network.
> 
> > > > 
> > > > Looking at 
> > > > 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or
> > , in 
> > > > former days, the doc now preserved at 
> > > > http://docs.ocselected.org/openstack-manuals/kilo/networking-
> > > guide/content/under_the_hood_openvswitch.html
> > > > ) I see the name br-ex used for $PUBLIC_BRIDGE--- not 
> > $OVS_PHYSICAL_BRIDGE
> > > > , right?  Wouldn't it be less confusing if 
> > > > 
http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a 
> > 
> > > > name other than "br-ex" for the exhibited commands that apply to 
> > > > $OVS_PHYSICAL_BRIDGE?
> > > 
> > > No, this is deliberate - br-ex is the bridge that is used for 
external
> > > network traffic - such as floating IPs and public IP address ranges. 
On
> > > the network node, a physical interface is attached to br-ex so that
> > > traffic will flow.
> > > 
> > > PUBLIC_BRIDGE is a carryover from DevStack's Nova-Network support 
and is
> > > used in some places, with OVS_PHYSICAL_BRIDGE being used by 
DevStack's
> > > Neutron support, for the Open vSwitch driver specifically. They are 
two
> > > variables that for the most part serve the same purpose. Frankly,
> > > DevStack has a lot of problems with configuration knobs, and
> > > PUBLIC_BRIDGE and OVS_PHYSICAL_BRIDGE is just a symptom.
> > 
> > Ah, thanks, that helps.  But I am still confused.  When using Neutron 
with 
> > two interfaces, there will be a bridge for each.
> 
> There shouldn't be. I'm pushing patches in the multiple interface
> section that includes output from the ovs-vsctl commands, hopefully
> it'll clarify things.
> 
> 
> > I have learned that 
> > DevStack will automatically create one bridge, and seen that it is 
named 
> > "br-ex" when following the instructions in the single-interface 
section. 
> > Now in the multiple-interface

[openstack-dev] [Monasca] Good guide to install Monasca on Centos7?

2015-10-13 Thread BYEONG-GI KIM

Hello.

I'm interested in Monasca, which is the one of a new OpenStack project for
monitoring, and I'd wanted to get an installation guide of the Monasca on
CentOS7 environment.

I've found a guide which is for Debian (Ubuntu) environment, but I couldn't
for the previous one. Could anybody know where the guide is?

Thanks in advance.

Best regards

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

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-13 Thread Cory Benfield

> On 13 Oct 2015, at 07:42, Thomas Goirand  wrote:
> In this particular case (ie: a difficult upstream which makes it
> impossible to have the same result with pip and system packages)

I don’t know how carefully you’ve followed this email trail, but the “difficult 
upstream” has had a policy in place for six months that ensures that you can 
have the same result with pip and system packages. For six months we have only 
updated to versions of urllib3 that are actually released, and therefore that 
are definitely available from pip (and potentially available from the 
distribution).

The reason this has not been working is because the distributions, when they 
unbundle us, have not been populating their setup.py to reflect the dependency: 
only their own metadata. We’ve been in contact with them, and this change is 
being made in the distributions we have relationships with.

Cory

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

Re: [openstack-dev] [Openstack] [openstack] [murano] Deployment of Environment gives [yaql.exceptions.YaqlExecutionException]: Unable to run values error

2015-10-13 Thread Nikolay Starodubtsev

Hi Sumanth,
Do you have this issue with other apps?



Nikolay Starodubtsev

Software Engineer

Mirantis Inc.


Skype: dark_harlequine1

2015-10-12 9:08 GMT+03:00 Sumanth Sathyanarayana <
sumanth.sathyanaray...@gmail.com>:

> Hi,
>
> I am trying to add a simple app like MySql into a new enviroment from the
> murano dashboard and trying to deploy the environment and I get the error -
> "[yaql.exceptions.YaqlExecutionException]: Unable to run values"
>
> I saw that this error/bug was already reported some time back and made
> sure that my code has the changes mentioned in:
> *https://review.openstack.org/#/c/119072/1/meta/io.murano/Classes/resources/Instance.yaml
> 
> - Bug#1364446*
> *&*
>
> *https://bugs.launchpad.net/murano/+bug/1359225
> *
>
> *But I still am getting the error even after restarting the murano-engine
> and murano-api services. If anyone has any suggestion on how to deploy a
> new environment, it would be very helpful.*
>
> *Thanks & Best Regards*
> *Sumanth*
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Requests + urllib3 + distro packages

On 10/13/2015 12:44 AM, Joshua Harlow wrote:
> Anvil gets somewhat far on this, although its not supporting DEBs it
> does build its best attempt at RPMs building them automatically and
> turning git repos of projects into RPMs.
> 
> http://anvil.readthedocs.org/en/latest/topics/summary.html (hopefully
> the existence of this is not news to folks).
> 
> A log of this in action (very verbose) is at:
> 
> http://logs.openstack.org/40/225240/4/check/gate-anvil-rpms-dsvm-devstack-centos7/0eea2a9/console.html

Automation can only bring you so far. I also have automation which we
could use for debs (see the pkgos-debpypi script from the
openstack-pkg-tools package), however, there's always the need for
manual reviews. I don't believe it ever will be possible to do full
automation, as each Python package has specificities. Note that this is
mainly an issue with Python modules, if it was PHP pear packages, it
could be fully automated. So probably there's some PEP that we could
start to ease this. If only everyone was using testr, pbr, defining
copyright correctly and providing a parseable long and short
description, it wouldn't be such an issue.

Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] The state of systemd _sd_notify & oslo.service in OpenStack

Hi,

As oslo.service implements _sd_notify, I am deeply thinking about
switching Debian .service files to use Type=notify instead of
Type=simple (which is the default, and what OpenStack packages are using
in Debian).

Though I'm not sure about the state of things. Which package has
switched to using oslo.service, and is _sd_notify always called when a
package declares a dependency on oslo.service? Could someone confirm a
list of projects for which I could enable Type=notify in all daemons?

Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] From where will start particiption in Neutron Component?

2015-10-13 Thread chandraprakash mishra

Hi Folks,

I have just started looking OpenStack ,As of now i would like to start
participation for neutron component . So where can i start participate for
neutron component .Is there any documentation for this components so that I
can start work on from bug-fix .Please any one help me(or share any
document)




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

Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

2015-10-13 Thread Flavio Percoco

On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote:

HI all,

Thanks for your feedback. We discussed this topic in this week weekly meeting
and we came to the conclusion that it would be better to use "pool-flavor"
instead of creating a namespace for Zaqar only (by prefixing everything with
the "message" key).

So, this commands would look like

openstack pool-flavor create
openstack pool-flavor get
openstack pool-flavor delete
openstack pool-flavor update
openstack pool-flavor list

First and foremost, I'm sorry for not attending the last meeting.

I just read the logs from the meeting and I'd like to raise my
concerns with the above. I think it's very confusing for users to have
a non-namespaced command.

For example, what's a pool-flavor? Is it related to Nova's flavors? Is
it something related to some network pools? etc.

I understand that one of the concerns is that things like `openstack
message message post` wouldn't look good but I think that the project
namespace could match the service catalog (will let folks for OSC
confirm/deny this).

Some examples:

$ openstack messaging post
$ openstack messaging flavor create
$ openstack messaging pool add

etc

Does the above make sense?
Flavio

Best,

Victoria

2015-10-10 10:10 GMT-03:00 Shifali Agrawal :

   All right, thanks for responses, will code accordingly :)

   On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann 
   wrote:

   Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400:
   >
   > Using `message flavor` works for me, and having two words is just
   fine.

   It might even be good to change "flavor" to "server flavor" (keeping
   flavor as a backwards-compatible alias, of course).

   Doug

   >

   > I'm in the process of collecting all of the existing "object" works
   are
   > putting them online, there's a lot of them. Hopefully this will
   reduce the
   > collisions in the future.
   >
   > Thanks,
   >
   > Steve Martinelli
   > OpenStack Keystone Core
   >
   >
   >
   > From:    Shifali Agrawal 
   > To:    openstack-dev@lists.openstack.org
   > Date:    2015/10/06 03:40 PM
   > Subject:    [openstack-dev] [Zaqar][cli][openstack-client] conflict
   in nova
   >             flavor and zaqar flavor
   >
   >
   >
   > Greetings,
   >
   > I am implementing cli commands for Zaqar flavors, the command should
   be
   > like:
   >
   > "openstack flavor "
   >
   > But there is already same command present for Nova flavors. After
   > discussing with Zaqar devs we thought to change all zaqar commands
   such
   > that they include `message` word after openstack, thus above Zaqar
   flavor
   > command will become:
   >
   > "openstack message flavor "
   >
   > Does openstack-client devs have something to say for this? Or they
   also
   > feel its good to move with adding `message` word to all Zaqar cli
   > commands?
   >
   > Already existing Zaqar commands will work with get a deprecation
   > message/warning and also I will implement them all to work with
   `message`
   > word, and all new commands will be implement so that they work only
   with
   > `message` word.

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

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

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

--
@flaper87
Flavio Percoco

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

Re: [openstack-dev] [TripleO] review priorities etherpad

2015-10-13 Thread marios

On 10/10/15 00:16, Dan Prince wrote:
> On Thu, 2015-10-08 at 09:17 -0400, James Slagle wrote:
>> At the TripleO meething this week, we talked about using an etherpad

speaking of which - and given attendance since the time change, should
we move this back to a weekly thing? Looking at
http://eavesdrop.openstack.org/ I only get one hit (us) for "Tuesday at
1400 UTC in #openstack-meeting-alt" so we could in theory just use the
same time+place,

marios

>> to help get some organization around reviews for the high priority
>> themes in progress.
>>
>> I started on one: 
>> https://etherpad.openstack.org/p/tripleo-review-priorities
> 
> Nice. Thanks.
> 
>>
>> And I subjectively added a few things :). Feel free to add more
>> stuff.
>> Personally, I like seeing it organized by "feature" or theme instead
>> of git repo, but we can work out whatever seems best.
> 
> Agree. For some things it really helps to see things grouped by feature
> in an etherpad.
> 
> Dan
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [all] Cross-project track schedule draft: Feedback needed

2015-10-13 Thread Thierry Carrez

Flavio Percoco wrote:
> We have a draft schedule for the cross-project track for the Mitaka
> summit[0] (find it at the bottom of the etherpad). Yay!
> 
> We would like to get feedback from folks that have proposed these
> sessions - hopefully you're all cc'd - or other folks that may be
> co-moderating them. If there are any conflicts for you in the current
> schedule, please, do let us know and we'll re-arange as possible.
> 
> Feedback from anyone is obviously welcomed but keep in mind that this
> is a process that will hardly make everyone happy.

Based on currently-expressed constraints, we could swap sessions 3 and
26 so that mtreinish can attend 26 (and dhellmann can attend both 3 and 11).

-- 
Thierry Carrez (ttx)



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

Re: [openstack-dev] From where will start particiption in Neutron Component?

2015-10-13 Thread Neil Jerram

On 13/10/15 08:45, chandraprakash mishra wrote:
> Hi Folks,
>
> I have just started looking OpenStack ,As of now i would like to start
> participation for neutron component . So where can i start participate
> for neutron component .Is there any documentation for this components
> so that I can start work on from bug-fix .Please any one help me(or
> share any document)

Yes, please take a look at
http://docs.openstack.org/developer/neutron/devref/.  There is lots of
information there about Neutron components.

Neil


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

[openstack-dev] [gertty] Replying to inline comments

2015-10-13 Thread Paul Bourke


Hi,

Does anyone know if this is possible in the current version of gertty?

Thanks,
-Paul

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

[openstack-dev] [horizon] - Overview page based in configurable widgets

2015-10-13 Thread Marcos Fermin Lobo

Hello,

I have a proposal in order to improve the Overview page in Horizon. The main 
idea is create a new Overview page based in configurable widgets.

You can check it in 
https://blueprints.launchpad.net/horizon/+spec/overview-page-widget-based

If any of you know other ideas like this, please write it in the topic.

All feedback is very welcome.

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

Re: [openstack-dev] Scheduler proposal

2015-10-13 Thread Dulko, Michal

On Mon, 2015-10-12 at 10:58 -0700, Joshua Harlow wrote:
> Just a related thought/question. It really seems we (as a community) 
> need some kind of scale testing ground. Internally at yahoo we were/are 
> going to use a 200 hypervisor cluster for some of this and then expand 
> that into 200 * X by using nested virtualization and/or fake drivers and 
> such. But this is a 'lab' that not everyone can have, and therefore 
> isn't suited toward community work IMHO. Has there been any thought on 
> such a 'lab' that is directly in the community, perhaps trystack.org can 
> be this? (users get free VMs, but then we can tell them this area is a 
> lab, so don't expect things to always work, free isn't free after all...)
> 
> With such a lab, there could be these kinds of experiments, graphs, 
> tweaks and such...

https://www.mirantis.com/blog/intel-rackspace-want-cloud/

"The plan is to build out an OpenStack developer cloud that consists of
two 1,000 node clusters available for use by anyone in the OpenStack
community for scaling, performance, and code testing. Rackspace plans to
have the cloud available within the next six months."

Stuff you've described is actually being worked on for a few months. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Scheduler proposal

2015-10-13 Thread Dulko, Michal

On Mon, 2015-10-12 at 10:13 -0700, Clint Byrum wrote:
> Zookeeper sits in a very different space from Cassandra. I have had good
> success with it on OpenJDK as well.
> 
> That said, we need to maybe go through some feature/risk matrices and
> compare to etcd and Consul (this might be good to do as part of filling
> out the DLM spec). The jvm issues goes away with both of those, but then
> we get to deal Go issues.
> 
> Also, ZK has one other advantage over those: It is already in Debian and
> Ubuntu, making access for developers much easier.

What about RHEL/CentOS? Maybe I'm mistaken, but I think these two
doesn't have it packaged.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] FYI - Depends-On vs. backports

2015-10-13 Thread Sean Dague

I was checking out where things were at this morning with fixing unit
tests, and found that a bunch of things were all gummed up in "merge
conflicts".

When you specify

Depends-On: ID

It requires everything with ID to be in a "merged" state to go forward.
A change being abandoned doesn't count.

This runs smack into our tendancy to make the UUID for backported
changes the same as the id in master (there is no reason we really have
to do that).

So the following sequence:

Fix A in requirements master
Fix B in nova master (depends on A)
Backport A to requirements stable/liberty
Abandon A in stable/liberty

Just means that B is stuck and can never land.


It's come up to let things through with Abandon, however Depends-On is
used to stack up changes across a bunch of different repos with
different review teams, and who can Abandon and then let changes through
that shouldn't land, gets kind of confusing. Also, if we don't support
depends on across branches, we can't use it for testing upgrade
scenarios. So the current edge case is probably the least weird edge
case that we can have.


So, in future if you want to use Depends-On in a backport situation, you
need to carefully do your backports so they don't share a UUID with master.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [heat][oslo] Exchanges in RabbitMQ

2015-10-13 Thread Anant Patil

Hi,

I am quite not sure on how RabbitMQ is working with Heat. We have 3
exchange topics: "engine", "heat-engine-listener" and "engine_worker"
defined in heat RPC.

But, When I do list_exchanges I see:

heattopic
heat-engine-listener_fanout fanout
engine_fanout   fanout
engine_worker_fanoutfanout

I am not sure how 'heat' topic is getting created? And, also, why the
exchange types are created as fanout when topic is given and fanout is
not given when creating a RPC server.

I also see that there are three queues created for each topic. For
engine topic, following three queues are created:

engine
engine.devserver
engine_fanout_dc656a70994141229af8879dfbaf3362

I was expecting two queues, one each for publishing and subscribing (I
have just one worker configured). I was not expecting engine.devserver
(devserver is hostname). I see the same for compute, conductor etc.

Can someone share me a document which explains how this works or help me
understand this?

Also, given that RabbitMQ will send the messages to a queue consumer in
a round robin fashion, is it okay to rely on AMQP for load-leveling
(even distribution of load)? The consumers are heat workers and they
subscribe to the "engine_worker" topic.

- Anant

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

Re: [openstack-dev] getting rid of tablib completely (Requests + urllib3 + distro packages)

On 10/12/2015 11:09 PM, Steve Baker wrote:
> On 13/10/15 02:05, Thomas Goirand wrote:
>>
>> BTW, the same applies for tablib which is in a even more horrible state
>> that makes it impossible to package with Py3 support. But tablib could
>> be removed from our (build-)dependency list, if someone cares about
>> re-writing cliff-tablib, which IMO wouldn't be that much work. Doug, how
>> many beers shall I offer you for that work? :)
>>
> Regarding tablib, cliff has had its own table formatter for some time,
> and now has its own json and yaml formatters. I believe the only tablib
> formatter left is the HTML one, which likely wouldn't be missed if it
> was just dropped (or it could be simply reimplemented inside cliff).
> 
> If the cliff deb depends on cliff-tablib

It does. And also the below packages have a build-dependency on
cliff-tablib:

- python-neutronclient
- python-openstackclient

python-openstackclient also has a runtime depends on cliff-tablib.

The problem is that *many* packages have (build-)depends on
neutronclient and openstackclient, so it blocks Py3 support for them as
well.

So we need to address this.

> I would recommend removing that
> dependency and just stop packaging cliff-tablib.

Can I just drop cliff-tablib from cliff, and be done with it? Really?

I am hereby announcing that I'm paying a beer in Tokyo to anyone who
helps fixing this mess, so we get rid of tablib. :)

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] Scheduler proposal

On 2015-10-12 20:49:44 -0700 (-0700), Joshua Harlow wrote:
> Does the openstack foundation have access to a scaling area that
> can be used by the community for this kind of experimental work?

The OpenStack Foundation has a staff of fewer than 20 full-time
employees, with a primary focus on event planning and preserving the
community's trademarks. If instead you mean the member companies who
make up the OpenStack Foundation, then I agree with the other reply
on the thread that it sounds like the effort already underway at
Intel and Rackspace.

> It seems like infra or others should be able make that possible?
[...]

The Infrastructure team is in the process of standing up a
community-managed deployment of OpenStack, but it's not even within
an order of magnitude of being 1k host scale (and at that, it's
still a multi-cycle plan just to reach viability).
-- 
Jeremy Stanley

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

[openstack-dev] [kuryr] Proposing Taku Fukushima as Kuryr core

2015-10-13 Thread Antoni Segura Puimedon

Hi fellow Kurýrs,

I would like to propose Taku Fukushima for the core Kuryr team due to his
unparalleled dedication to the project. He has written most of the code and
battled through the continuous libnetwork API changes. He will be a great
addition to the reviewing tasks.

Current core members, please, cast your vote by tomorrow night.

Regards,

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

[openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

2015-10-13 Thread Vladimir Kuklin

Puppetmaster and Fuelers,

Last week I mentioned that I would like to bring the theme of using native
ruby OpenStack client and use it within the providers.

Emilien told me that I had already been late and the decision was made that
puppet-openstack decided to not work with Aviator based on [0]. I went
through this thread and did not find any unresolvable issues with using
Aviator in comparison with potential benefits it could have brought up.

What I saw actually was like that:

* Pros

1) It is a native ruby client
2) We can import it in puppet and use all the power of Ruby
3) We will not need to have a lot of forks/execs for puppet
4) You are relying on negotiated and structured output provided by API
(JSON) instead of introducing workarounds for client output like [1]

* Cons

1) Aviator is not actively supported
2) Aviator does not track all the upstream OpenStack features while native
OpenStack client does support them
3) Ruby community is not really interested in OpenStack (this one is
arguable, I think)

* Proposed solution

While I completely understand all the cons against using Aviator right now,
I see that Pros above are essential enough to change our mind and invest
our own resources into creating really good OpenStack binding in Ruby.
Some are saying that there is not so big involvement of Ruby into
OpenStack. But we are actually working with Puppet/Ruby and are invloved
into community. So why should not we own this by ourselves and lead by
example here?

I understand that many of you do already have a lot of things on their
plate and cannot or would not want to support things like additional
library when native OpenStack client is working reasonably well for you.
But if I propose the following scheme to get support of native Ruby client
for OpenStack:

1) we (community) have these resources (speaking of the company I am
working for, we at Mirantis have a set of guys who could be very interested
in working on Ruby client for OpenStack)
2) we gradually improve Aviator code base up to the level that it
eliminates issues that are mentioned in  'Cons' section
3) we introduce additional set of providers and allow users and operators
to pick whichever they want
4) we leave OpenStackClient default one

Would you support it and allow such code to be merged into upstream
puppet-openstack modules?


[0]
https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
[1]
https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The state of systemd _sd_notify & oslo.service in OpenStack

2015-10-13 Thread Ihar Hrachyshka

For neutron-server, we use notify type since very long time, ~ RDO Icehouse.

https://github.com/openstack-packages/neutron/blob/rpm-master/neutron-server.service#L6

> On 13 Oct 2015, at 09:01, Thomas Goirand  wrote:
> 
> Hi,
> 
> As oslo.service implements _sd_notify, I am deeply thinking about
> switching Debian .service files to use Type=notify instead of
> Type=simple (which is the default, and what OpenStack packages are using
> in Debian).
> 
> Though I'm not sure about the state of things. Which package has
> switched to using oslo.service, and is _sd_notify always called when a
> package declares a dependency on oslo.service? Could someone confirm a
> list of projects for which I could enable Type=notify in all daemons?
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] From where will start particiption in Neutron Component?

2015-10-13 Thread Kyle Mestery

On Tue, Oct 13, 2015 at 1:41 AM, Neil Jerram 
wrote:

> On 13/10/15 08:45, chandraprakash mishra wrote:
> > Hi Folks,
> >
> > I have just started looking OpenStack ,As of now i would like to start
> > participation for neutron component . So where can i start participate
> > for neutron component .Is there any documentation for this components
> > so that I can start work on from bug-fix .Please any one help me(or
> > share any document)
>
> Yes, please take a look at
> http://docs.openstack.org/developer/neutron/devref/.  There is lots of
> information there about Neutron components.
>
>
And once you've done that, you can look at some low-hanging-fruit bugs [1]
as a good starting point for bugs to get you started with the codebase.

[1] https://bugs.launchpad.net/neutron/+bugs?field.tag=low-hanging-fruit

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

Re: [openstack-dev] [kuryr] Proposing Taku Fukushima as Kuryr core

2015-10-13 Thread Gal Sagie

+1

Taku is a great addition to the team and hoping to see him continue deliver
high quality
contribution in all aspects of the project.

On Tue, Oct 13, 2015 at 4:52 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

> Hi fellow Kurýrs,
>
> I would like to propose Taku Fukushima for the core Kuryr team due to his
> unparalleled dedication to the project. He has written most of the code and
> battled through the continuous libnetwork API changes. He will be a great
> addition to the reviewing tasks.
>
> Current core members, please, cast your vote by tomorrow night.
>
> Regards,
>
> Toni
>
>

-- 
Best Regards ,

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

Re: [openstack-dev] [Zaqar][Horizon] UI for pools and flavors

2015-10-13 Thread Shifali Agrawal

Thanks for the responses.

While discussion on IRC with Zaqar developers flwag(Fei Long Wang )
mentioned that we need to focus on queues and subscriptions as well along
with pools and flavor, for the first iteration lets have queues and pools
on dashboard.

Adding links here[1], [2], [3] of updated mock-ups, please let me know your
views for them, what more information we should add in queues grid? Should
we provide users a UI to decide maximum number of messages a queue can hold?


[Pools]: http://tinyurl.com/o2b9q6r
[Create Pool]: http://tinyurl.com/nh9df6m
[Queues]: http://tinyurl.com/ovzwut5

On Mon, Oct 12, 2015 at 7:40 PM, Fei Long Wang 
wrote:

>
>
> On 12/10/15 20:36, Matthias Runge wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 12/10/15 09:25, Flavio Percoco wrote:
>>
>>> On 10/10/15 21:07 +0530, Shifali Agrawal wrote:
>>>
 Greetings!

 I have prepared mock-ups[1],[2] to build Zaqar UI, at present
 focusing only to bring pools and flavors on dashboard. Sharing
 two mock-ups for same purpose - allowing all operations related
 to them(CRUD).

 It will be great to know the views of zaqar developers/users if
 the design is satisfactory to them or they want some amendments.
 Also let me know if any information of pools/flavors is missing
 and need to be added.

 In first mockup[1] showing pools information by default and will
 show flavors if user click on flavors button present on top
 second menu bar.

 [1]: http://tinyurl.com/o2b9q6r [2]: http://tinyurl.com/pqwgwhl

>>> I'm adding `[horizon]` to the subject to get more folks'
>>> attention.
>>>
>>> Thank you for bringing this up!
>>
>> maybe it's necessary to give a brief context for those mockups?
>>
> +1 For now, it would be nice if we can figure out where to hold the source
> code, a new dashboard project or in Horizon.
>
>> What does a pool here?
>>
> A pool is like a container to organize queues/messages. Admin can create
> many different pools based on their capabilities.
>
>>   why is a pool weighted (or how)
>>
> When there are many pools, the pool with higher weight will be selected to
> be posted messages.
>
>> and isn't a
>> pools and a pool group somehow the same?
>>
> Pool group is most like a group/container for group to organize groups.
>
>> If you have pools, what is the intention of flavors then?
>>
> Admin can create flavor based on pool group's capabilities. Then user can
> create queue based on pool group to leverage the advantage of the pool
> group. For example, there are two pool groups. One named 'fast storage'
> which contains pools: pool_A and pool_B, one named 'reliable storage' which
> contains pool_C and pool_D, then admin can create a flavor named
> 'fast_storage'. When user created a new queue and set the flavor with
> 'fast_storage', then the messages posted to the queue will be stored in
> pool_A and pool_B.
>
>> Just to ask the obvious questions here
>>
>> Matthias
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQIcBAEBCAAGBQJWG2LZAAoJEBdpskgc9eOLSnYQAIFJb2/u5FWUkuk+mAVcRHXJ
>> nHD0oAN5fxmAR0fqZH57n0T7et8Ocp+Xgp9aUD9roLPGlj9uFnLntMSHo9WIAzU9
>> gq2fl0pgnmpMzwJ0yooAiMq4HXyJcG5UaY9xImTReTH4382x8j1OTVFvS+9ws+VU
>> enK4S/2JW4Rvf6jpYGUcoNqtdmkFRLQohvu/K3V1Cg1Y+zMeYIQZxb4oZzcEOEyo
>> 6E+DicR/4VVGi8gl0UGPkXSmm/jFaG8H3m5KTvTQr0PDd6l5ypwDXvZcRKQvPYmc
>> c155EvjeXPByhm1jXpE6Cgv6NNROQFr+uRM1jKLF0Ss030XI7TSyMNYv9br6OVxi
>> /SMlF+BG+FK26uwTc9Mf5D5mqTF6qgbPTLLu4vlqKa3JX0/y7Z8a7NoujzTKUBEl
>> WAftY2ADAJE6Vb/1TEubujDIlKGBtoT/lGQUIJtj1t5VftfaNrZ1N2vMQ4P7c9hA
>> W2EoRCTe6m8YbPPT3b3QFuuH2oecPECTiWcjEgRxp23ksnoFDkgjEGeM1+xNeQVV
>> kfwfG4mcGP4lEUwPk2sdL/3xu16iUTMJURZdvkqI1FX3YfMwITjiY/jdqIwVwlNF
>> 03XhFn1uloXyHSNRNNFXf85r3v4FDw9FWQCeCU5mqOzkdZZafhvdi2tUjkHniGsG
>> mDyxERTHHiDOAqHUhLNn
>> =nLNP
>> -END PGP SIGNATURE-
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> --
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [neutron-LBaaS] Can anyone help to share a procedure to install lbaas on Kilo?

2015-10-13 Thread WANG, Ming Hao (Tony T)

Kobi,

Thanks for your info very much!
Is there any document to install lbaas manually?
My environment is installed manually instead by devstack or packstack.

Thanks,
Tony

From: Kobi Samoray [mailto:ksamo...@vmware.com]
Sent: Tuesday, October 13, 2015 7:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron-LBaaS] Can anyone help to share a 
procedure to install lbaas on Kilo?

Hi Tony,
Try the following:
https://chapter60.wordpress.com/2015/02/20/installing-openstack-lbaas-version-2-on-kilo-using-devstack/


On Oct 13, 2015, at 14:11, WANG, Ming Hao (Tony T) 
> wrote:

I installed an OpenStack environment manually, and I can’t use devstack or 
packstack to install neutron lbaas.
Can anyone help to share a procedure to install lbaas on Kilo? I can’t find one 
from Google. ☹

Thanks in advance,
Tony

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

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

Re: [openstack-dev] The state of systemd _sd_notify & oslo.service in OpenStack

2015-10-13 Thread Elena Ezhova

Hi,

We used a Launchpad bug [1] to track the process of moving to graduated
oslo.service so you can refer to the list of affected projects.

_sd_notify is called when a service is launched just before a wait loop
[2], [3] so you can check projects from [1] and look for those that start
services using ServiceLauncher or ProcessLauncher.

[1] https://bugs.launchpad.net/neutron/+bug/1466851
[2]
https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L277
[3]
https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L503

Thanks,
Elena

On Tue, Oct 13, 2015 at 10:01 AM, Thomas Goirand  wrote:

> Hi,
>
> As oslo.service implements _sd_notify, I am deeply thinking about
> switching Debian .service files to use Type=notify instead of
> Type=simple (which is the default, and what OpenStack packages are using
> in Debian).
>
> Though I'm not sure about the state of things. Which package has
> switched to using oslo.service, and is _sd_notify always called when a
> package declares a dependency on oslo.service? Could someone confirm a
> list of projects for which I could enable Type=notify in all daemons?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

2015-10-13 Thread Victoria Martínez de la Cruz

Fair enough, +1 to Flavio's suggestion

Thanks all,

Victoria

2015-10-13 3:35 GMT-03:00 Flavio Percoco :

> On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote:
>
>> HI all,
>>
>> Thanks for your feedback. We discussed this topic in this week weekly
>> meeting
>> and we came to the conclusion that it would be better to use "pool-flavor"
>> instead of creating a namespace for Zaqar only (by prefixing everything
>> with
>> the "message" key).
>>
>> So, this commands would look like
>>
>> openstack pool-flavor create
>> openstack pool-flavor get
>> openstack pool-flavor delete
>> openstack pool-flavor update
>> openstack pool-flavor list
>>
>
> First and foremost, I'm sorry for not attending the last meeting.
>
> I just read the logs from the meeting and I'd like to raise my
> concerns with the above. I think it's very confusing for users to have
> a non-namespaced command.
>
> For example, what's a pool-flavor? Is it related to Nova's flavors? Is
> it something related to some network pools? etc.
>
> I understand that one of the concerns is that things like `openstack
> message message post` wouldn't look good but I think that the project
> namespace could match the service catalog (will let folks for OSC
> confirm/deny this).
>
> Some examples:
>
> $ openstack messaging post
> $ openstack messaging flavor create
> $ openstack messaging pool add
>
> etc
>
> Does the above make sense?
> Flavio
>
>
>
>> Best,
>>
>> Victoria
>>
>> 2015-10-10 10:10 GMT-03:00 Shifali Agrawal > >:
>>
>>All right, thanks for responses, will code accordingly :)
>>
>>On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann 
>>wrote:
>>
>>Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32
>> -0400:
>>>
>>> Using `message flavor` works for me, and having two words is just
>>fine.
>>
>>It might even be good to change "flavor" to "server flavor"
>> (keeping
>>flavor as a backwards-compatible alias, of course).
>>  Doug
>>  >
>>> I'm in the process of collecting all of the existing "object"
>> works
>>are
>>> putting them online, there's a lot of them. Hopefully this will
>>reduce the
>>> collisions in the future.
>>>
>>> Thanks,
>>>
>>> Steve Martinelli
>>> OpenStack Keystone Core
>>>
>>>
>>>
>>> From:Shifali Agrawal 
>>> To:openstack-dev@lists.openstack.org
>>> Date:2015/10/06 03:40 PM
>>> Subject:[openstack-dev] [Zaqar][cli][openstack-client]
>> conflict
>>in nova
>>> flavor and zaqar flavor
>>>
>>>
>>>
>>> Greetings,
>>>
>>> I am implementing cli commands for Zaqar flavors, the command
>> should
>>be
>>> like:
>>>
>>> "openstack flavor "
>>>
>>> But there is already same command present for Nova flavors. After
>>> discussing with Zaqar devs we thought to change all zaqar
>> commands
>>such
>>> that they include `message` word after openstack, thus above
>> Zaqar
>>flavor
>>> command will become:
>>>
>>> "openstack message flavor "
>>>
>>> Does openstack-client devs have something to say for this? Or
>> they
>>also
>>> feel its good to move with adding `message` word to all Zaqar cli
>>> commands?
>>>
>>> Already existing Zaqar commands will work with get a deprecation
>>> message/warning and also I will implement them all to work with
>>`message`
>>> word, and all new commands will be implement so that they work
>> only
>>with
>>> `message` word.
>>
>>
>>  __
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?
>>subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>  __
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development

Re: [openstack-dev] [neutron-LBaaS] Can anyone help to share a procedure to install lbaas on Kilo?

2015-10-13 Thread Kobi Samoray

Hi Tony,
Try the following:
https://chapter60.wordpress.com/2015/02/20/installing-openstack-lbaas-version-2-on-kilo-using-devstack/


On Oct 13, 2015, at 14:11, WANG, Ming Hao (Tony T) 
> wrote:

I installed an OpenStack environment manually, and I can’t use devstack or 
packstack to install neutron lbaas.
Can anyone help to share a procedure to install lbaas on Kilo? I can’t find one 
from Google. ☹

Thanks in advance,
Tony

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

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

[openstack-dev] [neutron-LBaaS] Can anyone help to share a procedure to install lbaas on Kilo?

2015-10-13 Thread WANG, Ming Hao (Tony T)

I installed an OpenStack environment manually, and I can't use devstack or 
packstack to install neutron lbaas.
Can anyone help to share a procedure to install lbaas on Kilo? I can't find one 
from Google. :(

Thanks in advance,
Tony

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

Re: [openstack-dev] [gertty] Replying to inline comments

2015-10-13 Thread Flavio Percoco


On 13/10/15 10:46 +0100, Paul Bourke wrote:

Hi,

Does anyone know if this is possible in the current version of gertty?


It is. You just hit enter, write your comment and it'll be magically
ordered after you review the change (despite it showing your comment
on top of the existing one).

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [ceilometer][horizon] tentative design summit schedule

2015-10-13 Thread gord chung


hi,

for those interested, i've put up the tentative schedule[1] for 
telemetry-related topics for the Tokyo design summit.


note, there's a session to discuss horizon and ceilometer integration as 
that was a common issue raised in the recent ceilometer survey.


please let me know if there's any conflicts to work around.

[1] https://mitakadesignsummit.sched.org/overview/type/ceilometer

cheers,

--
gord


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

Re: [openstack-dev] [fuel] PTL & Component Leads elections

2015-10-13 Thread Tomasz Napierala

Congrats Dmitry! Well deserved.


> On 09 Oct 2015, at 19:13, Mike Scherbakov  wrote:
> 
> Congratulations to Dmitry!
> Now you are officially titled with PTL.
> It won't be easy, but we will support you!
> 
> 118 contributors voted. Thanks everyone! Thank you Sergey for organizing 
> elections for us.
> 
> On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov  wrote:
> Voting period ended and so we have an officially selected Fuel PTL - DB. 
> Congrats!
> 
> Poll results & details - 
> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0
> 
> Let's start proposing candidates for the component lead positions!
> 
> On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov  
> wrote:
> Hi folks,
> 
> I've just setup the voting system and you should start receiving email with 
> topic "Poll: Fuel PTL Elections Fall 2015".
> 
> NOTE: Please, don't forward this email, it contains *personal* unique token 
> for the voting.
> 
> Thanks.
> 
> On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin  wrote:
> +1 to Igor. Do we have voting system set up?
> 
> On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky  
> wrote:
> > * September 29 - October 8: PTL elections
> 
> So, it's in progress. Where I can vote? I didn't receive any emails.
> 
> On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
>  wrote:
> >> On 18 Sep 2015, at 04:39, Sergey Lukjanov  wrote:
> >>
> >>
> >> Time line:
> >>
> >> PTL elections
> >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
> >> * September 29 - October 8: PTL elections
> >
> > Just a reminder that we have a deadline for candidates today.
> >
> > Regards,
> > --
> > Tomasz 'Zen' Napierala
> > Product Engineering - Poland
> >
> >
> >
> >
> >
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> 
> 
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -- 
> Mike Scherbakov
> #mihgen
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







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

[openstack-dev] [neutron][fwaas] fwaas driver development steps

2015-10-13 Thread Oğuz Yarımtepe

Hi,

I need to write a driver for our friewall hardware to integrate it to our
Openstack environment. I checked the Neutron Development wiki page, FWaaS
wiki page, fwaas driver codes written at the Github. Since there is no
clear documentation about howto write a direwall driver for Neutron i need
some guidance. The firewall driver will have a REST API that can be used to
configure it so what i need now is how i will debug and develop neutron
while writing the driver. What is the suggested way? Which functions should
be implemented? I had seen the abstract functions like, create_friewall,
update_firewall, the question is what are the context of the parameters
coming there. So either i should debug one of them step by step like the
iptables driver or some clear definition i should have.

What is the right way to do it?



-- 
Oğuz Yarımtepe
http://about.me/oguzy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

2015-10-13 Thread Matt Fischer

>From a technical point of view, not forking and using a native library
makes total sense. I think it would likely be faster and certainly cleaner
than parsing output. Unfortunately I don't think that we have the resources
to actively maintain the library. I think that's the main blocker for me.

On Tue, Oct 13, 2015 at 7:13 AM, Vladimir Kuklin 
wrote:

> Puppetmaster and Fuelers,
>
> Last week I mentioned that I would like to bring the theme of using native
> ruby OpenStack client and use it within the providers.
>
> Emilien told me that I had already been late and the decision was made
> that puppet-openstack decided to not work with Aviator based on [0]. I went
> through this thread and did not find any unresolvable issues with using
> Aviator in comparison with potential benefits it could have brought up.
>
> What I saw actually was like that:
>
> * Pros
>
> 1) It is a native ruby client
> 2) We can import it in puppet and use all the power of Ruby
> 3) We will not need to have a lot of forks/execs for puppet
> 4) You are relying on negotiated and structured output provided by API
> (JSON) instead of introducing workarounds for client output like [1]
>
> * Cons
>
> 1) Aviator is not actively supported
> 2) Aviator does not track all the upstream OpenStack features while native
> OpenStack client does support them
> 3) Ruby community is not really interested in OpenStack (this one is
> arguable, I think)
>
> * Proposed solution
>
> While I completely understand all the cons against using Aviator right
> now, I see that Pros above are essential enough to change our mind and
> invest our own resources into creating really good OpenStack binding in
> Ruby.
> Some are saying that there is not so big involvement of Ruby into
> OpenStack. But we are actually working with Puppet/Ruby and are invloved
> into community. So why should not we own this by ourselves and lead by
> example here?
>
> I understand that many of you do already have a lot of things on their
> plate and cannot or would not want to support things like additional
> library when native OpenStack client is working reasonably well for you.
> But if I propose the following scheme to get support of native Ruby client
> for OpenStack:
>
> 1) we (community) have these resources (speaking of the company I am
> working for, we at Mirantis have a set of guys who could be very interested
> in working on Ruby client for OpenStack)
> 2) we gradually improve Aviator code base up to the level that it
> eliminates issues that are mentioned in  'Cons' section
> 3) we introduce additional set of providers and allow users and operators
> to pick whichever they want
> 4) we leave OpenStackClient default one
>
> Would you support it and allow such code to be merged into upstream
> puppet-openstack modules?
>
>
> [0]
> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
> [1]
> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] getting rid of tablib completely (Requests + urllib3 + distro packages)

2015-10-13 Thread Doug Hellmann

Excerpts from Thomas Goirand's message of 2015-10-13 12:38:00 +0200:
> On 10/12/2015 11:09 PM, Steve Baker wrote:
> > On 13/10/15 02:05, Thomas Goirand wrote:
> >>
> >> BTW, the same applies for tablib which is in a even more horrible state
> >> that makes it impossible to package with Py3 support. But tablib could
> >> be removed from our (build-)dependency list, if someone cares about
> >> re-writing cliff-tablib, which IMO wouldn't be that much work. Doug, how
> >> many beers shall I offer you for that work? :)
> >>
> > Regarding tablib, cliff has had its own table formatter for some time,
> > and now has its own json and yaml formatters. I believe the only tablib
> > formatter left is the HTML one, which likely wouldn't be missed if it
> > was just dropped (or it could be simply reimplemented inside cliff).
> > 
> > If the cliff deb depends on cliff-tablib
> 
> It does.

That dependency is backwards. cliff-tablib should depend on cliff. Cliff
does not need cliff-tablib, but cliff-tablib is only useful if cliff is
installed.

> And also the below packages have a build-dependency on
> cliff-tablib:
> 
> - python-neutronclient
> - python-openstackclient
> 
> python-openstackclient also has a runtime depends on cliff-tablib.

Now that we have a cliff with the formatters provided by tablib, we can
update those dependencies to remove cliff-tablib. Someone just needs to
follow through on that with patches to the requirements files for the
clients.

> 
> The problem is that *many* packages have (build-)depends on
> neutronclient and openstackclient, so it blocks Py3 support for them as
> well.
> 
> So we need to address this.
> 
> > I would recommend removing that
> > dependency and just stop packaging cliff-tablib.
> 
> Can I just drop cliff-tablib from cliff, and be done with it? Really?
> 
> I am hereby announcing that I'm paying a beer in Tokyo to anyone who
> helps fixing this mess, so we get rid of tablib. :)
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

2015-10-13 Thread Vladimir Kuklin

Matt

Thanks for your input. So, I mentioned the following - Fuel guys can
contribute into Ruby client for OpenStack as we are also interested in
making it faster. That's why I asked for support in case we invest
substantial effort (as we do not want to waste our time on things that will
not land into upstream) and asked if the approach that I proposed is OK
with you.

On Tue, Oct 13, 2015 at 6:07 PM, Matt Fischer  wrote:

> From a technical point of view, not forking and using a native library
> makes total sense. I think it would likely be faster and certainly cleaner
> than parsing output. Unfortunately I don't think that we have the resources
> to actively maintain the library. I think that's the main blocker for me.
>
> On Tue, Oct 13, 2015 at 7:13 AM, Vladimir Kuklin 
> wrote:
>
>> Puppetmaster and Fuelers,
>>
>> Last week I mentioned that I would like to bring the theme of using
>> native ruby OpenStack client and use it within the providers.
>>
>> Emilien told me that I had already been late and the decision was made
>> that puppet-openstack decided to not work with Aviator based on [0]. I went
>> through this thread and did not find any unresolvable issues with using
>> Aviator in comparison with potential benefits it could have brought up.
>>
>> What I saw actually was like that:
>>
>> * Pros
>>
>> 1) It is a native ruby client
>> 2) We can import it in puppet and use all the power of Ruby
>> 3) We will not need to have a lot of forks/execs for puppet
>> 4) You are relying on negotiated and structured output provided by API
>> (JSON) instead of introducing workarounds for client output like [1]
>>
>> * Cons
>>
>> 1) Aviator is not actively supported
>> 2) Aviator does not track all the upstream OpenStack features while
>> native OpenStack client does support them
>> 3) Ruby community is not really interested in OpenStack (this one is
>> arguable, I think)
>>
>> * Proposed solution
>>
>> While I completely understand all the cons against using Aviator right
>> now, I see that Pros above are essential enough to change our mind and
>> invest our own resources into creating really good OpenStack binding in
>> Ruby.
>> Some are saying that there is not so big involvement of Ruby into
>> OpenStack. But we are actually working with Puppet/Ruby and are invloved
>> into community. So why should not we own this by ourselves and lead by
>> example here?
>>
>> I understand that many of you do already have a lot of things on their
>> plate and cannot or would not want to support things like additional
>> library when native OpenStack client is working reasonably well for you.
>> But if I propose the following scheme to get support of native Ruby client
>> for OpenStack:
>>
>> 1) we (community) have these resources (speaking of the company I am
>> working for, we at Mirantis have a set of guys who could be very interested
>> in working on Ruby client for OpenStack)
>> 2) we gradually improve Aviator code base up to the level that it
>> eliminates issues that are mentioned in  'Cons' section
>> 3) we introduce additional set of providers and allow users and operators
>> to pick whichever they want
>> 4) we leave OpenStackClient default one
>>
>> Would you support it and allow such code to be merged into upstream
>> puppet-openstack modules?
>>
>>
>> [0]
>> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
>> [1]
>> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

2015-10-13 Thread Vladimir Kuklin

Rich

Thanks for your feedback - let me comment on a couple of things.

First of all, I do not think we have complete support for any action in
OpenStack client right now - we still need to rely on neutronclient,
glanceclient, etc.

Secondly, regarding Ruby power - this is about any good programming
language, not about Ruby - I can simply mention better exception handling
as you would not need to parse the output and generate your own exceptions
- this makes it easier to support the whole set of providers. As I
mentioned earlier, we do not have perfect exception handling for
intermittent operational issues.

Finally, I understand that you do not see metrics. Although, it seems to me
absolutely obvious that fork/exec is going to be the problem here, that's
OK, I will work on that and come up with quantitative analysis.


On Tue, Oct 13, 2015 at 5:18 PM, Rich Megginson <rmegg...@redhat.com> wrote:

> On 10/13/2015 07:13 AM, Vladimir Kuklin wrote:
>
> Puppetmaster and Fuelers,
>
> Last week I mentioned that I would like to bring the theme of using native
> ruby OpenStack client and use it within the providers.
>
> Emilien told me that I had already been late and the decision was made
> that puppet-openstack decided to not work with Aviator based on [0]. I went
> through this thread and did not find any unresolvable issues with using
> Aviator in comparison with potential benefits it could have brought up.
>
> What I saw actually was like that:
>
> * Pros
>
> 1) It is a native ruby client
> 2) We can import it in puppet and use all the power of Ruby
> 3) We will not need to have a lot of forks/execs for puppet
>
>
> I think 1), 2), and 3) go together - that is, the reason why 1) and 2) are
> good is because of 3) - since aviator is native ruby, there is no need to
> fork/exec.  What other "power of Ruby" is there to be taken advantage of?
>
> As for fork/exec, it remains to be seen that fork/exec is causing a
> performance problem.  Note that you can also run the openstackclient in
> "persistent" mode - that is, use it as a persistent pipe, which will read
> commands from stdin and output to stdout, which should alleviate much if
> not all of any performance problem caused by multiple fork/exec.  We just
> haven't investigated this route yet because it needs to be proven that
> fork/exec causes performance problems.
>
> 4) You are relying on negotiated and structured output provided by API
> (JSON) instead of introducing workarounds for client output like [1]
>
>
> openstackclient can output JSON.
>
>
> * Cons
>
> 1) Aviator is not actively supported
>
>
> This is huge.
>
> 2) Aviator does not track all the upstream OpenStack features while native
> OpenStack client does support them
>
>
> This is also huge.
>
> 3) Ruby community is not really interested in OpenStack (this one is
> arguable, I think)
>
> * Proposed solution
>
> While I completely understand all the cons against using Aviator right
> now, I see that Pros above are essential enough to change our mind and
> invest our own resources into creating really good OpenStack binding in
> Ruby.
>
>
> I'm still not convinced.
>
> Some are saying that there is not so big involvement of Ruby into
> OpenStack. But we are actually working with Puppet/Ruby and are invloved
> into community. So why should not we own this by ourselves and lead by
> example here?
>
>
>
>
>
> I understand that many of you do already have a lot of things on their
> plate and cannot or would not want to support things like additional
> library when native OpenStack client is working reasonably well for you.
> But if I propose the following scheme to get support of native Ruby client
> for OpenStack:
>
> 1) we (community) have these resources (speaking of the company I am
> working for, we at Mirantis have a set of guys who could be very interested
> in working on Ruby client for OpenStack)
> 2) we gradually improve Aviator code base up to the level that it
> eliminates issues that are mentioned in  'Cons' section
> 3) we introduce additional set of providers and allow users and operators
> to pick whichever they want
> 4) we leave OpenStackClient default one
>
> Would you support it and allow such code to be merged into upstream
> puppet-openstack modules?
>
>
> I would be in favor of such a plan if
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013
> questions 0.4.1-0.4.7 could be answered in the affirmative.
>
>
>
> [0]
> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
> [1]
> https://github.com/openstack/puppet-swift/bl

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

2015-10-13 Thread Clayton O'Neill

I agree that ideally, using a native ruby library would be better, but I
also share Matt's concern.  We'd need a commitment from more than one
person to maintain the library if we went that route.

I think the big advantages I see with the ruby client would be:

   - Potentially better performance
   - Faster turn around time for enhancements/bug fixes.  My concern here
   is that we're currently limited by how quickly distros pick up new versions
   of OpenStack Client.


I think if we did end up using a ruby library, we'd also want to make sure
it was not only vendored, but also usable independently, to increase the
audience.

On Tue, Oct 13, 2015 at 8:16 AM, Vladimir Kuklin 
wrote:

> Matt
>
> Thanks for your input. So, I mentioned the following - Fuel guys can
> contribute into Ruby client for OpenStack as we are also interested in
> making it faster. That's why I asked for support in case we invest
> substantial effort (as we do not want to waste our time on things that will
> not land into upstream) and asked if the approach that I proposed is OK
> with you.
>
> On Tue, Oct 13, 2015 at 6:07 PM, Matt Fischer 
> wrote:
>
>> From a technical point of view, not forking and using a native library
>> makes total sense. I think it would likely be faster and certainly cleaner
>> than parsing output. Unfortunately I don't think that we have the resources
>> to actively maintain the library. I think that's the main blocker for me.
>>
>> On Tue, Oct 13, 2015 at 7:13 AM, Vladimir Kuklin 
>> wrote:
>>
>>> Puppetmaster and Fuelers,
>>>
>>> Last week I mentioned that I would like to bring the theme of using
>>> native ruby OpenStack client and use it within the providers.
>>>
>>> Emilien told me that I had already been late and the decision was made
>>> that puppet-openstack decided to not work with Aviator based on [0]. I went
>>> through this thread and did not find any unresolvable issues with using
>>> Aviator in comparison with potential benefits it could have brought up.
>>>
>>> What I saw actually was like that:
>>>
>>> * Pros
>>>
>>> 1) It is a native ruby client
>>> 2) We can import it in puppet and use all the power of Ruby
>>> 3) We will not need to have a lot of forks/execs for puppet
>>> 4) You are relying on negotiated and structured output provided by API
>>> (JSON) instead of introducing workarounds for client output like [1]
>>>
>>> * Cons
>>>
>>> 1) Aviator is not actively supported
>>> 2) Aviator does not track all the upstream OpenStack features while
>>> native OpenStack client does support them
>>> 3) Ruby community is not really interested in OpenStack (this one is
>>> arguable, I think)
>>>
>>> * Proposed solution
>>>
>>> While I completely understand all the cons against using Aviator right
>>> now, I see that Pros above are essential enough to change our mind and
>>> invest our own resources into creating really good OpenStack binding in
>>> Ruby.
>>> Some are saying that there is not so big involvement of Ruby into
>>> OpenStack. But we are actually working with Puppet/Ruby and are invloved
>>> into community. So why should not we own this by ourselves and lead by
>>> example here?
>>>
>>> I understand that many of you do already have a lot of things on their
>>> plate and cannot or would not want to support things like additional
>>> library when native OpenStack client is working reasonably well for you.
>>> But if I propose the following scheme to get support of native Ruby client
>>> for OpenStack:
>>>
>>> 1) we (community) have these resources (speaking of the company I am
>>> working for, we at Mirantis have a set of guys who could be very interested
>>> in working on Ruby client for OpenStack)
>>> 2) we gradually improve Aviator code base up to the level that it
>>> eliminates issues that are mentioned in  'Cons' section
>>> 3) we introduce additional set of providers and allow users and
>>> operators to pick whichever they want
>>> 4) we leave OpenStackClient default one
>>>
>>> Would you support it and allow such code to be merged into upstream
>>> puppet-openstack modules?
>>>
>>>
>>> [0]
>>> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
>>> [1]
>>> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>

Re: [openstack-dev] [all] Cross-project track schedule draft: Feedback needed

2015-10-13 Thread Anne Gentle

On Tue, Oct 13, 2015 at 3:18 AM, Thierry Carrez 
wrote:

> Flavio Percoco wrote:
> > We have a draft schedule for the cross-project track for the Mitaka
> > summit[0] (find it at the bottom of the etherpad). Yay!
> >
> > We would like to get feedback from folks that have proposed these
> > sessions - hopefully you're all cc'd - or other folks that may be
> > co-moderating them. If there are any conflicts for you in the current
> > schedule, please, do let us know and we'll re-arange as possible.
> >
> > Feedback from anyone is obviously welcomed but keep in mind that this
> > is a process that will hardly make everyone happy.
>
> Based on currently-expressed constraints, we could swap sessions 3 and
> 26 so that mtreinish can attend 26 (and dhellmann can attend both 3 and
> 11).
>

I have to present at 2:50 Tuesday. Can we swap Documentation (10) with
something later in the afternoon?

Anne


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


-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposed solution to "Admin" ness improperly scoped:

2015-10-13 Thread Adam Young


On 10/13/2015 12:15 AM, Shinobu Kinjo wrote:

Sorry for my lack of explanation.
Are the both scopes of admin and non-admin totally different?

Is each project not nested in admin scope like:

So, a couple terms:
We use the term 'scope' to refer to the project.  Think of this as a 
container that holds resources.


The user  is assigned a role on the project, and that determines what 
operations the user can perform.


However, When OpenStack started, roles were not scoped, but were 
global.  Thus, there are many APIs
where the only check is that the user has the role 'admin' and the 
project scope is never checked.


Because Roles are defined in Keystone after install, none of the default 
policy files actually check any
specific roles.  The only role other than 'admin' that you will see in a 
Packstack install is that for
a Member (often _member_ ).  This role was added to standardize how we 
enforce policy; users used to be
assigned exclusively to a project, and adding this mechanism allowed a 
user to access multiple projects

while maintaining a single policy mechanism.

So there are some APIs where either the project scope is checked -OR- 
the role admin is checked.


We are not making use of hierarchical multitenatcy here; your example 
shows proejct-a,b, and c nested under admin.


This change would not require that.




  admin {
   Some properties
...
   {
...
project-a {
 owner-a
  ...
}
project-b {
 owner-b
  ...
}
 ...
project-x {
 owner-x
  ...
}
   }
  }

Or is "ADMIN_PROJECT_ID" totally different flag?


It means that only a token scoped to 'admin' would (potentially) have 
the role 'admin' available.




I hope you could get me -;

Shinobu

- Original Message -
From: "Adam Young" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, October 13, 2015 12:56:54 PM
Subject: Re: [openstack-dev] Proposed solution to "Admin" ness improperly 
scoped:

On 10/12/2015 08:07 PM, Shinobu Kinjo wrote:

Just question.
Will be scopes of non-admin users projects in admin scoped project?

I'm sorry I don't understand what you are asking.


Shinobu

- Original Message -
From: "Adam Young" 
To: "OpenStack Development Mailing List" 
Sent: Monday, October 12, 2015 3:38:01 AM
Subject: [openstack-dev] Proposed solution to "Admin" ness improperly scoped:

https://bugs.launchpad.net/keystone/+bug/968696/comments/39

1. Add a config value ADMIN_PROJECT_ID
2. In token creation, if ADMIN_PROJECT_ID is not None: only add the
admin role to the token if the id of the scoped project == ADMIN_PROJECT_ID

Does this work?

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

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


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

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



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

Re: [openstack-dev] Scheduler proposal

2015-10-13 Thread Alec Hothan (ahothan)

On 10/12/15, 12:05 PM, "Monty Taylor"  wrote:

>On 10/12/2015 02:45 PM, Joshua Harlow wrote:
>> Alec Hothan (ahothan) wrote:
>>>
>>>
>>>
>>>
>
>I want to do 100k hypervisors. No, that's not hyperbole.
>
>Also, I do not think that ZK/consul/etcd are very costly for small 
>deployments. Given the number of simple dev-oriented projects that start 
>with "so install ZK/consul/etcd" I think they've all proven their 
>ability to scale _down_ - and I'm also pretty sure all of them have 
>installations that clear 100k nodes.
>
>This:
>
>to produce the ubiquitous Open Source Cloud Computing platform that will 
>meet the needs of public and private clouds regardless of size, by being 
>simple to implement and massively scalable.
>
>is what we're doing.
>
>Our mission is NOT "produce a mid-range cloud that is too complex for 
>small deployments and tops out before you get to big ones"
>
>I don't think "handle massive clouds" has ever NOT been on the list of 
>stated goals. (that mission statement has not changed since we started 
>the project - although I agree with Joe, it's in need of an update- 
>there is no mention of users)

Then it'd be great that there be an official statement from the TC about the 
scale objectives and if possible put some numbers, "massive cloud" is ambiguous 
for folks who actually have to make sure they scale to specs.
So should mention "OpenStack should scale from 1 node to 100K nodes" for 
example. As long as everybody is fully aware about how far we are today from 
that lofty goal.
This clearly will have an impact on how we need to design services and how we 
should change the way we test for them. It will be tricky to get a 1000 node 
lab up and running just for openstack developers, it is just not practical at 
all. The only practical way will be to do proper unit testing at scale (e.g. 
emulate a 10K node cloud for unit testing any given service).

>
>BTW - Infra runs against currently runs against clouds rate-limited at 
>roughly 10 api calls / second. That's just one tenant - but it's a 
>perfectly managable rate. Now, if the cloud could continue to add nodes 
>and users without that rate degrading I think we'd be in really good shape.

I think that rate limit only applies to REST APIs, I don't think there is any 
rate limit for oslo messaging.
Even only 10 API calls per second per tenant can be a challenge with a large 
number of tenants. I don't think there is any provision today for example to 
ensure fairness across tenants.

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers


On 10/13/2015 07:13 AM, Vladimir Kuklin wrote:

Puppetmaster and Fuelers,

Last week I mentioned that I would like to bring the theme of using 
native ruby OpenStack client and use it within the providers.


Emilien told me that I had already been late and the decision was made 
that puppet-openstack decided to not work with Aviator based on [0]. I 
went through this thread and did not find any unresolvable issues with 
using Aviator in comparison with potential benefits it could have 
brought up.


What I saw actually was like that:

* Pros

1) It is a native ruby client
2) We can import it in puppet and use all the power of Ruby
3) We will not need to have a lot of forks/execs for puppet


I think 1), 2), and 3) go together - that is, the reason why 1) and 2) 
are good is because of 3) - since aviator is native ruby, there is no 
need to fork/exec.  What other "power of Ruby" is there to be taken 
advantage of?


As for fork/exec, it remains to be seen that fork/exec is causing a 
performance problem.  Note that you can also run the openstackclient in 
"persistent" mode - that is, use it as a persistent pipe, which will 
read commands from stdin and output to stdout, which should alleviate 
much if not all of any performance problem caused by multiple 
fork/exec.  We just haven't investigated this route yet because it needs 
to be proven that fork/exec causes performance problems.


4) You are relying on negotiated and structured output provided by API 
(JSON) instead of introducing workarounds for client output like [1]


openstackclient can output JSON.



* Cons

1) Aviator is not actively supported


This is huge.

2) Aviator does not track all the upstream OpenStack features while 
native OpenStack client does support them


This is also huge.

3) Ruby community is not really interested in OpenStack (this one is 
arguable, I think)


* Proposed solution

While I completely understand all the cons against using Aviator right 
now, I see that Pros above are essential enough to change our mind and 
invest our own resources into creating really good OpenStack binding 
in Ruby.


I'm still not convinced.

Some are saying that there is not so big involvement of Ruby into 
OpenStack. But we are actually working with Puppet/Ruby and are 
invloved into community. So why should not we own this by ourselves 
and lead by example here?






I understand that many of you do already have a lot of things on their 
plate and cannot or would not want to support things like additional 
library when native OpenStack client is working reasonably well for 
you. But if I propose the following scheme to get support of native 
Ruby client for OpenStack:


1) we (community) have these resources (speaking of the company I am 
working for, we at Mirantis have a set of guys who could be very 
interested in working on Ruby client for OpenStack)
2) we gradually improve Aviator code base up to the level that it 
eliminates issues that are mentioned in  'Cons' section
3) we introduce additional set of providers and allow users and 
operators to pick whichever they want

4) we leave OpenStackClient default one

Would you support it and allow such code to be merged into upstream 
puppet-openstack modules?


I would be in favor of such a plan if 
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013 questions 
0.4.1-0.4.7 could be answered in the affirmative.





[0] 
https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J 
<https://groups.google.com/a/puppetlabs.com/forum/#%21searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J>
[1] 
https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86

--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru <http://www.mirantis.ru/>
vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>


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


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

[openstack-dev] [Neutron][dns]What the meaning of "dns_assignment" and "dns_name"?

2015-10-13 Thread Zhi Chang

Hi, all
I install the latest devstack and create a vm by nova. I get the port's 
info which created by Neutron. I'm confused that what the meaning of column 
"dns_assignment" and column "dns_name".
First, column "dns_assignment" is a read-only attribute. What is it used 
for? I think that this column is useless except shows DNS infomation (include 
hostname, ip, fqdn). Does my thought right?
Second, I don't quite understand what the meaning of column "dns_name". I 
can update this column, but there is nothing happen when my operation was done. 
In other words, this column has no change when I run "neutron port-update xxx 
--dns_name=test". What the column "dns_name" use for?






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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

vel that it
eliminates issues that are mentioned in  'Cons' section
3) we introduce additional set of providers and allow users and
operators to pick whichever they want
4) we leave OpenStackClient default one

Would you support it and allow such code to be merged into
upstream puppet-openstack modules?


I would be in favor of such a plan if
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013
questions 0.4.1-0.4.7 could be answered in the affirmative.




[0]

https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J

<https://groups.google.com/a/puppetlabs.com/forum/#%21searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J>
[1]

https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
-- 
Yours Faithfully,

Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru <http://www.mirantis.ru/>
vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>


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



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




--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru <http://www.mirantis.ru/>
vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>


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


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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

On 10/13/2015 09:22 AM, Clayton O'Neill wrote:
I agree that ideally, using a native ruby library would be better, but 
I also share Matt's concern.  We'd need a commitment from more than 
one person to maintain the library if we went that route.

I think the big advantages I see with the ruby client would be:

  * Potentially better performance

But how much, and is it worth the cost, and also worth the cost vs. 
using openstackclient in "persistent" mode.

  * Faster turn around time for enhancements/bug fixes.  My concern
here is that we're currently limited by how quickly distros pick
up new versions of OpenStack Client.

IMO this is the biggest problem we have had with using openstackclient - 
being gated by distros, and having to wait months, in some cases, to use 
features supported by the services, which we could have used immediately 
using the API directly.

I think if we did end up using a ruby library, we'd also want to make 
sure it was not only vendored, but also usable independently, to 
increase the audience.

. . . and then are we also going to be gated by the distros in the same 
way, waiting for months to get an update to aviator?

On Tue, Oct 13, 2015 at 8:16 AM, Vladimir Kuklin > wrote:

Matt

Thanks for your input. So, I mentioned the following - Fuel guys
can contribute into Ruby client for OpenStack as we are also
interested in making it faster. That's why I asked for support in
case we invest substantial effort (as we do not want to waste our
time on things that will not land into upstream) and asked if the
approach that I proposed is OK with you.

On Tue, Oct 13, 2015 at 6:07 PM, Matt Fischer
> wrote:

From a technical point of view, not forking and using a native
library makes total sense. I think it would likely be faster
and certainly cleaner than parsing output. Unfortunately I
don't think that we have the resources to actively maintain
the library. I think that's the main blocker for me.

On Tue, Oct 13, 2015 at 7:13 AM, Vladimir Kuklin
> wrote:

Puppetmaster and Fuelers,

Last week I mentioned that I would like to bring the theme
of using native ruby OpenStack client and use it within
the providers.

Emilien told me that I had already been late and the
decision was made that puppet-openstack decided to not
work with Aviator based on [0]. I went through this thread
and did not find any unresolvable issues with using
Aviator in comparison with potential benefits it could
have brought up.

What I saw actually was like that:

* Pros

1) It is a native ruby client
2) We can import it in puppet and use all the power of Ruby
3) We will not need to have a lot of forks/execs for puppet
4) You are relying on negotiated and structured output
provided by API (JSON) instead of introducing workarounds
for client output like [1]

* Cons

1) Aviator is not actively supported
2) Aviator does not track all the upstream OpenStack
features while native OpenStack client does support them
3) Ruby community is not really interested in OpenStack
(this one is arguable, I think)

* Proposed solution

While I completely understand all the cons against using
Aviator right now, I see that Pros above are essential
enough to change our mind and invest our own resources
into creating really good OpenStack binding in Ruby.
Some are saying that there is not so big involvement of
Ruby into OpenStack. But we are actually working with
Puppet/Ruby and are invloved into community. So why should
not we own this by ourselves and lead by example here?

I understand that many of you do already have a lot of
things on their plate and cannot or would not want to
support things like additional library when native
OpenStack client is working reasonably well for you. But
if I propose the following scheme to get support of native
Ruby client for OpenStack:

1) we (community) have these resources (speaking of the
company I am working for, we at Mirantis have a set of
guys who could be very interested in working on Ruby
client for OpenStack)
2) we gradually improve Aviator code base up to the level
that it eliminates issues that are mentioned in  'Cons'
section
3) we introduce additional set of providers

Re: [openstack-dev] [sahara] Proposing Vitaly Gridnev to core reviewer team

2015-10-13 Thread Matthew Farrellee


+1!

On 10/12/2015 07:19 AM, Sergey Lukjanov wrote:

Hi folks,

I'd like to propose Vitaly Gridnev as a member of the Sahara core
reviewer team.

Vitaly contributing to Sahara for a long time and doing a great job on
reviewing and improving Sahara. Here are the statistics for reviews
[0][1][2] and commits [3].

Existing Sahara core reviewers, please vote +1/-1 for the addition of
Vitaly to the core reviewer team.

Thanks.

[0]
https://review.openstack.org/#/q/reviewer:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z
[1] http://stackalytics.com/report/contribution/sahara-group/180
[2] http://stackalytics.com/?metric=marks_id=vgridnev
[3]
https://review.openstack.org/#/q/status:merged+owner:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z

--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.


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




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

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-13 Thread Matthew Thode

On 10/08/2015 07:39 PM, Robert Collins wrote:
> This is a bugbear that keeps cropping up and biting us. I'm hoping we
> can figure out a permanent fix.
> 
> The problem that occurs is the result of a few interacting things:
>  - requests has very very specific versions of urllib3 it works with.
> So specific they aren't always released yet.
> 
>  - Linux vendors often unbundle urllib3 from requests and then apply
> what patches were needed to their urllib3; while not updating their
> requests package dependencies to reflect this.
> 
>  - we use urllib3 in some places and requests in others (but we don't
> mix them up)
> 
>  - if for any reason we have a distro-altered requests + a
> pip-installed urllib3, requests will [usually] break... see the 'not
> always released yet' key thing above.
> 
> Now, there are lots of places this last thing can happen; they all
> depend on us having a dependency on requests that is compatible with
> the version installed by the distro, but a urllib3 dependency that
> triggers an upgrade of just urllib3. When constraints are in use, the
> requests version has to match the distro requests version exactly, but
> that will happen from time to time.
> 
> e.g.
> 
>  - dvsm test jobs where the base image already has python-requests
> installed in it
> 
>  - virtualenvs where system-site-packages are enabled
> 
> 
> There are a few strategies that have been proposed to fix this. AIUI they are:
>  - make sure none of our testing environments include distro requests 
> packages.
> 
>  - make our requirements be tightly matched to what requests needs to
> deal with the unbundling
> 
>  - teach pip how to identify and avoid this situation by always
> upgrading requests (even if thats just a re-install of the version
> from PyPI) when the installed requests is a distro installed version
> **and** urllib3 is being modified.
> 
>  - get the distros to stop un-vendoring urllib3
> 
> 
> The first one addresses the situation for the CI gate but doesn't
> avoid developers getting bitten on their local machines. And
> installing any distro thing that uses requests would re-instate the
> potential for breakage. So while its not harmful, I don't think its
> sufficient to make this go away.
> 
> The second is trivially insufficient - anytime requests vendored
> urllib3 is not precisely identical to a released urllib3, it becomes
> impossible to satisfy that via dependency version pinning - the only
> way to satisfy it is with the urllib3 in the distro that has whatever
> change was needed included.
> 
> The third approach will require some negotiation I suspect - because
> its aesthetically wrong: from an upstream perspective urllib3 is
> independent of requests, and vice-versa, but from a distro perspective
> they are tightly coupled, no variation permitted.
> 
> The fourth approach meets the stone wall of 'but security' and 'no
> redundancy permitted' - I don't have the energy to try and get through
> the near-religious mindset I've encountered there before, though hey -
> if Fedora and Debian and Ubuntu folk are all interested in figuring
> out a sustainable way forward, that would be great: please don't feel
> cut out, I'm just not expecting anything.
> 
> If there are other approaches, great - please throw them up here.
> 
> -Rob
> 

At least for my packaging for Gentoo I haven't run into any issues here.
We have multiple versions of both requests and urllib3 available and I
can add a missing version if needed.

-- 
Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

2015-10-13 Thread Fox, Kevin M

lb's use the term pools too. A little more specific might be good.

Thanks,
Kevin

From: Victoria Martínez de la Cruz [victo...@vmartinezdelacruz.com]
Sent: Tuesday, October 13, 2015 5:28 AM
To: Flavio Percoco; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova 
flavor and zaqar flavor

Fair enough, +1 to Flavio's suggestion

Thanks all,

Victoria

2015-10-13 3:35 GMT-03:00 Flavio Percoco 
>:
On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote:
HI all,

Thanks for your feedback. We discussed this topic in this week weekly meeting
and we came to the conclusion that it would be better to use "pool-flavor"
instead of creating a namespace for Zaqar only (by prefixing everything with
the "message" key).

So, this commands would look like

openstack pool-flavor create
openstack pool-flavor get
openstack pool-flavor delete
openstack pool-flavor update
openstack pool-flavor list

First and foremost, I'm sorry for not attending the last meeting.

I just read the logs from the meeting and I'd like to raise my
concerns with the above. I think it's very confusing for users to have
a non-namespaced command.

For example, what's a pool-flavor? Is it related to Nova's flavors? Is
it something related to some network pools? etc.

I understand that one of the concerns is that things like `openstack
message message post` wouldn't look good but I think that the project
namespace could match the service catalog (will let folks for OSC
confirm/deny this).

Some examples:

$ openstack messaging post
$ openstack messaging flavor create
$ openstack messaging pool add

etc

Does the above make sense?
Flavio



Best,

Victoria

2015-10-10 10:10 GMT-03:00 Shifali Agrawal 
>:

   All right, thanks for responses, will code accordingly :)

   On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann 
>
   wrote:

   Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400:
   >
   > Using `message flavor` works for me, and having two words is just
   fine.

   It might even be good to change "flavor" to "server flavor" (keeping
   flavor as a backwards-compatible alias, of course).
 Doug
 >
   > I'm in the process of collecting all of the existing "object" works
   are
   > putting them online, there's a lot of them. Hopefully this will
   reduce the
   > collisions in the future.
   >
   > Thanks,
   >
   > Steve Martinelli
   > OpenStack Keystone Core
   >
   >
   >
   > From:Shifali Agrawal 
>
   > To:
openstack-dev@lists.openstack.org
   > Date:2015/10/06 03:40 PM
   > Subject:[openstack-dev] [Zaqar][cli][openstack-client] conflict
   in nova
   > flavor and zaqar flavor
   >
   >
   >
   > Greetings,
   >
   > I am implementing cli commands for Zaqar flavors, the command should
   be
   > like:
   >
   > "openstack flavor "
   >
   > But there is already same command present for Nova flavors. After
   > discussing with Zaqar devs we thought to change all zaqar commands
   such
   > that they include `message` word after openstack, thus above Zaqar
   flavor
   > command will become:
   >
   > "openstack message flavor "
   >
   > Does openstack-client devs have something to say for this? Or they
   also
   > feel its good to move with adding `message` word to all Zaqar cli
   > commands?
   >
   > Already existing Zaqar commands will work with get a deprecation
   > message/warning and also I will implement them all to work with
   `message`
   > word, and all new commands will be implement so that they work only
   with
   > `message` word.

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



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




__
OpenStack Development Mailing List

Re: [openstack-dev] Scheduler proposal


Jeremy Stanley wrote:

On 2015-10-12 20:49:44 -0700 (-0700), Joshua Harlow wrote:

Does the openstack foundation have access to a scaling area that
can be used by the community for this kind of experimental work?


The OpenStack Foundation has a staff of fewer than 20 full-time
employees, with a primary focus on event planning and preserving the
community's trademarks. If instead you mean the member companies who
make up the OpenStack Foundation, then I agree with the other reply
on the thread that it sounds like the effort already underway at
Intel and Rackspace.


Sure, that its *current* primary focus, but this could be an addition.

I've also been thinking that long-term cross project changes should 
really also be guided by the foundation as well. Something akin to 
keeping long-term changes (ones that require years of work, such as 
cross project quota, or...) on track even when member companies come and 
go (because IMHO expecting otherwise leaves things halfway done, or not 
done at all).





It seems like infra or others should be able make that possible?

[...]

The Infrastructure team is in the process of standing up a
community-managed deployment of OpenStack, but it's not even within
an order of magnitude of being 1k host scale (and at that, it's
still a multi-cycle plan just to reach viability).


Well go big or go home :-P

-Josh

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

Re: [openstack-dev] Scheduler proposal


Well great!

When is that going to be accessible :-P

Dulko, Michal wrote:

On Mon, 2015-10-12 at 10:58 -0700, Joshua Harlow wrote:

Just a related thought/question. It really seems we (as a community)
need some kind of scale testing ground. Internally at yahoo we were/are
going to use a 200 hypervisor cluster for some of this and then expand
that into 200 * X by using nested virtualization and/or fake drivers and
such. But this is a 'lab' that not everyone can have, and therefore
isn't suited toward community work IMHO. Has there been any thought on
such a 'lab' that is directly in the community, perhaps trystack.org can
be this? (users get free VMs, but then we can tell them this area is a
lab, so don't expect things to always work, free isn't free after all...)

With such a lab, there could be these kinds of experiments, graphs,
tweaks and such...


https://www.mirantis.com/blog/intel-rackspace-want-cloud/

"The plan is to build out an OpenStack developer cloud that consists of
two 1,000 node clusters available for use by anyone in the OpenStack
community for scaling, performance, and code testing. Rackspace plans to
have the cloud available within the next six months."

Stuff you've described is actually being worked on for a few months. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

2015-10-13 Thread John Davidge (jodavidg)

Hi Edgar,

Happy to continue contributing here.  Currently in GMT timezone, but probably 
PST by the end of the year. Looking forward to the first meeting!

Cheers,

John Davidge

From: Edgar Magana >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, 8 October 2015 01:11
To: "OpenStack Development Mailing List (not for usage questions)" 
>, 
"openstack-operat...@lists.openstack.org"
 
>,
 
"openstack-d...@lists.openstack.org" 
>
Subject: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for 
contributors

Hello,

I would like to invite everybody to become an active contributor for the 
OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

During the Liberty cycle we made a lot of progress and we feel that the guide 
is ready to have even more contributions and formalize a bit more the team 
around it.
The first thing that I want to propose is to have a regular meeting over IRC to 
discuss the progress and to welcome new contributors. This is the same process 
that other guides like the operators one are following currently.

The networking guide is based on this ToC: 
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
Contribution process is the same that the rest of the OpenStack docs under the 
openstack-manuals git repo: 
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source

Please, response to this thread and let me know if you could allocate some time 
to help us to make this guide a rock star as the other ones. Based on the 
responses, I will propose a couple of times for the IRC meeting that could 
allocate to everybody if possible, this is why is very important to let me know 
your time zone.

I am really looking forward to increase the contributors in this guide.

Thanks in advance!

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

Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

2015-10-13 Thread Hayes, Graham

On 13/10/15 16:46, Fox, Kevin M wrote:
> lb's use the term pools too. A little more specific might be good.
> 
> Thanks,
> Kevin
> 
> *From:* Victoria Martínez de la Cruz [victo...@vmartinezdelacruz.com]
> *Sent:* Tuesday, October 13, 2015 5:28 AM
> *To:* Flavio Percoco; OpenStack Development Mailing List (not for usage
> questions)
> *Subject:* Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in
> nova flavor and zaqar flavor
> 
> Fair enough, +1 to Flavio's suggestion
> 
> Thanks all,
> 
> Victoria
> 
> 2015-10-13 3:35 GMT-03:00 Flavio Percoco  >:
> 
> On 12/10/15 19:25 -0300, Victoria Martínez de la Cruz wrote:
> 
> HI all,
> 
> Thanks for your feedback. We discussed this topic in this week
> weekly meeting
> and we came to the conclusion that it would be better to use
> "pool-flavor"
> instead of creating a namespace for Zaqar only (by prefixing
> everything with
> the "message" key).
> 
> So, this commands would look like
> 
> openstack pool-flavor create
> openstack pool-flavor get
> openstack pool-flavor delete
> openstack pool-flavor update
> openstack pool-flavor list
> 
> 
> First and foremost, I'm sorry for not attending the last meeting.
> 
> I just read the logs from the meeting and I'd like to raise my
> concerns with the above. I think it's very confusing for users to have
> a non-namespaced command.
> 
> For example, what's a pool-flavor? Is it related to Nova's flavors? Is
> it something related to some network pools? etc.
> 
> I understand that one of the concerns is that things like `openstack
> message message post` wouldn't look good but I think that the project
> namespace could match the service catalog (will let folks for OSC
> confirm/deny this).
> 
> Some examples:
> 
> $ openstack messaging post
> $ openstack messaging flavor create
> $ openstack messaging pool add
> 
> etc
> 
> Does the above make sense?
> Flavio
> 
> 
> 
> Best,
> 
> Victoria
> 
> 2015-10-10 10:10 GMT-03:00 Shifali Agrawal
>  >:
> 
>All right, thanks for responses, will code accordingly :)
> 
>On Wed, Oct 7, 2015 at 9:31 PM, Doug Hellmann
> >
>wrote:
> 
>Excerpts from Steve Martinelli's message of 2015-10-06
> 16:09:32 -0400:
>>
>> Using `message flavor` works for me, and having two
> words is just
>fine.
> 
>It might even be good to change "flavor" to "server
> flavor" (keeping
>flavor as a backwards-compatible alias, of course).
>  Doug
>  >
>> I'm in the process of collecting all of the existing
> "object" works
>are
>> putting them online, there's a lot of them. Hopefully
> this will
>reduce the
>> collisions in the future.
>>
>> Thanks,
>>
>> Steve Martinelli
>> OpenStack Keystone Core
>>
>>
>>
>> From:Shifali Agrawal  >
>> To:openstack-dev@lists.openstack.org
> 
>> Date:2015/10/06 03:40 PM
>> Subject:[openstack-dev]
> [Zaqar][cli][openstack-client] conflict
>in nova
>> flavor and zaqar flavor
>>
>>
>>
>> Greetings,
>>
>> I am implementing cli commands for Zaqar flavors, the
> command should
>be
>> like:
>>
>> "openstack flavor "
>>
>> But there is already same command present for Nova
> flavors. After
>> discussing with Zaqar devs we thought to change all
> zaqar commands
>such
>> that they include `message` word after openstack, thus
> above Zaqar
>flavor
>> command will become:
>>
>> "openstack message flavor "
>>
>> Does openstack-client devs have something to say for
> this? Or they
>also
>> feel its good to move with adding `message` word to all
> Zaqar

Re: [openstack-dev] Scheduler proposal

2015-10-13 Thread Ian Wells

On 12 October 2015 at 21:18, Clint Byrum  wrote:

> We _would_ keep a local cache of the information in the schedulers. The
> centralized copy of it is to free the schedulers from the complexity of
> having to keep track of it as state, rather than as a cache. We also don't
> have to provide a way for on-demand stat fetching to seed scheduler 0.
>

I'm not sure that actually changes.  On restart of a scheduler, it wouldn't
have enough knowledge to schedule, but the other schedulers are not and can
service requests while it waits for data.  Using ZK, that takes fewer
seconds because it can get a braindump, but during that window in either
case the system works at n-1/n capacity assuming queries are only done in
memory.

Also, you were seeming to tout the ZK option would take less memory, but it
seems it would take more.  You can't schedule without a relatively complete
set of information or some relatively intricate query language, which I
didn't think ZK was up to (but I'm open to correction there, certainly).
That implies that when you notify a scheduler of a change to the data
model, it's going to grab the fresh data and keep it locally.

> > Also, the notification path here is that the compute host notifies ZK and
> > ZK notifies many schedulers, assuming they're all capable of handling all
> > queries.  That is in fact N * (M+1) messages, which is slightly more than
> > if there's no central node, as it happens.  There are fewer *channels*,
> but
> > more messages.  (I feel like I'm overlooking something here, but I can't
> > pick out the flaw...)  Yes, RMQ will suck at this - but then let's talk
> > about better messaging rather than another DB type.
> >
>
> You're calling transactions messages, and that's not really fair to
> messaging or transactions. :)
>

I was actually talking about the number of messages crossing the network.
Your point is that the transaction with ZK is heavier weight than the
update processing at the schedulers, I think.  But then removing ZK as a
nexus removes that transaction, so both the number of messages and the
number of transactions goes down.

However, it's important to note that in
> this situation, compute nodes do not have to send anything anywhere if
> nothing has changed, which is very likely the case for "full" compute
> nodes, and certainly will save many many redundant messages.

Now that's a fair comment, certainly, and would drastically reduce the
number of messages in the system if we can keep the nodes from updating
just because their free memory has changed by a couple of pages.

> Forgive me
> if nova already makes this optimization somehow, it didn't seem to when
> I was tinkering a year ago.
>

Not as far as I know, it doesn't.

There is also the complexity of designing a scheduler which is fault
> tolerant and scales economically. What we have now will overtax the
> message bus and the database as the number of compute nodes increases.
> We want to get O(1) complexity out of that, but we're getting O(N)
> right now.
>

O(N) will work providing O is small. ;)

I think our cost currently lies in doing 1 MySQL DB update per node per
minute, and one really quite mad query per schedule.  I agree that ZK would
be less costly for that in both respects, which is really more about
lowering O than N.  I'm wondering if we can do better still, that's all,
but we both agree that this approach would work.
-- 
Ian.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Scheduler proposal


Clint Byrum wrote:

Excerpts from Ian Wells's message of 2015-10-13 09:24:42 -0700:

On 12 October 2015 at 21:18, Clint Byrum  wrote:


We _would_ keep a local cache of the information in the schedulers. The
centralized copy of it is to free the schedulers from the complexity of
having to keep track of it as state, rather than as a cache. We also don't
have to provide a way for on-demand stat fetching to seed scheduler 0.


I'm not sure that actually changes.  On restart of a scheduler, it wouldn't
have enough knowledge to schedule, but the other schedulers are not and can
service requests while it waits for data.  Using ZK, that takes fewer
seconds because it can get a braindump, but during that window in either
case the system works at n-1/n capacity assuming queries are only done in
memory.



Yeah, I'd put this as a 3 on the 1-10 scale of optimizations. Not a
reason to do it, but an assessment that it improves the efficiency of
starting new schedulers. It also has the benefit that if you do choose
to just run 1 scheduler, you can just start a new one and it will walk
the tree and start scheduling immediately thereafter.


Also, you were seeming to tout the ZK option would take less memory, but it
seems it would take more.  You can't schedule without a relatively complete
set of information or some relatively intricate query language, which I
didn't think ZK was up to (but I'm open to correction there, certainly).
That implies that when you notify a scheduler of a change to the data
model, it's going to grab the fresh data and keep it locally.



If I did that, I was being unclear and I'm sorry for that. I do think
the cache of potential scheduling targets and stats should fit in RAM
easily for even 100,000 nodes, including indexes for fast lookups.
The intermediary is entirely to alleviate the need for complicated sync
protocols to be implemented in the scheduler and compute agent. RAM is
cheap, time is not.


+1

Servers come with many tens/hundreds gigabytes of memory now-a-days, and 
if we locally cache with various levels of indexing (perhaps even using 
some other db-like library to help here) then I'd hope we can fit as 
many nodes as we desire.





Also, the notification path here is that the compute host notifies ZK and
ZK notifies many schedulers, assuming they're all capable of handling all
queries.  That is in fact N * (M+1) messages, which is slightly more than
if there's no central node, as it happens.  There are fewer *channels*,

but

more messages.  (I feel like I'm overlooking something here, but I can't
pick out the flaw...)  Yes, RMQ will suck at this - but then let's talk
about better messaging rather than another DB type.


You're calling transactions messages, and that's not really fair to
messaging or transactions. :)


I was actually talking about the number of messages crossing the network.
Your point is that the transaction with ZK is heavier weight than the
update processing at the schedulers, I think.  But then removing ZK as a
nexus removes that transaction, so both the number of messages and the
number of transactions goes down.



Point taken and agreed.


However, it's important to note that in

this situation, compute nodes do not have to send anything anywhere if
nothing has changed, which is very likely the case for "full" compute
nodes, and certainly will save many many redundant messages.


Now that's a fair comment, certainly, and would drastically reduce the
number of messages in the system if we can keep the nodes from updating
just because their free memory has changed by a couple of pages.



Indeed, an optimization like this is actually orthogonal to the management
of the corpus of state from all hosts. Hosts should in fact be able
to optimize for this already. Of course, then you lose the heartbeat..
which might be more valuable than the savings in communication load.


Forgive me
if nova already makes this optimization somehow, it didn't seem to when
I was tinkering a year ago.


Not as far as I know, it doesn't.

There is also the complexity of designing a scheduler which is fault

tolerant and scales economically. What we have now will overtax the
message bus and the database as the number of compute nodes increases.
We want to get O(1) complexity out of that, but we're getting O(N)
right now.


O(N) will work providing O is small. ;)

I think our cost currently lies in doing 1 MySQL DB update per node per
minute, and one really quite mad query per schedule.  I agree that ZK would
be less costly for that in both respects, which is really more about
lowering O than N.  I'm wondering if we can do better still, that's all,
but we both agree that this approach would work.


Right, I think it is worth an experiment if for no other reason than
MySQL can't really go much faster for this. We could move the mad query
out into RAM, but then we get the problem of how to keep a useful dataset
in RAM and we're back to syncing or polling the

Re: [openstack-dev] Scheduler proposal

On 2015-10-13 09:15:02 -0700 (-0700), Clint Byrum wrote:
> Excerpts from Jeremy Stanley's message of 2015-10-13 06:13:32 -0700:
[...]
> > it's not even within an order of magnitude of being 1k host
> > scale (and at that, it's still a multi-cycle plan just to reach
> > viability).
> 
> Infra-cloud currently has about 200 total real servers donated by
> HP.
[...]

I stand corrected--it _is_ within an order of magnitude of being 1k
host scale!

Anyway, my point was that to build and manage something similar for
scalability experiments would require a lot of extra hardware,
people and time to implement and manage.
-- 
Jeremy Stanley

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

[openstack-dev] [magnum] Networking Subteam Meeting Cancelations

2015-10-13 Thread Daneyon Hansen (danehans)

All,

I have a conflict this week and will be unable to chair the weekly irc meeting 
[1]. Therefore, we will not meet this week. 10/22 and 10/29 meetings will also 
be canceled due to the Mitaka Design Summit. We will resume are regularly 
scheduled meetings on 11/5.

[1] 
https://wiki.openstack.org/wiki/Meetings/Containers#Container_Networking_Subteam_Meeting

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

Re: [openstack-dev] Scheduler proposal

On 2015-10-13 10:17:26 -0700 (-0700), Joshua Harlow wrote:
[...]
> Interesting, doesn't the foundation have money? I was under the
> assumption it does (but I'm not a finance person); seeing that the
> membership fee to become a member afaik is not cheap, and there
> seems to be quite a-lot of members
> (https://www.openstack.org/foundation/companies/) one could
> speculate that resources (compute, lab clouds, people to help
> manager all of these) shouldn't really be a problem...

Yep, there is some money. I have no idea whether there is surplus
sufficient to sustain facilities and staff for a 1k-node service
provider with no customer revenue, but I have my doubts. On the
other hand it might be easier for data center space, hardware and
humans to be donated from 0.1% of 5 different 200k-node service
providers since they already have experience doing that at some
economy of scale (where the OpenStack Foundation does not).

> Anyway, perhaps this is for another conversation...

Indeed, and one better had with the OpenStack Foundation Board of
Directors rather than the developer community/Infra team.
-- 
Jeremy Stanley

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

Re: [openstack-dev] Requests + urllib3 + distro packages

Thomas Goirand wrote:

On 10/13/2015 12:44 AM, Joshua Harlow wrote:

Anvil gets somewhat far on this, although its not supporting DEBs it
does build its best attempt at RPMs building them automatically and
turning git repos of projects into RPMs.

http://anvil.readthedocs.org/en/latest/topics/summary.html (hopefully
the existence of this is not news to folks).

A log of this in action (very verbose) is at:

http://logs.openstack.org/40/225240/4/check/gate-anvil-rpms-dsvm-devstack-centos7/0eea2a9/console.html

Automation can only bring you so far. I also have automation which we
could use for debs (see the pkgos-debpypi script from the
openstack-pkg-tools package), however, there's always the need for
manual reviews. I don't believe it ever will be possible to do full
automation, as each Python package has specificities. Note that this is
mainly an issue with Python modules, if it was PHP pear packages, it
could be fully automated. So probably there's some PEP that we could
start to ease this. If only everyone was using testr, pbr, defining
copyright correctly and providing a parseable long and short
description, it wouldn't be such an issue.

Agreed, there will always be that damn 1% (ok its probably around 10%)
of weird pypi packages that will require hand-tuning, the hope (and I
think the reality) is that most actually don't require hand-tuning.

Maybe someday it will be down to 0% (one can hope).

Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] [tc] New project: rally-ci

2015-10-13 Thread Sergey Skripnick

Rally-CI is single daemon which listens gerrit events, run tests and
publish results.

It sounds much like zuul but it is not zuul. The primary goal of rally-ci
is simpleness. It does not any git merges, it have not any complex
pipeline logic. Just test every single CR and put +1 or -1.

First of all Rally-CI is simple way to get up and running Third Party CI.

To configure CI you don't need to mess with puppet, jenkins, gearman etc.
Just one single yaml file with some inline bash.

Here is full configuration example with one job "dsvm-rally-block-migrate"
[0]
This job runs two VMs, deploys multinode devstack, and start rally scenario
"boot-and-live-migrate". It will put +1 only if VM actually migrates from
one
compute to another.

Here is current config of Mirantis Rally CI [1], and realtime status [2]

This project was started six month ago as little script, but it still
growing [3]
I believe this project can help people to catch more problems on early
stage.
Also it may be interesting for people who want to practice with asyncio.

Little tutorial "How to run third party CI on a single node" [4]
Change request in openstack-infra/project-config [5]

[0]
https://github.com/redixin/rci-config/blob/master/sample-multinode-dsvm.yaml
[1] https://github.com/redixin/rci-config/blob/master/config.yaml
[2] http://185.8.56.87/
[3] https://blueprints.launchpad.net/rally-ci
[4] https://github.com/redixin/rally-ci/
[5] https://review.openstack.org/#/c/185365/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] New project: rally-ci

On 2015-10-13 20:20:43 +0300 (+0300), Sergey Skripnick wrote:
[...]
> It sounds much like zuul but it is not zuul. The primary goal of
> rally-ci is simpleness. [...] First of all Rally-CI is simple way
> to get up and running Third Party CI. [...] Little tutorial "How
> to run third party CI on a single node"
[...]

For those who haven't been following the puppet-openstackci effort,
note that https://review.openstack.org/200330 added turn-key support
for third-party CI on one machine with Zuul/Nodepool/JJB/Jenkins.
-- 
Jeremy Stanley

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

Re: [openstack-dev] Scheduler proposal

2015-10-13 Thread Clint Byrum

Excerpts from Jeremy Stanley's message of 2015-10-13 06:13:32 -0700:
> On 2015-10-12 20:49:44 -0700 (-0700), Joshua Harlow wrote:
> > Does the openstack foundation have access to a scaling area that
> > can be used by the community for this kind of experimental work?
> 
> The OpenStack Foundation has a staff of fewer than 20 full-time
> employees, with a primary focus on event planning and preserving the
> community's trademarks. If instead you mean the member companies who
> make up the OpenStack Foundation, then I agree with the other reply
> on the thread that it sounds like the effort already underway at
> Intel and Rackspace.
> 
> > It seems like infra or others should be able make that possible?
> [...]
> 
> The Infrastructure team is in the process of standing up a
> community-managed deployment of OpenStack, but it's not even within
> an order of magnitude of being 1k host scale (and at that, it's
> still a multi-cycle plan just to reach viability).

Infra-cloud currently has about 200 total real servers donated by HP.
The primary focus is on adding nodes for nodepool, so that we can
keep ahead of the milestone surges and general widening of the scope
of OpenStack. Doing it the same way infra does their other apps also
means that infra can fix this cloud when it isn't suited to their needs,
instead of having to work around public cloud quirks.

However, it was always a secondary goal of infra-cloud to provide a cloud
that is 100% visible to the entire community, including operators, so
that the community can collaborate on improving said cloud which should
drive quality.

We're currently going very slow, mostly because there are basically
3 people working about 5-30 percent of their time on it. As the needs
listed above grow, I imagine infra-cloud will rise in our priorities.

If a member company were to donate _more_ nodes in a single place so that
we could push the bounds of a single region/az/cell, that would be great,
but I don't think those could be capitalized on without a donation of
more staff to the infra team as well.

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

Re: [openstack-dev] Scheduler proposal

2015-10-13 Thread Clint Byrum

Excerpts from Ian Wells's message of 2015-10-13 09:24:42 -0700:
> On 12 October 2015 at 21:18, Clint Byrum  wrote:
> 
> > We _would_ keep a local cache of the information in the schedulers. The
> > centralized copy of it is to free the schedulers from the complexity of
> > having to keep track of it as state, rather than as a cache. We also don't
> > have to provide a way for on-demand stat fetching to seed scheduler 0.
> >
> 
> I'm not sure that actually changes.  On restart of a scheduler, it wouldn't
> have enough knowledge to schedule, but the other schedulers are not and can
> service requests while it waits for data.  Using ZK, that takes fewer
> seconds because it can get a braindump, but during that window in either
> case the system works at n-1/n capacity assuming queries are only done in
> memory.
> 

Yeah, I'd put this as a 3 on the 1-10 scale of optimizations. Not a
reason to do it, but an assessment that it improves the efficiency of
starting new schedulers. It also has the benefit that if you do choose
to just run 1 scheduler, you can just start a new one and it will walk
the tree and start scheduling immediately thereafter.

> Also, you were seeming to tout the ZK option would take less memory, but it
> seems it would take more.  You can't schedule without a relatively complete
> set of information or some relatively intricate query language, which I
> didn't think ZK was up to (but I'm open to correction there, certainly).
> That implies that when you notify a scheduler of a change to the data
> model, it's going to grab the fresh data and keep it locally.
> 

If I did that, I was being unclear and I'm sorry for that. I do think
the cache of potential scheduling targets and stats should fit in RAM
easily for even 100,000 nodes, including indexes for fast lookups.
The intermediary is entirely to alleviate the need for complicated sync
protocols to be implemented in the scheduler and compute agent. RAM is
cheap, time is not.

> > > Also, the notification path here is that the compute host notifies ZK and
> > > ZK notifies many schedulers, assuming they're all capable of handling all
> > > queries.  That is in fact N * (M+1) messages, which is slightly more than
> > > if there's no central node, as it happens.  There are fewer *channels*,
> > but
> > > more messages.  (I feel like I'm overlooking something here, but I can't
> > > pick out the flaw...)  Yes, RMQ will suck at this - but then let's talk
> > > about better messaging rather than another DB type.
> > >
> >
> > You're calling transactions messages, and that's not really fair to
> > messaging or transactions. :)
> >
> 
> I was actually talking about the number of messages crossing the network.
> Your point is that the transaction with ZK is heavier weight than the
> update processing at the schedulers, I think.  But then removing ZK as a
> nexus removes that transaction, so both the number of messages and the
> number of transactions goes down.
> 

Point taken and agreed.

> However, it's important to note that in
> > this situation, compute nodes do not have to send anything anywhere if
> > nothing has changed, which is very likely the case for "full" compute
> > nodes, and certainly will save many many redundant messages.
> 
> 
> Now that's a fair comment, certainly, and would drastically reduce the
> number of messages in the system if we can keep the nodes from updating
> just because their free memory has changed by a couple of pages.
> 

Indeed, an optimization like this is actually orthogonal to the management
of the corpus of state from all hosts. Hosts should in fact be able
to optimize for this already. Of course, then you lose the heartbeat..
which might be more valuable than the savings in communication load.

> > Forgive me
> > if nova already makes this optimization somehow, it didn't seem to when
> > I was tinkering a year ago.
> >
> 
> Not as far as I know, it doesn't.
> 
> There is also the complexity of designing a scheduler which is fault
> > tolerant and scales economically. What we have now will overtax the
> > message bus and the database as the number of compute nodes increases.
> > We want to get O(1) complexity out of that, but we're getting O(N)
> > right now.
> >
> 
> O(N) will work providing O is small. ;)
> 
> I think our cost currently lies in doing 1 MySQL DB update per node per
> minute, and one really quite mad query per schedule.  I agree that ZK would
> be less costly for that in both respects, which is really more about
> lowering O than N.  I'm wondering if we can do better still, that's all,
> but we both agree that this approach would work.

Right, I think it is worth an experiment if for no other reason than
MySQL can't really go much faster for this. We could move the mad query
out into RAM, but then we get the problem of how to keep a useful dataset
in RAM and we're back to syncing or polling the database hard.

[openstack-dev] [ironic] weekly subteam status report

2015-10-13 Thread Ruby Loo

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

- (diff with Oct 5, no diff for inspector)
- Open: 143 (+6). 2 new (-2), 36 in progress (+2), 0 critical, 12 high
(+5) and 10 incomplete (-3)
- Nova bugs with Ironic tag: 24 (-1). 1 new, 0 critical, 0 high
- Inspector bugs: 12. 0 new, 0 critical, 4 high
- liberty-rc-potential:
- https://bugs.launchpad.net/ironic/+bug/1502903


Neutron/Ironic work (jroll)

- This seems to be working end to end, reviews welcome
- Putting up a nova blueprint/spec this week and hacking on that part of it


ironic-lib adoption (dtantsur)
==
- patch is being worked on
- ironic-lib g-r patch still not merged:
https://review.openstack.org/#/c/231368/


Nova Liaisons (jlvillal & mrda)
===
Nothing to report. Did bug scrub as usual


Oslo (lintan)
=
- Ironic is missing a header X-Openstack-Request-Id in API response. In
order to track operations cross projects,  many services like
Nova/Glance/Neutron/Cinder/Keystone have a such request ID header with HTTP
responsed. Python-ironicclient also should save this header and return to
caller.  It sounds like a feature but file a bug for this at the moment:
https://bugs.launchpad.net/ironic/+bug/1505119
- can we actually file a blueprint (no spec) for this? Probably with a
link to the cross project spec // jroll
- Sure, add one blueprint:
https://blueprints.launchpad.net/ironic/+spec/add-x-openstack-request-id-header


Testing/Quality (jlvillal/lekha/krtaylor)

- jlvillal started investigating how Nova does their functional testing.
- Will start initial code work this week.
- Can we learn/help or is it not multiperson work?


Inspector (dtansur)
===
- etherpad for summit discussions:
https://etherpad.openstack.org/p/mitaka-ironic-inspector


webclient (krotscheck / betherly)
=
- work continuing on upstream ironic panel
- work continuing on ironic webclient also as longer term solution


Drivers
==

AMT (lintan)

- More comments and discussion are welcome for amt driver
https://etherpad.openstack.org/p/new-ironic-amt-driver


iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until next week,
--ruby

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

Re: [openstack-dev] Scheduler proposal


Clint Byrum wrote:

Excerpts from Jeremy Stanley's message of 2015-10-13 06:13:32 -0700:

On 2015-10-12 20:49:44 -0700 (-0700), Joshua Harlow wrote:

Does the openstack foundation have access to a scaling area that
can be used by the community for this kind of experimental work?

The OpenStack Foundation has a staff of fewer than 20 full-time
employees, with a primary focus on event planning and preserving the
community's trademarks. If instead you mean the member companies who
make up the OpenStack Foundation, then I agree with the other reply
on the thread that it sounds like the effort already underway at
Intel and Rackspace.


It seems like infra or others should be able make that possible?

[...]

The Infrastructure team is in the process of standing up a
community-managed deployment of OpenStack, but it's not even within
an order of magnitude of being 1k host scale (and at that, it's
still a multi-cycle plan just to reach viability).


Infra-cloud currently has about 200 total real servers donated by HP.
The primary focus is on adding nodes for nodepool, so that we can
keep ahead of the milestone surges and general widening of the scope
of OpenStack. Doing it the same way infra does their other apps also
means that infra can fix this cloud when it isn't suited to their needs,
instead of having to work around public cloud quirks.

However, it was always a secondary goal of infra-cloud to provide a cloud
that is 100% visible to the entire community, including operators, so
that the community can collaborate on improving said cloud which should
drive quality.

We're currently going very slow, mostly because there are basically
3 people working about 5-30 percent of their time on it. As the needs
listed above grow, I imagine infra-cloud will rise in our priorities.

If a member company were to donate _more_ nodes in a single place so that
we could push the bounds of a single region/az/cell, that would be great,
but I don't think those could be capitalized on without a donation of
more staff to the infra team as well.


Interesting, doesn't the foundation have money? I was under the 
assumption it does (but I'm not a finance person); seeing that the 
membership fee to become a member afaik is not cheap, and there seems to 
be quite a-lot of members 
(https://www.openstack.org/foundation/companies/) one could speculate 
that resources (compute, lab clouds, people to help manager all of 
these) shouldn't really be a problem...


Anyway, perhaps this is for another conversation...

-Josh



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


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

[openstack-dev] [Neutron] Do not merge until further notice

2015-10-13 Thread Armando M.

Hi folks,

We are in the last hours of Liberty, let's pause for a second and consider
merging patches only if absolutely necessary. The gate is getting clogged
and we need to give priority to potential RC3 fixes or gate stability fixes.

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

Re: [openstack-dev] getting rid of tablib completely (Requests + urllib3 + distro packages)

2015-10-13 Thread Dean Troyer

On Tue, Oct 13, 2015 at 10:14 AM, Doug Hellmann 
wrote:

> Now that we have a cliff with the formatters provided by tablib, we can
> update those dependencies to remove cliff-tablib. Someone just needs to
> follow through on that with patches to the requirements files for the
> clients.


For OpenStackClient: https://review.openstack.org/234406

dt

-- 

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

Re: [openstack-dev] [all][stable][release] 2015.1.2

2015-10-13 Thread Matt Riedemann




On 10/13/2015 1:57 PM, Chuck Short wrote:

Hi

Im just in the last stages of release 2015.1.2. I dont think anything is
stopping us from opening it up agian. The tabrlls have been created. So
go for it.

Chuck

On Tue, Oct 13, 2015 at 2:46 PM, Matt Riedemann
> wrote:



On 10/7/2015 7:42 PM, Chuck Short wrote:

Hi,
stable/kilo is now frozen. I expect to do a release on Tuesday.
If you
need to include something please let me know.

Thanks
chuck



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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Looks like the 2015.1.2 tag is up and now we need to bump the
version to 2015.1.3 in setup.cfg for the projects, I don't see a
series up for that yet but it's blocking anything from passing tests
on stable/kilo now.

--

Thanks,

Matt Riedemann


__

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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



I've started these:

https://review.openstack.org/#/q/Ic97696684c8545068597b4f1efd9d3eb19294d93,n,z

But I'm wondering what to do with trove and the neutron-*aas projects 
since they don't have a 2015.1.2 tag, do we still set their pre-version 
in setup.cfg to 2015.1.3? That seems odd to me, but it's what we did for 
2015.1.2.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [all][stable][release] 2015.1.2

2015-10-13 Thread Sean Dague

On 10/13/2015 02:57 PM, Chuck Short wrote:
> Hi
> 
> Im just in the last stages of release 2015.1.2. I dont think anything is
> stopping us from opening it up agian. The tabrlls have been created. So
> go for it.

Chuck,

I think that whoever sets the tag should also push those fixes. We had
some kilo content bogging down the gate today because of this kind of
failure. Better to time this as close as possible with the tag setting.

-Sean

-
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Fuel] Changes in bugs workflow on Launchpad

2015-10-13 Thread Mike Scherbakov

Dmitry,
I think that #1 is reasonable.
For #2, separate LP projects, I'd want to assess pros/cons before making a
decision. I see more cons at the moment. I've started adding it in the
etherpad, I'd appreciate if other folks would join and provide their input
there.

Thank you,

On Tue, Oct 13, 2015 at 11:34 AM Dmitry Pyzhov  wrote:

> Guys,
>
> I propose several changes in bugs workflow on Launchpad.
> 1) Let's stop using component based team groups as assignees for bugs
> 2) Let's create separate Launchpad projects for qa, docs and infra teams
>
> It will affect everyone who tracks any list of bugs. So I want to be sure
> that everyone can ask question or raise concern.
>
> Why do we need this? We are growing community. In 7.0 release we addressed
> 2153 bugs. This number is almost unmanageable. We have a lot of tags (99
> official and 219 other tags), a lot of Launchpad groups. We have several
> big teams with their own workflows. We have 1482 bugs in our current
> release. In order to understand if a bug in really a bug or some kind of
> support request one have to analyse its tags, assignee and teams of
> assignee. And there is a chance that the analysis will produce wrong result.
>
> I'm trying to make our bug management as clear as possible and produce as
> little extra everyday mouse clicking as possible. Here is list of required
> changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy
>
> Feel free to ask questions.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling


On 10/13/2015 12:57 PM, Emilien Macchi wrote:


On 10/08/2015 07:38 AM, Vladimir Kuklin wrote:
[...]

* Proposed solution

Introduce a library of exception handling methods which should be the
same for all puppet openstack providers as these exceptions seem to be
generic. Then, for each of the providers we can introduce
provider-specific libraries that will inherit from this one.

Our mos-puppet team could add this into their backlog and could work on
that in upstream or downstream and propose it upstream.

What do you think on that, puppet folks?

This is excellent feedback from how modules work in Fuel and I'm sure
you're not alone, everybody deploying OpenStack with Puppet is hitting
these issues.

You might want to refactor [1] and manage more use-cases.
If you plan to work on it, I would suggest to use our upstream backlog
[2] so we can involve the whole group in that work.

[1]
https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack.rb
[2] https://trello.com/b/4X3zxWRZ/on-going-effort


If the issue is that openstackclient output is hard to parse, we should 
tell openstackclient to output JSON - 
https://bugs.launchpad.net/puppet-openstacklib/+bug/1479387




Thanks for taking care of that,


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


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

[openstack-dev] [fuel] Component Leads elections

2015-10-13 Thread Dmitry Borodaenko

Fuelers,

Please remember that the open candidacy period for Fuel Component Leads
nominations is now open. It closes in two days, on October 15. [0]

[0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015

We already have one nomination for fuel-python lead [1], thank you Igor
for volunteering!

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-October/076763.html

We have no nominations for fuel-library lead. Library developers, please
don't be shy and self-nominate yourselves!

Thank you,

-- 
Dmitry Borodaenko

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

Re: [openstack-dev] [all][stable][release] 2015.1.2

2015-10-13 Thread Matthew Thode

On 10/13/2015 01:46 PM, Matt Riedemann wrote:
> 
> 
> On 10/7/2015 7:42 PM, Chuck Short wrote:
>> Hi,
>> stable/kilo is now frozen. I expect to do a release on Tuesday. If you
>> need to include something please let me know.
>>
>> Thanks
>> chuck
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> Looks like the 2015.1.2 tag is up and now we need to bump the version to
> 2015.1.3 in setup.cfg for the projects, I don't see a series up for that
> yet but it's blocking anything from passing tests on stable/kilo now.
> 
I've updated/released on Gentoo.

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

2015-10-13 Thread Dean Troyer

On Tue, Oct 13, 2015 at 10:33 AM, Rich Megginson 
wrote:

> I think if we did end up using a ruby library, we'd also want to make sure
> it was not only vendored, but also usable independently, to increase the
> audience.
>
>
> . . . and then are we also going to be gated by the distros in the same
> way, waiting for months to get an update to aviator?
>

Yes.  Check out the recent thread (again!) about urllib3 vendored inside
Python requests.  Distros will unvendor that for you and you will have
again the same problem in a different place.

Rich, the daemon/persistent mode has been low on my radar for a bit and I
think needs a bit of work to be fully usable the way I think you envision.
Let us know if that becomes a higher priority as we're currently focusing
on fleshing out the in-repo API support and modernizing our auth (switching
to keystoneauth1).

dt

-- 

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

Re: [openstack-dev] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

2015-10-13 Thread Eric Harney

On 10/13/2015 02:57 PM, Dmitry Guryanov wrote:
> Hello,
> 
> RemoteFS drivers combine 2 logical tasks. The first one is how to mount
> a filesystem and select proper share for a new or existing volume. The
> second one: how to deal with an image files in given directory (mount
> point) (create, delete, create snapshot e.t.c.).
> 
> The first part is different for each volume driver. The second - the
> same for all volume drivers, but it depends on selected volume format:
> you can create qcow2 file on NFS or smbfs with the same code.
> 
> Since there are several volume formats (raw, qcow2, vhd and possibly
> some others), I propose to move the code, which works with image to
> separate classes, 'VolumeFormat' handlers.
> 
> This change have 3 advantages:
> 
> 1. Duplicated code from remotefs driver will be removed.
> 2. All drivers will support all volume formats.
> 3. New volume formats could be added easily, including non-qcow2 snapshots.
> 
> Here is a draft version of a patch:
> https://review.openstack.org/#/c/234359/
> 
> Although there are problems in it, most of the operations with volumes
> work and there are only about 10 fails in tempest.
> 
> 
> I'd like to discuss this approach before further work on the patch.
> 

I've only taken a quick look, but, a few comments:

IMO it is not a good idea to work on extending support for volume
formats until we get further on having Cinder manage data in different
formats in a robust and secure manner [1]. We should fix that problem
before making it a worse problem.

Points 2 and 3 above aren't really that straightforward.  For example,
calling delete_snapshot_online only works if Nova/libvirt/etc. support
managing the format you are using.  This is fine for the current uses,
because qcow2 is well-supported.  Adding this to a driver using a
different/new file format will likely not work, so combining all of the
code is questionable, even if it seems more nicely organized.

Point #2 assumes that there's a reason that someone would want to use
currently unsupported combinations such as NFS + VHD or SMB + qcow2.
The specific file format being used is not terribly interesting other
than in the context of what a hypervisor supports, and we don't need
more not-so-well-tested combinations for people to deploy.  So why
enable this?

We've already gone somewhat in the other direction with [2], which
removed the ability to configure the GlusterFS driver to use qcow2
volumes, and instead just lets you choose if you want thick or thinly
provisioned volumes, leaving the format choice as an implementation
detail rather than a deployment choice.  (It still uses qcow2 behind the
scenes.)  I think that's the right direction.

[1] https://review.openstack.org/#/c/165393/
[2] https://review.openstack.org/#/c/164527/

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers


On 10/13/2015 01:49 PM, Dean Troyer wrote:
On Tue, Oct 13, 2015 at 10:33 AM, Rich Megginson > wrote:



I think if we did end up using a ruby library, we'd also want to
make sure it was not only vendored, but also usable
independently, to increase the audience.


. . . and then are we also going to be gated by the distros in the
same way, waiting for months to get an update to aviator?


Yes.  Check out the recent thread (again!) about urllib3 vendored 
inside Python requests.  Distros will unvendor that for you and you 
will have again the same problem in a different place.


Rich, the daemon/persistent mode has been low on my radar for a bit 
and I think needs a bit of work to be fully usable the way I think you 
envision.  Let us know if that becomes a higher priority as we're 
currently focusing on fleshing out the in-repo API support and 
modernizing our auth (switching to keystoneauth1).


Ok.  It's unclear right now when/if this will be needed by puppet.



dt

--

Dean Troyer
dtro...@gmail.com 


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


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

[openstack-dev] [puppet] Proposing Denis Egorenko core

Denis Egorenko (degorenko) is working on Puppet OpenStack modules for
quite some time now.

Some statistics [1] about his contributions (last 6 months):
* 270 reviews
* 49 negative reviews
* 216 positive reviews
* 36 disagreements
* 30 commits

Beside stats, Denis is always here on IRC participating to meetings,
helping our group discussions, and is always helpful with our community.

I honestly think Denis is on the right path to become a good core member
team, he has strong knowledge in OpenStack deployments, knows enough
about our coding style and his involvement in the project is really
great. He's also a huge consumer of our modules since he's working on Fuel.

I would like to open the vote to promote Denis part of Puppet OpenStack
core reviewers.

[1] http://stackalytics.com/report/contribution/puppetopenstack-group/180
-- 
Emilien Macchi



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

Re: [openstack-dev] [puppet] weekly meeting #55



On 10/12/2015 10:36 AM, Emilien Macchi wrote:
> Hello!
> 
> Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
> in #openstack-meeting-4:
> 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013
> 
> Feel free to add any items you'd like to discuss.
> If our schedule allows it, we'll make bug triage during the meeting.

We did our meeting, you can read the notes:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-13-15.00.html
-- 
Emilien Macchi



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

Re: [openstack-dev] Scheduler proposal

2015-10-13 Thread Clint Byrum

Excerpts from Dulko, Michal's message of 2015-10-13 03:49:44 -0700:
> On Mon, 2015-10-12 at 10:13 -0700, Clint Byrum wrote:
> > Zookeeper sits in a very different space from Cassandra. I have had good
> > success with it on OpenJDK as well.
> > 
> > That said, we need to maybe go through some feature/risk matrices and
> > compare to etcd and Consul (this might be good to do as part of filling
> > out the DLM spec). The jvm issues goes away with both of those, but then
> > we get to deal Go issues.
> > 
> > Also, ZK has one other advantage over those: It is already in Debian and
> > Ubuntu, making access for developers much easier.
> 
> What about RHEL/CentOS? Maybe I'm mistaken, but I think these two
> doesn't have it packaged.

I don't know about RHEL/CentOS, but Fedora packages Zookeeper:

https://apps.fedoraproject.org/packages/zookeeper/sources

Seems like that can be spun into RHEL/CentOS relatively easily, perhaps
through EPEL?

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

Re: [openstack-dev] [neutron-LBaaS] Can anyone help to share a procedure to install lbaas on Kilo?

2015-10-13 Thread Kobi Samoray

Ah, in that case try this:
https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun

On Oct 13, 2015, at 15:05, WANG, Ming Hao (Tony T) 
> wrote:

Kobi,

Thanks for your info very much!
Is there any document to install lbaas manually?
My environment is installed manually instead by devstack or packstack.

Thanks,
Tony

From: Kobi Samoray [mailto:ksamo...@vmware.com]
Sent: Tuesday, October 13, 2015 7:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron-LBaaS] Can anyone help to share a 
procedure to install lbaas on Kilo?

Hi Tony,
Try the following:
https://chapter60.wordpress.com/2015/02/20/installing-openstack-lbaas-version-2-on-kilo-using-devstack/

On Oct 13, 2015, at 14:11, WANG, Ming Hao (Tony T) 
> wrote:

I installed an OpenStack environment manually, and I can’t use devstack or 
packstack to install neutron lbaas.
Can anyone help to share a procedure to install lbaas on Kilo? I can’t find one 
from Google. ☹

Thanks in advance,
Tony

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

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

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

Re: [openstack-dev] [fuel] Nominate Svetlana Karslioglu for fuel-docs core

2015-10-13 Thread Svetlana Karslioglu

Thank you, Olga!

On Tue, Oct 13, 2015 at 1:58 AM, Olga Gusarenko 
wrote:

> More than 5 days passed, and no objections.
> Congratulations, Svetlana, and welcome on board =) !
>
> On Fri, Oct 9, 2015 at 9:44 AM, Olga Gusarenko 
> wrote:
>
>> +1
>> Svetlana, thank you for your contribution, and looking forward to working
>> with you on the Fuel documentation improvement!
>>
>> Best,
>> Olga
>>
>> On Thu, Oct 8, 2015 at 11:13 AM, Alexander Adamov 
>> wrote:
>>
>>> +1 to Svetlana's nomination.
>>>
>>> On Tue, Sep 29, 2015 at 4:58 AM, Dmitry Borodaenko <
>>> dborodae...@mirantis.com> wrote:
>>>
 I'd like to nominate Svetlana Karslioglu as a core reviewer for the
 fuel-docs-core team. During the last few months, Svetlana restructured
 the Fuel QuickStart Guide, fixed a few documentation bugs for Fuel 7.0,
 and improved the quality of the Fuel documentation through reviews.

 I believe it's time to grant her core reviewer rights in the fuel-docs
 repository.

 Svetlana's contribution to fuel-docs:

 http://stackalytics.com/?user_id=skarslioglu=all_type=all=fuel-docs

 Core reviewer approval process definition:
 https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

 --
 Dmitry Borodaenko


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

>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Olga
>>
>> Technical Writer
>> skype: gusarenko.olga
>>
>>
>
>
> --
> Best regards,
> Olga
>
> Technical Writer
> skype: gusarenko.olga
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Svetlana Karslioglu
Sr. Technical Writer
Mirantis, Inc.
408-476-1692
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling



On 10/08/2015 07:38 AM, Vladimir Kuklin wrote:
[...]
> * Proposed solution
> 
> Introduce a library of exception handling methods which should be the
> same for all puppet openstack providers as these exceptions seem to be
> generic. Then, for each of the providers we can introduce
> provider-specific libraries that will inherit from this one.
> 
> Our mos-puppet team could add this into their backlog and could work on
> that in upstream or downstream and propose it upstream.
> 
> What do you think on that, puppet folks?

This is excellent feedback from how modules work in Fuel and I'm sure
you're not alone, everybody deploying OpenStack with Puppet is hitting
these issues.

You might want to refactor [1] and manage more use-cases.
If you plan to work on it, I would suggest to use our upstream backlog
[2] so we can involve the whole group in that work.

[1]
https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack.rb
[2] https://trello.com/b/4X3zxWRZ/on-going-effort

Thanks for taking care of that,
-- 
Emilien Macchi



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

[openstack-dev] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

2015-10-13 Thread Dmitry Guryanov


Hello,

RemoteFS drivers combine 2 logical tasks. The first one is how to mount 
a filesystem and select proper share for a new or existing volume. The 
second one: how to deal with an image files in given directory (mount 
point) (create, delete, create snapshot e.t.c.).


The first part is different for each volume driver. The second - the 
same for all volume drivers, but it depends on selected volume format: 
you can create qcow2 file on NFS or smbfs with the same code.


Since there are several volume formats (raw, qcow2, vhd and possibly 
some others), I propose to move the code, which works with image to 
separate classes, 'VolumeFormat' handlers.


This change have 3 advantages:

1. Duplicated code from remotefs driver will be removed.
2. All drivers will support all volume formats.
3. New volume formats could be added easily, including non-qcow2 snapshots.

Here is a draft version of a patch:
https://review.openstack.org/#/c/234359/

Although there are problems in it, most of the operations with volumes 
work and there are only about 10 fails in tempest.



I'd like to discuss this approach before further work on the patch.


--
Dmitry Guryanov

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

Re: [openstack-dev] [all][stable][release] 2015.1.2

2015-10-13 Thread Chuck Short

Hi

Im just in the last stages of release 2015.1.2. I dont think anything is
stopping us from opening it up agian. The tabrlls have been created. So go
for it.

Chuck

On Tue, Oct 13, 2015 at 2:46 PM, Matt Riedemann 
wrote:

>
>
> On 10/7/2015 7:42 PM, Chuck Short wrote:
>
>> Hi,
>> stable/kilo is now frozen. I expect to do a release on Tuesday. If you
>> need to include something please let me know.
>>
>> Thanks
>> chuck
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> Looks like the 2015.1.2 tag is up and now we need to bump the version to
> 2015.1.3 in setup.cfg for the projects, I don't see a series up for that
> yet but it's blocking anything from passing tests on stable/kilo now.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

2015-10-13 Thread D'Angelo, Scott

If you create a blueprint and a spec for this, the details can be discussed in 
the spec.

-Original Message-
From: Dmitry Guryanov [mailto:dgurya...@virtuozzo.com] 
Sent: Tuesday, October 13, 2015 12:57 PM
To: OpenStack Development Mailing List; Maxim Nestratov
Subject: [openstack-dev] [cinder] RemoteFS drivers refactoring: move code, 
which works with images to separate classes

Hello,

RemoteFS drivers combine 2 logical tasks. The first one is how to mount a 
filesystem and select proper share for a new or existing volume. The second 
one: how to deal with an image files in given directory (mount
point) (create, delete, create snapshot e.t.c.).

The first part is different for each volume driver. The second - the same for 
all volume drivers, but it depends on selected volume format: 
you can create qcow2 file on NFS or smbfs with the same code.

Since there are several volume formats (raw, qcow2, vhd and possibly some 
others), I propose to move the code, which works with image to separate 
classes, 'VolumeFormat' handlers.

This change have 3 advantages:

1. Duplicated code from remotefs driver will be removed.
2. All drivers will support all volume formats.
3. New volume formats could be added easily, including non-qcow2 snapshots.

Here is a draft version of a patch:
https://review.openstack.org/#/c/234359/

Although there are problems in it, most of the operations with volumes work and 
there are only about 10 fails in tempest.

I'd like to discuss this approach before further work on the patch.

--
Dmitry Guryanov

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

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

[openstack-dev] [Fuel] Changes in bugs workflow on Launchpad

2015-10-13 Thread Dmitry Pyzhov

Guys,

I propose several changes in bugs workflow on Launchpad.
1) Let's stop using component based team groups as assignees for bugs
2) Let's create separate Launchpad projects for qa, docs and infra teams

It will affect everyone who tracks any list of bugs. So I want to be sure
that everyone can ask question or raise concern.

Why do we need this? We are growing community. In 7.0 release we addressed
2153 bugs. This number is almost unmanageable. We have a lot of tags (99
official and 219 other tags), a lot of Launchpad groups. We have several
big teams with their own workflows. We have 1482 bugs in our current
release. In order to understand if a bug in really a bug or some kind of
support request one have to analyse its tags, assignee and teams of
assignee. And there is a chance that the analysis will produce wrong result.

I'm trying to make our bug management as clear as possible and produce as
little extra everyday mouse clicking as possible. Here is list of required
changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy

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

Re: [openstack-dev] [all][stable][release] 2015.1.2

2015-10-13 Thread Matt Riedemann




On 10/7/2015 7:42 PM, Chuck Short wrote:

Hi,
stable/kilo is now frozen. I expect to do a release on Tuesday. If you
need to include something please let me know.

Thanks
chuck


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



Looks like the 2015.1.2 tag is up and now we need to bump the version to 
2015.1.3 in setup.cfg for the projects, I don't see a series up for that 
yet but it's blocking anything from passing tests on stable/kilo now.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [openstack-ansible][security] All STIGs proposed -- time for reviews!

2015-10-13 Thread Major Hayden

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello there,

Thanks again to everyone who is helping to make openstack-ansible-security 
better!  Various members of the openstack-ansible team, the security team, and 
other OpenStack contributors have been providing help with reviews and reaching 
out to me via email and IRC.

As of today, all of the Ansible tasks and documentation for 
openstack-ansible-security have been proposed[1].  I'm working to fix up a few 
problems with AIDE and organize the documentation a bit better.

If anyone would like to join in the review process, many of these reviews are 
fairly simple as they contain an Ansible task or two, and small bits of 
documentation.  Here's what I'm really looking for in the reviews:

1) Does the Ansible task(s) and/or exception documentation cover the STIG's 
requirements?
2) Is the commit good quality? (Proper Ansible YAML and quality documentation)
3) Is there a better implementation than the one that is proposed?
4) Should certain changes be opt-in or opt-out that aren't current configured 
that way?

Thanks again for all of the help.  Feel free to reach out to me anytime with 
any questions. :)

[1] 
https://review.openstack.org/#/q/status:open+project:openstack/openstack-ansible-security,n,z

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWHVIrAAoJEHNwUeDBAR+xFsEQAIs+UTOGLwdHQKk90Xn2zyg9
4+7UQCmWjHZG3NQb+ydlenhkAVWiPYsKqcmldEVzZu+BGAbdkhIbn777SoCcMqRD
DWv1NjJuIHcAzkf4pgjQ+MCa3CbV/tQLuEhYcge+72pORVijv3b9NE3vLcDLx6FW
MywatnpVG6g1/TGrcsAMjKJy3/4E5eB7eZuw6IF2tvFVJvyxmFd/1b2ULDOADrhp
pjYritmWsLLBsRgD6pqOEbxl4pZVTepWPIbksIkCGC8UJfSqZ6RKR01+q5/WiVBD
w+p15+A81/Ruj7WfUw3VkFpWlFE0PvnLA8LljBUYLTUnmY3agBM2ljjmGVkmbXg9
HIXqJGZlAqewUWBNxLFB+5IhasYHHYhCUhNoxIVVdvqocIMssRFUrQtoFLrN8XVf
+BCCjQ+JRLFRl2yP230PjDAlVZ096HWeSALaXSvOIJIp1gTO23OPIun2EQoop3qe
GpG+NHQdxZAsBz18Ckx9ozq66tRxjh0F3gkwZWx3rOwORnOLERNsbZiDHI4wmC+z
m5tVXjpjkK5n6qGdx4TwDSc8G7k8pbOGNEfI3BBPAfvrUJCOeFWckDIUSRkbstgs
Fdls+pS1ud5Z/KIQOOJffzDCh97uZ2Y8RAJbIbPsBaT8MtfzZa5BIRv/es3YAsxB
bBNPwI69xtr1bqH7eDTY
=wiCK
-END PGP SIGNATURE-

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

Re: [openstack-dev] [puppet] WARNING - breaking backwards compatibility in puppet-keystone