Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Tue, Dec 1, 2015 at 1:57 AM, Steve Martinelli wrote: > Trying to summarize here... > > - There isn't much interest in keeping eventlet around. > - Folks are OK with running keystone in a WSGI server, but feel they are > constrained by Apache. > - uWSGI could help to

[openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Hello Magnumites, The API Working Group [1] is looking for a Cross-Project Liaison [2] from the Magnum project. What does such a role entail? The API Working Group seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their

Re: [openstack-dev] [nova]New Quota Subteam on Nova

So whats needed to build out that 'framework'? Is it just dispatching provision requests to nova, and then seeing when the quota becomes out of sync, and then backtracking through logs and notifications (+- other) to then figure out the root cause? Or is that framework some kind of local

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

On Nov 30, 2015, at 7:58 AM, michael mccune wrote: > > On 11/30/2015 08:45 AM, Sean Dague wrote: >> Ok, I'm going to assume with no real disagreement we're agreed here. I'm >> moving the api-wg notifications to #openstack-sdks now - >>

[openstack-dev] [nfv][telco] Telco Working Group Meeting Reminder - Wednesday December 2nd at 1400 UTC in #openstack-meeting-alt

Hi all, This week's Telco Working Group meeting [1] is on Wednesday December 2nd at 1400 UTC in #openstack-meeting-alt [2]. The proposed agenda is here: https://etherpad.openstack.org/p/nfv-meeting-agenda Thanks, Steve [1] http://eavesdrop.openstack.org/#Telco_Working_Group_meeting [2]

Re: [openstack-dev] [TripleO/heat] openstack debug command

On 02/12/15 03:18, Lennart Regebro wrote: On Tue, Dec 1, 2015 at 3:39 AM, Steve Baker wrote: I mean _here_ https://review.openstack.org/#/c/251587/ OK, that's great! If you want any help implementing it, I can try. Hey Lennart, help is always appreciated. I can

[openstack-dev] [searchlight][ceilometer][qa][infra] Elasticsearch 2.0 client release

Hi, The elasticsearch 2.0 python client is not backwards compatible with the 1.x client nor server. Currently global-requirements has no upper cap on it; I've proposed https://review.openstack.org/252075 to cap it under version 2.0 on the basis that devstack installs elasticsearch 1.x and I

Re: [openstack-dev] [all][glance] Add Sabari Kumar Murugesan <smuruge...@vmware.com>

Thank you all for the support. It's a big responsibility and I hope to do my best. - Sabari On Tue, Dec 1, 2015 at 11:01 AM, Flavio Percoco wrote: > On 23/11/15 17:20 -0300, Flavio Percoco wrote: > >> Greetings, >> >> I'd like to propose adding Sabari Kumar Murugesan to the

Re: [openstack-dev] [nova] [ironic] Hardware composition

On 12/01/15 at 03:44pm, Vladyslav Drok wrote: Hi list! There is an idea of making use of hardware composition (e.g. http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html) to create nodes for ironic. The current

Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible

On Tue, 2015-12-01 at 20:35 +0530, Sharma Swati6 wrote: > However, I just want to know if I have to implement this in > openstack-ansible, or for that matter, I want to add any new > component to it, are there any steps or guidelines to be followed. > For example, first I create containers and

[openstack-dev] [Fuel] Feature Freeze Exception Request: Task Based Deployment in Astute

Hi, Folks ** Intro * During Iteration 3 our Enhancements Team as long as other folks worked on the feature called "Task Based Deployment with Astute". Here is a link to its blueprint: https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute Major implication of this feature

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

I just upgraded to keystone liberty for one of my production clouds, and went with apache since eventlet was listed as deprecated. It was pretty easy. Just ran into one issue. RadosGW wouldn't work against it until I added "WSGIChunkedRequest On'" in the config. otherwise, the config as shipped

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

With bit more details, I hope this covers all the risks and decision points now. First of all, current list of outstanding commits: https://etherpad.openstack.org/p/fuel_on_centos7 The above list has two sections: backwards compatible changes that can be merged one at a time even if the rest of

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

Hello All! Well, side-effects (or any other effects) are quite obvious and predictable - this will decrease availability of RPC queues a bit. That's for sure. However, Dmitry's guess is that the overall messaging backplane stability increase (RabitMQ won't fail too often in some cases) would

Re: [openstack-dev] [Murano] 'NoMatchingFunctionException: No function "#operator_." matches supplied arguments' error when adding an application to an environment

Thanks Stan. It makes sense now. I was able to see the yaml in the database, but I agree that the cached file extension should change to avoid confusion. I appreciate your thorough response. Regards, --Vahid From: Stan Lagun To: "OpenStack Development Mailing List

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On 01/12/15 06:22, Steven Hardy wrote: > +1 > > I don't think it hurts to turn it on, but tbh I'm uncomfortable with the > mental overhead of a non-voting job that I have to manually treat as a > voting job. If it's stable enough to make it a voting job, I'd prefer we >

Re: [openstack-dev] [nova] [ironic] Hardware composition

On Tue, Dec 1, 2015 at 12:07 PM, Andrew Laski wrote: > On 12/01/15 at 03:44pm, Vladyslav Drok wrote: > >> Hi list! >> >> There is an idea of making use of hardware composition (e.g. >> >>

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Everett, Thanks for reaching out. Eli is a good choice for this role. We should also identify an alternate as well. Adrian -- Adrian > On Dec 1, 2015, at 6:15 PM, Qiao,Liyong wrote: > > hi Everett > I'd like to take it. > > thanks > Eli. > >> On 2015年12月02日 05:18,

[openstack-dev] Gerrit Upgrade 12/16

Hi All, The infra team will be taking gerrit offline for an upgrade on December 16th. We will start the operation at 17:00 UTC and will continue until about 21:00 UTC. This outage is to upgrade Gerrit to version 2.11. The IP address of Gerrit will not be changing. There is a thread beginning

Re: [openstack-dev] [Openstack-i18n] DocImpact Changes

On 24 November 2015 at 13:11, Lana Brindley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Akihiro, > > Judging by most of the bugs we see in the openstack-manuals queue, the > bugs that will be raised in projects' own queues will usually be against

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On Tue, Dec 1, 2015 at 3:22 AM, Steven Hardy wrote: > On Mon, Nov 30, 2015 at 03:35:13PM -0800, Devananda van der Veen wrote: > >On Mon, Nov 30, 2015 at 3:07 PM, Zane Bitter > wrote: > > > > On 30/11/15 12:51, Ruby Loo wrote: > > > >On 30

[openstack-dev] [ironic]Create vm fails when using IronicDriver

hi, all I install Ironic in my devstack by following the document http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html. But I meet a problem now. Create a vm fail by nova by using IronicDriver. My nova.conf like this: ./nova.conf:scheduler_host_manager =

Re: [openstack-dev] [magnum] Mesos Conductor

Hi, Sorry I was off for some days because of health issues. So I think the work items for this BP[1] are: 1)Add support to accept json file in container-create command2)Handle JSON input in docker_conductor3)Implement mesos conductor for container create,delete and list. Correct me if I am

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

