[Openstack-operators] [nfv][telcowg] Telco Working Group meeting schedule

Hi all, As discussed in last week's meeting [1] we have been seeing increasingly limited engagement in the 1900 UTC meeting slot. For this reason starting from next week's meeting (October 6th) it is proposed that we consolidate on the 1400 UTC slot which is generally better attended and stop

[Openstack-operators] Openstack-AngularJS related queries

Hi , I want to know what is the use of creating manifest.json file in openstack? How the data is fetched from all the files and passed to the dynamically created .js file in /static/dashboard/js directory. If I make any changes in the dynamically created .js files instead of actual files

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

> > > > I agree with John Griffith. I don't have any empirical evidences to back > my "feelings" on that one but it's true that we weren't enable to enable > Cinder v2 until now. > > Which makes me wonder: When can we actually deprecate an API version? I > *feel* we are fast to jump on the

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

On 2015-09-28 11:43 PM, John Griffith wrote: > > > On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker > wrote: > > FWIW, the most popular client libraries in the last user survey[1] > other than OpenStack’s own clients were: libcloud (48

Re: [Openstack-operators] [openstack-operators][osops] Something other than NOOP in our jenkins tests

Seems reasonable. If someone could put a "dumping ground" directory together that would help. (with an uncurated script as an example) So, i'm getting a feeling we should roll back the bashscript gate, and go back to noop. Thoughts? Best Regards, JJ Asghar c: 512.619.0722 t: @jjasghar irc:

Re: [Openstack-operators] [openstack-operators][osops] Something other than NOOP in our jenkins tests

+1 I like that idea. I think it also ties in nicely with both the Monitoring and Tools WGs. Some projects have a directory called "contrib" that contains contributed items which might not be up to standard. Would that be a simple solution for the "dumping ground"? On Tue, Sep 29, 2015 at 2:29

Re: [Openstack-operators] [ops] Operator Local Patches

Hello All, We have some pretty good contributions of local patches on the etherpad. We are going through right now and trying to group patches that multiple people are carrying and patches that people may not be carrying but solves a problem that they are running into. If you can take some

Re: [Openstack-operators] [openstack-operators][osops] Something other than NOOP in our jenkins tests

If we are going to be stringent on formatting – I would also like to see us be relatively consistent on arguments/env variables that are needed to make a script run. Some pull in ENV vars, some source a rc file, some just say already source your rc file to start with, others accept command

Re: [Openstack-operators] [ops] Operator Local Patches

Just spit balling here But wouldn't the way you deploy/patch these patches be good for the OSOps tools? I bet there is some overlap and having a discussion around how to get those patches _out_ would be a good topic? (Probably for the Tools WG, but worth mentioning here) Best Regards, JJ

Re: [Openstack-operators] Neutron DHCP failover bug

Why not run neutron dhcp agents on both nodes?  On September 29, 2015 at 7:04:57 PM, Sam Morrison (sorri...@gmail.com) wrote: Hi All, We are running Kilo and have come across this bug  https://bugs.launchpad.net/neutron/+bug/1410067 Pretty easy to replicate, have 2 network nodes, shutdown 1 of

[Openstack-operators] Tokyo Ops Design Summit Tracks - Agenda on Sched

Hi all, The agenda for Tokyo design summit's ops track is now on sched (buy Thierry wine if you see him): https://mitakadesignsummit.sched.org/overview/type/ops * Note that we have some unallocated slots (marked "TBC"). In order to help out our software development community who are short

[Openstack-operators] Neutron DHCP failover bug

Hi All, We are running Kilo and have come across this bug https://bugs.launchpad.net/neutron/+bug/1410067 Pretty easy to replicate, have 2 network nodes, shutdown 1 of them and DHCP etc. moves over to the new host fine. Except doing a

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

Mark T. Voelker > On Sep 29, 2015, at 12:36 PM, Matt Fischer wrote: > > > > I agree with John Griffith. I don't have any empirical evidences to back > my "feelings" on that one but it's true that we weren't enable to enable > Cinder v2 until now. > > Which makes me

[Openstack-operators] [Election] [TC] TC Candidacy

Hello to you all. I would like to propose myself as a candidate for the Technical Committee for the upcoming term. The reasons for running in the last election [1] are still relevant for this election of the TC. Since the last election my involvement in OpenStack has increased with a

Re: [Openstack-operators] [openstack-operators][osops] Something other than NOOP in our jenkins tests

On 09/29/2015 07:45 PM, JJ Asghar wrote: So this popped up today[1]. This seems like something that should be leveraged in our gates/validations? I prepared review requests to enable checks on the gates for * osops-tools-monitoring: https://review.openstack.org/#/c/229094/ *

Re: [Openstack-operators] [openstack-operators][osops] Something other than NOOP in our jenkins tests

Awesome! That works! Best Regards, JJ Asghar c: 512.619.0722 t: @jjasghar irc: j^2 On 9/29/15 1:27 PM, Christian Berendt wrote: > On 09/29/2015 07:45 PM, JJ Asghar wrote: >> So this popped up today[1]. This seems like something that should be >> leveraged in our gates/validations? > > I