Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Matthias Runge
On 12/11/14 08:40, Richard Jones wrote:

 
 I believe the nodeenv method of installing node solves this, as it's
 entirely local to the development environment.

See below, this touches package build as well.
 
 
 I will have to go through all dependencies and do a review, if those are
 acceptable for inclusion e.g in Fedora. The same is true for Thomas
 Goirand for inclusion in Debian.
 
 
  Petr Belanyi has added optional jshint install for js linting into
  Horizon and it installs nodejs as it depends on it. Could this approach
  work for our need of js tooling too? [1]
 
 Sigh, this nonsense doesn't go away? This is the third time the same
 issue comes up.
 
 jshint is NOT free software.
 
 https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 
 
 
 They're trying to resolve that https://github.com/jshint/jshint/issues/1234
 
 But regardless, jshint doesn't have to be installed from a Linux
 repository; it's usually installed using npm alongside the other node tools.
 
Thanks for the pointer, this is good news!

Regarding package managers, my POV is completely different. From a
distributor perspective, where customers expect everything provided from
a single source, I'm not using npm, pip etc. I'm packaging that stuff
properly before using it.

There are companies out there, where security policy does not allow to
install software from a third party repository. pypi etc. are considered
as a third party here in this context.

I would prefer to have the complete tool chain available as (RPM)
packages. I am executing unit tests etc. during package build. Our
builders don't have access to the internet, downloading any other stuff
from the internet is no option.

Matthias





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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Matthias Runge
On 11/11/14 08:02, Richard Jones wrote:

 There were some discussions around tooling. We're using xstatic to
 manage 3rd party components, but there's a lot missing from that
 environment. I hesitate to add supporting xstatic components on to the
 already large pile of work we have to do, so would recommend we switch
 to managing those components with bower instead. For reference the list
 of 3rd party components I used in angboard* (which is really only a
 teensy fraction of the total application we'd end up with, so this
 components list is probably reduced):
 
 json3
 es5-shim
 angular
 angular-route
 angular-cookies
 angular-animate
 angular-sanitize
 angular-smart-table
 angular-local-storage
 angular-bootstrap
 angular-translate
 font-awesome
 boot
 underscore
 ng-websocket
 
 Just looking at PyPI, it looks like only a few of those are in xstatic,
 and those are out of date.

Richard,

thank you for writing this up!

bower is (not yet) available e.g in Fedora, Debian, Ubuntu.

I'm quite a bit skeptical why the need for 3 additional package managers
(npm, grunt, bower) for simply installing javascript files.

Looking at es5-shim, it pulls in additional 28 dependent packages, json3
has 12 dependencies (including a circular dependency, one circular
depencency in dependencies),

Not counting dependencies in dependent packages, I can only suspect,
this will bring us at least 100 new packages required.

Once this is finalized, we'll need people to walk through all deps and
put packages up for review, to have those available when kilo is ready.

Matthias


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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Matthias Runge
On 12/11/14 09:28, Matthias Runge wrote:

 
 Looking at es5-shim, it pulls in additional 28 dependent packages, json3
 has 12 dependencies (including a circular dependency, one circular
 depencency in dependencies),
Please scratch that. I'll need to look at that a bit deeper (after
another coffee)

Matthias


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


Re: [openstack-dev] questions on result of diagnostics on libvirt

2014-11-12 Thread Sahid Orentino Ferdjaoui
On Tue, Nov 11, 2014 at 01:59:12PM +0800, Chen CH Ji wrote:
 
 see the error value of diagnostics is huge , but I don't think my disk is
 that bad ... is this wrong info or wrong usage of libvirt?
 Also, all the disk has same error number curious me , any guide ?

Considering you are using libvirt/KVM, libvirt asks qemu to get
information about block stats.

You can begin by executing the command from libvirt and compare the
result.

  virsh domstats domain

If results are equivalent we can probably avoid that the problem comes
from Nova.

Also you could connect yourself to the VM or using libguestfs to
execute some commands and get information about errors.

s.

 jichen@cloudcontroller:/opt/stack/nova/nova$ nova diagnostics jieph1
 +---+--+
 | Property  | Value|
 +---+--+
 | cpu0_time | 1071000  |
 | hdd_errors| 18446744073709551615 |
 ...
 | tapf1ce9c02-01_tx_packets | 24   |
 | vda_errors| 18446744073709551615 |
 | vda_read  | 2848768  |
 | vda_read_req  | 453  |
 | vda_write | 348160   |
 | vda_write_req | 105  |
 | vdb_errors| 18446744073709551615 |
 | vdb_read  | 829440   |
 | vdb_read_req  | 30   |
 | vdb_write | 4096 |
 
 Best Regards!
 
 Kevin (Chen) Ji 纪 晨
 
 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
 Beijing 100193, PRC

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


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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Martin Geisler
Richard Jones r1chardj0...@gmail.com writes:

 On 12 November 2014 18:17, Matthias Runge mru...@redhat.com wrote:

 Sigh, this nonsense doesn't go away? This is the third time the same
 issue comes up.

 jshint is NOT free software.

 https://github.com/jshint/jshint/blob/master/src/jshint.js#L19


 They're trying to resolve that https://github.com/jshint/jshint/issues/1234

I've switched to ESLint for my own projects:

  http://eslint.org/

I find it to be better documented and easier to extend than JSHint. Plus
it has had a sane license from the beginning :)

-- 
Martin Geisler

http://google.com/+MartinGeisler


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


Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

2014-11-12 Thread Anita Kuno
On 11/12/2014 08:04 AM, marios wrote:
 On 12/11/14 04:17, Clint Byrum wrote:
 Just as a counter-point: The entire reason that a mid-cycle is an
 important thing to do is to achieve higher bandwidth communication between
 contributors. We can do Hangouts all the time and that's certainly a
 useful thing. But making the people in the room who have high bandwidth
 slow down for those who are at the other end of low-bandwidth may not be
 a productive thing as a whole.

 Anyway, just a thought as somebody who has tried this before.
 
 I understand but I am definitely not saying the room should slow down
 for someone on hangout - heck I'd be ecstatic if microphones are even
 used). In my experience this can work best if it is understood that
 remotees have a read-only feed into the room audio (best case + video of
 slides) - it makes the world of difference compared to say just staring
 at the etherpad being updated.  I don't see this as having a high cost
 to setup (just point a laptop at the speaker, end),
 
 If you are a remotee and need read/write into the meeeting then you
 should prepare beforehand and have stuff written down to share. It is
 only common courtesy, and I absolutely agree it would be in the very
 least inconsiderate to expect the room to stop/slow down to allow any
 kind of conversation to happen over hangout. In fact, just click the
 on-air button and that way you get a youtube link to share, which
 obviously *is* read-only (r/w participation is limited @ 10 afaik),
 
 my 2c, thanks, marios
You seem to have put quite a bit of thought into this marios, why can't
you attend? If the reason is purely financial, please approach Kyle in
private and I will contact him as well to see if we can access some
finances for folks committed to working on the technical debt for
neutron that need financial assistance.

Having you there is far more productive than not.

Thank you,
Anita.
 
 

 Excerpts from Marios Andreou's message of 2014-11-11 08:56:05 -0800:
 +1 would be great to at least have a hangout going



 _sent from my mobile device, sorry for spacing/spelling/top-posting/.*_

 -Original Message-
 From: Kyle Mestery [mest...@mestery.com]
 Received: Tuesday, 11 Nov 2014, 16:14
 To: OpenStack Development Mailing List (not for usage questions) 
 [openstack-dev@lists.openstack.org]
 Subject: Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

 On Tue, Nov 11, 2014 at 8:00 AM, Gary Kotton gkot...@vmware.com wrote:
 Hi,
 For those unable to attend will there be an option of remote access?
 Thanks
 Gary

 We'll do our best to make this happen. I'll see if we can get a Google
 Hangout going in the room, and make sure people are on IRC.

 Thanks!
 Kyle

 On 11/11/14, 3:04 PM, Kyle Mestery mest...@mestery.com wrote:

 Hi folks:

 Apologies for the delay in announcing the Neutron mid-cycle, but I was
 confirming the details up until last night. I've captured the details
 on an etherpad here [1]. The dates are December 8-10
 (Monday-Wednesday), and it will be at the Adobe offices in Lehi, Utah,
 USA.

 We're still collecting information on hotels which should be on the
 etherpad later today.

 Thanks, looking forward to seeing everyone I missed in Paris!
 Kyle

 [1] https://etherpad.openstack.org/p/neutron-kilo-midcycle

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


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

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

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

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


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


[openstack-dev] [Fuel] Current development focus

2014-11-12 Thread Mike Scherbakov
Folks,
as we all getting hurry with features landing before Feature Freeze
deadline, we destabilize master. Right after FF, we must be focused on
stability, and bug squashing.
Now we are approaching Soft Code Freeze [1], which is planned for Nov 13th.
Master is still not very stable, and we are getting intermittent build
failures.

Let's focus on bug squashing, and in a first order, critical bugs which are
known to be causing BVT tests failures. Please postpone, if possible, other
action items, such as researches for new features, before we are known to
be in good shape with release candidates.

[1] https://wiki.openstack.org/wiki/Fuel/6.0_Release_Schedule

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


Re: [openstack-dev] [Neutron] Translation technical debt

2014-11-12 Thread Irena Berezovsky
Count me in

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, November 11, 2014 3:47 PM
To: OpenStack List
Subject: [openstack-dev] [Neutron] Translation technical debt

Hi,
In order to enforce our translation policies - 
http://docs.openstack.org/developer/oslo.i18n/guidelines.html - we have added a 
hacking rule in Neutron. If you wish to jump aboard this effort then please let 
me know. There are patches for all directories except the plugins and services.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Maxime Vidori
Hello all,

I will write here some things I have noticed in the mailing list and on which I 
can contribute.

Npm and Bower: 
bower and npm are here for two separate things, the first one is here to handle 
the dependencies of the webapp (angular, es5shim, d3.js and so on), meanwhile 
npm is here to handle the development environment (karma, grunt, jasmine, 
etc...). There is a possibility to avoid the use of bower by using npm alone, 
but I never tested that so a POC can be required.

Grunt vs Gulp:
Both are equivalent but I have a preference for the second one. It is more 
powerful than grunt, more customizable, easier to understand for new comers. 
All the plugins for an angular development exists and are quite stable. Last 
but not least the angular team is now pushing to replace its infra from grunt 
to gulp. But like I said both are equivalent and can be switched easily, so if 
you are more comfortable with grunt it is not a big deal.

Tastipy vs Djangular:
Like it has already been said we will use a restful API to handle the client 
server exchanges, so Tastipy seems to be preferable over Djangular.

Jasmine vs Mocha + Chai:
I am not really aware of Mocha + Chai features, but I have already used Jasmine 
for all my angular testing and it feeds all my needs, please use the version 
2.0 of it for its powerful features on asynchronous testing and the clean 
handle of variables in the testings. Last it is only one library which already 
have plugins for the karma test runner.

I do not know if I addressed all the questions but here is a starting.

Cheers 

Max


- Original Message -
From: Matthias Runge mru...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, November 12, 2014 9:39:29 AM
Subject: Re: [openstack-dev] [Horizon] the future of angularjs development in 
Horizon

On 12/11/14 09:28, Matthias Runge wrote:

 
 Looking at es5-shim, it pulls in additional 28 dependent packages, json3
 has 12 dependencies (including a circular dependency, one circular
 depencency in dependencies),
Please scratch that. I'll need to look at that a bit deeper (after
another coffee)

Matthias


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

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Martin Geisler
Richard Jones r1chardj0...@gmail.com writes:

 Hi all,

 At the summit last week, we developed a plan for moving forward with
 modernising Horizon's UI using AngularJS. If you weren't at that meeting
 and are interested in helping out with this effort please let me know!

I have been working on an interface for Swift written in Angular. You'll
find a ready-to-deploy tarball and zip file here:

  https://github.com/zerovm/swift-browser/releases/

This will eventually be an interface for starting ZeroVM instances on a
Swift cluster, but for now it's a pure Swift interface.

I don't know if this is something that can be used in Horizon, but maybe
there are useful bits.

One thing interesting thing in Swift Browser is its testing: I wrote a
Swift simulator that is injected into the application for end-to-end
testing with Protractor. Is is basically an in-memory (and in-browser)
Swift that responds to queries made against the Swift REST API. I've
found that very useful in the development:

  
https://github.com/zerovm/swift-browser/blob/master/app/js/test/swift-simulator.js

I don't know the other OpenStack components and their APIs very well,
but I guess that this kind of mocking might be too much for a full
OpenStack dashboard.

-- 
Martin Geisler

http://google.com/+MartinGeisler


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


Re: [openstack-dev] [Nova][Cells] Cells subgroup and meeting times

2014-11-12 Thread Belmiro Moreira
Fine for me.


On Wed, Nov 12, 2014 at 8:51 AM, Sylvain Bauza sba...@redhat.com wrote:


 Le 11/11/2014 23:07, Matt Riedemann a écrit :



 On 11/11/2014 3:51 PM, Matt Riedemann wrote:



 On 11/11/2014 3:50 PM, Matt Riedemann wrote:



 On 11/11/2014 3:04 PM, Andrew Laski wrote:

 We had a great discussion on cells at the summit which is captured at
 https://etherpad.openstack.org/p/kilo-nova-cells.  One of the tasks we
 agreed upon there was to form a subgroup to co-ordinate this effort and
 report progress to the Nova meeting regularly.  To that end I would
 like
 to find a meeting time, or more likely alternating times, that will
 work
 for interested parties.

 I am proposing Wednesday as the meeting day since it's more open than
 Tues/Thurs so finding a meeting room at almost any time should be
 feasible.  My opening bid is alternating between 1700 and 2200 UTC.
 That
 should provide options that aren't too early or too late for most
 people.  Is this fine for everyone or should it be adjusted a bit?


 Fine by me. I should be able to attend at least those at 1700 UTC.

 -Sylvain



  A meeting room will be picked once we're settled on times.  And I'm not
 planning on a meeting this week since we haven't picked times yet and I
 haven't had time to put together specs yet and I would like to start
 with a discussion on those.

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


 Not office hours for me and I've got mini-me to pickup at 1700 every
 day, but barring that it seems like an OK time.  Plus I'm planning on
 mostly working on (1) giving review priority and (2) QA (Tempest)
 changes, which can probably be worked separately from a meeting as long
 as I can get the minutes.


 I guess I should say that 2200 is definitely doable for me, mini-me is
 in bed by then (or so help me...).


 Nevermind, I failed clocks in 2nd grade, these times are perfect for me.
 :)



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

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


Re: [openstack-dev] [Keystyone] Mid-Cycle Meetup Planning

2014-11-12 Thread Henry Nash
I'll be there!

Henry
On 12 Nov 2014, at 02:29, Adam Young ayo...@redhat.com wrote:

 On 11/11/2014 08:18 PM, Morgan Fainberg wrote:
 I am trying to pin down a location for our mid-cycle meetup, I need to get 
 an idea of who will be joining us at the Keystone meetup. I’ve included a 
 couple questions relating to Barbican in the case we can double-up and have 
 a day of overlap like the Juno meetup. I apologize for the delay, this 
 should have been sent out by the end of the summit or earlier. As details 
 are available I’ll provide updates.
 
 Due to timing (so that people can get visas, get travel approval, etc as 
 soon as possible), I will be making a final call on dates by the end of this 
 week and location as soon as the space is confirmed, so your prompt 
 responses are super important!
 
 http://goo.gl/forms/4W7xVM9x49
 
 Cheers,
 Morgan
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 I plan on attending.  If it is in Sunnvale, Nate Kinder from Red Hat  will be 
 able to attend as well.  Its a bit of a schlep for Jamie but I know he wants 
 to attend.  
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Maxime Vidori
Thanks Martin, I remember that eslint was mentioned at some point to replace 
jshint. Maybe, it can be interesting to look at this, the extension possibility 
is a major point for a switch.

- Original Message -
From: Martin Geisler mar...@geisler.net
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Wednesday, November 12, 2014 10:37:15 AM
Subject: Re: [openstack-dev] [Horizon] the future of angularjs development  
in Horizon

Richard Jones r1chardj0...@gmail.com writes:

 Hi all,

 At the summit last week, we developed a plan for moving forward with
 modernising Horizon's UI using AngularJS. If you weren't at that meeting
 and are interested in helping out with this effort please let me know!

I have been working on an interface for Swift written in Angular. You'll
find a ready-to-deploy tarball and zip file here:

  https://github.com/zerovm/swift-browser/releases/

This will eventually be an interface for starting ZeroVM instances on a
Swift cluster, but for now it's a pure Swift interface.

I don't know if this is something that can be used in Horizon, but maybe
there are useful bits.

One thing interesting thing in Swift Browser is its testing: I wrote a
Swift simulator that is injected into the application for end-to-end
testing with Protractor. Is is basically an in-memory (and in-browser)
Swift that responds to queries made against the Swift REST API. I've
found that very useful in the development:

  
https://github.com/zerovm/swift-browser/blob/master/app/js/test/swift-simulator.js

I don't know the other OpenStack components and their APIs very well,
but I guess that this kind of mocking might be too much for a full
OpenStack dashboard.

-- 
Martin Geisler

http://google.com/+MartinGeisler

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

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


Re: [openstack-dev] [Neutron] Provider Router topology

2014-11-12 Thread Salvatore Orlando
Hi Jaume,

The concept of provider router is useful as it maps what actually already
happens in several infrastructures. I am not entirely sure that this
however implies we need to expose new API constructs and change the
topology API.

The provider router perhaps can exist in a concealed way, where tenants
still put gateways on an external network, but that would be implemented
with a provider router.

Anyway, I am sure you are aware of the technical debt repayment activities
scheduled for Kilo. Some of them pertain the l3 agent [1], and I'd say
those have the highest priority. If this spec will bring non-negligible
changes in the l3 agent, perhaps it's the case of doing that after the
agent restructuring to avoid conflicts which will slow down everything.

Finally, can you post the specification for this work in gerrit? It seems
it is not the one under the 'edge router' name [2]

Salvatore

[1] https://review.openstack.org/#/c/131535/
[2] https://review.openstack.org/128272

On 31 October 2014 10:01, Jaume Devesa devv...@gmail.com wrote:

 Hi all,

 in Midokura we are working on a blueprint to define a new kind of topology
 for floating ranges, as alternative to external network topology. It is
 based on the idea of a Provider Router that links directly with Tenant
 Routers using /30 networks. It aims to be more pure-floating, helping the
 deployment of floating ranges across different physical L2 Networks. (We
 know there is some interest in this[1]) We think that also it might help in
 add Firewall specific policies at the edge of the cloud and define
 per-tenant or per-network QoS definitions.

 Document[2] is still WIP, with high level ideas and just some API details.
 But we would love to hear Neutron community feedback to go further in a
 steady way. In the implementation level, we are concerned in being
 compatible with current DVR and don't add a new SPOF in Neutron OVS plugin.
 So DVR developers feedback would be highly appreciated.

 We are also interested in chat about it during the summit, maybe during
 the Kilo L3 refractor BoF? [3]

 Thanks in advance!

 PD: Blueprint is here[4]

 [1]: https://blueprints.launchpad.net/neutron/+spec/pluggable-ext-net
 [2]:
 https://docs.google.com/a/midokura.com/document/d/1fUPhpBWpiUvBe_c55lkokDIls--4dKVSFmGVtjxjg0w/edit#
 [3]: https://etherpad.openstack.org/p/kilo-l3-refactoring
 [4]:
 https://blueprints.launchpad.net/neutron/+spec/neutron-provider-router


 --
 Jaume Devesa
 Software Engineer at Midokura

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


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


Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

2014-11-12 Thread marios
On 12/11/14 11:18, Anita Kuno wrote:
 On 11/12/2014 08:04 AM, marios wrote:
 On 12/11/14 04:17, Clint Byrum wrote:
 Just as a counter-point: The entire reason that a mid-cycle is an
 important thing to do is to achieve higher bandwidth communication between
 contributors. We can do Hangouts all the time and that's certainly a
 useful thing. But making the people in the room who have high bandwidth
 slow down for those who are at the other end of low-bandwidth may not be
 a productive thing as a whole.

 Anyway, just a thought as somebody who has tried this before.

 I understand but I am definitely not saying the room should slow down
 for someone on hangout - heck I'd be ecstatic if microphones are even
 used). In my experience this can work best if it is understood that
 remotees have a read-only feed into the room audio (best case + video of
 slides) - it makes the world of difference compared to say just staring
 at the etherpad being updated.  I don't see this as having a high cost
 to setup (just point a laptop at the speaker, end),

 If you are a remotee and need read/write into the meeeting then you
 should prepare beforehand and have stuff written down to share. It is
 only common courtesy, and I absolutely agree it would be in the very
 least inconsiderate to expect the room to stop/slow down to allow any
 kind of conversation to happen over hangout. In fact, just click the
 on-air button and that way you get a youtube link to share, which
 obviously *is* read-only (r/w participation is limited @ 10 afaik),

 my 2c, thanks, marios
 You seem to have put quite a bit of thought into this marios, why can't
 you attend? If the reason is purely financial, please approach Kyle in
 private and I will contact him as well to see if we can access some
 finances for folks committed to working on the technical debt for
 neutron that need financial assistance.

