Re: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

+1 -- Adrian On Jul 22, 2016, at 10:28 AM, Hongbin Lu > wrote: Hi all, Spyros has consistently contributed to Magnum for a while. In my opinion, what differentiate him from others is the significance of his contribution, which adds

Re: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

+1, Spyros will be a great addition to the team. Yuanying 2016年7月25日(月) 9:39 taget : > I am +1 > > Eli. > > > On 2016年07月23日 04:27, Hongbin Lu wrote: > > Hi all, > > > > Spyros has consistently contributed to Magnum for a while. In my opinion, > what differentiate him from

[openstack-dev] [ironic][nova] Nova midcycle, Ironic perspective

Hi all, The nova midcycle went very well from an ironic perspective. Jay Pipes and Andrew Laski had a new (better!) proposal for how we schedule ironic resources, which I'd like to detail for folks. We explicitly split this off from the topic of running multiple nova-compute daemons for Ironic,

[openstack-dev] [keystone]keystone v2 bug

Hi all, In the mitaka version, I used v2 RESTful API of keystone as following: curl -i -H "Content-Type: application/json" -d ' { "auth": { "tenantName": "admin", "passwordCredentials": { "username": "admin", "password": "password" } } }'

Re: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

I am +1 Eli. On 2016年07月23日 04:27, Hongbin Lu wrote: Hi all, Spyros has consistently contributed to Magnum for a while. In my opinion, what differentiate him from others is the significance of his contribution, which adds concrete value to the project. For example, the operator-oriented

[openstack-dev] [dragonflow] The failure of fullstack tests

Currently, we suffer from the fullstack failures. At the first glance, I noticed the infinite wait at the line 'self.policy.wait(30)' until eventlet exception happened in fullstack.test_apps.TestArpResponder. There were no logs(df-controller and q-svc) generated for that test case, which means

Re: [openstack-dev] [kolla] Monitoring tooling

Hi, correct me if wrong please: Isn't gnocchi more targeting cloud tenants rather than cloud ops? If that's the case I wont find info like "controller cpu usage" or "hypervisor memory usage". Cheers Mathias Am 24.07.2016 23:02 schrieb "Matthias Runge" : > On 23/07/16 00:15,

[openstack-dev] [neutron] how to create initial db migration script to sub-project

Hi, I am trying to create initial db for the networking-mlnx project. I am following this neutron alembic documentation [1]. I added a entrypoint to networking-mlnx setup.cfg neutron.db.alembic_migrations = networking-mlnx = networking_mlnx.db.migration:alembic_migrations I added model.py

Re: [openstack-dev] [kolla] Monitoring tooling

Thanks Mathias, I'm not tied to Sensu.. anything can really fill that gap in my mind. You've done a good job at outlining the steps involved. I created a blueprint with the steps I had in mind[0] For this cycle, I wanted to keep it simple so it was easily achievable. I only planned to have

Re: [openstack-dev] [kolla] Monitoring tooling

Guys, thanks for all that! Can we for a second abstract this discussion from technology and start by lining up scenerios we want to achieve. Then put a software that will allow us to achieve all/most of scenerios with least amount of work/maintenance? So my scenerios: I want to see when health

[openstack-dev] [Kolla] How to use template-override to build image?

Hi, There seems no doc or example about how to customize the Dockerfile with template override. For example, if I want to run ./tools/build.py --template-only --template-override ./heat-extend.j2 heat, what is the correct format for heat-extend.j2? When the content of heat-extend.j2 is {% set

Re: [openstack-dev] [daisycloud-core] IRC Meeting Log 20160722

Hi Yujun, Thanks for the information. I will create a meeting as you suggested. On Fri, Jul 22, 2016 at 9:35 PM, Yujun Zhang wrote: > Why not try the meeting bot to record the IRC log and archive it > automatically? See http://eavesdrop.openstack.org/ > > -- > Yujun

Re: [openstack-dev] [kolla] Monitoring tooling

On 23/07/16 00:15, Steven Dake (stdake) wrote: > Hi folks, > > At the midcycle we decided to push off implementing Monitoring until > post Newton. The rationale for this decision was that the core review > team has enough on their plates and nobody was super keen to implement > any monitoring

[openstack-dev] [Nova] No cellsv2 meeting this week

Since the majority of us met in person last week and there doesn't seem to be anything that needs discussion right now I am not planning to have a meeting this week. In it's place please feel free to do some reviews :)__

Re: [openstack-dev] [all] Proposal: Architecture Working Group

Hi, all, Thanks to intiate the architecture working group, would be glad to join the group if there is still a place to stand. According to the comment from Thierry in the Tricircle big-tent application https://review.openstack.org/#/c/338796/: "From an OpenStack community standpoint, we

Re: [openstack-dev] [neutron] how to create initial db migration script to sub-project

Hi Moshe, It has been a while since a neutron sub-project initialized new alembic migrations, so the devref is out of date, sorry. Let me help you get this sorted out and then I can update the devref with the latest info. First you need to create the initial migration for each branch (expand and

Re: [openstack-dev] [kolla] Monitoring tooling

Puhh, that is is going to be endless :D I want to see: Operating System / Hardware: system load, cpu user, cpu system, memory usage, swap, swap activity, user/free disk space, nic bw, nic packets, disk bw, disk iops, zombie procs, hdd smart, RAID status Docker: cpu / memory per container,

Re: [openstack-dev] [kolla] Monitoring tooling

I think Sensu is the best monitoring approach out there atm. Nagios / Icinga are way to static and scale badly imho. The kind of checks you proposed are quite interesting. I would suggest to wrap a sensu check around Tempest but that's going to far for the first cycle. The two stacks (Sensu +

Re: [openstack-dev] [kolla] Monitoring tooling

Monitoring is a difficult topic as the number of options regarding the toolset and mechanisms are very high. We had some chats about it in IRC that discovered even more options than I thought existed :D I believe Dave's view on Sensu is generally correct in that Sensu is more directed to

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testingcore

+1 On 7/22/16, 9:49 PM, "Brandon Logan" wrote: +1 On Fri, 2016-07-22 at 09:19 -0500, Darek Śmigiel wrote: > I’m not a core, so treat this as +0 but I think Jakub will be good > addition to core team. > >

Re: [openstack-dev] [kolla] Monitoring tooling

On 25/07/16 06:38, Mathias Ewald wrote: > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud > tenants rather than cloud ops? If that's the case I wont find info like > "controller cpu usage" or "hypervisor memory usage". > > Cheers > Mathias > Uhm, in this scenario, gnocchi just