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

Thomas Goirand writes: Hi Thomas, > On 11/15/2014 05:34 PM, Martin Geisler wrote: >> I'm sorry if I came across as being hostile towards packagers and >> distros. I've been running Debian for 15 years and that is because of >> the work the Debian developers put into making the system work well >

[openstack-dev] Ceilometer memory.usage can not get info from libvirt

Hi all, 2014-11-17 16:04:01.563 5162 INFO ceilometer.agent [-] Polling pollster memory.usage in the context of meter_source 14 2014-11-17 16:04:01.564 5162 DEBUG ceilometer.compute.pollsters.memory [-] Checking memory usage for instance 7e53172c-f05f-4fda-9855-af6775c1f4a8 get_samples /opt/sta

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

Thank you for the clarification, yes I know about the blueprint/specification, I submitted yet them and the spec is currently under review :) I noticed there are several steps one has always to do to enable and make a v3 api to work and pass the tests. It would be awesome to have a guideline

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

On 30/10/14 13:13, Matthias Runge wrote: > Hi, > > tl;dr: how to progreed in separating horizon and openstack_dashboard Options so far: horizon_lib/openstack_horizon horizon_lib/horizon_dashboard horizon_lib/horizon horizon/openstack_dashboard did I miss something? If not, I'll create a poll. Ma

Re: [openstack-dev] [neutron] L2 gateway as a service

Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. wrote: > Last Friday I recall we had two discussions around this topic. One in the > morning, which I think led to Maruti to push [1]. The way I understood [1] > was that it is an attempt at unifying [2] and [3], by choosing the API > approach of one

[openstack-dev] [Cinder][DR]replication/CG support in driver

Hi all, We want to add replication/CG related support in huawei driver, would this also be bound to the Dec.19th deadline? There is confusion on whether the deadline is for new drivers or for all the proposals for Kilo. As I remembered in the design summit meetup, it was set for the new drivers co

Re: [openstack-dev] [neutron] L2 gateway as a service

> On Nov 17, 2014, at 9:13 AM, Mathieu Rohon wrote: > > Hi > > On Fri, Nov 14, 2014 at 6:26 PM, Armando M. wrote: >> Last Friday I recall we had two discussions around this topic. One in the >> morning, which I think led to Maruti to push [1]. The way I understood [1] >> was that it is an atte

[openstack-dev] 答复: Ceilometer memory.usage can not get info from libvirt

As described in the document: http://docs.openstack.org/developer/ceilometer/measurements.html#measurements “”” Note To enable the libvirt memory.usage supporting, you need libvirt version 1.1.1+, qemu version 1.5+, and you need to prepare suitable balloon driver in the image, particula

[openstack-dev] [nova] mapping of hypervisor support matrix to driver functions - agenda?

On Fri Nov 14 16:32:59 UTC 2014 Daniel P. Berrange wrote: > One of the items that came out of the design summit is to produce a > formal document to detail so called "capabilities" of virtualization > drivers, to replace what's currently in the wiki page you quote, and > ultimately provide a much

Re: [openstack-dev] [neutron] L2 gateway as a service

I think this thread is about the L2 gateway service... how's that related with the notion of trunk port? I know that the spec under review adds a component which is tantamount to a L2 gateway, but while the functionality is similar, the use case, and therefore the API exposed, are rather different

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

This is in testtools 1.4.0 but I can't upload it to pypi atm - its 500ing. :( -Rob On 17 November 2014 18:41, Nikhil Manchanda wrote: > Thanks Robert! > > Looks like it failed the Travis CI job due to an intermittent connectivity > issue > and I don't have the rights to kick-off the job again.

[openstack-dev] Zero MQ remove central broker. Architecture change.

Hi, all! We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. Actual architecture uses uncharacteristic single broker architecture model. In this way we are ignoring the key 0MQ ideas. Lets describe our message in quotes from ZeroMQ doc

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

On 17/11/14 09:53, Martin Geisler wrote: [...] > As Richard said, npm and bower are not competitors. You use npm to > install bower, and you use bower to download Angular, jQuery, Bootstrap > and other static files. These are the static files that you will want to > include when you finally deplo