thanks very much for your kind offer Anita :) - my gut feeling is that
this kind of funding shouldn't be used to subsidize travel for corporate
engineers, but it is excellent to know it is there regardles.

To be fair I haven't even mentioned this to my manager - imo it doesn't
make sense for this one. The specific technical debt I scored at summit
is functional testing for l2-agent and dhcp-agent (as well as the
general 'help out/reviews etc'). Neither of those are controversial or
require any particular deep discussion about approach :). I am based in
the far eastern Mediterranean so 1 month is probably also very close to
the minimum time before which you can comfortably plan travel to the states.

thanks! marios

 
 Having you there is far more productive than not.
 
 Thank you,
 Anita.



 Excerpts from Marios Andreou's message of 2014-11-11 08:56:05 -0800:
 +1 would be great to at least have a hangout going



 _sent from my mobile device, sorry for spacing/spelling/top-posting/.*_

 -Original Message-
 From: Kyle Mestery [mest...@mestery.com]
 Received: Tuesday, 11 Nov 2014, 16:14
 To: OpenStack Development Mailing List (not for usage questions) 
 [openstack-dev@lists.openstack.org]
 Subject: Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

 On Tue, Nov 11, 2014 at 8:00 AM, Gary Kotton gkot...@vmware.com wrote:
 Hi,
 For those unable to attend will there be an option of remote access?
 Thanks
 Gary

 We'll do our best to make this happen. I'll see if we can get a Google
 Hangout going in the room, and make sure people are on IRC.

 Thanks!
 Kyle

 On 11/11/14, 3:04 PM, Kyle Mestery mest...@mestery.com wrote:

 Hi folks:

 Apologies for the delay in announcing the Neutron mid-cycle, but I was
 confirming the details up until last night. I've captured the details
 on an etherpad here [1]. The dates are December 8-10
 (Monday-Wednesday), and it will be at the Adobe offices in Lehi, Utah,
 USA.

 We're still collecting information on hotels which should be on the
 etherpad later today.

 Thanks, looking forward to seeing everyone I missed in Paris!
 Kyle

 [1] https://etherpad.openstack.org/p/neutron-kilo-midcycle

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


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

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

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



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

 
 
 

Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

2014-11-12 Thread Salvatore Orlando
On 12 November 2014 09:53, marios mar...@redhat.com wrote:

 On 12/11/14 11:18, Anita Kuno wrote:
  On 11/12/2014 08:04 AM, marios wrote:
  On 12/11/14 04:17, Clint Byrum wrote:
  Just as a counter-point: The entire reason that a mid-cycle is an
  important thing to do is to achieve higher bandwidth communication
 between
  contributors. We can do Hangouts all the time and that's certainly a
  useful thing. But making the people in the room who have high bandwidth
  slow down for those who are at the other end of low-bandwidth may not
 be
  a productive thing as a whole.
 
  Anyway, just a thought as somebody who has tried this before.
 
  I understand but I am definitely not saying the room should slow down
  for someone on hangout - heck I'd be ecstatic if microphones are even
  used). In my experience this can work best if it is understood that
  remotees have a read-only feed into the room audio (best case + video of
  slides) - it makes the world of difference compared to say just staring
  at the etherpad being updated.  I don't see this as having a high cost
  to setup (just point a laptop at the speaker, end),
 
  If you are a remotee and need read/write into the meeeting then you
  should prepare beforehand and have stuff written down to share. It is
  only common courtesy, and I absolutely agree it would be in the very
  least inconsiderate to expect the room to stop/slow down to allow any
  kind of conversation to happen over hangout. In fact, just click the
  on-air button and that way you get a youtube link to share, which
  obviously *is* read-only (r/w participation is limited @ 10 afaik),
 
  my 2c, thanks, marios
  You seem to have put quite a bit of thought into this marios, why can't
  you attend? If the reason is purely financial, please approach Kyle in
  private and I will contact him as well to see if we can access some
  finances for folks committed to working on the technical debt for
  neutron that need financial assistance.

 thanks very much for your kind offer Anita :) - my gut feeling is that
 this kind of funding shouldn't be used to subsidize travel for corporate
 engineers, but it is excellent to know it is there regardles.


You should not see yourself as evil and not worth using foundation budget
just because you work for a private enterprise!
After all - it's corporations like yours and mine which fund OpenStack.
If for any reason your employer can' authorise your travel, and - obviously
- if you want to come, you should probably do as Anita suggests.


 To be fair I haven't even mentioned this to my manager - imo it doesn't
 make sense for this one. The specific technical debt I scored at summit
 is functional testing for l2-agent and dhcp-agent (as well as the
 general 'help out/reviews etc').


As we are working to get somebody from QA  Infra at the meetup, we will
probably have a working table dedicated to testing.


 Neither of those are controversial or
 require any particular deep discussion about approach :).


We're not meeting to argue or have fights. There's already a summit every 6
months for that! This meeting is about finalizing designs into low level
aspects and then getting our hands dirty on the keyboard.


 I am based in
 the far eastern Mediterranean so 1 month is probably also very close to
 the minimum time before which you can comfortably plan travel to the
 states.


Fortunately there are no easyjets or ryanairs for intercontinental flights.
You can buy reasonably priced tickets up to 2 weeks before departure. Idk
where you are precisely but flights from London, Rome, and Munich to Salt
Lake City are around 850 euros at the moment.



 thanks! marios

 
  Having you there is far more productive than not.
 
  Thank you,
  Anita.
 
 
 
  Excerpts from Marios Andreou's message of 2014-11-11 08:56:05 -0800:
  +1 would be great to at least have a hangout going
 
 
 
  _sent from my mobile device, sorry for
 spacing/spelling/top-posting/.*_
 
  -Original Message-
  From: Kyle Mestery [mest...@mestery.com]
  Received: Tuesday, 11 Nov 2014, 16:14
  To: OpenStack Development Mailing List (not for usage questions) [
 openstack-dev@lists.openstack.org]
  Subject: Re: [openstack-dev] [neutron] Neutron mid-cycle announcement
 
  On Tue, Nov 11, 2014 at 8:00 AM, Gary Kotton gkot...@vmware.com
 wrote:
  Hi,
  For those unable to attend will there be an option of remote access?
  Thanks
  Gary
 
  We'll do our best to make this happen. I'll see if we can get a Google
  Hangout going in the room, and make sure people are on IRC.
 
  Thanks!
  Kyle
 
  On 11/11/14, 3:04 PM, Kyle Mestery mest...@mestery.com wrote:
 
  Hi folks:
 
  Apologies for the delay in announcing the Neutron mid-cycle, but I
 was
  confirming the details up until last night. I've captured the
 details
  on an etherpad here [1]. The dates are December 8-10
  (Monday-Wednesday), and it will be at the Adobe offices in Lehi,
 Utah,
  USA.
 
  We're still collecting information on hotels 

Re: [openstack-dev] URLs

2014-11-12 Thread Chris Dent

On Tue, 11 Nov 2014, Adam Young wrote:

My suggestion, from a while ago, was to have a naming scheme that deconflicts 
putting all of the services onto a single server, on port 443.


+1

The current state of affairs is indeed weird.

Is this something that ought to be considered in the api-wg's
discussions?

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

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


Re: [openstack-dev] [oslo][all] Alembic migrations for SQLite

2014-11-12 Thread Victor Sergeyev
Great job, Mike, thanks!

Doug, as for migration from sqlalchemy-migrate to Alembic - at the moment
it's hard to realize this because we suppose to keep backward compatibility
with available migrations. I'd like to re-review existing approach with
Mike and Roman, create road-map for this migration, and try to migrate one
of the projects as Proof-Of-Concept.

On Tue, Nov 11, 2014 at 5:58 PM, Doug Hellmann d...@doughellmann.com
wrote:


 On Nov 10, 2014, at 10:55 AM, Mike Bayer mba...@redhat.com wrote:

  Bonjour openstackers -
 
  While you were all sipping champagne on the Champs-Élysées, I took some
 time to tackle one of the two most critically wanted features in Alembic,
 which is that of being able to migrate tables on a SQLite database with
 some degree of sanity.   My immediate focus on Alembic was spurred on
 partially because some changes to the test suite pushed it into 0.7.0, and
 then we got a very large number of bug fixes in, so the urgency to get
 0.7.0 is relatively high; but what good is a pseudo-major point release
 without some big new features ?
 
  The feature works similarly to that of SQLAlchemy-Migrate, but I’m
 hoping in a way that is more controllable and open-ended.   I would
 encourage all those interested to take a look at the basic mode of
 operation over at
 http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases.
  Highlights include that several table operations can take place within one
 “move and copy” operation at once, and the system can also be applied to
 other databases if one so desired (not a common use case but some have
 expressed interest in this being possible…so it is!).   The format of a
 SQLite-compatible migration script will change slightly, though for the
 better as per-table operations are grouped together, and the scripts of
 course in the default case continue to work exactly as before on all other
 target databases.

 This sounds great, Mike, and I’m sure it will make it much easier for us
 to use sqlite databases for unit/functional tests.

 
  I know that a handful of projects have moved or started with Alembic,
 and I’d like to continue pushing Alembic to be the single solution across
 all projects.  There’s some work in oslo.db to define a common
 environmental format as well (see https://review.openstack.org/#/c/112842/).
 I would encourage projects to continue to evaluate moving their migrations
 over to Alembic at some point in the future, which should also include
 sending me emails/ircs/bug reports about what additional features/fixes are
 needed.

 I want to stress this. We ran into issues with sqlalchemy-migrate during
 Juno, and we’re having an increasingly difficult time finding reviewers
 even though OpenStack (not Oslo) has adopted the library. The Oslo team is
 working on improving Alembic support with the intent to deprecate support
 for sqlalchemy-migrate in the “near future” (not Kilo). Please work with
 Mike, Viktor, Roman, and the rest of the oslo.db team to identify any holes
 that would delay your ability to start using alembic for new migrations in
 the next release cycle.

 
  The next major feature for Alembic, which I will tentatively use this
 week to see if I can get it online, is the multiple heads/branch resolution
 feature (
 https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support)
 which a *lot* of people are really asking for.   This feature would allow
 independent migration series to coexist simultaneously, as well “merge
 point” migrations that join disparate branches back into a single stream.
  The risk level for this feature is significantly higher than that of the
 SQLite migration feature, as while the SQLite migration feature lives
 entirely within a new API that is otherwise unused, the multiple branch
 feature makes some fundamental changes to how versioning is performed.   So
 while I’d like to get this in 0.7.0 as well, if it gets into the weeds I
 may have to push 0.7.0 without it as there’s really a crapload of other
 fixes to be pushed.
 
  Thanks for reading!
 
  - mike
 
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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


Re: [openstack-dev] [Openstack-security] [Barbican][OSSG] Mid Cycle Attendance / Crossover.

2014-11-12 Thread Clark, Robert Graham
Sounds like a security/identity/secrets mashup might be on the cards  – should 
be fun!

-Rob

From: Morgan Fainberg 
morgan.fainb...@gmail.commailto:morgan.fainb...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 11 November 2014 21:52
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-security] [Barbican][OSSG] Mid Cycle 
Attendance / Crossover.


On Nov 11, 2014, at 1:45 PM, Lance Bragstad 
lbrags...@gmail.commailto:lbrags...@gmail.com wrote:



On Tue, Nov 11, 2014 at 3:30 PM, Douglas Mendizabal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com 
wrote:
I think it would also be interesting to hear for the Keystone folks that
are interested in attending OSSG and/or Barbican.

We did record some of our plans for the Keystone mid-cycle meetup during our 
last session
at the summit [1]. I don't think we have any specifics set in stone yet though. 
Maybe we could hash
it out during one of the project meetings next week if people are interested?


[1] https://etherpad.openstack.org/p/kilo-keystone-meetup


I’ve just updated the ether pad with some details. I expect to send an email 
out to the ML re the mid-cycle in the next day or so (for coordination 
purposes).
Is there currently a (even tentative) plan for Barbican?

—Morgan

  A few people have told
me they found the Keystone/Barbican overlap for the last mid-cycle to be
helpful, so it might be worthwhile doing again.

-Doug M.


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




On 11/7/14, 8:02 PM, Clark, Robert Graham 
robert.cl...@hp.commailto:robert.cl...@hp.com wrote:

Hi All,

How many people would want to attend both the OSSG mid-cycle and the
Barbican one? Both expected to be on the west coast of the US.

We are trying to work out how/if we should organise these events to take
place at adjacent times and if they should be in the same location, back
to back to reduce travel costs.

Cheers
-Rob


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


[openstack-dev] [Heat] midcycle meetup venue selection

2014-11-12 Thread Angus Salkeld
Hi

As promised at the dev sessions I have made a doodle so we can vote for
a venue for the midcycle meetup.

Here is the link:
https://doodle.com/b9m4bf8hvm3mna97

Note: I have added one more option to the doodle no meetup. I understand
that this is a big financial burden and I'd like to get an idea on who just
can't
make it. Maybe we can give an electronic skype/hangout a go if the costs are
too high.

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


[openstack-dev] [Nova][Evacuate] nova evacuate command failed

2014-11-12 Thread zhang xiaobin

hi, i run command nova evacuate failed, anyone can help point out direction?
steps:
1.run two compute host A and B
2.run instance vm01 on host A, shutdown host A
3.run command nova evacuate --on-shared-storage vm01 B


My analysis is:
When VM starting to be created in Host B, I can see the 'network-vif-plugged' 
message showed up in neutron server log.
but after VM is created, no more neutron 'network-vif-plugged' rpc message 
generated, thus we got 'timeout' error.
actually no any error messages in neutron server log during evacuation.

i see from source code that it has some notifier with port api 
create/delete/update and port db insert/update/set.
i guess that it is due to the port data not changed during evacuation, so no 
any message to be sent out as notification

could any confirm this?

-
Host B compute log:
nova-nova.virt.libvirt.driver WARNING: Timeout waiting for vif plugging 
callback for instance 091cde07-297b-437c-b21f-32bc53c24701
nova-nova.compute.manager INFO: Lifecycle event 1 on VM 
091cde07-297b-437c-b21f-32bc53c24701
nova-nova.compute.manager INFO: During sync_power_state the instance has a 
pending task. Skip.
nova-nova.virt.libvirt.driver INFO: Deleting instance files 
/instance_path/091cde07-297b-437c-b21f-32bc53c24701
nova-nova.virt.libvirt.driver INFO: Deletion of 
/instance_path/091cde07-297b-437c-b21f-32bc53c24701 complete
nova-nova.compute.manager ERROR: Setting instance vm_state to ERROR
Traceback (most recent call last):
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 5529, 
in _error_out_instance_on_exception
yield
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2524, 
in rebuild_instance
self._rebuild_default_impl(**kwargs)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2377, 
in _rebuild_default_impl
block_device_info=new_block_device_info)
  File /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py, line 
2265, in spawn
block_device_info)
  File /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py, line 
3675, in _create_domain_and_network
raise exception.VirtualInterfaceCreateException()
VirtualInterfaceCreateException: Virtual Interface creation failed
nova-oslo.messaging.rpc.dispatcher ERROR: Exception during message handling: 
Virtual Interface creation failed
Traceback (most recent call last):
  File /usr/lib/python2.6/site-packages/oslo/messaging/rpc/dispatcher.py, 
line 133, in _dispatch_and_reply
incoming.message))
  File /usr/lib/python2.6/site-packages/oslo/messaging/rpc/dispatcher.py, 
line 176, in _dispatch
return self._do_dispatch(endpoint, method, ctxt, args)
  File /usr/lib/python2.6/site-packages/oslo/messaging/rpc/dispatcher.py, 
line 122, in _do_dispatch
result = getattr(endpoint, method)(ctxt, **new_args)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 393, in 
decorated_function
return function(self, context, *args, **kwargs)
  File /usr/lib/python2.6/site-packages/oslo/messaging/rpc/server.py, line 
139, in inner
return func(*args, **kwargs)
  File /usr/lib/python2.6/site-packages/nova/exception.py, line 88, in wrapped
payload)
  File /usr/lib/python2.6/site-packages/nova/openstack/common/excutils.py, 
line 68, in __exit__
six.reraise(self.type_, self.value, self.tb)
  File /usr/lib/python2.6/site-packages/nova/exception.py, line 71, in wrapped
return f(self, context, *args, **kw)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 274, in 
decorated_function
pass
  File /usr/lib/python2.6/site-packages/nova/openstack/common/excutils.py, 
line 68, in __exit__
six.reraise(self.type_, self.value, self.tb)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 260, in 
decorated_function
return function(self, context, *args, **kwargs)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 327, in 
decorated_function
function(self, context, *args, **kwargs)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 303, in 
decorated_function
e, sys.exc_info())
  File /usr/lib/python2.6/site-packages/nova/openstack/common/excutils.py, 
line 68, in __exit__
six.reraise(self.type_, self.value, self.tb)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 290, in 
decorated_function
return function(self, context, *args, **kwargs)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2524, 
in rebuild_instance
self._rebuild_default_impl(**kwargs)
  File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2377, 
in _rebuild_default_impl
block_device_info=new_block_device_info)
  File /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py, line 
2265, in spawn
block_device_info)
  File 

Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-12 Thread Tomasz Napierala

On 06 Nov 2014, at 12:20, Przemyslaw Kaminski pkamin...@mirantis.com wrote:

 I didn't mean a robust monitoring system, just something simpler. 
 Notifications is a good idea for FuelWeb.

I’m all for that, but if we add it, we need to document ways to clean up space. 
We could also add some kind of simple job to remove rotated logs, obsolete 
spanshots, etc., but this is out of scope for 6.0 I guess.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







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


Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

2014-11-12 Thread Anita Kuno
On 11/12/2014 11:06 AM, Salvatore Orlando wrote:
 On 12 November 2014 09:53, marios mar...@redhat.com wrote:
 
 On 12/11/14 11:18, Anita Kuno wrote:
 On 11/12/2014 08:04 AM, marios wrote:
 On 12/11/14 04:17, Clint Byrum wrote:
 Just as a counter-point: The entire reason that a mid-cycle is an
 important thing to do is to achieve higher bandwidth communication
 between
 contributors. We can do Hangouts all the time and that's certainly a
 useful thing. But making the people in the room who have high bandwidth
 slow down for those who are at the other end of low-bandwidth may not
 be
 a productive thing as a whole.

 Anyway, just a thought as somebody who has tried this before.

 I understand but I am definitely not saying the room should slow down
 for someone on hangout - heck I'd be ecstatic if microphones are even
 used). In my experience this can work best if it is understood that
 remotees have a read-only feed into the room audio (best case + video of
 slides) - it makes the world of difference compared to say just staring
 at the etherpad being updated.  I don't see this as having a high cost
 to setup (just point a laptop at the speaker, end),

 If you are a remotee and need read/write into the meeeting then you
 should prepare beforehand and have stuff written down to share. It is
 only common courtesy, and I absolutely agree it would be in the very
 least inconsiderate to expect the room to stop/slow down to allow any
 kind of conversation to happen over hangout. In fact, just click the
 on-air button and that way you get a youtube link to share, which
 obviously *is* read-only (r/w participation is limited @ 10 afaik),

 my 2c, thanks, marios
 You seem to have put quite a bit of thought into this marios, why can't
 you attend? If the reason is purely financial, please approach Kyle in
 private and I will contact him as well to see if we can access some
 finances for folks committed to working on the technical debt for
 neutron that need financial assistance.

 thanks very much for your kind offer Anita :) - my gut feeling is that
 this kind of funding shouldn't be used to subsidize travel for corporate
 engineers, but it is excellent to know it is there regardles.

 
 You should not see yourself as evil and not worth using foundation budget
 just because you work for a private enterprise!
 After all - it's corporations like yours and mine which fund OpenStack.
 If for any reason your employer can' authorise your travel, and - obviously
 - if you want to come, you should probably do as Anita suggests.
Thanks Salvadore.

Please start by talking to your manager, marios, if they are willing to
finance any part of your travel (accommodation or food) that is a start.
We can see about organizing car pooling for you. I have a friend in Lehi
who has recommended I rent a car which I am planning on doing. We can
work with others who rent cars to ensure you have a ride to and from the
airport, to meetings, to restaurants and whereever else you need to travel.

The main decision point is if you want to come. If you want to come we
will do our best to help you attend. But only you can make that
decision. Do let use know what you want.