hi Everett I'd like to take it. thanks Eli. On 2015年12月02日 05:18, Everett Toews wrote: Hello Magnumites, The API Working Group [1] is looking for a Cross-Project Liaison [2] from the Magnum project. What does such a role entail? The API Working Group seeks API subject matter experts for

Re: [openstack-dev] [OpenStack-docs] [Openstack-i18n] DocImpact Changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/15 12:53, Armando M. wrote: > On 24 November 2015 at 13:11, Lana Brindley > wrote: > > Hi Akihiro, > > Judging by most of the bugs we see in the openstack-manuals queue, the > bugs that will be raised in

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

On 12/01/2015 08:08 AM, Duncan Thomas wrote: > > > On 1 December 2015 at 13:40, Sean Dague > wrote: > > > The current approach means locks block on their own, are processed in > the order they come in, but deletes aren't possible. The busy lock

Re: [openstack-dev] [cross-project] Cross-project Liaisons

On 09:29 Dec 01, Doug Hellmann wrote: > Excerpts from Mike Perez's message of 2015-11-30 17:30:52 -0800: > > Hello all, > > > > Currently for cross-project specs, the author of the spec spends the time to > > explain why a certain feature makes sense to be across multiple projects. > > This > >

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

Hi, we have plugins for neutron (DVS and NSX). We'll finish the work on component registry . You could safely remove nova-network altogether. On Tue, Dec 1, 2015 at 5:49 PM, Sheena Gregson wrote: > We do support Neutron for

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