Re: [openstack-dev] [cinder] [nova] Consistency groups?

Hello Xing, > Do you have a libvirt volume driver on the Nova side for DRBD? No, we don't. We'd just use the existing DRBD 9 kernel module to provide the local block devices. > Regarding getting consistency group information to the Nova nodes, can > you help me understand the steps you need to

Re: [openstack-dev] [Ironic] A mascot for Ironic

On Sun, Nov 16, 2014 at 2:27 PM, Assaf Muller wrote: > > > - Original Message - >> Hi Ironickers, >> >> I was thinking this weekend: All the cool projects does have a mascot >> so I thought that we could have one for Ironic too. >> >> The idea about what the mascot would be was easy becaus

Re: [openstack-dev] [Ironic] A mascot for Ironic

I'm adding all the names suggestions to the Ironic WhiteBoard etherpad[1] (at the bottom). Feel free to include more names there and then we can call a vote. [1] https://etherpad.openstack.org/p/IronicWhiteBoard Lucas On Mon, Nov 17, 2014 at 10:56 AM, Lucas Alvares Gomes wrote: > On Sun, Nov 1

Re: [openstack-dev] [Ironic] A mascot for Ironic

Bear Metal +1 > On 17 Nov 2014, at 12:00, Lucas Alvares Gomes wrote: > > I'm adding all the names suggestions to the Ironic WhiteBoard > etherpad[1] (at the bottom). > > Feel free to include more names there and then we can call a vote. > > [1] https://etherpad.openstack.org/p/IronicWhiteBoard

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

On 11/15/2014 02:51 PM, Robert Collins wrote: > It probably needs to be backed out of stable/icehouse. The issue is > that we were installing unittest2 via distro packages *and* testtools > new dependency on unittest2 did not express a minimum version. > > We're just about to issue 1.2.1 which wil

Re: [openstack-dev] [neutron] L2 gateway as a service

On Mon, Nov 17, 2014 at 10:13:50AM +0100, Mathieu Rohon wrote: > Hi Hi. > On Fri, Nov 14, 2014 at 6:26 PM, Armando M. wrote: > > Last Friday I recall we had two discussions around this topic. One in the > > morning, which I think led to Maruti to push [1]. The way I understood [1] > > was tha

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

On 11/16/2014 06:11 PM, Robert Collins wrote: > On 17 November 2014 11:29, Alan Pevec wrote: >> 2014-11-15 23:06 GMT+01:00 Robert Collins : >>> We did find a further issue, which was due to the use of setUpClass in >>> tempest (a thing that testtools has never supported per se - its >>> always bee

Re: [openstack-dev] [infra][devstack] CI failed The plugin token_endpoint could not be found

There needs to be a lot more context than that provided. As seen here - https://review.openstack.org/#/c/134379/ this seems to be working fine upstream. -Sean On 11/16/2014 09:16 PM, Wan, Sam wrote: > Hi Sean, > > Seems once I unset ' > DEVSTACK_PROJECT_FROM_GIT=python-keystoneclient,

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

On Mon, Nov 17, 2014 at 7:30 PM, Pasquale Porreca < [email protected]> wrote: > Thank you for the clarification, yes I know about the > blueprint/specification, I submitted yet them and the spec is currently > under review :) > > I noticed there are several steps one has always to d

Re: [openstack-dev] Solving the client libs stable support dilemma

On 11/16/2014 11:23 AM, Doug Hellmann wrote: > > On Nov 16, 2014, at 9:54 AM, Jeremy Stanley wrote: > >> On 2014-11-16 09:06:02 -0500 (-0500), Doug Hellmann wrote: >>> So we would pin the client libraries used by the servers and >>> installed globally, but then install the more recent client >>>

[openstack-dev] [Trove] Clustering API next steps

Good day, Stackers/Trovers. During Paris Design Summit Clustering session [1] we, as community, came up with need of changing existing clustering API. By changing an API i mean deprecating existing clustering action because of its close connection to MongoDB datastore. There were no disagreement

[openstack-dev] [mistral] Team meeting - 11/17/2014