Thanks,
Anita.
 
 
 To be fair I haven't even mentioned this to my manager - imo it doesn't
 make sense for this one. The specific technical debt I scored at summit
 is functional testing for l2-agent and dhcp-agent (as well as the
 general 'help out/reviews etc').
 
 
 As we are working to get somebody from QA  Infra at the meetup, we will
 probably have a working table dedicated to testing.
 
 
 Neither of those are controversial or
 require any particular deep discussion about approach :).
 
 
 We're not meeting to argue or have fights. There's already a summit every 6
 months for that! This meeting is about finalizing designs into low level
 aspects and then getting our hands dirty on the keyboard.
 
 
 I am based in
 the far eastern Mediterranean so 1 month is probably also very close to
 the minimum time before which you can comfortably plan travel to the
 states.


 Fortunately there are no easyjets or ryanairs for intercontinental flights.
 You can buy reasonably priced tickets up to 2 weeks before departure. Idk
 where you are precisely but flights from London, Rome, and Munich to Salt
 Lake City are around 850 euros at the moment.
 
 
 
 thanks! marios


 Having you there is far more productive than not.

 Thank you,
 Anita.



 Excerpts from Marios Andreou's message of 2014-11-11 08:56:05 -0800:
 +1 would be great to at least have a hangout going



 _sent from my mobile device, sorry for
 spacing/spelling/top-posting/.*_

 -Original Message-
 From: Kyle Mestery [mest...@mestery.com]
 Received: Tuesday, 11 Nov 2014, 16:14
 To: OpenStack Development Mailing List (not for usage questions) [
 openstack-dev@lists.openstack.org]
 Subject: Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

 On Tue, Nov 11, 2014 at 8:00 AM, Gary Kotton gkot...@vmware.com
 

[openstack-dev] [Heat] Heat Resource Plugin for third party storage

2014-11-12 Thread Pradip Mukhopadhyay
Hello,


We come across this:
http://docs.openstack.org/developer/heat/pluginguide.html


Looks like it solves three of the purposes listed below:

1. Define a custom resource type with properties and attributes
2. Register the resource to the Hear orchestrator
3. Write a driver/plugin (most likely the Life Cycle methods) which can
create/manage the resources when encounter from the Heat orchestration
engine.


Am I right?


Now the question is: in one place it is mentioned as:


It defines methods corresponding to the life cycle as well as the basic
hooks for plug-ins to handle the work of communicating with specific
down-stream services



Can this down-stream service be *anything* (say a third-party storage
array)? Or it has to be a OpenStack service only?




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


Re: [openstack-dev] URLs

2014-11-12 Thread Darren Kenny

Chris Dent wrote:

On Tue, 11 Nov 2014, Adam Young wrote:

My suggestion, from a while ago, was to have a naming scheme that deconflicts putting all of the 
services onto a single server, on port 443.


+1

The current state of affairs is indeed weird.


It is, and as BUIs move more towards client's doing the access of the URLs, it
is something we need to fix - since most browsers restrict cross-domain 
access (including different ports on the same host) for security reasons.


This is the reason that the Horizon guys wrote a kind of reverse-proxy 
WSGI to enable demonstrations of the AngularJS work last week - so that

all the REST API calls were back to the origin of Horizon itself.



Is this something that ought to be considered in the api-wg's
discussions?



That would appear to fit within the aims of that working group.

Thanks,

Darren.


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


Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

2014-11-12 Thread marios
On 12/11/14 12:55, Anita Kuno wrote:
 On 11/12/2014 11:06 AM, Salvatore Orlando wrote:
 On 12 November 2014 09:53, marios mar...@redhat.com wrote:

 On 12/11/14 11:18, Anita Kuno wrote:
 On 11/12/2014 08:04 AM, marios wrote:
 On 12/11/14 04:17, Clint Byrum wrote:
 Just as a counter-point: The entire reason that a mid-cycle is an
 important thing to do is to achieve higher bandwidth communication
 between
 contributors. We can do Hangouts all the time and that's certainly a
 useful thing. But making the people in the room who have high bandwidth
 slow down for those who are at the other end of low-bandwidth may not
 be
 a productive thing as a whole.

 Anyway, just a thought as somebody who has tried this before.

 I understand but I am definitely not saying the room should slow down
 for someone on hangout - heck I'd be ecstatic if microphones are even
 used). In my experience this can work best if it is understood that
 remotees have a read-only feed into the room audio (best case + video of
 slides) - it makes the world of difference compared to say just staring
 at the etherpad being updated.  I don't see this as having a high cost
 to setup (just point a laptop at the speaker, end),

 If you are a remotee and need read/write into the meeeting then you
 should prepare beforehand and have stuff written down to share. It is
 only common courtesy, and I absolutely agree it would be in the very
 least inconsiderate to expect the room to stop/slow down to allow any
 kind of conversation to happen over hangout. In fact, just click the
 on-air button and that way you get a youtube link to share, which
 obviously *is* read-only (r/w participation is limited @ 10 afaik),

 my 2c, thanks, marios
 You seem to have put quite a bit of thought into this marios, why can't
 you attend? If the reason is purely financial, please approach Kyle in
 private and I will contact him as well to see if we can access some
 finances for folks committed to working on the technical debt for
 neutron that need financial assistance.

 thanks very much for your kind offer Anita :) - my gut feeling is that
 this kind of funding shouldn't be used to subsidize travel for corporate
 engineers, but it is excellent to know it is there regardles.


 You should not see yourself as evil and not worth using foundation budget
 just because you work for a private enterprise!
 After all - it's corporations like yours and mine which fund OpenStack.
 If for any reason your employer can' authorise your travel, and - obviously
 - if you want to come, you should probably do as Anita suggests.
 Thanks Salvadore.
 
 Please start by talking to your manager, marios, if they are willing to
 finance any part of your travel (accommodation or food) that is a start.
 We can see about organizing car pooling for you. I have a friend in Lehi
 who has recommended I rent a car which I am planning on doing. We can
 work with others who rent cars to ensure you have a ride to and from the
 airport, to meetings, to restaurants and whereever else you need to travel.
 
 The main decision point is if you want to come. If you want to come we
 will do our best to help you attend. But only you can make that
 decision. Do let use know what you want.

thanks again Anita and Salvatore: as I said before I don't think it
makes sense for this one (Salv: I am in Cyprus, so there is at least an
additional hop into EU for connection). I will make use of whatever
means are made available for remote participation but to reiterate, I
don't anticipate issues with the l2/dhcp functional tests. If it really
is too much of a pain to setup audio/hangout for remotees then I will do
my best to catchup/follow any related discussions (thanks Salvatore, I
will look out for the testing session/working table or related discussion),

thanks again, have an excellent day!

marios

 
 Thanks,
 Anita.


 To be fair I haven't even mentioned this to my manager - imo it doesn't
 make sense for this one. The specific technical debt I scored at summit
 is functional testing for l2-agent and dhcp-agent (as well as the
 general 'help out/reviews etc').


 As we are working to get somebody from QA  Infra at the meetup, we will
 probably have a working table dedicated to testing.


 Neither of those are controversial or
 require any particular deep discussion about approach :).


 We're not meeting to argue or have fights. There's already a summit every 6
 months for that! This meeting is about finalizing designs into low level
 aspects and then getting our hands dirty on the keyboard.


 I am based in
 the far eastern Mediterranean so 1 month is probably also very close to
 the minimum time before which you can comfortably plan travel to the
 states.


 Fortunately there are no easyjets or ryanairs for intercontinental flights.
 You can buy reasonably priced tickets up to 2 weeks before departure. Idk
 where you are precisely but flights from London, Rome, and Munich to Salt
 Lake City are around 850 euros at 

Re: [openstack-dev] [Nova][Cells] Cells subgroup and meeting times

2014-11-12 Thread John Garbutt
 On 11/11/2014 3:04 PM, Andrew Laski wrote:

 We had a great discussion on cells at the summit which is captured at
 https://etherpad.openstack.org/p/kilo-nova-cells.  One of the tasks we
 agreed upon there was to form a subgroup to co-ordinate this effort
 and
 report progress to the Nova meeting regularly.  To that end I would
 like
 to find a meeting time, or more likely alternating times, that will
 work
 for interested parties.

 I am proposing Wednesday as the meeting day since it's more open than
 Tues/Thurs so finding a meeting room at almost any time should be
 feasible.  My opening bid is alternating between 1700 and 2200 UTC.
 That
 should provide options that aren't too early or too late for most
 people.  Is this fine for everyone or should it be adjusted a bit?


 Fine by me. I should be able to attend at least those at 1700 UTC.

 -Sylvain

+1

I can do the 1700 UTC one, so thats cool.

Thanks,
John

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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Alexis Lee
Zane Bitter said on Tue, Nov 11, 2014 at 04:06:17PM -0500:
 FWIW literally everyone that Clint has pitched the JS
 idea to thought it was crazy ;)

+1

 YAQL ... looks like line noise to me

YAML representing function call stacks (an AST) looks pretty bad to me
:)

The YAQL doc is not great at the moment but the language is not
difficult. It's pretty similar to XPath, jq and JSP EL, i.e. dotted
syntax with square brackets for attribute selection and slicing. That's
also pretty similar to Python btw.

Is there another expression language you prefer?

 From the beginning we've tried to have the absolute minimum
 number of intrinsic functions in HOT.

This is understandable but there are things I want to do (as an operator
- like first_nonnull) which I cannot. The options as I see them:

  * Add a bunch of operators and a LOT of functions
  * Add a bunch of operators, a few functions and lambda
  * Add a bunch of functions and use an expression language for
arithmetic, comparison etc
  * Use an expression language for all complex processing

 I would much prefer to resurrect the previous proposal for adding
 conditionals and then see what is still missing than to just dive
 straight in to embedding a whole other language in HOT.

Do you mean this? https://blueprints.launchpad.net/heat/+spec/intrinsics
This only provides string equality and boolean logic. It's insufficient
to implement first_nonnull for example.

I'd like to emphasise that we don't have to offer the whole YAQL stdlib
in HOT initially. We can use it just for its operator suite and a few
key functions then add others as usecases are discovered.

 On 11/11/14 13:34, Ryan Brown wrote:
 Vendored HOT
 the real issue is that it's under the control of the operator and not
 the template author.

Yep, the solution has to be through the template as that's 99% of the
user interface.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Thomas Goirand
On 11/11/2014 03:02 PM, Richard Jones wrote:
 Hi all,
 
 At the summit last week, we developed a plan for moving forward with
 modernising Horizon's UI using AngularJS. If you weren't at that meeting
 and are interested in helping out with this effort please let me know!
 
 The relevant etherpad from the meeting:
 https://etherpad.openstack.org/p/kilo-horizon-contributors-meetup
 
 TL;DR: piece by piece we will replace Django views in Horizon with
 angular views, and we're going to start with Identity
 
 First up, I'd like to ask the UX folk who raised their hands in that
 meeting to indicate which of the Identity panes we should start with. I
 believe a wizard was mentioned, as a way to exercise the new wizard code
 from Maxime.
 
 At the same time, I'm looking at updating the AngularJS recommendations
 in the wiki. I believe other aspects of the current approach to angular
 code should also be revisited, if we're to scale up to the full angular
 front-end envisaged. I'd appreciate if those interested in this aspect
 in particular could contact me so we can sort this out as a team!
 
 I'd like to start the design work for the new REST API layer we'll be
 exposing to the angular application code, but that is also part of the
 broader discussion about the structure of the angular code in the
 Horizon application as mentioned above. Should it be a new blueprint/spec?
 
 There were some discussions around tooling. We're using xstatic to
 manage 3rd party components, but there's a lot missing from that
 environment. I hesitate to add supporting xstatic components on to the
 already large pile of work we have to do, so would recommend we switch
 to managing those components with bower instead. For reference the list
 of 3rd party components I used in angboard* (which is really only a
 teensy fraction of the total application we'd end up with, so this
 components list is probably reduced):
 
 json3
 es5-shim
 angular
 angular-route
 angular-cookies
 angular-animate
 angular-sanitize
 angular-smart-table
 angular-local-storage
 angular-bootstrap
 angular-translate
 font-awesome
 boot
 underscore
 ng-websocket

Hi,

Let's please continue to use xstatic packages, which are very good for
distributions. I will do the effort on the Debian side of things to make
sure that we have all packaged correctly. Using some magic that do the
same kind of horrible stuff as pip install or pear install or CPAN,
or... you name it, will not fix things on my side. Quite the opposite,
it will add issues after issues. The XStatic things, on the other hand,
is very easy for me to maintain, even though that's a lot of work.

On 11/12/2014 04:03 PM, Matthias Runge wrote:
 There are companies out there, where security policy does not allow to
 install software from a third party repository. pypi etc. are
 considered as a third party here in this context.

It's also not Debian policy compliant to download from these sources in
a package. So that'd be a no-go for Debian, and anyway, these
dependencies would have to be packaged in some way.

Again, let's please stick on the xstatic way of doing things. It worked
for Juno, let's make it work for Kilo as well.

Cheers,

Thomas Goirand (zigo)


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


[openstack-dev] [NFV] NFV sub group meeting week of November 10th

2014-11-12 Thread MENDELSOHN, ITAI (ITAI)
Team,

Do we meet Wednesday or Thursday this week?

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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Angus Salkeld
On Wed, Nov 12, 2014 at 9:33 PM, Alexis Lee alex...@hp.com wrote:

 Zane Bitter said on Tue, Nov 11, 2014 at 04:06:17PM -0500:
  FWIW literally everyone that Clint has pitched the JS
  idea to thought it was crazy ;)

 +1

  YAQL ... looks like line noise to me

 YAML representing function call stacks (an AST) looks pretty bad to me
 :)

 The YAQL doc is not great at the moment but the language is not
 difficult. It's pretty similar to XPath, jq and JSP EL, i.e. dotted
 syntax with square brackets for attribute selection and slicing. That's
 also pretty similar to Python btw.

 Is there another expression language you prefer?

  From the beginning we've tried to have the absolute minimum
  number of intrinsic functions in HOT.

 This is understandable but there are things I want to do (as an operator
 - like first_nonnull) which I cannot. The options as I see them:

   * Add a bunch of operators and a LOT of functions
   * Add a bunch of operators, a few functions and lambda
   * Add a bunch of functions and use an expression language for
 arithmetic, comparison etc
   * Use an expression language for all complex processing



I think it's pretty clear we need something more powerful that adding
heaps of intrinsic functions, IMHO as long as we can prove it is safe
we should add yaql (it's nice that there would be a consistent user
experience
between these projects -mistral/heat/murano).

-Angus


  I would much prefer to resurrect the previous proposal for adding
  conditionals and then see what is still missing than to just dive
  straight in to embedding a whole other language in HOT.

 Do you mean this? https://blueprints.launchpad.net/heat/+spec/intrinsics
 This only provides string equality and boolean logic. It's insufficient
 to implement first_nonnull for example.

 I'd like to emphasise that we don't have to offer the whole YAQL stdlib
 in HOT initially. We can use it just for its operator suite and a few
 key functions then add others as usecases are discovered.


+1


  On 11/11/14 13:34, Ryan Brown wrote:
  Vendored HOT
  the real issue is that it's under the control of the operator and not
  the template author.

 Yep, the solution has to be through the template as that's 99% of the
 user interface.


 Alexis
 --
 Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

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

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


[openstack-dev] [MagnetoDB] Backup / Restore API draft

2014-11-12 Thread Illia Khudoshyn
Team,

I've just submitted a spec for backup/restore API [1][2]
Please share your thoughts.

[1] https://review.openstack.org/#/c/133933/
[2] https://blueprints.launchpad.net/magnetodb/+spec/backup-restore-api


-- 

Best regards,

Illia Khudoshyn,
Software Engineer, Mirantis, Inc.



38, Lenina ave. Kharkov, Ukraine

www.mirantis.com http://www.mirantis.ru/

www.mirantis.ru



Skype: gluke_work

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


[openstack-dev] [NFV][Telco] No meeting this week.

2014-11-12 Thread Steve Gordon
Hi all,

Please note there will be no Telco Working Group (formerly NFV subteam) meeting 
this week. We will pick up next Wednesday @ 1400 UTC in #openstack-meeting-alt. 
I will also send an email with a more APAC/US West friendly alternate time than 
the current Thursday one shortly.

Thanks,

Steve

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


Re: [openstack-dev] [NFV] NFV sub group meeting week of November 10th

2014-11-12 Thread Steve Gordon
Hi Itai,

I just sent an email about this - no meeting this week (would have been 
Thursday), we will pick up next Wednesday. I am in the process of selecting a 
new meeting time for the Thursday alternate and will also be sending out an 
email about the CI needs shortly :).

Thanks,

Steve

- Original Message -
 From: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Wednesday, November 12, 2014 6:46:14 AM
 Subject: [openstack-dev] [NFV] NFV sub group meeting week of November 10th
 
 Team,
 
 Do we meet Wednesday or Thursday this week?
 
 Best,
 Itai
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

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


[openstack-dev] [Fuel] Waiting for Haproxy backends

2014-11-12 Thread Aleksandr Didenko
HI,

in order to make sure some critical Haproxy backends are running (like
mysql or keystone) before proceeding with deployment, we use execs like [1]
or [2].

We're currently working on a minor improvements of those execs, but there
is another approach - we can replace those execs with puppet resource
providers and move all the iterations/loops/timeouts logic there. Also we
should fail catalog compilation/run if those resource providers are not
able to ensure needed Haproxy backends are up and running. Because there is
no point to proceed with deployment if keystone is not running, for example.

If no one objects, I can start implementing this for Fuel-6.1. We can
address it as a part of pacemaker improvements BP [3] or create a new BP.

[1]
https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/manifests/cluster_ha.pp#L551-L572
[2]
https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/openstack/manifests/ha/mysqld.pp#L28-L33
[3] https://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements

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


[openstack-dev] [Zaqar] Meeting Monday 17th at 15:00 UTC

2014-11-12 Thread Flavio Percoco

Greetings,

Zaqar team will pick up its regular meetings next Monday at 15 UTC.
We'll keep alternating time, therefore the meeting after the next one
will be at 21 UTC.

The team meets in the #openstack-meeting-3 channel and we keep the
agenda in the wiki[0]. Do feel free to add items to it that you'd like
to discuss during the meeting.

[0] https://wiki.openstack.org/wiki/Meetings/Zaqar

Looking forward to see you there,
Flavio

--
@flaper87
Flavio Percoco


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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Zane Bitter

On 12/11/14 06:33, Alexis Lee wrote:

I would much prefer to resurrect the previous proposal for adding
conditionals and then see what is still missing than to just dive
straight in to embedding a whole other language in HOT.

Do you mean this?https://blueprints.launchpad.net/heat/+spec/intrinsics
This only provides string equality and boolean logic. It's insufficient
to implement first_nonnull for example.


I meant this: https://review.openstack.org/#/c/84468/

- ZB

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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Zane Bitter

On 12/11/14 06:48, Angus Salkeld wrote:

(it's nice that there would be a consistent user experience
between these projects -mistral/heat/murano).


It's actually potentially horrible, because you introduce potential 
quoting issues when you embed mistral workbooks in Heat templates or 
pass Heat templates to Murano.


cheers,
Zane.

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


Re: [openstack-dev] [Nova][DR][NFV] opnfv proposal on DR capability enhancement on OpenStack Nova

2014-11-12 Thread Steve Gordon
- Original Message -
 From: Zhipeng Huang zhipengh...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 
 Hi Team,
 
 I knew we didn't propose this in the design summit and it is kinda rude in
 this way to jam a topic into the schedule. We were really stretched thin
 during the summit and didn't make it to the Nova discussion. Full apologies
 here :)
 
 What we want to discuss here is that we proposed a project in opnfv (
 https://wiki.opnfv.org/collaborative_development_projects/rescuer), which
 in fact is to enhance inter-DC DR capabilities in Nova. We hope we could
 achieve this in the K cycle, since there is no HUGE changes required to
 be done in Nova. We just propose to add certain DR status in Nova so
 operators could see what DR state the OpenStack is currently in, therefore
 when disaster occurs they won't cut off the wrong stuff.
 
 Sorry again if we kinda barge in here, and we sincerely hope the Nova
 community could take a look at our proposal. Feel free to contact me if
 anyone got any questions :)
 
 --
 Zhipeng Huang

Hi Zhipeng,

I would just like to echo the comments from the opnfv-tech-discuss list (which 
I notice is still private?) in saying that there is very little detail on the 
wiki page describing what you actually intend to do. Given this, it's very hard 
to provide any meaningful feedback. A lot more detail is required, particularly 
if you intend to propose a specification based on this idea.

Thanks,

Steve

[1] https://wiki.opnfv.org/collaborative_development_projects/rescuer


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


[openstack-dev] Could we actually write short and long descriptions for Python modules?

2014-11-12 Thread Thomas Goirand
Hi,

Please have a look into these:
https://pypi.python.org/pypi/oslo.concurrency
https://pypi.python.org/pypi/oslo.middleware