> > Denis, I actually don't think that Swift needs to use oslo.messaging at > all. The middleware loads the rabbit configuration for the Notifier class > from the CONF object here: > > https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L112 > and that conf

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Sean Dague wrote: On 12/01/2015 08:08 AM, Duncan Thomas wrote: On 1 December 2015 at 13:40, Sean Dague> wrote: The current approach means locks block on their own, are processed in the order they come in, but deletes aren't possible. The busy

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

Hi, Current scheme supports only one RabbitMQ node with url parameter. That's not true, you can pass many hosts via the url like that: rabbit://user:pass@host1:port1,user:pass@host2:port2/vhost http://docs.openstack.org/developer/oslo.messaging/transport.html#oslo_messaging.TransportURL

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

So my takeaway is we need each project to have something like: https://gist.github.com/harlowja/b4f0ddadbda1f92cc1e2 That could possibly exist in oslo (I just threw it together) but the idea is that a thread/greenthread would run that 'run_forever' method in that code and it would

Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror

Vladimir, if you've been behind of this, could you please share further plans in separate email thread or (better) provide plans in README in the repo, so everyone can be aware of planned changes and can review them too? If you or someone else propose a change, please post a link here... Thanks,

Re: [openstack-dev] [Fuel] Patch size limit

TL/DR: I think you're trying to solve the problem the wrong way. If you're trying to reduce the burden of large patches, I feel the project in question should distribute the burden of reviewing the big ones so one person's not stuck doing them all. That also means you can keep that patch in mental

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

+1. No doubts. ) Aleksey Kasatkin On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov wrote: > Guys, > > I propose to promote Roman Prykhodchenko to python-fuelclient cores. He is > the main contributor and maintainer of this repo. And he did a great job > making changes

Re: [openstack-dev] [cross-project] Cross-project Liaisons

Excerpts from Mike Perez's message of 2015-12-01 08:45:30 -0800: > On 09:29 Dec 01, Doug Hellmann wrote: > > Excerpts from Mike Perez's message of 2015-11-30 17:30:52 -0800: > > > Hello all, > > > > > > Currently for cross-project specs, the author of the spec spends the time > > > to > > >

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 30 November 2015 at 23:43, Gal Sagie wrote: > To me, and i could got it wrong, the stadium means two main things: (At > this point in time) > > 1) Remove/ease the burden of OpenStack governance and extra job for > projects/drivers that implement Neutron and are

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 1 December 2015 at 03:03, Neil Jerram wrote: > On 01/12/15 10:42, Thierry Carrez wrote: > > Armando M. wrote: > >> [...] > >> So my question is: would revisiting/clarifying the concept be due after > >> some time we have seen it in action? I would like to think so.

Re: [openstack-dev] [TripleO] RFC: profile matching

Sorry for not getting to this earlier. Some thoughts inline. On 11/09/2015 08:51 AM, Dmitry Tantsur wrote: > Hi folks! > > I spent some time thinking about bringing profile matching back in, so > I'd like to get your comments on the following near-future plan. > > First, the scope of the

