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

[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

[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

[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

[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 

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

[Martin Geisler]

Richard Jones  writes:

> On 12 November 2014 18:17, Matthias Runge  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

[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  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"  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

[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

[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

[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" 
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

[Martin Geisler]

Richard Jones  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

[Belmiro Moreira]

Fine for me.


On Wed, Nov 12, 2014 at 8:51 AM, Sylvain Bauza  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

[Henry Nash]

I'll be there!

Henry
On 12 Nov 2014, at 02:29, Adam Young  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

[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" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, November 12, 2014 10:37:15 AM
Subject: Re: [openstack-dev] [Horizon] the future of angularjs development  
in Horizon

Richard Jones  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

[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  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

[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  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"  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
>>>
>>> ___
>>> 

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

[Salvatore Orlando]

On 12 November 2014 09:53, marios  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 
> 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"  wrote:
> >
> >> Hi folks:
> >>
> >> Apologies for the delay in announcing the Neutron mid-cycle, but I
> was
>

Re: [openstack-dev] URLs

[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

[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 
wrote:

>
> On Nov 10, 2014, at 10:55 AM, Mike Bayer  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.

[Clark, Robert Graham]

Sounds like a security/identity/secrets mashup might be on the cards  – should 
be fun!

-Rob

From: Morgan Fainberg 
mailto:morgan.fainb...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 11 November 2014 21:52
To: OpenStack List 
mailto: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 
mailto:lbrags...@gmail.com>> wrote:



On Tue, Nov 11, 2014 at 3:30 PM, Douglas Mendizabal 
mailto: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" 
mailto: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

[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

[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
bloc

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

[Tomasz Napierala]

On 06 Nov 2014, at 12:20, Przemyslaw Kaminski  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

[Anita Kuno]

On 11/12/2014 11:06 AM, Salvatore Orlando wrote:
> On 12 November 2014 09:53, marios  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]

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

[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

[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

[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  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

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

[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

[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

[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

[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

[Angus Salkeld]

On Wed, Nov 12, 2014 at 9:33 PM, Alexis Lee  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

[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 

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.

[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

[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)" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 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

[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

[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

[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

[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

[Steve Gordon]

- Original Message -
> From: "Zhipeng Huang" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> 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?

[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?

[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  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

[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

[Saro Chandra Bhooshan T.V.]

count me also.

On Wed, Nov 12, 2014 at 2:48 PM, Irena Berezovsky 
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

[Stan Lagun]

On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter  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


___
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

[Pradip Mukhopadhyay]

Thanks, Zane for pointing out the right mailing list.



--pradip


On Wed, Nov 12, 2014 at 6:35 PM, Zane Bitter  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

[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

[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

[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  wrote:

> - Original Message -
> > From: "Zhipeng Huang" 
> > 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

[Monty Taylor]

On 11/12/2014 02:40 AM, Richard Jones wrote:
> On 12 November 2014 18:17, 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.
>>
> 
> 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
>> 
> 
> 
> 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?

[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  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

[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

[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 
> 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

[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  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



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?

[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  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

[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

[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 
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

[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

[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

[Zane Bitter]

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


On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter 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

[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  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

[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.

[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

[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

[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 modules

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

[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
 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

[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 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
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.

[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  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
>  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

[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

[Doug Hellmann]

On Nov 12, 2014, at 5:12 AM, Victor Sergeyev  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  wrote:
> 
> On Nov 10, 2014, at 10:55 AM, Mike Bayer  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.op

Re: [openstack-dev] URLs

[Dean Troyer]

On Wed, Nov 12, 2014 at 4:11 AM, Chris Dent  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

[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



On Wed, Nov 12, 2014 at 6:10 PM, 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, 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()

[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 = 
object.update()
object.save()
return 

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

[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

[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()

[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

[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 
Date:   Wed Nov 5 08:35:10 2014 +

Updated from global requirements

Change-Id: I88286d9ef8ff5fc5210a9ed87bacffd60ff78a56

commit 33f60020b7b476e07edbf8fa40e755887ce66f2a
Author: OpenStack Proposal Bot 
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 
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 
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 
Date:   Mon Oct 27 12:21:13 2014 +

Updated from global requirements

Change-Id: Id3da9d10632b68df8017d4f3dc69cec6ff2f1eb1

commit 8ed3d5308aae453c9f5ed3cd543e91dbf7c4dd9b
Author: Vipin Balachandran 
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 
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 
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 
Date:   Mon Oct 13 18:50:38 2014 +

Updated from global requirements

Change-Id: Id7ac4a6fda3eb2701ab372ce63cfc4f697edced4

commit 84a39fb46b63dc07d9387518cf4e673d6ef8d46b
Author: OpenStack Proposal Bot 
Date:   Sat Oct 11 15:56:20 2014 +

Updated from global requirements

Change-Id: Iea56589abd2f4a764bbd22fc92fb3d2a9189d276

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

[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()

[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] [fuel]

[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]

[Tomasz Napierala]

On 12 Nov 2014, at 17:56, foss geek  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]

[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  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

[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

[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

[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"  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()

[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

[Randall Burt]

On Nov 12, 2014, at 10:42 AM, Zane Bitter 
 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

[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

[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  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  > >> > wrote:
> > >>> On Sat, Oct 18, 2014 at 10:04 AM, Roman Bogorodskiy <
> > >> rbogorods...@mirantis.com > 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

[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

[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.

[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

[Victoria Martínez de la Cruz]

+1!

2014-11-12 9:31 GMT-03:00 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
>
> ___
> 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

[Doug Hellmann]

On Nov 12, 2014, at 1:30 PM, David Kranz  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()

[Mike Bayer]

> On Nov 12, 2014, at 12:45 PM, Dan Smith  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()

# 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()

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

[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

[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

[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

[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

[Doug Hellmann]

On Nov 12, 2014, at 3:29 PM, Andreas Jaeger  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

[Donald Stufft]

> On Nov 12, 2014, at 3:32 PM, Doug Hellmann  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