Am I supposed to dig into the code to double-guess what the library is
doing, and write that in the debian/control? Guys, please make the
effort *before* we release a lib, and *before* we depend on them. This
isn't the first time I'm raising the topic...

Cheers,

Thomas Goirand (zigo)

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


Re: [openstack-dev] Could we actually write short and long descriptions for Python modules?

2014-11-12 Thread Davanum Srinivas
Thomas,

We hear your frustration, bugs were logged yesterday

https://bugs.launchpad.net/oslo.middleware/+bug/1391551
https://bugs.launchpad.net/oslo.concurrency/+bug/1391550

thanks,
dims

On Wed, Nov 12, 2014 at 7:55 AM, Thomas Goirand tho...@goirand.fr wrote:
 Hi,

 Please have a look into these:
 https://pypi.python.org/pypi/oslo.concurrency
 https://pypi.python.org/pypi/oslo.middleware

 Am I supposed to dig into the code to double-guess what the library is
 doing, and write that in the debian/control? Guys, please make the
 effort *before* we release a lib, and *before* we depend on them. This
 isn't the first time I'm raising the topic...

 Cheers,

 Thomas Goirand (zigo)

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



-- 
Davanum Srinivas :: https://twitter.com/dims

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


Re: [openstack-dev] [Heat] Heat Resource Plugin for third party storage

2014-11-12 Thread Zane Bitter
The developer mailing list is not for usage questions. Please ask this 
on ask.openstack.org - I'm sure a lot of people will be interested in 
the answer and we want it searchable for them in future. Feel free to 
ping me with a link when you've posted it.


cheers,
Zane.

On 12/11/14 06:00, Pradip Mukhopadhyay wrote:

Hello,


We come across this:
http://docs.openstack.org/developer/heat/pluginguide.html


Looks like it solves three of the purposes listed below:

1. Define a custom resource type with properties and attributes
2. Register the resource to the Hear orchestrator
3. Write a driver/plugin (most likely the Life Cycle methods) which can
create/manage the resources when encounter from the Heat orchestration
engine.


Am I right?


Now the question is: in one place it is mentioned as:


It defines methods corresponding to the life cycle as well as the basic
hooks for plug-ins to handle the work of communicating with specific
down-stream services



Can this down-stream service be /anything/ (say a third-party storage
array)? Or it has to be a OpenStack service only?




Thanks in advance,
Pradip



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




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


Re: [openstack-dev] [Neutron] Translation technical debt

2014-11-12 Thread Saro Chandra Bhooshan T.V.
count me also.

On Wed, Nov 12, 2014 at 2:48 PM, Irena Berezovsky ire...@mellanox.com
wrote:

  Count me in



 *From:* Gary Kotton [mailto:gkot...@vmware.com]
 *Sent:* Tuesday, November 11, 2014 3:47 PM
 *To:* OpenStack List
 *Subject:* [openstack-dev] [Neutron] Translation technical debt



 Hi,

 In order to enforce our translation policies -
 http://docs.openstack.org/developer/oslo.i18n/guidelines.html – we have
 added a hacking rule in Neutron. If you wish to jump aboard this effort
 then please let me know. There are patches for all directories except the
 plugins and services.

 Thanks

 Gary

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


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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Stan Lagun
On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter zbit...@redhat.com wrote:

 It's actually potentially horrible, because you introduce potential
 quoting issues when you embed mistral workbooks in Heat templates or pass
 Heat templates to Murano.


Could you please give an example of template with such issue?
Also note that
a. YAQL uses only single quote marks (') for string while JSON uses double
quotes ()
b. If Mistral worbook is embedded into HOT template it should not be parsed
or interpreted anyway. Otherwise consider what would happen if that
workbook would in turn have HOT snippets embedded


Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

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


Re: [openstack-dev] [Heat] Heat Resource Plugin for third party storage

2014-11-12 Thread Pradip Mukhopadhyay
Thanks, Zane for pointing out the right mailing list.



--pradip


On Wed, Nov 12, 2014 at 6:35 PM, Zane Bitter zbit...@redhat.com wrote:

 The developer mailing list is not for usage questions. Please ask this on
 ask.openstack.org - I'm sure a lot of people will be interested in the
 answer and we want it searchable for them in future. Feel free to ping me
 with a link when you've posted it.

 cheers,
 Zane.

 On 12/11/14 06:00, Pradip Mukhopadhyay wrote:

 Hello,


 We come across this:
 http://docs.openstack.org/developer/heat/pluginguide.html


 Looks like it solves three of the purposes listed below:

 1. Define a custom resource type with properties and attributes
 2. Register the resource to the Hear orchestrator
 3. Write a driver/plugin (most likely the Life Cycle methods) which can
 create/manage the resources when encounter from the Heat orchestration
 engine.


 Am I right?


 Now the question is: in one place it is mentioned as:

 
 It defines methods corresponding to the life cycle as well as the basic
 hooks for plug-ins to handle the work of communicating with specific
 down-stream services
 


 Can this down-stream service be /anything/ (say a third-party storage
 array)? Or it has to be a OpenStack service only?




 Thanks in advance,
 Pradip



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



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

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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Ryan Brown


On 11/12/2014 07:50 AM, Zane Bitter wrote:
 On 12/11/14 06:48, Angus Salkeld wrote:
 (it's nice that there would be a consistent user experience
 between these projects -mistral/heat/murano).
 
 It's actually potentially horrible, because you introduce potential
 quoting issues when you embed mistral workbooks in Heat templates or
 pass Heat templates to Murano.

I think the intention here was to say there are two paths forward.

1) Add an intrinsic for first_nonnull, and every other task.
2) Add YAQL to let users build their own expressions.

And that (1) involves users learning the Heat way of munging their data
with intrinsics, while (2) encourages them to learn YAQL, which they can
use across Heat, Mistral, and Murano. This would be a better experience
since users would (in theory) spend less time looking up the domain
language for task X.

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Monty Taylor
On 11/12/2014 02:17 AM, Matthias Runge wrote:
 On 11/11/14 10:53, Jiri Tomasek wrote:
 Hey,

 Thanks for writing this up!
 
 The Storyboard project has successfully integrated these tools into
 the OpenStack CI environment.
 
 OpenStack CI and distributors are different, because OpenStack CI does
 not distribute software.


 Using javascript tooling (yeoman, grunt, bower, etc.) has this issue of
 being dependent on nodejs which if I recall correctly is causing
 problems for packagers as some versions of these tools require different
 nodejs versions - please Mathias correct me if I am wrong. I know this
 discussion has been here before, but using these tools is necessary for
 effective development. So we need to resolve the problem asap.
 Storyboard does not have this issue as it is infra thing.
 
 As far as I know, those tools don't require different nodejs versions.
 But: we can not have different node.js versions installed at the same
 time. I assume, this is true for all distributions. Creating and
 maintaining parallel installable versions just sucks and causes many issues.
 
 In the past, customers wanted the complete tool-chain to modify their
 version of dashboard. I understand, this is not an issue, for all
 companies not distributing software, but directly providing services
 based on that software.
 
 I will have to go through all dependencies and do a review, if those are
 acceptable for inclusion e.g in Fedora. The same is true for Thomas
 Goirand for inclusion in Debian.
 

 Petr Belanyi has added optional jshint install for js linting into
 Horizon and it installs nodejs as it depends on it. Could this approach
 work for our need of js tooling too? [1]
 
 Sigh, this nonsense doesn't go away? This is the third time the same
 issue comes up.
 
 jshint is NOT free software.
 
 https://github.com/jshint/jshint/blob/master/src/jshint.js#L19

Reasonable people disagree on this point. I, for one, am one of them. In
my opnion:

A usage clause in a license header is bonghits and unenforcable, as
copyright terms cover the legality of copying things, not how you use
them. For those terms to be enforcable, it would need to be a EULA,
which jshint does not have.

However, other people disagree with me, which is their prerogative.

I'm mainly suggesting that it's probably not nonsense, it's a
disagreement, and it's also probably not going to go away, since jshint
is far and away the most common javascript linting tool in existence.
Maybe some of the people who are vehemently opposed to the clause in the
license header should figure out an alternative.

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


Re: [openstack-dev] [Nova][DR][NFV] opnfv proposal on DR capability enhancement on OpenStack Nova

2014-11-12 Thread Zhipeng Huang
Hi Steve,

We are hammering out the details right now, and will send it out to the
community,like real soon :) Thanks for the comment!

On Wed, Nov 12, 2014 at 1:53 PM, Steve Gordon sgor...@redhat.com wrote:

 - Original Message -
  From: Zhipeng Huang zhipengh...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 
  Hi Team,
 
  I knew we didn't propose this in the design summit and it is kinda rude
 in
  this way to jam a topic into the schedule. We were really stretched thin
  during the summit and didn't make it to the Nova discussion. Full
 apologies
  here :)
 
  What we want to discuss here is that we proposed a project in opnfv (
  https://wiki.opnfv.org/collaborative_development_projects/rescuer),
 which
  in fact is to enhance inter-DC DR capabilities in Nova. We hope we could
  achieve this in the K cycle, since there is no HUGE changes required to
  be done in Nova. We just propose to add certain DR status in Nova so
  operators could see what DR state the OpenStack is currently in,
 therefore
  when disaster occurs they won't cut off the wrong stuff.
 
  Sorry again if we kinda barge in here, and we sincerely hope the Nova
  community could take a look at our proposal. Feel free to contact me if
  anyone got any questions :)
 
  --
  Zhipeng Huang

 Hi Zhipeng,

 I would just like to echo the comments from the opnfv-tech-discuss list
 (which I notice is still private?) in saying that there is very little
 detail on the wiki page describing what you actually intend to do. Given
 this, it's very hard to provide any meaningful feedback. A lot more detail
 is required, particularly if you intend to propose a specification based on
 this idea.

 Thanks,

 Steve

 [1] https://wiki.opnfv.org/collaborative_development_projects/rescuer


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




-- 
Zhipeng Huang
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402
OpenStack, OpenDaylight, OpenCompute affcienado
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Monty Taylor
On 11/12/2014 02:40 AM, Richard Jones wrote:
 On 12 November 2014 18:17, Matthias Runge mru...@redhat.com wrote:
 
 On 11/11/14 10:53, Jiri Tomasek wrote:
 Hey,

 Thanks for writing this up!

 The Storyboard project has successfully integrated these tools into
 the OpenStack CI environment.

 OpenStack CI and distributors are different, because OpenStack CI does
 not distribute software.

 
 Ah, I wasn't clear; my concern was whether the tools chosen would be
 compatible with the CI environment. I'm hoping that distribution of the
 tools isn't our concern (see below).
u
 Using javascript tooling (yeoman, grunt, bower, etc.) has this issue of
 being dependent on nodejs which if I recall correctly is causing
 problems for packagers as some versions of these tools require different
 nodejs versions - please Mathias correct me if I am wrong. I know this
 discussion has been here before, but using these tools is necessary for
 effective development. So we need to resolve the problem asap.
 Storyboard does not have this issue as it is infra thing.

 As far as I know, those tools don't require different nodejs versions.
 But: we can not have different node.js versions installed at the same
 time. I assume, this is true for all distributions. Creating and
 maintaining parallel installable versions just sucks and causes many
 issues.

 
 I believe the nodeenv method of installing node solves this, as it's
 entirely local to the development environment.
 

Just for the record, I believe that we should chose the tools that make
sense for making our software, as long as it's not physically impossible
for them to be packaged. This means we should absolutely not use things
that require multiple versions of node to be needed. The nodejs that's
in trusty is new enough to work with all of the modern javascript tool
chain things needed for this, so other than the various javascript tools
and libraries not being packaged in the distros yet, it should be fine.

That a bunch of javascript libraries will need to be distro pacakged
should not be a blocker (although I don't think that anyone is saying it
is) That is, after all, the important work the distros do. At this
point, given the popularity of javascript and javascript tooling, I'm
pretty sure the problem is going to have to be solved at some point.

 I will have to go through all dependencies and do a review, if those are
 acceptable for inclusion e.g in Fedora. The same is true for Thomas
 Goirand for inclusion in Debian.


 Petr Belanyi has added optional jshint install for js linting into
 Horizon and it installs nodejs as it depends on it. Could this approach
 work for our need of js tooling too? [1]

 Sigh, this nonsense doesn't go away? This is the third time the same
 issue comes up.

 jshint is NOT free software.

 https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
 https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
 
 
 They're trying to resolve that https://github.com/jshint/jshint/issues/1234
 
 But regardless, jshint doesn't have to be installed from a Linux
 repository; it's usually installed using npm alongside the other node tools.
 
 
 Richard
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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


Re: [openstack-dev] [cinder]How to do the cert test?

2014-11-12 Thread Ivan Kolodyazhny
Hi Liu,

3rd party CI isn't for driver cert test, it is for checking driver with
every review request to Cinder. Every driver vendor should setup own 3rd
party CI.

To get Cinder Driver Cert results you need to run cinder_driver_cert.sh
script from devstack repo (
https://github.com/openstack-dev/devstack/blob/master/driver_certs/cinder_driver_cert.sh
).




Regards,
Ivan Kolodyazhny

On Wed, Nov 12, 2014 at 5:21 AM, liuxinguo liuxin...@huawei.com wrote:


 I have read the related article in
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers, but I
 still have a little confused about the cert test:

 1. Should I run the the tempest (at https://github.com/openstack/tempest)
 in our own 3rd party CI test environment? Our 3rd party CI have already set
 up.
 2. How should I post the result and where to post?
 3. Is there any thing else should I do for our driver to passes the cert
 test and the results are posted?

 Thanks,

 Liu

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

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


[openstack-dev] [Nova] v2 or v3 for new api

2014-11-12 Thread Pasquale Porreca

Hello

I am working on an api for a new feature in nova, but I am wondering 
what is the correct way to add a new extension: should it be supported 
by v2, v3 or both?


BR

--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


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


Re: [openstack-dev] [Neutron] Translation technical debt

2014-11-12 Thread Romil Gupta
Hi Gary,

I posted the patch-set addressing ML2 plugin
https://review.openstack.org/#/c/130992/ .

I feel it is becoming long chain. It would be great we should first start
approving those patch-sets first rather than approving other bug-fix
related patch-set and ensure that all fulfills i18n translations.


On Wed, Nov 12, 2014 at 6:51 PM, Saro Chandra Bhooshan T.V. 
bhooshan.openst...@gmail.com wrote:

 count me also.

 On Wed, Nov 12, 2014 at 2:48 PM, Irena Berezovsky ire...@mellanox.com
 wrote:

  Count me in



 *From:* Gary Kotton [mailto:gkot...@vmware.com]
 *Sent:* Tuesday, November 11, 2014 3:47 PM
 *To:* OpenStack List
 *Subject:* [openstack-dev] [Neutron] Translation technical debt



 Hi,

 In order to enforce our translation policies -
 http://docs.openstack.org/developer/oslo.i18n/guidelines.html – we have
 added a hacking rule in Neutron. If you wish to jump aboard this effort
 then please let me know. There are patches for all directories except the
 plugins and services.

 Thanks

 Gary

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



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




-- 
*Regards,*

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Jiri Tomasek

On 11/12/2014 02:35 PM, Monty Taylor wrote:

On 11/12/2014 02:40 AM, Richard Jones wrote:

On 12 November 2014 18:17, Matthias Runge mru...@redhat.com wrote:


On 11/11/14 10:53, Jiri Tomasek wrote:

Hey,

Thanks for writing this up!

The Storyboard project has successfully integrated these tools into
the OpenStack CI environment.

OpenStack CI and distributors are different, because OpenStack CI does
not distribute software.


Ah, I wasn't clear; my concern was whether the tools chosen would be
compatible with the CI environment. I'm hoping that distribution of the
tools isn't our concern (see below).

u

Using javascript tooling (yeoman, grunt, bower, etc.) has this issue of
being dependent on nodejs which if I recall correctly is causing
problems for packagers as some versions of these tools require different
nodejs versions - please Mathias correct me if I am wrong. I know this
discussion has been here before, but using these tools is necessary for
effective development. So we need to resolve the problem asap.
Storyboard does not have this issue as it is infra thing.

As far as I know, those tools don't require different nodejs versions.
But: we can not have different node.js versions installed at the same
time. I assume, this is true for all distributions. Creating and
maintaining parallel installable versions just sucks and causes many
issues.


I believe the nodeenv method of installing node solves this, as it's
entirely local to the development environment.


Just for the record, I believe that we should chose the tools that make
sense for making our software, as long as it's not physically impossible
for them to be packaged. This means we should absolutely not use things
that require multiple versions of node to be needed. The nodejs that's
in trusty is new enough to work with all of the modern javascript tool
chain things needed for this, so other than the various javascript tools
and libraries not being packaged in the distros yet, it should be fine.

That a bunch of javascript libraries will need to be distro pacakged
should not be a blocker (although I don't think that anyone is saying it
is) That is, after all, the important work the distros do. At this
point, given the popularity of javascript and javascript tooling, I'm
pretty sure the problem is going to have to be solved at some point.

+1, I am really glad this has been said.



I will have to go through all dependencies and do a review, if those are

acceptable for inclusion e.g in Fedora. The same is true for Thomas
Goirand for inclusion in Debian.


Petr Belanyi has added optional jshint install for js linting into
Horizon and it installs nodejs as it depends on it. Could this approach
work for our need of js tooling too? [1]

Sigh, this nonsense doesn't go away? This is the third time the same
issue comes up.

jshint is NOT free software.

https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
https://github.com/jshint/jshint/blob/master/src/jshint.js#L19


They're trying to resolve that https://github.com/jshint/jshint/issues/1234

But regardless, jshint doesn't have to be installed from a Linux
repository; it's usually installed using npm alongside the other node tools.


 Richard



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



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


Jiri

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


Re: [openstack-dev] [cinder]How to do the cert test?

2014-11-12 Thread Duncan Thomas
If you have tempest running in the third party CI with every commit,
you don't need a cert test result. The CI is very much the preferred
method.

To post a result, open a bug with 'Huawei XXX  driver cert result; and
the logs attached.

Other than, that, it is just a matter of waiting for reviews. The spec
looks fine, people will get to the driver shortly.



On 12 November 2014 05:21, liuxinguo liuxin...@huawei.com wrote:

 I have read the related article in 
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers, but I still 
 have a little confused about the cert test:

 1. Should I run the the tempest (at https://github.com/openstack/tempest) in 
 our own 3rd party CI test environment? Our 3rd party CI have already set up.
 2. How should I post the result and where to post?
 3. Is there any thing else should I do for our driver to passes the cert 
 test and the results are posted?

 Thanks,

 Liu

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



-- 
Duncan Thomas

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


[openstack-dev] [all] python-troveclient keystone v3 support breaking the world

2014-11-12 Thread Sean Dague
https://review.openstack.org/#/c/102315/ was merged yesterday, it
creates a non functional trove python client. (There are currently no
tests in python trove client to see if the commands even run after a
code change).

This means the trove devstack exercise can't work.

Which means everything testing cells (oslo.db, nova, glance, heat, etc)
can't pass any changes.

I've proposed 2 fixes.

1) just delete the trove exercise so we can move forward -
https://review.openstack.org/#/c/133930 - that will need to be
backported as well.

2) revert the troveclient change -
https://review.openstack.org/#/c/102315/ (which I think also should be
done) and not repropose until there are actual tests in the troveclient
tree to prevent this kind of breakage.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] URLs

2014-11-12 Thread Anton Zemlyanov
For the REST API to be visible from browser it should either be on the same
domain and port or it should implement CORS spec (Cross-site HTTP requests,
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS).

If REST API implements CORS, then every HTTP request will be preceded with
OPTIONS request to check the real invocation is allowed. In practice, all
the API services are usually proxied from a single location, so URL naming
scheme is very desirable.

Anton

On Wed, Nov 12, 2014 at 3:21 PM, Darren Kenny darren.ke...@oracle.com
wrote:

 Chris Dent wrote:

 On Tue, 11 Nov 2014, Adam Young wrote:

  My suggestion, from a while ago, was to have a naming scheme that
 deconflicts putting all of the services onto a single server, on port 443.


 +1

 The current state of affairs is indeed weird.


 It is, and as BUIs move more towards client's doing the access of the
 URLs, it
 is something we need to fix - since most browsers restrict cross-domain
 access (including different ports on the same host) for security reasons.

 This is the reason that the Horizon guys wrote a kind of reverse-proxy
 WSGI to enable demonstrations of the AngularJS work last week - so that
 all the REST API calls were back to the origin of Horizon itself.


 Is this something that ought to be considered in the api-wg's
 discussions?


 That would appear to fit within the aims of that working group.

 Thanks,

 Darren.



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

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


Re: [openstack-dev] [all] python-troveclient keystone v3 support breaking the world