This is a reminder about our team meeting scheduled for today 16.00 UTC. Agenda: Review action items Paris Summit results Current status (progress, issues, roadblocks, further plans) Release 0.2 progress Open discussion (can also be seen at https://wiki.openstack.org/wiki/Meetings/MistralAgenda

Re: [openstack-dev] [neutron] L2 gateway as a service

Sorry, it's early, I was being imprecise and using trunk to mean, "methods to connect x to a neutron (l2 segment". Doug On Nov 17, 2014, at 10:35 AM, Salvatore Orlando mailto:[email protected]>> wrote: I think this thread is about the L2 gateway service... how's that related with the notion

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

On 11/17/2014 06:09 AM, Sean Dague wrote: > On 11/16/2014 06:11 PM, Robert Collins wrote: >> On 17 November 2014 11:29, Alan Pevec wrote: >>> 2014-11-15 23:06 GMT+01:00 Robert Collins : We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools

[openstack-dev] [barbican] Secret store API validation

Hello Barbican folks, Recently I was experimenting with the KMIPSecretStore and observed the following behaviour. Issuing the API call: "curl -X POST -H 'content-type:application/json' -H 'X-Project-Id:12345' -d '{"payload": "my-secret-here", "payload_content_type": "text/plain", "algorithm": "

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

I'm fine with getting this patch in... though a few things should be fixed first, in my opinion: 1. I don't see a header in the blueprint, who is responsible for what. See example in the blueprint: https://blueprints.launchpad.net/fuel/+spec/send-anon-usage (Feature Lead, QA, etc.)

Re: [openstack-dev] [Fuel] Separate code freeze for repos

I believe that we need to do this, and agree with Vitaly. Basically, when we are getting low amount of review requests, it's easy enough to do backports to stable branch. So criteria should be based on this, and I believe it can be even more soft, than what Vitaly suggests. I suggest the followin

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

>> We don't support 2.6 any more in OpenStack. If we decide to pin >> testtools on stable/*, we could just let this be. > > We still support 2.6 on the python clients and oslo libraries - but > indeed not for trove itself with master. What Andreas said, also testtools claims "testtools gives you t

Re: [openstack-dev] [Cinder][DR]replication/CG support in driver

The K1 deadline is for new drivers, not extended functionality on existing drivers, however work submitted after K2 is likely to struggle to get reviewer time as we work on the details of our structural code changes - early submission is therefore strongly advised. On 17 November 2014 11:19, Zhipe

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

Le 11/11/2014 09:30, Jiri Tomasek a écrit : > From what was discussed on contributors meetup, keeping the names > 'horizon' for the lib (framework) and 'openstack_dashboard' for > dashboard seemed most convenient. And I happen to aggree with that. +1 We also discussed the fact that we could kee

[openstack-dev] [Fuel] CentOS falls into interactive mode: Unsupported hardware

Hi all, I was skimming through a nicely written blogpost about Fuel experience [1], and noticed "This hardware ... not supported by CentOS" [2] on one of the screenshots. Looks like CentOS goes into interactive mode and complains about unsupported hardware. Can we do anything with this? I can hardl

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

On 11/17/2014 07:26 AM, Alan Pevec wrote: >>> We don't support 2.6 any more in OpenStack. If we decide to pin >>> testtools on stable/*, we could just let this be. >> >> We still support 2.6 on the python clients and oslo libraries - but >> indeed not for trove itself with master. > > What Andreas

Re: [openstack-dev] [Cinder][DR]replication/CG support in driver

Hi Duncan, thanks for the clear up :) On Mon, Nov 17, 2014 at 8:26 PM, Duncan Thomas wrote: > The K1 deadline is for new drivers, not extended functionality on > existing drivers, however work submitted after K2 is likely to > struggle to get reviewer time as we work on the details of our > stru

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

On 17/11/14 13:28, Yves-Gwenaël Bourhis wrote: > > > Le 11/11/2014 09:30, Jiri Tomasek a écrit : >> From what was discussed on contributors meetup, keeping the names >> 'horizon' for the lib (framework) and 'openstack_dashboard' for >> dashboard seemed most convenient. And I happen to aggree with