[openstack-dev] [Fuel] Disabling HA for RPC queues in RabbitMQ

Hello guys, I would like to propose to disable HA for OpenStack RPC queues. The rationale is to reduce load on RabbitMQ by removing necessity for it to replicate messages across the cluster. You can find more details about proposal in spec [1]. To what is in the spec I can add that I've ran a

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 1 December 2015 at 02:40, Thierry Carrez wrote: > Armando M. wrote: > > [...] > > So my question is: would revisiting/clarifying the concept be due after > > some time we have seen it in action? I would like to think so. > > I also think it's time to revisit this

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 1 December 2015 at 02:40, Neil Jerram wrote: > On 01/12/15 05:16, Doug Wiegley wrote: > > Part of the issue is that in a year, we added all the repos above. And > > all of said repos were all heading over to infra with the same newbie > > questions/mistakes. Not a

[openstack-dev] [Fuel] Responsibility for merging change requests to fuel-main

Hi all, according to numerous requests from fuel engineers ci-team 30 Nov updated the iso in Fuel CI (from ISO#199 to ISO#230). New iso had the last of the code from the fuel master which pass bvt tests. But ISO had the critical bug[0] which broke CI for fuel-library repository. There were 2 ways

Re: [openstack-dev] Gerrit Upgrade 12/16

On 12/01/2015 06:38 PM, Spencer Krum wrote: > There is a thread beginning here: > http://lists.openstack.org/pipermail/openstack-dev/2015-October/076962.html > which covers what to expect from the new software. Nice! This is awesome: the new review panel lets you edit files on the web interface.

[openstack-dev] [midonet] What repos to migrate to OpenStack infrastructure

Hi all, Trying to prepare moving our repos to the OpenStack infrastructure, I got reminded just how many repos we have in our GitHub organization [1] - and how many of those seem to be deprecated or tangential. Now, do we still want to migrate them? Pretty sure the answer is "no" for the

Re: [openstack-dev] [nova][glance][cinder][neutron]How to make use of x-openstack-request-id

Hi Tan, Most of the OpenStack RESTful API returns `X-Openstack-Request-Id` in the API response header but this request id is not available to the caller from the python client. When you use --debug option from command from the command prompt using client, you can see

[openstack-dev] [tricircle] weekly meeting of Dec.2

Hi, Let’s have regular meeting today starting UTC1300 at #openstack-meeting. The networking proposal is updated in the document, and a proposal for stateless PoC also was updated in the doc. https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit?usp=sharing Best

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Adrian, If need more than one alternates, I would like to be that. Thanks & Best Regards Hou Ming Wang On Wed, Dec 2, 2015 at 2:32 PM, 王华 wrote: > Adrian, > I would like to be an alternate. > > Regards > Wanghua > > > On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Adrian, I would like to be an alternate. Regards Wanghua On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto wrote: > Everett, > > Thanks for reaching out. Eli is a good choice for this role. We should > also identify an alternate as well. > > Adrian > > -- > Adrian > > >

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Excerpts from Joshua Harlow's message of 2015-12-01 09:28:18 -0800: > Sean Dague wrote: > > On 12/01/2015 08:08 AM, Duncan Thomas wrote: > >> > >> On 1 December 2015 at 13:40, Sean Dague >> > wrote: > >> > >> > >> The current approach means locks block

[openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

Folks, I would like to request feature freeze exception for disabling HA for RPC queues in RabbitMQ [1]. As I already wrote in another thread [2], I've conducted tests which clearly show benefit we will get from that change. The change itself is a very small patch [3]. The only thing which I

Re: [openstack-dev] [all][glance] Add Sabari Kumar Murugesan <smuruge...@vmware.com>

On 23/11/15 17:20 -0300, Flavio Percoco wrote: Greetings, I'd like to propose adding Sabari Kumar Murugesan to the glance-core team. Sabari has been contributing for quite a bit to the project with great reviews and he's also been providing great feedback in matters related to the design of the

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

+1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Dec 1, 2015 at 6:15 PM, Aleksey Kasatkin wrote: > +1. > No doubts. ) > > > Aleksey Kasatkin > > > On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov > wrote: > >> Guys, >> >> I

Re: [openstack-dev] [keystone]Different projects authentication strategy

On 12/01/2015 01:23 AM, 1021710773 wrote: Every Developers, Hello. I here would like to ask some questions about policy rules. Now the policy rules of openstack in keystone and other projects are set in policy.json, in other words, the policy rules are equal to each projects. And the

[openstack-dev] [Magnum] Networking Subteam Meeting

All, I will be on leave this Thursday and will be unable to chair the Networking Subteam meeting. Please respond if you would like to chair the meeting. Otherwise, we will not have a meeting this week and pick things back up on 12/10. Regards, Daneyon Hansen

Re: [openstack-dev] [nova]New Quota Subteam on Nova

I am highly supportive for the idea of Nova Quota sub-team, for something as complex as Quota, as it helps to move quickly on reviews and changes. Agree with John, a test framework to test quotas will be helpful and can be one of the first task the Nova Quota sub team can focus on as that will

Re: [openstack-dev] [Fuel] Patch size limit

Hi, On Tue, Dec 1, 2015 at 5:41 PM, Michael Krotscheck wrote: > TL/DR: I think you're trying to solve the problem the wrong way. If you're > trying to reduce the burden of large patches, I feel the project in > question should distribute the burden of reviewing the big

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

Hi, -1 for FFE for disabling HA for RPC queue as we do not know all side effects in HA scenarios. On Tue, Dec 1, 2015 at 7:34 PM, Dmitry Mescheryakov < dmescherya...@mirantis.com> wrote: > Folks, > > I would like to request feature freeze exception for disabling HA for RPC > queues in RabbitMQ

Re: [openstack-dev] [ironic] Install Time Too Long Ironic in devstack

Hi Zhi, it seems that Ironic is building a new deploy ramdisk for you with diskimage-builder. You can skip it if you state IRONIC_BUILD_DEPLOY_RAMDISK=False in your local.conf, then the bootstrap image will be downloaded from tarballs.o.o. If you are interested here is a sample ironic setting

[openstack-dev] [nova] Nova API sub-team meeting

Hi, We have weekly Nova API meeting this week. The meeting is being held Tuesday UTC1200. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks

Re: [openstack-dev] [Magnum] Liberty RPMs for RDO

Hello Mathieu, On Mon, Nov 30, 2015 at 4:48 PM, Alan Pevec wrote: > Hi Mathieu, > > 2015-11-30 10:54 GMT+01:00 Mathieu Velten : > > Hi, > > > > Let me first introduce myself : I am currently working at CERN to help > > evaluate and deploy Magnum. > > >

Re: [openstack-dev] [networking-ovs-dpdk] VM creation fails with Unexpected vif_type=binding_failed

Hi Sean, I noticed that above talking using openstack with dpdk only in devstack. I already have kilo environment and want it to support dpdk. Could reinstalling ovs with dpdk will be work? Thanks. Yu 在 2015/11/27 20:38, Mooney, Sean K 写道: For kilo we provided a single node all in

Re: [openstack-dev] [oslo][messaging] configurable ack-then-process (at least/most once) behavior

On 30.11.2015 14:28, Bogdan Dobrelya wrote: > Hello. > Please let's make this change [0] happen to the Oslo messaging. > This is reasonable, straightforward and backwards compatible change. And > it is required for OpenStack applications - see [1] - to implement a > sane HA. The only thing left is

Re: [openstack-dev] [Fuel] Feature Freeze is soon

Mike I think, it is rather good idea. I guess we can have a couple of requests still - although everyone is shy, we might get a little storm of FFE's. BTW, I will file at least one. On Tue, Dec 1, 2015 at 10:28 AM, Mike Scherbakov wrote: > Hi Fuelers, > we are couple

Re: [openstack-dev] Encouraging first-time contributors through bug tags/reviews

sean roberts wrote: > Being successful at your first patch for most people means that their > first effort is different than an a regular patch. > > Identifying abandoned work more quickly is good. It doesn't help the > first timer. > > Tagging low hanging fruit for first timers I like. I'm

Re: [openstack-dev] [cross-project] Cross-project Liaisons

Mike Perez wrote: > [...] > I would like to propose cross-project liaisons which would have the following > duties: > > * Watching the cross-project spec repo [1]. > - Comment on specs that involve your project. +1 to carry forward for TC > approval. > -- If you're not able to provide

[openstack-dev] [Magnum] 'fixed_network' actually means 'fixed_subnet'. Which way is better to fix this?

Hi All, I'm working on API related enhancement and encountered the following issue: bay-creation return 400 Bad Request with a valid fixed-network in baymodel( https://bugs.launchpad.net/magnum/+bug/1519748 ) The 'fixed_network' actually means 'fixed_network_cidr', or more precisely

Re: [openstack-dev] [stable] Stable team PTL nominations are open

The nomination deadline is passed, we have two candidates! I'll be setting up the election shortly (with Jeremy's help to generate election rolls). Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List