2014-11-12 Thread Sean Dague
On 11/12/2014 09:17 AM, Sean Dague wrote:
 https://review.openstack.org/#/c/102315/ was merged yesterday, it
 creates a non functional trove python client. (There are currently no
 tests in python trove client to see if the commands even run after a
 code change).
 
 This means the trove devstack exercise can't work.
 
 Which means everything testing cells (oslo.db, nova, glance, heat, etc)
 can't pass any changes.
 
 I've proposed 2 fixes.
 
 1) just delete the trove exercise so we can move forward -
 https://review.openstack.org/#/c/133930 - that will need to be
 backported as well.
 
 2) revert the troveclient change -
 https://review.openstack.org/#/c/102315/ (which I think also should be
 done) and not repropose until there are actual tests in the troveclient
 tree to prevent this kind of breakage.
 
   -Sean
 

The bug in question - http://status.openstack.org/elastic-recheck/#1391840

-Sean

-- 
Sean Dague
http://dague.net

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


[openstack-dev] [Neutron][ML2] no ML2 IRC meeting today

2014-11-12 Thread Robert Kukura
Let's skip the ML2 IRC meeting this week, while some people are still 
traveling and/or recovering. Next week I hope to have good discussions 
regarding a common ML2 driver repo vs. separate repos per vendor, as 
well as the ML2 BPs for Kilo.


-Bob


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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Zane Bitter

On 12/11/14 08:24, Stan Lagun wrote:


On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:

It's actually potentially horrible, because you introduce potential
quoting issues when you embed mistral workbooks in Heat templates or
pass Heat templates to Murano.


Could you please give an example of template with such issue?


I don't have one to hand, but we'd want to prove that such an issue 
*can't* happen before implementing this.



Also note that
a. YAQL uses only single quote marks (') for string while JSON uses
double quotes ()
b. If Mistral worbook is embedded into HOT template it should not be
parsed or interpreted anyway. Otherwise consider what would happen if
that workbook would in turn have HOT snippets embedded


That's exactly the problem I'm talking about. If you have a HOT snippet 
embedded in a Mistral workbook embedded in a HOT template passed to 
Murano, can you guarantee that each piece of YAQL will be interpreted 
only in exactly the right place? Will the user be able to predict where 
that will be? My brain hurts just thinking about it.


We can protect other formats from Heat by wrapping an intrinsic function 
around the YAQL; I'm not certain that HOT would be protected from 
Mistral and Murano in the same way, because this wasn't previously a 
design goal for them.


cheers,
Zane.

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


Re: [openstack-dev] [Neutron] Provider Router topology

2014-11-12 Thread Jaume Devesa
Hello Salvatore,

thanks for the response. Rest of the responses inline:

El 12/11/14 a las 10:49, Salvatore Orlando escribió:
 Hi Jaume,
 
 The concept of provider router is useful as it maps what actually already
 happens in several infrastructures. I am not entirely sure that this
 however implies we need to expose new API constructs and change the
 topology API.
Our first mistake was to use the word 'Provider Router' for the spec.
Maybe the 'edge' concept was better. We don't mean to add or substitute
functionality for the current Provider Router, but offer a different
topology without the need to define an External Network to provide a
public floating range, or even a public routable for IPv6 use cases.

 
 The provider router perhaps can exist in a concealed way, where tenants
 still put gateways on an external network, but that would be implemented
 with a provider router.
 
 Anyway, I am sure you are aware of the technical debt repayment activities
 scheduled for Kilo. Some of them pertain the l3 agent [1], and I'd say
 those have the highest priority. If this spec will bring non-negligible
 changes in the l3 agent, perhaps it's the case of doing that after the
 agent restructuring to avoid conflicts which will slow down everything.
I am. Actually I'm willing to collaborate on it.

 
 Finally, can you post the specification for this work in gerrit? It seems
 it is not the one under the 'edge router' name [2]
I changed the blueprint URL and I forgot to update this spec. I'll
update it in a few days.

 
 Salvatore
 
 [1] https://review.openstack.org/#/c/131535/
 [2] https://review.openstack.org/128272
 
 On 31 October 2014 10:01, Jaume Devesa devv...@gmail.com wrote:
 
 Hi all,

 in Midokura we are working on a blueprint to define a new kind of topology
 for floating ranges, as alternative to external network topology. It is
 based on the idea of a Provider Router that links directly with Tenant
 Routers using /30 networks. It aims to be more pure-floating, helping the
 deployment of floating ranges across different physical L2 Networks. (We
 know there is some interest in this[1]) We think that also it might help in
 add Firewall specific policies at the edge of the cloud and define
 per-tenant or per-network QoS definitions.

 Document[2] is still WIP, with high level ideas and just some API details.
 But we would love to hear Neutron community feedback to go further in a
 steady way. In the implementation level, we are concerned in being
 compatible with current DVR and don't add a new SPOF in Neutron OVS plugin.
 So DVR developers feedback would be highly appreciated.

 We are also interested in chat about it during the summit, maybe during
 the Kilo L3 refractor BoF? [3]

 Thanks in advance!

 PD: Blueprint is here[4]

 [1]: https://blueprints.launchpad.net/neutron/+spec/pluggable-ext-net
 [2]:
 https://docs.google.com/a/midokura.com/document/d/1fUPhpBWpiUvBe_c55lkokDIls--4dKVSFmGVtjxjg0w/edit#
 [3]: https://etherpad.openstack.org/p/kilo-l3-refactoring
 [4]:
 https://blueprints.launchpad.net/neutron/+spec/neutron-provider-router


 --
 Jaume Devesa
 Software Engineer at Midokura

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


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

-- 
Jaume Devesa
Software Engineer, Midokura

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


Re: [openstack-dev] [all] python-troveclient keystone v3 support breaking the world

2014-11-12 Thread Amrith Kumar
Sean, I'm looking into this and have proposed 
https://review.openstack.org/#/c/133958/ as an interim measure. As soon as the 
trove gate passes I'll try and get a couple of other votes and have that change 
merged.

Dims and I had a short chat on IRC and weren't able to come up with a quick 
solution to the problem; I think the change you identified needs to be reworked.

More to come.

-amrith

| -Original Message-
| From: Sean Dague [mailto:s...@dague.net]
| Sent: Wednesday, November 12, 2014 9:22 AM
| To: OpenStack Development Mailing List (not for usage questions)
| Subject: Re: [openstack-dev] [all] python-troveclient keystone v3 support
| breaking the world
| 
| On 11/12/2014 09:17 AM, Sean Dague wrote:
|  https://review.openstack.org/#/c/102315/ was merged yesterday, it
|  creates a non functional trove python client. (There are currently no
|  tests in python trove client to see if the commands even run after a
|  code change).
| 
|  This means the trove devstack exercise can't work.
| 
|  Which means everything testing cells (oslo.db, nova, glance, heat,
|  etc) can't pass any changes.
| 
|  I've proposed 2 fixes.
| 
|  1) just delete the trove exercise so we can move forward -
|  https://review.openstack.org/#/c/133930 - that will need to be
|  backported as well.
| 
|  2) revert the troveclient change -
|  https://review.openstack.org/#/c/102315/ (which I think also should be
|  done) and not repropose until there are actual tests in the
|  troveclient tree to prevent this kind of breakage.
| 
|  -Sean
| 
| 
| The bug in question - http://status.openstack.org/elastic-recheck/#1391840
| 
|   -Sean
| 
| --
| Sean Dague
| http://dague.net
| 
| ___
| OpenStack-dev mailing list
| OpenStack-dev@lists.openstack.org
| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


[openstack-dev] [Fuel] NTP settings.

2014-11-12 Thread Stanislaw Bogatkin
Hi all,
Today we have a next workflow about NTP in Fuel:

1. When someone deploy a master node, we need to somehow operate with NTP
and set upstream NTP servers to Fuel NTP daemon on master node.
2. NTP will enabled by default and set to default upstream values (from
ntp.org pool).
3. If user will enter to fuelmenu then then he can change that values and
it will stored as new ones.

That can lead to some errors at deploy, some as:
1. User set upstream NTP (or use defaults).
2. By some reasons that NTP servers get unreacheable (i.e. network down).
3. User creates environment and push 'deploy' button.
4. In the middle of deploy process upstream NTP become reacheable and
master node sync with them.
If time on master node before that sync will have big shift regarding to
real time, then we will have 2 problems:
1. Deploy can fail, cause slave nodes will sync with master one time only -
right after provisioning and if master node resync with upstream in the
middle of deploy - some services can stop works (e.g. mcollective).
3. It will be more complicate to understand logs, cause it will shifted too.

As I see, we have two ways to solve this:
1. Check upstream NTP reachability and disable upstream servers if they
unreachable at fuelmenu step. It will cost us some shift with real time in
the end.

 or

2. Disable NTP upstream servers if they unreachable right after user press
'deploy' button and enable them after deploy is over.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Clint Byrum
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
 On 11/11/14 13:34, Ryan Brown wrote:
  I am strongly against allowing arbitrary Javascript functions for
  complexity reasons. It's already difficult enough to get meaningful
  errors when you  up your YAML syntax.
 
 Agreed, and FWIW literally everyone that Clint has pitched the JS idea 
 to thought it was crazy ;)
 

So far nobody has stepped up to defend me, so I'll accept that maybe
people do think it is crazy. What I'm really confused by is why we have
a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),
and that would somehow be less crazy than a well known mature language
that has always been meant for embedding such as javascript.

Anyway, I'd prefer YAQL over trying to get the intrinsic functions in
HOT just right. Users will want to do things we don't expect. I say, let
them, or large sections of the users will simply move on to something
else.

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Jiri Tomasek

On 11/11/2014 08:02 AM, Richard Jones wrote:

Hi all,

At the summit last week, we developed a plan for moving forward with 
modernising Horizon's UI using AngularJS. If you weren't at that 
meeting and are interested in helping out with this effort please let 
me know!


The relevant etherpad from the meeting:
https://etherpad.openstack.org/p/kilo-horizon-contributors-meetup

TL;DR: piece by piece we will replace Django views in Horizon with 
angular views, and we're going to start with Identity


First up, I'd like to ask the UX folk who raised their hands in that 
meeting to indicate which of the Identity panes we should start with. 
I believe a wizard was mentioned, as a way to exercise the new wizard 
code from Maxime.


At the same time, I'm looking at updating the AngularJS 
recommendations in the wiki. I believe other aspects of the current 
approach to angular code should also be revisited, if we're to scale 
up to the full angular front-end envisaged. I'd appreciate if those 
interested in this aspect in particular could contact me so we can 
sort this out as a team!


I'd like to start the design work for the new REST API layer we'll be 
exposing to the angular application code, but that is also part of the 
broader discussion about the structure of the angular code in the 
Horizon application as mentioned above. Should it be a new blueprint/spec?


There were some discussions around tooling. We're using xstatic to 
manage 3rd party components, but there's a lot missing from that 
environment. I hesitate to add supporting xstatic components on to the 
already large pile of work we have to do, so would recommend we switch 
to managing those components with bower instead. For reference the 
list of 3rd party components I used in angboard* (which is really only 
a teensy fraction of the total application we'd end up with, so this 
components list is probably reduced):


json3
es5-shim
angular
angular-route
angular-cookies
angular-animate
angular-sanitize
angular-smart-table
angular-local-storage
angular-bootstrap
angular-translate
font-awesome
boot
underscore
ng-websocket

Just looking at PyPI, it looks like only a few of those are in 
xstatic, and those are out of date.


grunt provides a lot of features for developing an angular interface. 
In particular LiveReload accelerates development significantly. 
There's a django-livereload but it uses tiny-lr under the hood, so 
we're still using a node application for LiveReload support... so it 
might make sense to just use grunt. grunt provides many other features 
as well (wiredep integration with bower, build facilities with ngMin, 
test monitoring and reload etc).


There seemed to be agreement to move to jasmine (from qunit) for 
writing the tests. It's not noted in the etherpad, but I recall karma 
was accepted as a given for the test runner. For those not in the 
meeting, angboard uses mocha+chai for test writing, but I agreed that 
jasmine is acceptable, and is already used by Storyboard (see below).


Also, phantomjs so we don't have to fire up a browser for exercising 
(what should hopefully be an extensive) unit test suite.


The Storyboard project has successfully integrated these tools into 
the OpenStack CI environment.



 Richard

* https://github.com/r1chardj0n3s/angboard


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



I am going to try to conclude what has been said in emails across this 
thread.


As Monty Taylor said, nodejs itself is not a blocker as multiple 
versions of it should not be needed by our tools. (That's also what npm 
and bower are taking care of, right?) Only thing that is required is 
that all tools/js libs we want to use would eventually have to be 
packaged. This is just a bunch of work for packagers.



Approach on using Xstatic packages vs Js tooling:

As only problem with using js tooling should be just actual packaging of 
it, I think it makes sense to use these tools and make development 
simpler then going other way around and using Xstatic packages - which 
means devs would have to care about getting stuff packaged as xstatic 
and added to the code, while maintaining proper versions and making sure 
that they work ok together. NPM and Bower do this for us. Common sense 
tells me packagers should take care of packaging.
Packaging of these tools will have to get resolved somehow anyway, as 
there will be rise in requirements of using them not just from Horizon...



Which tools should we use eventually:

Based on the contributions by Maxime, Martin and the others, I think the 
list of tools should end up as follows:


Tooling:
npm
bower
gulp
Jasmine
Karma/Protractor(?)/eslint
...?

Bower and Gulp seems to get along well 
(https://github.com/yeoman/generator-gulp-webapp)


Tastypie on the Django side

Angular 

Re: [openstack-dev] [Fuel] NTP settings.

2014-11-12 Thread Andrew Woodward
Should we just block the deployment until the NTP is fixed so they
know they need to fix it?

On Wed, Nov 12, 2014 at 6:06 PM, Stanislaw Bogatkin
sbogat...@mirantis.com wrote:
 Hi all,
 Today we have a next workflow about NTP in Fuel:

 1. When someone deploy a master node, we need to somehow operate with NTP
 and set upstream NTP servers to Fuel NTP daemon on master node.
 2. NTP will enabled by default and set to default upstream values (from
 ntp.org pool).
 3. If user will enter to fuelmenu then then he can change that values and it
 will stored as new ones.

 That can lead to some errors at deploy, some as:
 1. User set upstream NTP (or use defaults).
 2. By some reasons that NTP servers get unreacheable (i.e. network down).
 3. User creates environment and push 'deploy' button.
 4. In the middle of deploy process upstream NTP become reacheable and master
 node sync with them.
 If time on master node before that sync will have big shift regarding to
 real time, then we will have 2 problems:
 1. Deploy can fail, cause slave nodes will sync with master one time only -
 right after provisioning and if master node resync with upstream in the
 middle of deploy - some services can stop works (e.g. mcollective).
 3. It will be more complicate to understand logs, cause it will shifted too.

 As I see, we have two ways to solve this:
 1. Check upstream NTP reachability and disable upstream servers if they
 unreachable at fuelmenu step. It will cost us some shift with real time in
 the end.

  or

 2. Disable NTP upstream servers if they unreachable right after user press
 'deploy' button and enable them after deploy is over.

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




-- 
Andrew
Mirantis
Ceph community

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


Re: [openstack-dev] [Keystyone] Mid-Cycle Meetup Planning

2014-11-12 Thread Brad Topol
I have filled out the form and very much look forward to attending!!!


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Morgan Fainberg morgan.fainb...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org, 
Date:   11/11/2014 08:20 PM
Subject:[openstack-dev] [Keystyone] Mid-Cycle Meetup Planning



I am trying to pin down a location for our mid-cycle meetup, I need to get 
an idea of who will be joining us at the Keystone meetup. I’ve included a 
couple questions relating to Barbican in the case we can double-up and 
have a day of overlap like the Juno meetup. I apologize for the delay, 
this should have been sent out by the end of the summit or earlier. As 
details are available I’ll provide updates.

Due to timing (so that people can get visas, get travel approval, etc as 
soon as possible), I will be making a final call on dates by the end of 
this week and location as soon as the space is confirmed, so your prompt 
responses are super important!

http://goo.gl/forms/4W7xVM9x49

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


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


Re: [openstack-dev] [Fuel] NTP settings.

2014-11-12 Thread Matthew Mosesohn
Andrew,
That just shifts the error into Nailgun which is forced to examine NTP
settings of the host. With docker containerization, it makes detecting
this much more difficult. Erroring during fuelmenu is the only chance
where a user can effectively set the NTP parameters correctly. We
could write a ton of infrastructure around this capability, but all it
wins us is a more beautiful error that blocks a user from proceeding.

On Wed, Nov 12, 2014 at 7:21 PM, Andrew Woodward xar...@gmail.com wrote:
 Should we just block the deployment until the NTP is fixed so they
 know they need to fix it?

 On Wed, Nov 12, 2014 at 6:06 PM, Stanislaw Bogatkin
 sbogat...@mirantis.com wrote:
 Hi all,
 Today we have a next workflow about NTP in Fuel:

 1. When someone deploy a master node, we need to somehow operate with NTP
 and set upstream NTP servers to Fuel NTP daemon on master node.
 2. NTP will enabled by default and set to default upstream values (from
 ntp.org pool).
 3. If user will enter to fuelmenu then then he can change that values and it
 will stored as new ones.

 That can lead to some errors at deploy, some as:
 1. User set upstream NTP (or use defaults).
 2. By some reasons that NTP servers get unreacheable (i.e. network down).
 3. User creates environment and push 'deploy' button.
 4. In the middle of deploy process upstream NTP become reacheable and master
 node sync with them.
 If time on master node before that sync will have big shift regarding to
 real time, then we will have 2 problems:
 1. Deploy can fail, cause slave nodes will sync with master one time only -
 right after provisioning and if master node resync with upstream in the
 middle of deploy - some services can stop works (e.g. mcollective).
 3. It will be more complicate to understand logs, cause it will shifted too.

 As I see, we have two ways to solve this:
 1. Check upstream NTP reachability and disable upstream servers if they
 unreachable at fuelmenu step. It will cost us some shift with real time in
 the end.

  or

 2. Disable NTP upstream servers if they unreachable right after user press
 'deploy' button and enable them after deploy is over.

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




 --
 Andrew
 Mirantis
 Ceph community

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

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


[openstack-dev] [Fuel] Default templates for Sahara feature in 6.0

2014-11-12 Thread Dmitry Mescheryakov
Hello fuelers,

I would like to request you merging CR [1] which implements blueprint [2].
It is a nice UX feature we really would like to have in 6.0. On the other
side, the implementation is really small: it is a small piece of puppet
which runs a shell script. The script always exits with 0, so the change
should not be dangerous. Other files in the change are used in the shell
script only. Please consider reviewing and merging this though we've
already reached FF.

Thanks,

Dmitry

[1] https://review.openstack.org/#/c/132196/
[2]
https://blueprints.launchpad.net/mos/+spec/sahara-create-default-templates
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][all] Alembic migrations for SQLite

2014-11-12 Thread Doug Hellmann

On Nov 12, 2014, at 5:12 AM, Victor Sergeyev vserge...@mirantis.com wrote:

 Great job, Mike, thanks!
 
 Doug, as for migration from sqlalchemy-migrate to Alembic - at the moment 
 it's hard to realize this because we suppose to keep backward compatibility 
 with available migrations. I'd like to re-review existing approach with Mike 
 and Roman, create road-map for this migration, and try to migrate one of the 
 projects as Proof-Of-Concept.

The plan we came up with before was to stop adding new sqlalchemy-migrate 
migrations and start adding new ones with Alembic. We would then run both tools 
(sqlalchemy-migrate followed by alembic) to apply all migrations. When the 
older migrations can be deprecated, we can drop the sqlalchemy-migrate step. 

I thought we were still on track to follow that plan. Have you identified an 
issue that would prevent us from starting the cut-over to writing alembic 
migrations for L or M?

