Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

Yes, you could consider Neutron as a proxy for this. It creates the network, subnet, router… To be honest I think that we should maybe consider ofering a template that can be created by Neutron and then the template ID passed from Nova or wherever. This will enable an admin to pre cook a number

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Yingxin, Basically, what we implemented was next: - Scheduler consumes RPC updates from Computes - Scheduler keeps world state in memory (and each message from compute is treat like a incremental update) - Incremental update is shared across multiple instances of schedulers (so one message

Re: [openstack-dev] [Nova] Update on live migration priority

2016-02-13 0:21 GMT+08:00 Murray, Paul (HP Cloud) : > This time with a tag in case anyone is filtering… > > > > *From:* Murray, Paul (HP Cloud) > *Sent:* 12 February 2016 16:16 > *To:* openstack-dev@lists.openstack.org > *Subject:* [openstack-dev] Update on live migration

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Thanks Boris, the idea is quite similar in “Do not have db accesses during scheduler decision making” because db blocks are introduced at the same time, this is very bad for the lock-free design of nova scheduler. Another important idea is that “Only compute node knows its own final

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Hi, I wanted to give some thoughts to the thread. There are various perspective around “Hosted vs Self-managed COE”, But if you stand at the developer's position, it basically comes down to “Ops vs Flexibility”. For those who want more control of the stack, so as to customize in anyway they see

Re: [openstack-dev] [Horizon] eslint without color?

On 02/14/2016 10:45 PM, Richard Jones wrote: > I'm just curious why our eslint configuration (in packages.json) specifies > --no-color. It's much harder to spot the errors without color, and I always > end up running it manually to get the color. Also, karma output has color, > so why one and not

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Yingxin, This looks quite similar to the work of this bp: https://blueprints.launchpad.net/nova/+spec/no-db-scheduler It's really nice that somebody is still trying to push scheduler refactoring in this way. Thanks. Best regards, Boris Pavlovic On Sun, Feb 14, 2016 at 9:21 PM, Cheng, Yingxin

[openstack-dev] [Neutron][Dragonflow] IRC Meeting today (2/15) - 0900 UTC

Hello All, We will have an IRC meeting today (Monday, 2/15) at 0900 UTC in #openstack-meeting-4 Please review the expected meeting agenda here: https://wiki.openstack.org/wiki/Meetings/Dragonflow You can view last meeting action items and logs here:

[openstack-dev] [Horizon] eslint without color?

I'm just curious why our eslint configuration (in packages.json) specifies --no-color. It's much harder to spot the errors without color, and I always end up running it manually to get the color. Also, karma output has color, so why one and not the other? In short, would anyone object to turning

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

2016-02-13 19:05 GMT+08:00 Andrew Laski : > > > On Fri, Feb 12, 2016, at 03:51 PM, Ed Leafe wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 02/12/2016 02:41 PM, Andrew Laski wrote: > > > > >> I think if the point of the experience for this API is to be

[openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Hi, I've uploaded a prototype https://review.openstack.org/#/c/280047/ to testify its design goals in accuracy, performance, reliability and compatibility improvements. It will also be an Austin Summit Session if elected:

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

May I ask can we put those thing in to the CLI? I guess there should have similar discussion and I missed. As we didn't want to provide more neutron API proxy, this works sounds like adding more proxy. And API is more simple and more flexible, this make the API have more complex behaviour. Just

[openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 2/15

Meeting on #openstack-meeting-alt at 1400 UTC (7:00AM MDT) 1) Patches/Reviews - https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking 2) Bugs - https://bugs.launchpad.net/nova/+bugs?field.tag=scheduler 3) Opens -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph:

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

If we support 2.x.y, when we bump 'x' is a problem. We didn't order the API changes for now, the version of API change is just based on the order of patch merge. For support 2.x.y, we need bump 'y' first for back-compatible changes I guess. As I remember, we said before, the new feature is the

Re: [openstack-dev] [magnum]swarm + compose = k8s?

HongBin, See my replies and questions in line. >> Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring

[openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

Hi, Short Story: pycryptodome if installed inadvertently will break several projects: Example : https://review.openstack.org/#/c/279926/ Long Story: There's a new kid in town pycryptodome: https://github.com/Legrandin/pycryptodome Because pycrypto itself has not been maintained for a while:

[openstack-dev] [tripleO][Neutron] Appropriate location for networking-* pythonclient extensions

Hi Triple-O folks, I am trying to understand how the notion of overcloud and undercloud would play with the Neutron subprojects. Neutron has sub-projects like networking-l2gw [1], networking-bgpvpn [2] etc, which have their own python-neutronclient CLI extensions [3][4] in their respective

[openstack-dev] [nova][all] Deprecation policy between projects

Hi, Do we have any deprecation policies between projects? When we can remove old drivers of the other projects after they were marked as deprecated? In nova, there are many drivers for the other projects and there are patches which remove this kind of code. (e.g:

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 2/14/16, 3:59 PM, "Ken'ichi Ohmichi" wrote: >2016-02-12 11:19 GMT-08:00 Andrew Laski : >> On Fri, Feb 12, 2016, at 01:45 PM, John Garbutt wrote: >>> On 12 February 2016 at 18:17, Andrew Laski wrote: >>> > >>> > >>> > On Fri, Feb

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Kai Qiang, A major benefit is to have Magnum manage the COEs for end-users. Currently, Magnum basically have its end-users manage the COEs by themselves after a successful deployment. This might work well for domain users, but it is a pain for non-domain users to manage their COEs. By moving

[openstack-dev] [magnum] Re: Assistance with Magnum Setup

Shiva, First off, welcome to OpenStack :) Feel free to call me Steve. Ccing openstack-dev which is typically about development questions not usage questions, but you might have found some kind of bug. I am not sure what the state of Magnum and Keystone is with OpenStack. I recall at our

Re: [openstack-dev] [magnum] Re: Assistance with Magnum Setup

Steve, Thanks for directing Shiva to here. BTW, most of your code on objects and db are still here :). Shiva, Please do join the #openstack-containers channel (It is hard to do trouble-shooting in ML). I believe contributors in the channel are happy to help you. For Magnum team, it looks we

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On 14 Feb 2016, at 09:53, Henry Nash wrote: > On 13 Feb 2016, at 03:06, Adam Young > wrote: > > On 02/12/2016 06:17 AM, Eoghan Glynn wrote: >> >>> Hello all, >>> >>> tl;dr >>> = >>> >>> I have long thought that the