[openstack-dev] [midonet] IRC: ditch #midonet-dev?

Hi, Our IRC channels have been neglected for a long time, and as a result we lost ownership of #midonet-dev, which is now owner by freenode-staff. In theory, it should be very easy to get ownership back, particularly since we still own #midonet. But in reality, it seems like none of the freenode

Re: [openstack-dev] [midonet] IRC: ditch #midonet-dev?

+1 for #2 On Tue, Dec 1, 2015 at 10:57 AM, Sandro Mathys wrote: > Hi, > > Our IRC channels have been neglected for a long time, and as a result > we lost ownership of #midonet-dev, which is now owner by > freenode-staff. In theory, it should be very easy to get ownership >

Re: [openstack-dev] [midonet] IRC: ditch #midonet-dev?

On Tue, Dec 1, 2015 at 10:59 AM, Ivan Kelly wrote: > +1 for #2 > PS: Beware of the top-posting! It makes vote counting harder ;-) > > On Tue, Dec 1, 2015 at 10:57 AM, Sandro Mathys > wrote: > > Hi, > > > > Our IRC channels have been neglected for a

Re: [openstack-dev] [midonet] IRC: ditch #midonet-dev?

On Tue, Dec 1, 2015 at 7:08 PM, Antoni Segura Puimedon wrote: > > > On Tue, Dec 1, 2015 at 10:59 AM, Ivan Kelly wrote: >> >> +1 for #2 > > > PS: Beware of the top-posting! It makes vote counting harder ;-) > >> >> >> On Tue, Dec 1, 2015 at 10:57