Doug

 
 On Tue, Nov 11, 2014 at 5:58 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 On Nov 10, 2014, at 10:55 AM, Mike Bayer mba...@redhat.com wrote:
 
  Bonjour openstackers -
 
  While you were all sipping champagne on the Champs-Élysées, I took some 
  time to tackle one of the two most critically wanted features in Alembic, 
  which is that of being able to migrate tables on a SQLite database with 
  some degree of sanity.   My immediate focus on Alembic was spurred on 
  partially because some changes to the test suite pushed it into 0.7.0, and 
  then we got a very large number of bug fixes in, so the urgency to get 
  0.7.0 is relatively high; but what good is a pseudo-major point release 
  without some big new features ?
 
  The feature works similarly to that of SQLAlchemy-Migrate, but I’m hoping 
  in a way that is more controllable and open-ended.   I would encourage all 
  those interested to take a look at the basic mode of operation over at 
  http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases.
 Highlights include that several table operations can take place within 
  one “move and copy” operation at once, and the system can also be applied 
  to other databases if one so desired (not a common use case but some have 
  expressed interest in this being possible…so it is!).   The format of a 
  SQLite-compatible migration script will change slightly, though for the 
  better as per-table operations are grouped together, and the scripts of 
  course in the default case continue to work exactly as before on all other 
  target databases.
 
 This sounds great, Mike, and I’m sure it will make it much easier for us to 
 use sqlite databases for unit/functional tests.
 
 
  I know that a handful of projects have moved or started with Alembic, and 
  I’d like to continue pushing Alembic to be the single solution across all 
  projects.  There’s some work in oslo.db to define a common environmental 
  format as well (see https://review.openstack.org/#/c/112842/).  I would 
  encourage projects to continue to evaluate moving their migrations over to 
  Alembic at some point in the future, which should also include sending me 
  emails/ircs/bug reports about what additional features/fixes are needed.
 
 I want to stress this. We ran into issues with sqlalchemy-migrate during 
 Juno, and we’re having an increasingly difficult time finding reviewers even 
 though OpenStack (not Oslo) has adopted the library. The Oslo team is working 
 on improving Alembic support with the intent to deprecate support for 
 sqlalchemy-migrate in the “near future” (not Kilo). Please work with Mike, 
 Viktor, Roman, and the rest of the oslo.db team to identify any holes that 
 would delay your ability to start using alembic for new migrations in the 
 next release cycle.
 
 
  The next major feature for Alembic, which I will tentatively use this week 
  to see if I can get it online, is the multiple heads/branch resolution 
  feature 
  (https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support)
   which a *lot* of people are really asking for.   This feature would allow 
  independent migration series to coexist simultaneously, as well “merge 
  point” migrations that join disparate branches back into a single stream.   
  The risk level for this feature is significantly higher than that of the 
  SQLite migration feature, as while the SQLite migration feature lives 
  entirely within a new API that is otherwise unused, the multiple branch 
  feature makes some fundamental changes to how versioning is performed.   So 
  while I’d like to get this in 0.7.0 as well, if it gets into the weeds I 
  may have to push 0.7.0 without it as there’s really a crapload of other 
  fixes to be pushed.
 
  Thanks for reading!
 
  - mike
 
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] URLs

2014-11-12 Thread Dean Troyer
On Wed, Nov 12, 2014 at 4:11 AM, Chris Dent chd...@redhat.com wrote:

 The current state of affairs is indeed weird.

 Is this something that ought to be considered in the api-wg's
 discussions?


It does and I think that is where the proposed mapping of URL-to-API should
reside.  Proposed at least until it is actually implemented.

FWIW, I've played with this in the past in DevStack using mod_rewrite and
IIRC there is (may be) some proxy-like transformations required.  I don't
recall the details but I'll dig up that branch and see where things are ATM.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Stan Lagun
My point is that quoting problem do exists probably but it exists even
without YAQL being used anywhere.
For example consider Mistral workbook containing value: { get_attr:
[my_instance, first_address] }. get_attr in Mistral may have nothing to to
with Heat's get_attr and even if it is it may be just a HOT snippet that
cannot be evaluated at the moment. For example it may be part of a HOT
template embedded into Mistral workbook and Mistral workflow is going to
create another Heat stack using that template. Now if you embed such
workbook into HOT template (and thus get HOT embedded into Mistral embedded
into HOT :) ) you need to make sure that Heat's parser is not going to try
to parse that workbook but treats it like a black box. This is regardless
of YAQL being even exist. But if you treat workbooks like
black-boxes/arbitrary JSON you should not care if it contains YAQL or not.

As for Murano this may cause some problems in cases when someone just took
YAML HOT and copy-paste it into MuranoPL class without double-checking. But
those errors can be easily fixed and such issues do exist even with current
HOT syntax without YAQL being used at all.

What I'm really confused by is why we have
 a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),


YAQL syntax is almost identical to Python's or JS if you narrow them to
one-line expressions. The only noticeable difference is that all
variable/parameter names are prefixed with '$' as in PHP/Perl which are
both popular languages. I can hardly imagine why such negligible difference
from JS or Python (languages you do like) makes language weird ugly

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

sla...@mirantis.com

On Wed, Nov 12, 2014 at 6:10 PM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
  On 11/11/14 13:34, Ryan Brown wrote:
   I am strongly against allowing arbitrary Javascript functions for
   complexity reasons. It's already difficult enough to get meaningful
   errors when you  up your YAML syntax.
 
  Agreed, and FWIW literally everyone that Clint has pitched the JS idea
  to thought it was crazy ;)
 

 So far nobody has stepped up to defend me, so I'll accept that maybe
 people do think it is crazy. What I'm really confused by is why we have
 a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),
 and that would somehow be less crazy than a well known mature language
 that has always been meant for embedding such as javascript.

 Anyway, I'd prefer YAQL over trying to get the intrinsic functions in
 HOT just right. Users will want to do things we don't expect. I say, let
 them, or large sections of the users will simply move on to something
 else.

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

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


[openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-12 Thread Matthew Booth
I'm currently investigating the feasibility of a generic
compare-and-swap feature for NovaObject.save(). This post isn't about
that, but that's the larger context.

As a preliminary step towards that goal, I've started by investigating
how Nova objects are saved today. Ideally there would be some
consistency in how objects are saved, but unfortunately that's not there
today. An initial inconsistency I have noticed is that some objects
refresh themselves from the database when calling save(), but others don't.

For brevity, I have conflated what happens in object.save() with what
happens in db.api. Where the code lives isn't relevant here: I'm only
looking at what happens.

Specifically, the following objects refresh themselves on save:

Aggregate
BlockDeviceMapping
ComputeNode
FloatingIP
Instance
InstanceGroup
Migration
Network
PciDevice
SecurityGroup
Service

whereas the following objects do not:

Flavor
Agent
FixedIP
InstanceInfoCache
InstancePCIRequest

Excluding irrelevant complexity, the general model for objects which
refresh on update is:

object = select row from object table
object.update()
object.save()
return select row from object table again

Some objects skip out the second select and return the freshly saved
object. That is, a save involves an update + either 1 or 2 selects.

The lack of consistency in behaviour is obviously a problem, and I can't
think of any good reason for a second select for objects which do that.
However, I don't think it is good design for save() to refresh the
object at all, and the reason is concurrency. The cached contents of a
Nova object are *always* potentially stale. A refresh does nothing to
change that, because the contents are again potentially stale as soon as
it returns. Handling this requires concurrency primitives which we don't
currently have (see the larger context I mentioned above). Refreshing an
object's contents might reduce the probability of a race, but it doesn't
fix it. Callers who want a refresh after save can always call
object.refresh(), but for others it's just wasted hits on the db.

Refresh on save() is also arbitrary. Why should the object be updated
then rather than at any other time? The timing of an update in thread X
is unrelated to the timing of an update in thread Y, but it's a problem
whenever it happens.

Can anybody see a problem if we didn't fetch the row at all, and simply
updated it? Absent locking or compare-and-swap this is effectively what
we're already doing, and it reduces the db cost of save to a single
update statement. The difference would be that the object would remain
stale without an explicit refresh(). Value munging would remain unaffected.

Additionally, Instance, InstanceGroup, and Flavor perform multiple
updates on save(). I would apply the same rule to the sub-updates, and
also move them into a single transaction such that the updates are atomic.

Thanks,

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Julie Pichon
On 12/11/14 15:12, Jiri Tomasek wrote:
 Approach on using Xstatic packages vs Js tooling:
 
 As only problem with using js tooling should be just actual packaging of
 it, I think it makes sense to use these tools and make development
 simpler then going other way around and using Xstatic packages - which
 means devs would have to care about getting stuff packaged as xstatic
 and added to the code, while maintaining proper versions and making sure
 that they work ok together. NPM and Bower do this for us. Common sense
 tells me packagers should take care of packaging.
 Packaging of these tools will have to get resolved somehow anyway, as
 there will be rise in requirements of using them not just from Horizon...

I can't speak for the rest but that part doesn't seem correct to me. The
XStatic packages are Python packages (as in, dependencies) that the
Horizon team is responsible for (when they don't already exist) and
maintains on stackforge, so we do have to create them and make sure they
all work well together. The later packaging as rpm or deb or others is
left to the distro packagers of course.

There are instructions already on how to create xstatic packages [1],
it's not very complicated and just takes some review time.

Thanks,

Julie

[1]
http://docs.openstack.org/developer/horizon/contributing.html#javascript-and-css-libraries


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


Re: [openstack-dev] [Mistral] Event Subscription

2014-11-12 Thread W Chan
Nikolay,

You're right.  We will need to store the events in order to re-publish.
How about a separate Event model?  The events are written to the DB by the
same worker that publishes the event.  The retention policy for these
events is then managed by a config option.

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


Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-12 Thread Dan Smith
 An initial inconsistency I have noticed is that some objects refresh 
 themselves from the database when calling save(), but others don't.

I agree that it would be ideal for all objects to behave the same in
this regard. I expect that in practice, it's not necessary for all
objects to do this, and since it is an extra step/query in some places,
it's not without cost to just always refresh (there is no reason to
refresh a Flavor object AFAIK, for instance).

 The lack of consistency in behaviour is obviously a problem, and I 
 can't think of any good reason for a second select for objects which 
 do that. However, I don't think it is good design for save() to 
 refresh the object at all, and the reason is concurrency. The cached 
 contents of a Nova object are *always* potentially stale. A refresh 
 does nothing to change that, because the contents are again 
 potentially stale as soon as it returns. Handling this requires 
 concurrency primitives which we don't currently have (see the larger 
 context I mentioned above). Refreshing an object's contents might 
 reduce the probability of a race, but it doesn't fix it. Callers who 
 want a refresh after save can always call object.refresh(), but for 
 others it's just wasted hits on the db.

Doing a refresh() after a save() is more than just another DB hit, it's
another RPC round-trip, which is far more expensive.

There is a lot of code in the compute manager (and elsewhere I'm sure)
that expects to get back the refreshed object after a save (our instance
update functions have always exhibited this behavior, so there is code
built to expect it). Any time something could change async on the object
that might affect what we're about to do will benefit from this implicit
refreshing. A good example is when we're doing something long-running on
an instance and it is deleted underneath us. If we didn't get the
deleted=True change after a save(), we might go continue doing a lot of
extra work before we notice it the next time.

It's not that doing so prevents the object's contents from being stale,
it's that it reduces the amount of time before we notice a change, and
avoids us needing to explicitly check. Any code we have that can't
tolerate the object being stale is broken anyway.

 Refresh on save() is also arbitrary. Why should the object be updated
 then rather than at any other time? The timing of an update in thread
 X is unrelated to the timing of an update in thread Y, but it's a
 problem whenever it happens.

Because it's not about cache consistency, it's about the expense
required to do any of these things. To save(), we *have* to make the
round-trip, so why not get a refresh at the same time? In cases where we
explicitly want to refresh, we call refresh(), but otherwise we use
natural synchronization points like save() to do that.

 Can anybody see a problem if we didn't fetch the row at all, and 
 simply updated it? Absent locking or compare-and-swap this is 
 effectively what we're already doing, and it reduces the db cost of 
 save to a single update statement. The difference would be that the 
 object would remain stale without an explicit refresh(). Value 
 munging would remain unaffected.

At least for instance, I don't want to do away with the implicit
refreshing. I would be up for any of these options:

1. Documenting which objects do and don't auto-refresh
2. Making the case for non-Instance objects to not auto-refresh
3. Making them all auto-refresh for consistency, with the appropriate
   re-tooling of the db/api code to minimize performance impact.

 Additionally, Instance, InstanceGroup, and Flavor perform multiple 
 updates on save(). I would apply the same rule to the sub-updates, 
 and also move them into a single transaction such that the updates 
 are atomic.

Yep, no complaints about fixing these non-atomic updates, of course :)

--Dan



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


[openstack-dev] oslo.vmware release 0.7.0

2014-11-12 Thread Doug Hellmann
The Oslo team is pleased to announce the release of oslo.vmware 0.7.0.

This release includes several bug fixes 
(https://launchpad.net/oslo.vmware/+milestone/0.7.0) as well as many other 
changes:


1661a0a Updated from global requirements
33f6002 Imported Translations from Transifex
8b1f97b Do not log when reraising an exception
575fd70 Imported Translations from Transifex
0b7ff54 Updated from global requirements
8ed3d53 Add unit test for VC 5.1 web fault handling
776c20d Fix to get exception detail with vCenter 5.1
62d0ba7 Download image API to bypass vCenter
6aa427d Updated from global requirements
84a39fb Updated from global requirements
e25af91 Enable the PBM WSDL to be updated
9f6f2a3 Support building wheels (PEP-427)
73d1160 Fixup autoindex.rst only if it exists
42eab0c Supress error logs when exception is thrown
2350257 Fix handling of fault details
7591589 Fix UnboundLocalError during WebFault handling
89d0131 Use faultstring attribute in suds.WebFault.fault
54455f2 Imported Translations from Transifex
95e84eb Fix the log message for progress
264e428 Add API to get the entity inventory path
ee4d9c0 VimExceptions need to support i18n objects
df59368 Switch to using oslo.utils
e55e677 Use custom transport adapter for file URLs
1c2987b getText can be called only when doc is not None
def85dd Updated from global requirements
80057e4 Add unit test for suds cache expiration
a3e493a Add a memory based shared cache
6a72bf1 Updated from global requirements
4bd0b4c VMware: Enable vCenter SSL certificate validation


For more details, please see the git log history below or 
http://git.openstack.org/cgit/openstack/oslo.vmware/log/

Please report issues through launchpad: https://launchpad.net/oslo.vmware



$ git log --no-merges 0.6.0..0.7.0

commit 1661a0af8ce14edbfb00fed0a30a3b9135517d93
Author: OpenStack Proposal Bot openstack-in...@lists.openstack.org
Date:   Wed Nov 5 08:35:10 2014 +

Updated from global requirements

Change-Id: I88286d9ef8ff5fc5210a9ed87bacffd60ff78a56

commit 33f60020b7b476e07edbf8fa40e755887ce66f2a
Author: OpenStack Proposal Bot openstack-in...@lists.openstack.org
Date:   Sun Nov 2 06:08:05 2014 +

Imported Translations from Transifex

For more information about this automatic import see:
https://wiki.openstack.org/wiki/Translations/Infrastructure

Change-Id: I2edec2f04103684b48e37e3d3cbf52756c7ae6a8

commit 8b1f97bc7e36b4c3bf85fb6c92b7481e6845f470
Author: Arnaud Legendre arnaud...@gmail.com
Date:   Wed Oct 22 16:56:53 2014 -0700

Do not log when reraising an exception

It should be up to the caller to use the log level error
when the exception is reraised. For example, if the call
to a VIM api fails, _poll_task is currently throwing a big
red block even if the caller ignores the exception.

This patch removes the logging from _poll_task.

Change-Id: I5bceb41c9a24dca45ff8689daee0eeafa7da839c

commit 575fd70985b5d21dbbe36efc317d9b0a0256d990
Author: OpenStack Proposal Bot openstack-in...@lists.openstack.org
Date:   Tue Oct 28 06:08:32 2014 +

Imported Translations from Transifex

For more information about this automatic import see:
https://wiki.openstack.org/wiki/Translations/Infrastructure

Change-Id: I376cde927d248be21354cee58e43bce78dec8832

commit 0b7ff54050e2e6565c9e8a3b71b41155524527d4
Author: OpenStack Proposal Bot openstack-in...@lists.openstack.org
Date:   Mon Oct 27 12:21:13 2014 +

Updated from global requirements

Change-Id: Id3da9d10632b68df8017d4f3dc69cec6ff2f1eb1

commit 8ed3d5308aae453c9f5ed3cd543e91dbf7c4dd9b
Author: Vipin Balachandran vb...@vmware.com
Date:   Tue Oct 14 17:30:48 2014 +0530

Add unit test for VC 5.1 web fault handling

This patch adds unit test for web fault raised by vCenter 5.1.

Change-Id: I6879dcb50db919386facd81d3ba5e7b133f75397

commit 776c20d96845c602ed60aea0962c6bb190fa67a5
Author: Arnaud Legendre arnaud...@gmail.com
Date:   Mon Oct 13 17:34:32 2014 -0700

Fix to get exception detail with vCenter 5.1

The current child path used '/detail' is not compatible with
vCenter 5.1.

This patch adds a lookup to '/Envelope/Body/Fault/detail' to make
sure we get the detail of the exception.

Change-Id: Id5ca2d87a7cba8b531a4c54111505e72c70df021

commit 62d0ba719d7dde8507f558a95a3a885f5655
Author: Arnaud Legendre arnaud...@gmail.com
Date:   Wed Sep 17 13:56:12 2014 -0700

Download image API to bypass vCenter

This patch introduces a new API to download images. This new API
provides a new signature which gives the ability to bypass vCenter
when downloading images.

Change-Id: Id3cf3f03e1d0622a99573bd090b8ea6b397765e0

commit 6aa427d733b6ac215477f99ffd6727f4f8b9063a
Author: OpenStack Proposal Bot openstack-in...@lists.openstack.org
Date:   Mon Oct 13 18:50:38 2014 +

Updated from global requirements

Change-Id: 

Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Zane Bitter

On 12/11/14 10:10, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:

On 11/11/14 13:34, Ryan Brown wrote:

I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you  up your YAML syntax.


Agreed, and FWIW literally everyone that Clint has pitched the JS idea
to thought it was crazy ;)



So far nobody has stepped up to defend me,


I'll defend you, but I can't defend the idea :)


so I'll accept that maybe
people do think it is crazy. What I'm really confused by is why we have
a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),


Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is 
probably not the way to win over Python developers :D



and that would somehow be less crazy than a well known mature language
that has always been meant for embedding such as javascript.


JS is a Turing-complete language, it's an entirely different kettle of 
fish to a domain-specific language that is inherently safe to interpret 
from user input. Sure, we can try to lock it down. It's a very tricky 
job to get right. (Plus it requires a new external dependency of unknown 
quality... honestly if you're going to embed a Turing-complete language, 
Python is a much more obvious choice than JS.)



Anyway, I'd prefer YAQL over trying to get the intrinsic functions in
HOT just right. Users will want to do things we don't expect. I say, let
them, or large sections of the users will simply move on to something
else.


The other side of that argument is that users are doing one of two 
things with data they have obtained from resources in the template:


1) Passing data to software deployments
2) Passing data to other resources

In case (1) they can easily transform the data into whatever format they 
want using their own scripts, running on their own server.


In case (2), if it's not easy for them to just do what they want without 
having to perform this kind of manipulation, we have failed to design 
good resources. And if we give people the tools to just paper over the 
problem, we'll never hear about it so we can correct it at the source, 
just launch a thousand hard-to-maintain hacks into the world.


cheers,
Zane.

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


Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-12 Thread Matthew Booth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/11/14 16:22, Dan Smith wrote:
 An initial inconsistency I have noticed is that some objects
 refresh themselves from the database when calling save(), but
 others don't.
 
 I agree that it would be ideal for all objects to behave the same
 in this regard. I expect that in practice, it's not necessary for
 all objects to do this, and since it is an extra step/query in some
 places, it's not without cost to just always refresh (there is no
 reason to refresh a Flavor object AFAIK, for instance).
 
 The lack of consistency in behaviour is obviously a problem, and
 I can't think of any good reason for a second select for objects
 which do that. However, I don't think it is good design for
 save() to refresh the object at all, and the reason is
 concurrency. The cached contents of a Nova object are *always*
 potentially stale. A refresh does nothing to change that, because
 the contents are again potentially stale as soon as it returns.
 Handling this requires concurrency primitives which we don't
 currently have (see the larger context I mentioned above).
 Refreshing an object's contents might reduce the probability of a
 race, but it doesn't fix it. Callers who want a refresh after
 save can always call object.refresh(), but for others it's just
 wasted hits on the db.
 
 Doing a refresh() after a save() is more than just another DB hit,
 it's another RPC round-trip, which is far more expensive.
 
 There is a lot of code in the compute manager (and elsewhere I'm
 sure) that expects to get back the refreshed object after a save
 (our instance update functions have always exhibited this behavior,
 so there is code built to expect it). Any time something could
 change async on the object that might affect what we're about to do
 will benefit from this implicit refreshing. A good example is when
 we're doing something long-running on an instance and it is deleted
 underneath us. If we didn't get the deleted=True change after a
 save(), we might go continue doing a lot of extra work before we
 notice it the next time.
 
 It's not that doing so prevents the object's contents from being
 stale, it's that it reduces the amount of time before we notice a
 change, and avoids us needing to explicitly check. Any code we have
 that can't tolerate the object being stale is broken anyway.
 
 Refresh on save() is also arbitrary. Why should the object be
 updated then rather than at any other time? The timing of an
 update in thread X is unrelated to the timing of an update in
 thread Y, but it's a problem whenever it happens.
 
 Because it's not about cache consistency, it's about the expense 
 required to do any of these things. To save(), we *have* to make
 the round-trip, so why not get a refresh at the same time? In cases
 where we explicitly want to refresh, we call refresh(), but
 otherwise we use natural synchronization points like save() to do
 that.