[openstack-dev] Removing Nova V2 API xml support

Sean, Joe, Dean, all, Here's the Nova change to disable the V2 XML support: https://review.openstack.org/#/c/134332/ To keep all the jobs happy, we'll need changes in tempest, devstack, devstack-gate as well: Tempest : https://review.openstack.org/#/c/134924/ Devstack : https://review.openstack.

[openstack-dev] [Designate] New meeting time survey

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, We discussed moving the weekly meeting recently - I have put a survey up so we can choose the right time. https://www.surveymonkey.com/r/FJRBSVF If you could please fill this in, it would be great! Graham -BEGIN PGP SIGNATURE- Vers

Re: [openstack-dev] [swift] LTFS integration with OpenStack Swift for scenario like - Data Archival as a Service .

On 14.11.14 20:43, Tim Bell wrote: > It would need to be tiered (i.e. migrate whole collections rather than > files) and a local catalog would be needed to map containers to tapes. > Timeouts would be an issue since we are often waiting hours for recall > (to ensure that multiple recalls for the sa

Re: [openstack-dev] [Fuel] CentOS falls into interactive mode: Unsupported hardware

Hi Mike, I actually reported this to CentOS back in May: https://bugs.centos.org/view.php?id=7136 It's a bug/feature in Anaconda. It can be worked around quite easily by adding "unsupported_hardware" to kernel params or to the kickstart file. I reported the bug because there's no support for Cent

[openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

Good day, Stackers. During Paris Design summit oslo.messaging session was raised good question about maintaining ZeroMQ driver in upstream (see section “dropping ZeroMQ support in oslo.messaging” at [1]) . As we all know, good thoughts are comming always after. I’d like to propose several improve

[openstack-dev] [Zaqar][all] Getting rid of queues: Feedback needed

Greetings, I'd like to discuss in a wider space the change proposed here[0]. I'll explain briefly what the proposal is about for those not familiar with the project. As of now, queue's are a first-class resouce. They need to exist in the backend in order to post messages. In v1.1 of the API queu

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

Le 17/11/2014 14:19, Matthias Runge a écrit : > There is already horizon on pypi[1] > > IMHO this will lead only to more confusion. > > Matthias > > > [1] https://pypi.python.org/pypi/horizon/2012.2 Well the current "horizon" on Pypi is "The OpenStack Dashboard" + horizon(_lib) included If t

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

Hi guys, I've created spec for this patch: https://review.openstack.org/#/c/134937/ Please, check out it. 2014-11-17 15:41 GMT+04:00 Mike Scherbakov : > I'm fine with getting this patch in... > though a few things should be fixed first, in my opinion: > >1. I don't see a header in the bluep

Re: [openstack-dev] Removing Nova V2 API xml support

On Mon, Nov 17, 2014 at 08:24:47AM -0500, Davanum Srinivas wrote: > Sean, Joe, Dean, all, > > Here's the Nova change to disable the V2 XML support: > https://review.openstack.org/#/c/134332/ > > To keep all the jobs happy, we'll need changes in tempest, devstack, > devstack-gate as well: > > Tem

Re: [openstack-dev] 答复: Ceilometer memory.usage can not get info from libvirt

libvirt cannot inspect memory usage because some condition is not satisfied. But the AttributeError exception is ugly, Ceilometer should add basic check for return value, otherwise the unnecessary exception will bother cloud operator. I have reported a bug in Ceilometer for this issue, see https:

Re: [openstack-dev] [Fuel] CentOS falls into interactive mode: Unsupported hardware

Can we add it to our kickstart file? On Mon, Nov 17, 2014 at 4:41 PM, Matthew Mosesohn wrote: > Hi Mike, > > I actually reported this to CentOS back in May: > https://bugs.centos.org/view.php?id=7136 > It's a bug/feature in Anaconda. It can be worked around quite easily > by adding "unsupported_

Re: [openstack-dev] [Horizon] [Devstack]

Hello everyone, I have bumped into an article from one of the memcached creators where he discuss the use of memcached to store session data: http://dormando.livejournal.com/495593.html Maybe we need to take it into consideration. Maybe it'll bring more problems than solutions for a future,

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

+1 for Yves. On Mon, Nov 17, 2014 at 10:43 PM, Yves-Gwenaël Bourhis wrote: > Le 17/11/2014 14:19, Matthias Runge a écrit : > >> There is already horizon on pypi[1] >> >> IMHO this will lead only to more confusion. >> >> Matthias >> >> >> [1] https://pypi.python.org/pypi/horizon/2012.2 > > Well th

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

On 11/17/2014 05:44 AM, Ilya Pekelny wrote: > Hi, all! > > We want to discuss opportunity of implementation of the p-2-p messaging > model in oslo.messaging for ZeroMQ driver. On a related note, have you looked into AMQP 1.0 at all? I have been hopeful about the development to support it because

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Denis On 17/11/14 07:43, Denis Makogon wrote: > During Paris Design summit oslo.messaging session was raised good > question about maintaining ZeroMQ driver in upstream (see section > “dropping ZeroMQ support in oslo.messaging” at [1]) . As we

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

On Mon, Nov 17, 2014 at 4:26 PM, Russell Bryant wrote: > On 11/17/2014 05:44 AM, Ilya Pekelny wrote: > > Hi, all! > > > > We want to discuss opportunity of implementation of the p-2-p messaging > > model in oslo.messaging for ZeroMQ driver. > > On a related note, have you looked into AMQP 1.0 at

Re: [openstack-dev] [oslo] oslo.messaging outcome from the summit

Thanks, Josh, I’ll subscribe to the issue to keep up to date. On Nov 16, 2014, at 6:58 PM, Joshua Harlow wrote: > I started the following issue on kombu's github page (to see if there is any > interest on there side to such an effort): > > https://github.com/celery/kombu/issues/430 > > It's a

Re: [openstack-dev] Solving the client libs stable support dilemma

On Nov 17, 2014, at 6:16 AM, Sean Dague wrote: > On 11/16/2014 11:23 AM, Doug Hellmann wrote: >> >> On Nov 16, 2014, at 9:54 AM, Jeremy Stanley wrote: >> >>> On 2014-11-16 09:06:02 -0500 (-0500), Doug Hellmann wrote: So we would pin the client libraries used by the servers and insta

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

On Nov 17, 2014, at 7:46 AM, Sean Dague wrote: > On 11/17/2014 07:26 AM, Alan Pevec wrote: We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. >>> >>> We still support 2.6 on the python clients and oslo libraries - but >>>

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

On Mon, Nov 17, 2014 at 4:26 PM, James Page wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Denis > > On 17/11/14 07:43, Denis Makogon wrote: > > During Paris Design summit oslo.messaging session was raised good > > question about maintaining ZeroMQ driver in upstream (see secti

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

On Mon, Nov 17, 2014 at 5:44 AM, Ilya Pekelny wrote: > We want to discuss opportunity of implementation of the p-2-p messaging > model in oslo.messaging for ZeroMQ driver. Actual architecture > uses uncharacteristic single broker architecture model. In this way we are > ignoring the key 0MQ ideas

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

On Mon, Nov 17, 2014 at 8:43 AM, Denis Makogon wrote: > Good day, Stackers. > > > During Paris Design summit oslo.messaging session was raised good question > about maintaining ZeroMQ driver in upstream (see section “dropping ZeroMQ > support in oslo.messaging” at [1]) . As we all know, good thou

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

Since there have been no stated conflicts or issues with these times yet we will go with Wednesdays alternating between 1700 and 2200 UTC in #openstack-meeting-3 which seems to be open at that time. This week the meeting will be at 1700. I'll see you all there! On 11/11/2014 04:04 PM, Andre

Re: [openstack-dev] [neutron] L2 gateway as a service

What would be the best meeting to discuss these works and any others related? Maybe, collectively, a very flexible solution for all related use cases could be found. I also want to go forward with some work I've developed a couple months ago, part of "methods to connect x to a neutron l2 segment",

[openstack-dev] oslo.db 1.1.0 released

Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global requirements 766ff5e Activate pep8 check that _ is

Re: [openstack-dev] oslo.db 1.1.0 released

go team oslo!!! > On Nov 17, 2014, at 10:36 AM, Victor Sergeyev wrote: > > Hello All! > > Oslo team is pleased to announce the new release of Oslo database handling > library - oslo.db 1.1.0 > > List of changes: > $ git log --oneline --no-merges 1.0.2..master > 1b0c2b1 Imported Translation

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

On Mon, Nov 17, 2014 at 5:12 PM, Eric Windisch wrote: > > > On Mon, Nov 17, 2014 at 8:43 AM, Denis Makogon > wrote: > >> Good day, Stackers. >> >> >> During Paris Design summit oslo.messaging session was raised good >> question about maintaining ZeroMQ driver in upstream (see section “dropping >

[openstack-dev] [horizon] Changing "Host marked for maintenance" BP target milestone

Hi guys, I've start working on this BP: https://blueprints.launchpad.net/horizon/+spec/mark-host-down-for-maintenance One of the reviews from this BP has been already merged (in juno). Another one has to be finalized. So I have a question: is it possible to change milestone target for this BP fe

Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

Hi Steve, For SR-IOV testing we have a CI job running on a multi node setup with Cisco SR-IOV NIC doing API testing on Neutron patches. It is not reporting results up to Neutron yet and currently is used for internal testing only. We are working on the following: 1. Getting the full Tempest te

[openstack-dev] [nova] RT/Scheduler summit summary and Kilo development plan

Good morning Stackers, At the summit in Paris, we put together a plan for work on the Nova resource tracker and scheduler in the Kilo timeframe. A large number of contributors across many companies are all working on this particular part of the Nova code base, so it's important that we keep co

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

Thank you very much Christopher On 11/17/14 12:15, Christopher Yeoh wrote: Yes, sorry documentation has been on our todo list for too long. Could I get you to submit a bug report about the lack of developer documentation for api plugins? It might hurry us up :-) I reported as a bug and subscr

Re: [openstack-dev] [nova] RT/Scheduler summit summary and Kilo development plan

On Mon, Nov 17, 2014 at 10:58:52AM -0500, Jay Pipes wrote: > Good morning Stackers, > > At the summit in Paris, we put together a plan for work on the Nova resource > tracker and scheduler in the Kilo timeframe. A large number of contributors > across many companies are all working on this particu

Re: [openstack-dev] [Ironic] A mascot for Ironic

On Sun, Nov 16, 2014 at 01:14:13PM +, Lucas Alvares Gomes wrote: > Hi Ironickers, > > I was thinking this weekend: All the cool projects does have a mascot > so I thought that we could have one for Ironic too. > > The idea about what the mascot would be was easy because the RAX guys > put "be

[openstack-dev] Process for program without lead

In the last two elections there was a program that was in the last hours of the nomination period before someone stepped up to lead. Currently there is no process for how to address leadership for a program should the nomination period expire without a someone stepping forward. I would like to disc

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

Le 17/11/2014 14:43, Yves-Gwenaël Bourhis a écrit : > Well the current "horizon" on Pypi is "The OpenStack Dashboard" + > horizon(_lib) included > > If the future "horizon" on pypi is "openstack_dashboard" alone, it would > still pull "horizon_lib" as a dependency, so it would not brake the > exis

Re: [openstack-dev] [oslo] oslo.messaging outcome from the summit

Flavio Percoco wrote: > Still, I'd like us to learn from > previous experiences and have a better plan for this driver (and > future cases like this one). Hi, all! As one of a just joined ZeroMQ maintainers I have a growing plan of ZeroMQ refactoring and development. At the most abstract view

Re: [openstack-dev] [nova] RT/Scheduler summit summary and Kilo development plan

Le 17/11/2014 16:58, Jay Pipes a écrit : Good morning Stackers, At the summit in Paris, we put together a plan for work on the Nova resource tracker and scheduler in the Kilo timeframe. A large number of contributors across many companies are all working on this particular part of the Nova c

Re: [openstack-dev] Process for program without lead

On 17/11/14 16:18, Anita Kuno wrote: > In the last two elections there was a program that was in the last hours > of the nomination period before someone stepped up to lead. Currently > there is no process for how to address leadership for a program should > the nomination period expire without a s

Re: [openstack-dev] URLs

++ from me. On 11/11/2014 05:35 PM, Adam Young wrote: Recent recurrence of the "Why ios everything on its own port" question triggered my desire to take this pattern and put it to rest. My suggestion, from a while ago, was to have a naming scheme that deconflicts putting all of the services ont

Re: [openstack-dev] Process for program without lead

On 11/17/2014 11:35 AM, Hayes, Graham wrote: > On 17/11/14 16:18, Anita Kuno wrote: >> In the last two elections there was a program that was in the last hours >> of the nomination period before someone stepped up to lead. Currently >> there is no process for how to address leadership for a program

[openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

Greetings, Regardless of how big/small bugs backlog is for each project, I believe this is a common, annoying and difficult problem. At the oslo meeting today, we're talking about how to address our bug triage process and I proposed something that I've seen done in other communities (rust-languag

Re: [openstack-dev] URLs

Adam, I'm not sure why you've marked Swift URLs as having their own scheme. It's true that Swift doesn't have the concept of "admin" URLs, but in general if Swift were to assume some URL path prefix, I'm not sure why it wouldn't work (for some definition of work). Other issues might be the fac

[openstack-dev] [mistral] Team meeting minutes/log - 11/17/2014

Thanks for joining us today, Here are the links to the meeting minutes and full log: Minutes - http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-17-16.00.html Full log - http://eavesdrop.ope

Re: [openstack-dev] Process for program without lead

On 11/17/2014 11:45 AM, Anita Kuno wrote: > On 11/17/2014 11:35 AM, Hayes, Graham wrote: >> On 17/11/14 16:18, Anita Kuno wrote: >>> In the last two elections there was a program that was in the last hours >>> of the nomination period before someone stepped up to lead. Currently >>> there is no pro

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

On 11/17/2014 06:43 AM, Yves-Gwenaël Bourhis wrote: > Le 17/11/2014 14:19, Matthias Runge a écrit : > >> There is already horizon on pypi[1] >> >> IMHO this will lead only to more confusion. >> >> Matthias >> >> >> [1] https://pypi.python.org/pypi/horizon/2012.2 > > Well the current "horizon" on

[openstack-dev] [Keystone] Weekly meeting to resume tomorrow Nov. 18 at 1800 UTC

This is just a friendly reminder that the Keystone weekly meeting will resume this week at the normal time. I hope everyone has had a good summit (and potentially break post summit). Welcome back and see everyone tomorrow! Cheers, Morgan Fainberg ___ O

Re: [openstack-dev] [Neutron] Stale patches

good job :-) 2014-11-14 18:34 GMT+08:00 Miguel Ángel Ajo : > Thanks for cleaning up the house!, > > Best regards, > > Miguel Ángel Ajo > > On Friday, 14 de November de 2014 at 00:46, Salvatore Orlando wrote: > > There are a lot of neutron patches which, for different reasons, have not > been upda

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

On 11/17/14, 10:00 AM, "Jason Rist" wrote: >On 11/17/2014 06:43 AM, Yves-Gwenaël Bourhis wrote: >> Le 17/11/2014 14:19, Matthias Runge a écrit : >> >>> There is already horizon on pypi[1] >>> >>> IMHO this will lead only to more confusion. >>> >>> Matthias >>> >>> >>> [1] https://pypi.python.or

[openstack-dev] [FUEL]Re-thinking Fuel Client

Hi folks! I’ve made several internal discussions with Łukasz Oleś and Igor Kalnitsky and decided that the existing Fuel Client has to be redesigned. The implementation of the client we have at the moment does not seem to be compliant with most of the use cases people have in production and canno

Re: [openstack-dev] [horizon] Changing "Host marked for maintenance" BP target milestone

The first review was actually the implementation for a separate blueprint. https://blueprints.launchpad.net/horizon/+spec/evacuate-host The content for this blueprint should follow the horizon blueprint process for Kilo. See: https://blueprints.launchpad.net/horizon/+spec/template Once the bluepr

Re: [openstack-dev] Process for program without lead

On 17/11/14 16:46, Anita Kuno wrote: > On 11/17/2014 11:35 AM, Hayes, Graham wrote: >> On 17/11/14 16:18, Anita Kuno wrote: >>> In the last two elections there was a program that was in the last hours >>> of the nomination period before someone stepped up to lead. Currently >>> there is no process

Re: [openstack-dev] Removing Nova V2 API xml support

Matt, Thanks for the help/reviews!. Looks like the sequence seems to be DevStack / Icehouse - https://review.openstack.org/#/c/134972/ DevStack / Juno - https://review.openstack.org/#/c/134975/ Tempest - https://review.openstack.org/#/c/134924/ Tempest - https://review.openstack.org/#/c/134985/ N

Re: [openstack-dev] Process for program without lead

On Mon, 2014-11-17 at 17:25 +, Hayes, Graham wrote: > Quite often people will come forward in a vacuum - people who thought > they were not right for the job, or felt that someone else would suit > the role better can come forward in a by-election. (I only have > anecdotal evidence for this, bu

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 2014-11-17 15:26, James Page a écrit : This was discussed in the oslo.messaging summit session, and re-enabling zeromq support in devstack is definately on my todo list, but I don't think the should block landing of the currently proposed unit

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

On 11/17/2014 06:43 AM, Yves-Gwenaël Bourhis wrote: > Le 17/11/2014 14:19, Matthias Runge a écrit : > >> There is already horizon on pypi[1] >> >> IMHO this will lead only to more confusion. >> >> Matthias >> >> >> [1] https://pypi.python.org/pypi/horizon/2012.2 > > Well the current "horizon" on Py

[openstack-dev] [oslo.messaging] status of rabbitmq heartbeat support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Many peoples want to have heartbeat support into the rabbit driver of oslo.messaging (https://launchpad.net/bugs/856764) We have different approaches to add this feature: - - Putting all the heartbeat logic into the rabbitmq driver. (htt

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/11/14 09:01, Denis Makogon wrote: > I'm not sure I understand you statement about them not being > "gate"-able - the functional/unit tests currently proposed for the > zmq driver run fine as part of the standard test suite execution - > maybe

Re: [openstack-dev] [neutron] L2 gateway as a service

On 17 November 2014 01:13, Mathieu Rohon wrote: > Hi > > On Fri, Nov 14, 2014 at 6:26 PM, Armando M. wrote: > > Last Friday I recall we had two discussions around this topic. One in the > > morning, which I think led to Maruti to push [1]. The way I understood > [1] > > was that it is an attempt

Re: [openstack-dev] [Fuel] CentOS falls into interactive mode: Unsupported hardware

> > On Mon, Nov 17, 2014 at 4:41 PM, Matthew Mosesohn > wrote: > >> I actually reported this to CentOS back in May: >> https://bugs.centos.org/view.php?id=7136 >> It's a bug/feature in Anaconda. It can be worked around quite easily >> by adding "unsupported_hardware" to kernel params or to the kic

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

понедельник, 17 ноября 2014 г. пользователь Mehdi Abaakouk написал: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Le 2014-11-17 15:26, James Page a écrit : > >> This was discussed in the oslo.messaging summit session, and >> re-enabling zeromq support in devstack is definately on my to

[openstack-dev] [stable] [glance] glance_store scheduled release 0.1.10

Hi all, Following last week's (mentioned) corrections to get Glance and the glance_store library come to stable state, we've got a few changes [0, 1, 2] merged. The library is set for the next release in a couple hours or so. Just wanted to give a head's up and see if there were any concerns.

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

On 18 November 2014 01:46, Sean Dague wrote: > On 11/17/2014 07:26 AM, Alan Pevec wrote: We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. >>> >>> We still support 2.6 on the python clients and oslo libraries - but >>> indee

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

понедельник, 17 ноября 2014 г. пользователь James Page написал: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 17/11/14 09:01, Denis Makogon wrote: > > I'm not sure I understand you statement about them not being > > "gate"-able - the functional/unit tests currently proposed for the >

  1   2   >