Re: [openstack-dev] [ironic] Install Time Too Long Ironic indevstack

Thanks for your reply. But now, I meet a new problem. My console display: 2015-12-01 10:06:20.591 | ++ timeout 15 sh -c 'while ! ssh -p 22 -o StrictHostKeyChecking=no -i /opt/stack/data/ironic/ssh_keys/ironic_key stack@10.250.11.127 echo success; do sleep 1; done' 2015-12-01 10:06:35.598 | ++

[openstack-dev] Install Openstack-Ansible

Hi All, I have been following the below link for Openstack-Ansible : http://docs.rackspace.com/rpc/api/v11/bk-rpc-installation/content/ch-playbooks-openstack.html#sec-utility-container-overview . The ansible playbooks are running as of now and as per my understanding, it is only installing

Re: [openstack-dev] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral

On Mon, Nov 30, 2015 at 5:07 AM, WANG, Ming Hao (Tony T) < tony.a.w...@alcatel-lucent.com> wrote: > For the object storage support, does Murano have any plan to support the > auto-uploading function? Murano has plans to support everything applications may need. It is just a matter of

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On 30 November 2015 at 18:19, Derek Higgins wrote: > Hi All, > > A few months tripleo switch from its devtest based CI to one that was > based on instack. Before doing this we anticipated disruption in the ci > jobs and removed them from non tripleo projects. > > We'd

Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror

-1 I personally know Dmitry and respect his contributions into our package management and CI systems around it. Thanks to Dmitry, a lot of bad things were prevented and many things developed which work very well. However, I don't particularly understand this proposal, and I'd like to get some

Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror

On 12/01/2015 09:25 AM, Mike Scherbakov wrote: > 4. I don't quite understand how repo is organized. I see a lot of > Python code regarding to fuel-mirror itself and packetary, which is > used as fuel-mirrors core and being written and maintained mostly by > Bulat [5]. There are seem

Re: [openstack-dev] [Fuel][library] CI gate for regressions detection in deployment data

On 30.11.2015 13:03, Bogdan Dobrelya wrote: > On 20.11.2015 17:41, Bogdan Dobrelya wrote: >>> Hi, >>> >>> let me try to rephrase this a bit and Bogdan will correct me if I'm wrong >>> or missing something. >>> >>> We have a set of top-scope manifests (called Fuel puppet tasks) that we use >>> for

Re: [openstack-dev] [Magnum] 'fixed_network' actually means 'fixed_subnet'. Which way is better to fix this?

Hi HouMing, I checked the heat templates again, and check with heat developers. For heat stack creation now, it can not directly use existed network when create new stack. which means, it need create a new net and subnet. So for fixed_network, the name is still need. just like when you create

Re: [openstack-dev] [Fuel][library] CI gate for regressions detection in deployment data

Hi, > pregenerated catalogs for the Noop tests to become the very first > committed state in the data regression process has to be put in the > *separate repo* +1 to that, we can put this new repo into .fixtures.yml > note, we could as well move the tests/noop/astute.yaml/ there +1 here too,

[openstack-dev] [all][oslo] On Python 3, request_id must by Unicode, not bytes

Hi, The next oslo.context release including the following change (still under review) might break the voting Python 3 gate of your project: https://review.openstack.org/#/c/250731/ Please try to run Python 3 tests of your project with this change. I already ran the tests on Python 3 of

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 01/12/15 04:13, Russell Bryant wrote: > On 11/30/2015 07:56 PM, Armando M. wrote: >> As a result, there is quite an effort imposed on the PTL, the various >> liaisons (release, infra, docs, testing, etc) and the core team to >> help manage the existing relationships and to ensure that the

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

It can be selected but we have no tests for deployment which are run on periodical basis. So, we do not have any recent status. Also, serializer in Nailgun for Nova-Network is now not in use (it is not tested how serialization will work in 8.0). Aleksey Kasatkin On Tue, Dec 1, 2015 at 9:36 AM,

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 01/12/15 05:16, Doug Wiegley wrote: > Part of the issue is that in a year, we added all the repos above. And > all of said repos were all heading over to infra with the same newbie > questions/mistakes. Not a bad thing in and of itself, but the sheer > volume was causing a lot of infra load. So

Re: [openstack-dev] [Neutron] Evolving the stadium concept

Armando M. wrote: > [...] > So my question is: would revisiting/clarifying the concept be due after > some time we have seen it in action? I would like to think so. I also think it's time to revisit this experience now that it's been around for some time. On one hand the Neutron stadium allowed

[openstack-dev] [kolla] ValueError: No JSON object could be decoded

Link: https://openstack.nimeyo.com/67158/?show=67158#q67158 From: kunciil TASK: [ceph | Fetching Ceph keyrings] * fatal: [gridppcl11 -> gridppcl13] => Traceback (most recent call last): File

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On Mon, Nov 30, 2015 at 06:07:44PM -0500, Zane Bitter wrote: > On 30/11/15 12:51, Ruby Loo wrote: > > > > > >On 30 November 2015 at 10:19, Derek Higgins >> wrote: > > > >Hi All, > > > > A few months tripleo switch from its devtest based CI