Ok, it makes more sense in this context.

 Can anybody see a problem if we didn't fetch the row at all, and
  simply updated it? Absent locking or compare-and-swap this is 
 effectively what we're already doing, and it reduces the db cost
 of save to a single update statement. The difference would be
 that the object would remain stale without an explicit refresh().
 Value munging would remain unaffected.
 
 At least for instance, I don't want to do away with the implicit 
 refreshing. I would be up for any of these options:
 
 1. Documenting which objects do and don't auto-refresh 2. Making
 the case for non-Instance objects to not auto-refresh 3. Making
 them all auto-refresh for consistency, with the appropriate 
 re-tooling of the db/api code to minimize performance impact.

I personally favour having consistent behaviour across the board. How
about updating them all to auto-refresh by default for consistency,
but adding an additional option to save() to disable it for particular
calls? Ideally we'd have the opposite default and fix all callers, but
I suspect that's more likely to bite us in the short term unless we're
confident we can identify all the critical callers.

I also suggest a tactical fix to any object which fetches itself twice
on update (e.g. Aggregate).

 
 Additionally, Instance, InstanceGroup, and Flavor perform
 multiple updates on save(). I would apply the same rule to the
 sub-updates, and also move them into a single transaction such
 that the updates are atomic.
 
 Yep, no complaints about fixing these non-atomic updates, of course
 :)

Thanks,

Matt
- -- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRjkEcACgkQNEHqGdM8NJC5hACfYimQH2MqcMTnvHc7loqi1QAZ
R2EAoIOSVe83htncBWBIDBxBwFdANajG
=veuA
-END PGP SIGNATURE-

___
OpenStack-dev mailing list

[openstack-dev] [fuel]

2014-11-12 Thread foss geek
I am reading Fuel reference-architecture documentation in the below link:

http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture

In the page no 2 note says:

*Note*

*In environments that use vCenter as the hypervisor, the Nova-compute
service can run only on Controller nodes. *

Is it specific to Fuel?

Let say I deployed a environment (controller + compute + storage) with KVM
as the hypervisor and later manually doing all the necessary configuration
change to make compute node with vCenter as the hypervisor.  In this case
does *Nova-compute (running in compute-node) service work with vCenter?*


-- 
Thanks  Regards
Mobile: +91-9444955058
E-Mail: thefossg...@gmail.com
IRC: neophy
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [fuel]

2014-11-12 Thread Tomasz Napierala

On 12 Nov 2014, at 17:56, foss geek thefossg...@gmail.com wrote:

 
 I am reading Fuel reference-architecture documentation in the below link:
 
 http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture
 
 In the page no 2 note says:
 
 Note
 
 In environments that use vCenter as the hypervisor, the Nova-compute service 
 can run only on Controller nodes. 
 
 Is it specific to Fuel? 
 
 Let say I deployed a environment (controller + compute + storage) with KVM as 
 the hypervisor and later manually doing all the necessary configuration 
 change to make compute node with vCenter as the hypervisor.  In this case 
 does Nova-compute (running in compute-node) service work with vCenter? 
 

This is Fuel specific. We’ve just decided to put nova-compute responsible to 
control vCenter on controller nodes. You can configure it on any node you want, 
similar to any other service. You just need to take care of access to vCenter 
control plane.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







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


Re: [openstack-dev] [fuel]

2014-11-12 Thread Andrew Woodward
neophy,

This is a requirement of the fuel deployment with vCenter selected as
the compute hyper-visor. In this case the nova-compute service would
be configured on the controller nodes and the fuel ui would not allow
you to deploy kvm computes.

You can post configure additional services on the nodes as desired

On Wed, Nov 12, 2014 at 7:56 PM, foss geek thefossg...@gmail.com wrote:

 I am reading Fuel reference-architecture documentation in the below link:

 http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture

 In the page no 2 note says:

 Note

 In environments that use vCenter as the hypervisor, the Nova-compute service
 can run only on Controller nodes.

 Is it specific to Fuel?

 Let say I deployed a environment (controller + compute + storage) with KVM
 as the hypervisor and later manually doing all the necessary configuration
 change to make compute node with vCenter as the hypervisor.  In this case
 does Nova-compute (running in compute-node) service work with vCenter?


 --
 Thanks  Regards
 Mobile: +91-9444955058
 E-Mail: thefossg...@gmail.com
 IRC: neophy



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




-- 
Andrew
Mirantis
Ceph community

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


Re: [openstack-dev] [stable][neutron] Fwd: Re: [Openstack-stable-maint] Neutron backports for security group performance

2014-11-12 Thread James Page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Ihar

On 11/11/14 19:39, Ihar Hrachyshka wrote:
 there is a series of Neutron backports in the Juno queue that are
 
 intended to significantly improve service performance when
 handling security groups (one of the issues that are main pain
 points of current users): - https://review.openstack.org/130101
 - https://review.openstack.org/130098 - 
 https://review.openstack.org/130100 - 
 https://review.openstack.org/130097 - 
 https://review.openstack.org/130105 The first four patches are
 optimizing db side (controller), while the last one is to avoid
 fetching security group rules by OVS agent when firewall is
 disabled.

In terms of putting some figures around how these proposed stable
patches help improve a Neutron based Juno cloud, I can provide some
metrics based on recent testing that Canonical did in-conjuction with HP.

The cloud we deployed was all based on Intel Atom Quad Core processors,
with 16G of RAM and SSD disk; 540 servers in total including 8 nova
controllers and 4 neutron controllers.  OpenStack Juno release on
Ubuntu 14.04.

With around 12,000 running instances, which was as far as I could push
a vanilla ML2/ovs based Juno cloud, the load on the 4 neutron
controllers was around 40 with CPU maxing out all of the time - which
pretty much mean't it was impossible to create any new instances due
to vif plugging timeouts in nova waiting for neutron to complete
network setup.

I patched in:

  https://review.openstack.org/#/c/130101/
  https://review.openstack.org/#/c/130098/
  https://review.openstack.org/#/c/130100/
  https://review.openstack.org/#/c/130105/

and re-ran the same test; the messaging load on the RabbitMQ server at
12,000 instances was considerably less in terms of volume, and the
load on the 4 neutron controllers was around 10 (vs 40) with CPU at
around 55-65% utilization - so still pretty busy, but a better
situation than without the patches.

My testing was quite synthetic (boot small instances until things
start to break) but it does illustrate the difference these patches make.

HTH

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUY5czAAoJEL/srsug59jDIJ8QAJAK8aWUSQGyPrcAqvKi+OE7
vS4NhVWog1ifubPcIpDstAoELHIfQVQKaryCN7oXAzQ0Yyp68DE68mw+o8rrly2S
25gPebORNath1BOJMMlv5iRS0lVN30cfmRrs9nfQ5bdAE6qkaPlofG9GsGRggCG2
feewRR9w+PFFQQ9NdsZ141FoQDtpLjhY095rEwzUhyah8spM2w2er2XiEJLHRTI/
HcJybUSX/Nu8OV4FJ6dn+pebWv1iWgzNOV/eqCYHf1Mx9G6HrB8ZQpv486LznyX1
PSNuiVMgUFcSWUcN1lFQSEe/ASW+G2t3/aEMKZBXiXsO3DTORtZ79oCTkzipkehj
18ztLr+nkCDrdGzbvkD6LWGt9F7MjTzsXao4RwGe/EiRBvcrvnHpkc5kfaW2aIb3
+rH8pcHpfaC04y7Zy492lFrkmrXn+73c2a+hS+gS3bMmQ1bcwF+QeeXunsMajgVo
CQW98n3HJI/jAjCBEbV5cmmw+BXQDWOHYlP+tZiAMC5Tnj42/9+K+KWZr+truhLK
cKGFlM+vaVsykAh9KIf1E/e6G72o/kihXDUnpx/mSk27sxDILEz9ItcQRJgpQCPN
cH3sIj+qG76NDqIhdLYs8LgyjwQI2SdOeSi+32oCCe3tnaI35FKKuRMI0oSP0HKn
3U7bekTsjXhlBWusW9Wb
=WaFI
-END PGP SIGNATURE-

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-12 Thread Jiri Tomasek

On 11/12/2014 05:18 PM, Julie Pichon wrote:

On 12/11/14 15:12, Jiri Tomasek wrote:

Approach on using Xstatic packages vs Js tooling:

As only problem with using js tooling should be just actual packaging of
it, I think it makes sense to use these tools and make development
simpler then going other way around and using Xstatic packages - which
means devs would have to care about getting stuff packaged as xstatic
and added to the code, while maintaining proper versions and making sure
that they work ok together. NPM and Bower do this for us. Common sense
tells me packagers should take care of packaging.
Packaging of these tools will have to get resolved somehow anyway, as
there will be rise in requirements of using them not just from Horizon...

I can't speak for the rest but that part doesn't seem correct to me. The
XStatic packages are Python packages (as in, dependencies) that the
Horizon team is responsible for (when they don't already exist) and
maintains on stackforge, so we do have to create them and make sure they
all work well together. The later packaging as rpm or deb or others is
left to the distro packagers of course.

There are instructions already on how to create xstatic packages [1],
it's not very complicated and just takes some review time.

Thanks,

Julie

[1]
http://docs.openstack.org/developer/horizon/contributing.html#javascript-and-css-libraries


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


I might have expressed myself wrong about XStatic packages. But as you 
say as well, to use XStatic packages, we need to most often create them 
and maintain the correct versions we require in Horizon and they don't 
help to packagers either.  I makes sense to use them in Django 
application as they can be included in requirements.txt and we don't 
have to carry them directly in the code. So I am definitely ok to use 
them for Django dependencies we have.


Similar thing is npm and bower doing on the Angular side except for we 
don't have to create these libraries as they already exist. NPM and 
Bower are taking care of including the right versions of js libs our dev 
env and our application needs. They use similar description files as 
requirements.txt in Django.


It makes no sense not to use them and try to include js libraries using 
XStatic packages and listing them in requirements.txt because this way 
we don't know which version of js lib to use etc. NPM and bower are 
doing this for us.


In both approaches dependencies need to have packages in the end 
regadles of being it XStatic package or js library or Angular module.


It is about using the right tools for the job.


I see relation between Nodejs and js libs/tools and Angular app defining 
it's dependencies using NPM and Bower quite similar as Ruby, Rubygems 
and Rails application defining it's dependencies in Gemfile.lock. 
Rubygems are being packaged in distros, so why shouldn't node packages?



Jiri


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


Re: [openstack-dev] [stable][neutron] Fwd: Re: [Openstack-stable-maint] Neutron backports for security group performance

2014-11-12 Thread Kevin Benton
Hi James,

This is awesome. I seem to have misplaced my 540-node cluster. ;-)

Is it possible for you to also patch in
https://review.openstack.org/#/c/132372/ ? In my rally testing of port
retrieval, this one probably made the most significant improvement.


On Nov 12, 2014 9:26 AM, James Page james.p...@ubuntu.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi Ihar

 On 11/11/14 19:39, Ihar Hrachyshka wrote:
  there is a series of Neutron backports in the Juno queue that are
 
  intended to significantly improve service performance when
  handling security groups (one of the issues that are main pain
  points of current users): - https://review.openstack.org/130101
  - https://review.openstack.org/130098 -
  https://review.openstack.org/130100 -
  https://review.openstack.org/130097 -
  https://review.openstack.org/130105 The first four patches are
  optimizing db side (controller), while the last one is to avoid
  fetching security group rules by OVS agent when firewall is
  disabled.

 In terms of putting some figures around how these proposed stable
 patches help improve a Neutron based Juno cloud, I can provide some
 metrics based on recent testing that Canonical did in-conjuction with HP.

 The cloud we deployed was all based on Intel Atom Quad Core processors,
 with 16G of RAM and SSD disk; 540 servers in total including 8 nova
 controllers and 4 neutron controllers.  OpenStack Juno release on
 Ubuntu 14.04.

 With around 12,000 running instances, which was as far as I could push
 a vanilla ML2/ovs based Juno cloud, the load on the 4 neutron
 controllers was around 40 with CPU maxing out all of the time - which
 pretty much mean't it was impossible to create any new instances due
 to vif plugging timeouts in nova waiting for neutron to complete
 network setup.

 I patched in:

   https://review.openstack.org/#/c/130101/
   https://review.openstack.org/#/c/130098/
   https://review.openstack.org/#/c/130100/
   https://review.openstack.org/#/c/130105/

 and re-ran the same test; the messaging load on the RabbitMQ server at
 12,000 instances was considerably less in terms of volume, and the
 load on the 4 neutron controllers was around 10 (vs 40) with CPU at
 around 55-65% utilization - so still pretty busy, but a better
 situation than without the patches.

 My testing was quite synthetic (boot small instances until things
 start to break) but it does illustrate the difference these patches make.

 HTH

 James

 - --
 James Page
 Ubuntu and Debian Developer
 james.p...@ubuntu.com
 jamesp...@debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJUY5czAAoJEL/srsug59jDIJ8QAJAK8aWUSQGyPrcAqvKi+OE7
 vS4NhVWog1ifubPcIpDstAoELHIfQVQKaryCN7oXAzQ0Yyp68DE68mw+o8rrly2S
 25gPebORNath1BOJMMlv5iRS0lVN30cfmRrs9nfQ5bdAE6qkaPlofG9GsGRggCG2
 feewRR9w+PFFQQ9NdsZ141FoQDtpLjhY095rEwzUhyah8spM2w2er2XiEJLHRTI/
 HcJybUSX/Nu8OV4FJ6dn+pebWv1iWgzNOV/eqCYHf1Mx9G6HrB8ZQpv486LznyX1
 PSNuiVMgUFcSWUcN1lFQSEe/ASW+G2t3/aEMKZBXiXsO3DTORtZ79oCTkzipkehj
 18ztLr+nkCDrdGzbvkD6LWGt9F7MjTzsXao4RwGe/EiRBvcrvnHpkc5kfaW2aIb3
 +rH8pcHpfaC04y7Zy492lFrkmrXn+73c2a+hS+gS3bMmQ1bcwF+QeeXunsMajgVo
 CQW98n3HJI/jAjCBEbV5cmmw+BXQDWOHYlP+tZiAMC5Tnj42/9+K+KWZr+truhLK
 cKGFlM+vaVsykAh9KIf1E/e6G72o/kihXDUnpx/mSk27sxDILEz9ItcQRJgpQCPN
 cH3sIj+qG76NDqIhdLYs8LgyjwQI2SdOeSi+32oCCe3tnaI35FKKuRMI0oSP0HKn
 3U7bekTsjXhlBWusW9Wb
 =WaFI
 -END PGP SIGNATURE-

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

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


Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-12 Thread Dan Smith
 I personally favour having consistent behaviour across the board. How
 about updating them all to auto-refresh by default for consistency,
 but adding an additional option to save() to disable it for particular
 calls?

I think these should be two patches: one to make them all auto-refresh,
and another to make it conditional. That serves the purpose of (a)
bisecting a regression to one or the other, and (b) we can bikeshed on
the interface and appropriateness of the don't-refresh flag :)

 I also suggest a tactical fix to any object which fetches itself twice
 on update (e.g. Aggregate).

I don't see that being anything other than an obvious win, unless there
is some obscure reason for it. But yeah, seems like a good thing to do.

--Dan



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


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Randall Burt
On Nov 12, 2014, at 10:42 AM, Zane Bitter zbit...@redhat.com
 wrote:

 On 12/11/14 10:10, Clint Byrum wrote:
 Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
 On 11/11/14 13:34, Ryan Brown wrote:
 I am strongly against allowing arbitrary Javascript functions for
 complexity reasons. It's already difficult enough to get meaningful
 errors when you  up your YAML syntax.
 
 Agreed, and FWIW literally everyone that Clint has pitched the JS idea
 to thought it was crazy ;)
 
 
 So far nobody has stepped up to defend me,
 
 I'll defend you, but I can't defend the idea :)
 
 so I'll accept that maybe
 people do think it is crazy. What I'm really confused by is why we have
 a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),
 
 Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is 
 probably not the way to win over Python developers :D
 
 and that would somehow be less crazy than a well known mature language
 that has always been meant for embedding such as javascript.
 
 JS is a Turing-complete language, it's an entirely different kettle of fish 
 to a domain-specific language that is inherently safe to interpret from user 
 input. Sure, we can try to lock it down. It's a very tricky job to get right. 
 (Plus it requires a new external dependency of unknown quality... honestly if 
 you're going to embed a Turing-complete language, Python is a much more 
 obvious choice than JS.)
 
 Anyway, I'd prefer YAQL over trying to get the intrinsic functions in
 HOT just right. Users will want to do things we don't expect. I say, let
 them, or large sections of the users will simply move on to something
 else.
 
 The other side of that argument is that users are doing one of two things 
 with data they have obtained from resources in the template:
 
 1) Passing data to software deployments
 2) Passing data to other resources
 
 In case (1) they can easily transform the data into whatever format they want 
 using their own scripts, running on their own server.
 
 In case (2), if it's not easy for them to just do what they want without 
 having to perform this kind of manipulation, we have failed to design good 
 resources. And if we give people the tools to just paper over the problem, 
 we'll never hear about it so we can correct it at the source, just launch a 
 thousand hard-to-maintain hacks into the world.

I disagree with this last bit. Having some manner of data manipulation facility 
as part of the template language doesn't mean the resources are badly designed 
or implemented, it just means that users have constraints that we don't 
directly address. Having something more general purpose (whatever it may be) 
seems like a longer term and more maintainable solution to me than eternal tail 
chasing where 1000 specific intrinsic functions bloom. IMO, intrinsics have a 
place, but supporting something like YAQL (or whatever) seems like a general 
solution to a lot of common problems our users come up against.

As for hard-to-maintain hacks, isn't that what drives a lot of our users to 
ask for these sorts of solutions in the first place? If doing something via 
YAQL is perceived by a user as some sub-optimal hack for their use case, I see 
no reason for that to be any less visible than any other pain point or 
usability issue we have.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

2014-11-12 Thread Clint Byrum
Excerpts from Zane Bitter's message of 2014-11-12 08:42:44 -0800:
 On 12/11/14 10:10, Clint Byrum wrote:
  Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
  On 11/11/14 13:34, Ryan Brown wrote:
  I am strongly against allowing arbitrary Javascript functions for
  complexity reasons. It's already difficult enough to get meaningful
  errors when you  up your YAML syntax.
 
  Agreed, and FWIW literally everyone that Clint has pitched the JS idea
  to thought it was crazy ;)
 
 
  So far nobody has stepped up to defend me,
 
 I'll defend you, but I can't defend the idea :)
 
  so I'll accept that maybe
  people do think it is crazy. What I'm really confused by is why we have
  a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),
 
 Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is 
 probably not the way to win over Python developers :D
 
  and that would somehow be less crazy than a well known mature language
  that has always been meant for embedding such as javascript.
 
 JS is a Turing-complete language, it's an entirely different kettle of 
 fish to a domain-specific language that is inherently safe to interpret 
 from user input. Sure, we can try to lock it down. It's a very tricky 
 job to get right. (Plus it requires a new external dependency of unknown 
 quality... honestly if you're going to embed a Turing-complete language, 
 Python is a much more obvious choice than JS.)
 

There's a key difference though. Python was never designed to be run
from untrusted sources. Javascript was _from the beginning_. There are
at least two independent javascript implementations which both have been
designed from the ground up to run code from websites in the local
interpreter. From the standpoint of Heat, it would be even easier to do
this.

Perhaps I can carve out some of that negative-1000-days of free time I
have and I can make it a resource plugin, with the properties being code
and references to other resources, and the attributes being the return.

  Anyway, I'd prefer YAQL over trying to get the intrinsic functions in
  HOT just right. Users will want to do things we don't expect. I say, let
  them, or large sections of the users will simply move on to something
  else.
 
 The other side of that argument is that users are doing one of two 
 things with data they have obtained from resources in the template:
 
 1) Passing data to software deployments
 2) Passing data to other resources
 
 In case (1) they can easily transform the data into whatever format they 
 want using their own scripts, running on their own server.
 
 In case (2), if it's not easy for them to just do what they want without 
 having to perform this kind of manipulation, we have failed to design 
 good resources. And if we give people the tools to just paper over the 
 problem, we'll never hear about it so we can correct it at the source, 
 just launch a thousand hard-to-maintain hacks into the world.
 

I for one would rather serve the users than ourselves, and preventing
them from papering over the problems so they have to whine at us is a
self-serving agenda.

As a primary whiner about Heat for a long time, I respect a lot that
this development team _bends over backwards_ to respond to user
requests. It's amazing that way.

However, I think to grow beyond open source savvy, deeply integrated
users like me, one has to let the users solve their own problems. They'll
know that their javascript or YAQL is debt sometimes, and they can
come to Heat's development community with suggestions like If you had
a coalesce function I wouldn't need to write it in javascript. But if
you don't give them _something_, they'll just move on.

Anyway, probably looking further down the road than I need to, but
please keep an open mind for this idea, as users tend to use tools that
solve their problem _and_ get out of their way in all other cases.

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


Re: [openstack-dev] FreeBSD host support

2014-11-12 Thread Michał Dubiel
Hi,

As for the Devstack it requires some rebasing work (not necessarily
straightforward) in order to push the changes upstream. As for the neutron,
it should not be difficult to port FreeBSD networking support (we have some
code in our forked repos) from nova-network to neutron plugin.

Regards,
Michal

On 30 October 2014 12:21, Roman Bogorodskiy bogorods...@gmail.com wrote:

   Monty Taylor wrote:

  On 10/27/2014 06:39 AM, Michael Still wrote:
   On Tuesday, October 21, 2014, Roman Bogorodskiy 
 rbogorods...@mirantis.com
   wrote:
  
   On Mon, Oct 20, 2014 at 10:19 PM, Joe Gordon joe.gord...@gmail.com
   javascript:; wrote:
   On Sat, Oct 18, 2014 at 10:04 AM, Roman Bogorodskiy 
   rbogorods...@mirantis.com javascript:; wrote:
  
  
   [snip]
  
  
   High level overview of what needs to be done:
  
- Nova
 * linux_net needs to be re-factored to allow to plug in FreeBSD
   support (that's what the spec linked above is about)
 * nova.virt.disk.mount needs to be extended to support FreeBSD's
   mdconfig(8) in a similar way to Linux's losetup
  
  
   [snip]
  
  
   What about neutron? We are in the process of trying to deprecate
   nova-network, so any new thing needs to support neutron.
  
  
   AFAIK, there's no defined migration plan yet, unless I missed that.
   Anyway, I don't see any blockers regarding an implementation of a
 driver
   similar to linuxbridge that'd work on FreeBSD.
  
   Also, Semihalf guys are working on OpenContail/FreeBSD and
   Neutron/OpenContrial support, so that's an option as well.
  
  
   I have no problem with supporting FreeBSD as a hypervisor operating
 system,
   especially if there is a solid team on the FreeBSD side that will
 commit to
   maintaining the changes required and adding the necessary CI
 (especially
   ensuring that when it breaks it gets fixed).
 
  I believe that the CI related things that would be needed would be:
 
  - solid devstack support
  - someone willing to step up and make sure that nodepool can provide
  freebsd images like ianw recently did with centos

 Semihalf guys implemented FreeBSD support devstack as well (Michał
 CCed):

  https://github.com/Semihalf/openstack-devstack

 I don't know if they did an attempt to push these changes back.

 Creating FreeBSD images is not hard and I could do that.

 Anyway, there are some points regarding the CI that are not quite clear
 to me.

  - Should it be a 3rd party CI or integrated to the main CI?
  - At what point we want to start tempest/devstack testing over FreeBSD?
I think it'll take quite some time to make these pass (maybe several
release cycles).

   However, I see Neutron support as a firm requirement. We've spent a
 large
   amount of time getting closer and closer to deprecating nova-network.
   Despite opening it up for limited development again, I don't think we
   should be making the transition plan harder by introducing new features
   that don't work with Neutron.
 
  I agree with Mikal on this.

 Good. It doesn't look like a problem to me to bring the support into
 Neutron over nova-network. After a brief view the level of effort for
 the Neutron implementation is not much higher comparing to nova-network.

 Roman Bogorodskiy

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


[openstack-dev] Plans for removing xml support

2014-11-12 Thread David Kranz
Code has started going into tempest for several projects 
(nova,neutron,keystone) to allow removal of xml support in kilo. There 
have been many (heated) off and on threads on this list over the years. 
I'm sure many projects would like to do this, but there is evidence that 
not all have an understanding that this is ok. Is this a TC issue? If 
so, could there be a clear statement about xml support?


 -David

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


[openstack-dev] [oslo] kilo graduation plans

2014-11-12 Thread Doug Hellmann
During our “Graduation Schedule” summit session we worked through the list of 
modules remaining the in the incubator. Our notes are in the etherpad [1], but 
as part of the Write it Down” theme for Oslo this cycle I am also posting a 
summary of the outcome here on the mailing list for wider distribution. Let me 
know if you remembered the outcome for any of these modules differently than 
what I have written below.

Doug



Deleted or deprecated modules:

funcutils.py - This was present only for python 2.6 support, but it is no 
longer used in the applications. We are keeping it in the stable/juno branch of 
the incubator, and removing it from master (https://review.openstack.org/130092)

hooks.py - This is not being used anywhere, so we are removing it. 
(https://review.openstack.org/#/c/125781/)

quota.py - A new quota management system is being created 
(https://etherpad.openstack.org/p/kilo-oslo-common-quota-library) and should 
replace this, so we will keep it in the incubator for now but deprecate it.

crypto/utils.py - We agreed to mark this as deprecated and encourage the use of 
Barbican or cryptography.py (https://review.openstack.org/134020)

cache/ - Morgan is going to be working on a new oslo.cache library as a 
front-end for dogpile, so this is also deprecated 
(https://review.openstack.org/134021)

apiclient/ - With the SDK project picking up steam, we felt it was safe to 
deprecate this code as well (https://review.openstack.org/134024).

xmlutils.py - This module was used to provide a security fix for some XML 
modules that have since been updated directly. It was removed. 
(https://review.openstack.org/#/c/125021/)



Graduating:

oslo.context:
- Dims is driving this
- https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-context
- includes:
context.py

oslo.service:
- Sachi is driving this
- https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-service
- includes:
eventlet_backdoor.py
loopingcall.py
periodic_task.py
request_utils.py
service.py
sslutils.py
systemd.py
threadgroup.py

oslo.utils:
- We need to look into how to preserve the git history as we import these 
modules.
- includes:
fileutils.py
versionutils.py



Remaining untouched:

scheduler/ - Gantt probably makes this code obsolete, but it isn’t clear 
whether Gantt has enough traction yet so we will hold onto these in the 
incubator for at least another cycle.

report/ - There’s interest in creating an oslo.reports library containing this 
code, but we haven’t had time to coordinate with Solly about doing that.



Other work:

We will continue the work on oslo.concurrency and oslo.log that we started 
during Juno.

[1] https://etherpad.openstack.org/p/kilo-oslo-library-proposals
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

2014-11-12 Thread Steve Gordon
Hi all,

We had some discussions last week - particularly in the Nova NFV design session 
[1] - on the subject of ensuring that telecommunications and NFV-related 
functionality has adequate continuous integration testing. In particular the 
focus here is on functionality that can't easily be tested on the public clouds 
that back the gate, including:

- NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device locality)
- SR-IOV with Intel, Cisco, and Mellanox devices (possibly others)
  
In each case we need to confirm where we are at, and the plan going forward, 
with regards to having:

1) Hardware to run the CI on.
2) Tests that actively exercise the functionality (if not already in existence).
3) Point person for each setup to maintain it and report into the third-party 
meeting [2].
4) Getting the jobs operational and reporting [3][4][5][6].

In the Nova session we discussed a goal of having the hardware by K-1 (Dec 18) 
and having it reporting at least periodically by K-2 (Feb 5). I'm not sure if 
similar discussions occurred on the Neutron side of the design summit.

SR-IOV
==

Adrian and Irena mentioned they were already in the process of getting up to 
speed with third party CI for their respective SR-IOV configurations. Robert 
are you attempting similar with regards to Cisco devices? What is the status of 
each of these efforts versus the four items I lifted above and what do you need 
assistance with?

NUMA


We still need to identify some hardware to run third party CI for the 
NUMA-related work, and no doubt other things that will come up. It's expected 
that this will be an interim solution until OPNFV resources can be used (note 
cdub jokingly replied 1-2 years when asked for a rough estimate - I mention 
this because based on a later discussion some people took this as a serious 
estimate).

Ian did you have any luck kicking this off? Russell and I are also endeavouring 
to see what we can do on our side w.r.t. this short term approach - in 
particular if you find hardware we still need to find an owner to actually 
setup and manage it as discussed.

In theory to get started we need a physical multi-socket box and a virtual 
machine somewhere on the same network to handle job control etc. I believe the 
tests themselves can be run in VMs (just not those exposed by existing public 
clouds) assuming a recent Libvirt and an appropriately crafted Libvirt XML that 
ensures the VM gets a multi-socket topology etc. (we can assist with this).

Thanks,

Steve

[1] https://etherpad.openstack.org/p/kilo-nova-nfv
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] http://ci.openstack.org/third_party.html
[4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
[5] 
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
[6] 
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/

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


Re: [openstack-dev] [Zaqar] Meeting Monday 17th at 15:00 UTC

2014-11-12 Thread Victoria Martínez de la Cruz
+1!

2014-11-12 9:31 GMT-03:00 Flavio Percoco fla...@redhat.com:

 Greetings,

 Zaqar team will pick up its regular meetings next Monday at 15 UTC.
 We'll keep alternating time, therefore the meeting after the next one
 will be at 21 UTC.

 The team meets in the #openstack-meeting-3 channel and we keep the
 agenda in the wiki[0]. Do feel free to add items to it that you'd like
 to discuss during the meeting.

 [0] https://wiki.openstack.org/wiki/Meetings/Zaqar

 Looking forward to see you there,
 Flavio

 --
 @flaper87
 Flavio Percoco

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


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


Re: [openstack-dev] Plans for removing xml support

2014-11-12 Thread Doug Hellmann

On Nov 12, 2014, at 1:30 PM, David Kranz dkr...@redhat.com wrote:

 Code has started going into tempest for several projects 
 (nova,neutron,keystone) to allow removal of xml support in kilo. There have 
 been many (heated) off and on threads on this list over the years. I'm sure 
 many projects would like to do this, but there is evidence that not all have 
 an understanding that this is ok. Is this a TC issue? If so, could there be a 
 clear statement about xml support?

Sean started a thread on the TC mailing list at the beginning of the year [1] 
which led to a discussion at the meeting on Jan 21 [2]. The current documented 
policy for incubated projects is “at least a JSON entity representation” [3].

Doug

[1] http://lists.openstack.org/pipermail/openstack-tc/2014-January/000494.html
[2] http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-01-21-20.03.log.html
[3] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst#n51


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


Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-12 Thread Mike Bayer

 On Nov 12, 2014, at 12:45 PM, Dan Smith d...@danplanet.com wrote:
 
 I personally favour having consistent behaviour across the board. How
 about updating them all to auto-refresh by default for consistency,
 but adding an additional option to save() to disable it for particular
 calls?
 
 I think these should be two patches: one to make them all auto-refresh,
 and another to make it conditional. That serves the purpose of (a)
 bisecting a regression to one or the other, and (b) we can bikeshed on
 the interface and appropriateness of the don't-refresh flag :)
 
 I also suggest a tactical fix to any object which fetches itself twice
 on update (e.g. Aggregate).
 
 I don't see that being anything other than an obvious win, unless there
 is some obscure reason for it. But yeah, seems like a good thing to do.

lets keep in mind my everyone-likes-it-so-far proposal for reader() and 
writer(): https://review.openstack.org/#/c/125181/   (this is where it’s going 
to go as nobody has -1’ed it, so in absence of any “no way!” votes I have to 
assume this is what we’re going with).

in this system, the span of session use is implicit within the context and/or 
decorator, and when writer() is specified, a commit() can be implicit as well.  
IMHO there should be no “.save()” at all, at least as far as database writing 
is concerned. SQLAlchemy doesn’t need boilerplate like that - just let the 
ORM work normally:

@sql.writer
def some_other_api_method(context):
someobject = context.session.query(SomeObject)….one()
someobject.change_some_state(stuff)

# done!

if you want an explicit refresh, then just do so:

@sql.writer
def some_other_api_method(context):
someobject = context.session.query(SomeObject)….one()
someobject.change_some_state(stuff)

context.session.flush()
context.session.refresh(someobject)
# do something with someobject

however, seeing as this is all one API method the only reason you’d want to 
refresh() is that you think something has happened between that flush() and the 
refresh() that would actually show up, I can’t imagine what that would be 
looking for, unless maybe some large amount of operations took up a lot of time 
between the flush() and the refresh().



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


[openstack-dev] [oslo] alpha version numbering discussion from summit

2014-11-12 Thread Doug Hellmann
The outcome of the “Should Oslo continue to use alpha versions” session at the 
summit [1] was unclear, so I would like to continue the discussion here.

As we discussed at the summit, the primary reason for marking Oslo library 
releases as alphas was to indicate that the library is under development and 
not “stable”, so it should not be included in a deployment using stable 
branches. 

I think we were very close to being able to say that Oslo could stop using 
Alpha versions for new library releases because we would pin the versions of 
libraries used in the stable branches to MAJOR.MINOR+1 to only allow bug-fix 
releases to appear in deployments using those branches. However, we will not 
(and perhaps cannot) pin the versions of client libraries, and some of the 
clients are now using oslo.utils and potentially other oslo libraries. This 
would either break the clients (if they used a feature of an oslo library not 
in the version of the library supported by the server) or the server (if the 
oslo library is upgraded and a setuptools requirements check notices or some 
feature has been removed from the oslo library).

We came to this realization just as we were running out of time for the 
session, so we did not come up with a solution. I wasn’t able to attend the 
stable branch session, so I am hoping that someone who was there will be able 
to explain a bit about the version pinning discussion and how that may, or may 
not, affect Oslo library versioning.

Doug


[1] https://etherpad.openstack.org/p/kilo-oslo-alpha-versioning
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo] oslo.messaging outcome from the summit

2014-11-12 Thread Doug Hellmann
The oslo.messaging session at the summit [1] resulted in some plans to evolve 
how oslo.messaging works, but probably not during this cycle.

First, we talked about what to do about the various drivers like ZeroMQ and the 
new AMQP 1.0 driver. We decided that rather than moving those out of the main 
tree and packaging them separately, we would keep them all in the main 
repository to encourage the driver authors to help out with the core library 
(oslo.messaging is a critical component of OpenStack, and we’ve lost several of 
our core reviewers for the library to other priorities recently).

There is a new set of contributors interested in maintaining the ZeroMQ driver, 
and they are going to work together to review each other’s patches. We will 
re-evaluate keeping ZeroMQ at the end of Kilo, based on how things go this 
cycle.

We also talked about the fact that the new version of Kombu includes some of 
the features we have implemented in our own driver, like heartbeats and 
connection management. Kombu does not include the calling patterns 
(cast/call/notifications) that we have in oslo.messaging, but we may be able to 
remove some code from our driver and consolidate the qpid and rabbit driver 
code to let Kombu do more of the work for us.

Python 3 support is coming slowly. There are a couple of patches up for review 
to provide a different sort of executor based on greenio and trollius. Adopting 
that would require some application-level changes to use co-routines, so it may 
not be an optimal solution even though it would get us off of eventlet. (During 
the Python 3 session later in the week we talked about the possibility of 
fixing eventlet’s monkey-patching to allow us to use the new eventlet under 
python 3.)

We also talked about the way the oslo.messaging API uses URLs to get some 
settings and configuration options for others. I thought I remembered this 
being a conscious decision to pass connection-specific parameters in the URL, 
and “global” parameters via configuration settings. It sounds like that split 
may not have been implemented as cleanly as originally intended, though. We 
identified documenting URL parameters as an issue for removing the 
configuration object, as well as backwards-compatibility. I don’t think we 
agreed on any specific changes to the API based on this part of the discussion, 
but please correct me if your recollection is different.

We also learned that there is a critical bug [2] related to heartbeats for 
RabbitMQ, and we have a few patches up to propose fixes in different ways (see 
the bottom of [1]). This highlighted again the fact that we have a shortage of 
reviewers for oslo.messaging.

Doug

[1] https://etherpad.openstack.org/p/kilo-oslo-oslo.messaging
[2] https://bugs.launchpad.net/nova/+bug/856764


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


Re: [openstack-dev] [oslo] kilo graduation plans

2014-11-12 Thread Andreas Jaeger
On 11/12/2014 08:06 PM, Doug Hellmann wrote:
 During our “Graduation Schedule” summit session we worked through the list of 
 modules remaining the in the incubator. Our notes are in the etherpad [1], 
 but as part of the Write it Down” theme for Oslo this cycle I am also 
 posting a summary of the outcome here on the mailing list for wider 
 distribution. Let me know if you remembered the outcome for any of these 
 modules differently than what I have written below.
 
 Doug
 
 
 
 Deleted or deprecated modules:
 
 [...]

 apiclient/ - With the SDK project picking up steam, we felt it was safe to 
 deprecate this code as well (https://review.openstack.org/134024).

I see all the python clients using this:
python-cinderclient/openstack-common.conf:module=apiclient
python-glanceclient/openstack-common.conf:module=apiclient
python-heatclient/openstack-common.conf:modules=importutils,gettextutils,strutils,apiclient.base,apiclient.exceptions
python-ironicclient/openstack-common.conf:module=apiclient
python-keystoneclient/openstack-common.conf:module=apiclient
python-manilaclient/openstack-common.conf:module=apiclient
python-novaclient/openstack-common.conf:module=apiclient
python-saharaclient/openstack-common.conf:module=apiclient.exceptions
python-troveclient/openstack-common.conf:module=apiclient
python-tuskarclient/openstack-common.conf:module=apiclient

So, this needs a good transition plan,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

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


[openstack-dev] [oslo] dropping namespace packages

2014-11-12 Thread Doug Hellmann
We rather quickly came to consensus at the summit that we should drop the use 
of namespace packages in Oslo libraries [1]. As far as I could tell, everyone 
was happy with my proposed approach [2] of moving the code from oslo.foo to 
oslo_foo and then creating a backwards-compatibility shim in oslo.foo that 
imports public symbols from oslo_foo. We also agreed that we would not rename 
existing libraries, and we would continue to use the same naming convention for 
new libraries. So the distribution and git repository both will be called 
“oslo.foo” and the import statement would look like “from oslo_foo import bar”.

Doug

[1] https://etherpad.openstack.org/p/kilo-oslo-namespace-packages
[2] https://review.openstack.org/128759
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] kilo graduation plans

2014-11-12 Thread Doug Hellmann

On Nov 12, 2014, at 3:29 PM, Andreas Jaeger a...@suse.com wrote:

 On 11/12/2014 08:06 PM, Doug Hellmann wrote:
 During our “Graduation Schedule” summit session we worked through the list 
 of modules remaining the in the incubator. Our notes are in the etherpad 
 [1], but as part of the Write it Down” theme for Oslo this cycle I am also 
 posting a summary of the outcome here on the mailing list for wider 
 distribution. Let me know if you remembered the outcome for any of these 
 modules differently than what I have written below.
 
 Doug
 
 
 
 Deleted or deprecated modules:
 
 [...]
 
 apiclient/ - With the SDK project picking up steam, we felt it was safe to 
 deprecate this code as well (https://review.openstack.org/134024).
 
 I see all the python clients using this:
 python-cinderclient/openstack-common.conf:module=apiclient
 python-glanceclient/openstack-common.conf:module=apiclient
 python-heatclient/openstack-common.conf:modules=importutils,gettextutils,strutils,apiclient.base,apiclient.exceptions
 python-ironicclient/openstack-common.conf:module=apiclient
 python-keystoneclient/openstack-common.conf:module=apiclient
 python-manilaclient/openstack-common.conf:module=apiclient
 python-novaclient/openstack-common.conf:module=apiclient
 python-saharaclient/openstack-common.conf:module=apiclient.exceptions
 python-troveclient/openstack-common.conf:module=apiclient
 python-tuskarclient/openstack-common.conf:module=apiclient
 
 So, this needs a good transition plan,

Right, the idea is to deprecate it so we won’t work on new features, and 
encourage any energy that would have been spent on new features to go into the 
SDK project instead. We’ll carry the code for bug fixes until we can safely 
delete it completely.

Doug


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


Re: [openstack-dev] [oslo] dropping namespace packages

2014-11-12 Thread Donald Stufft

 On Nov 12, 2014, at 3:32 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 We rather quickly came to consensus at the summit that we should drop the use 
 of namespace packages in Oslo libraries [1]. As far as I could tell, everyone 
 was happy with my proposed approach [2] of moving the code from oslo.foo to 
 oslo_foo and then creating a backwards-compatibility shim in oslo.foo that 
 imports public symbols from oslo_foo. We also agreed that we would not rename 
 existing libraries, and we would continue to use the same naming convention 
 for new libraries. So the distribution and git repository both will be called 
 “oslo.foo” and the import statement would look like “from oslo_foo import 
 bar”.
 
 Doug
 
 [1] https://etherpad.openstack.org/p/kilo-oslo-namespace-packages
 [2] https://review.openstack.org/128759

+1 for whatever my vote is worth :)

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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


  1   2   >