Re: [openstack-dev] Install Openstack-Ansible

Hi Major, Thanks for your prompt response. I will plan to create a spec for Designate. However, I just want to know if I have to implement this in openstack-ansible, or for that matter, I want to add any new component to it, are there any steps or guidelines to be followed. For example,

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

On 11/29/2015 03:35 PM, Emilien Macchi wrote: > Hello! > > Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151201 We did our (short) meeting, you can rea

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Tuesday 01 December 2015 08:50:14 Lance Bragstad wrote: > On Tue, Dec 1, 2015 at 6:05 AM, Sean Dague wrote: > > > > From an interop perspective, this concerns me a bit. My > > understanding is that Apache is specifically needed for > > Federation. Federation is the norm that

Re: [openstack-dev] [Neutron] need help in translating sql query to sqlalchemy query

Thanks Sean. I will check that. Meanwhile I tried this and it is working port1 = orm.aliased(models_v2.Port, name="port1") port2 = orm.aliased(models_v2.Port, name="port2") router_intf_qry = context.session.query(RouterPort.router_id).join((port1,

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

Hi, in your plan you need to have an item about updating ISO on fuel-library CI gates. Regards, Alex On Tue, Dec 1, 2015 at 4:11 PM, Sergii Golovatiuk wrote: > Hi, > > On Tue, Dec 1, 2015 at 3:58 PM, Dmitry Teselkin > wrote: > >> Hello, >> >>

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Fox, this is one of the reasons. There are others listed in my original letter. Guys, I have prepared two patches [1] and [2] that can properly deploy the master node. I still have not got any positive feedback on the spec [3]. My intention was to wait until Centos 7 feature is merged and then

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

Hi, On Tue, Dec 1, 2015 at 3:58 PM, Dmitry Teselkin wrote: > Hello, > > We're almost got green BVT on custom CentOS7 ISO and it seems that it's > the time to discuss the plan how this feature could be merged. > > This is not the only one feature that is in a queue.

[openstack-dev] [nova] Milestone 13.0.0.0b1 (aka. Mitaka-1) to be cut tomorrow

Hi, As you probably know, the Mitaka Release schedule for Nova defines a first milestone between Dec 1-3 [1] We had an hard dependency for translations and reno changes [2] but now everything is landed in tree. As a consequence, the release patch is provided for cutting the milestone

Re: [openstack-dev] [neutron][neutron-*] Notice! pylint breakage

Should we not be updating this in the requirements project? From: Paul Michali > Reply-To: OpenStack List > Date: Tuesday, December 1, 2015 at 4:50 PM To: OpenStack List

Re: [openstack-dev] [kolla] ValueError: No JSON object could be decoded

Hello, First of all, this is not a mailing list for debugging, I invite you sir/madam to join us on #kolla and ask questions there. Second, this doesn't help whole lot, we can get to the source of problem, but we need your help with that, so let me invite you again to our #kolla channel. Third,

Re: [openstack-dev] [Neutron] need help in translating sql query to sqlalchemy query

On Tue, Dec 01, 2015 at 10:22:41AM EST, Venkata Anil wrote: > Thanks Sean. I will check that. > > Meanwhile I tried this and it is working > > port1 = orm.aliased(models_v2.Port, name="port1") > port2 = orm.aliased(models_v2.Port, name="port2") > router_intf_qry = >

[openstack-dev] [Fuel] Configuration management for Fuel 7.0

Hello, folks. We need any kind of CM for Fuel 7.0. Otherwise new project with 800+ nodes will be near impossible to support. Customer always wants to change something. In our opinion, there are two major approaches for CM: #1 Independent CM (Puppet master, Chef, Ansible, whatever) #2 Fuel-based

  1   2   >