Re: [openstack-dev] [Manila] Attach/detach semantics

On 11/18/2015 05:31 AM, John Spray wrote: On Wed, Nov 18, 2015 at 4:33 AM, Ben Swartzlander wrote: On 11/17/2015 10:02 AM, John Spray wrote: Hi all, As you may know, there is ongoing work on a spec for Nova to define an "attach/detach" API for tighter integration with

Re: [openstack-dev] [opnfv-tech-discuss] How can I install Redhat-OSP using Fuel

Hi Steven and Tim, Thank you for your reply. (And sorry for my late respond because I was preparing my exams.) My company has decided to try OSP Director before making further decisions. Just few more questions, hoping the answer will make my work easier. :-) 1) I have learnt that both OSP

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

Perfect. The agent will have all static hooks for the extensions in place, like they are used in todays agents (the modular agent was derived from existing lb agent). The knowledge which concrete extension implementation to chose (e.g. lb) comes from the implementation specific manager class that

Re: [openstack-dev] [opnfv-users] [opnfv-tech-discuss] How can I install Redhat-OSP using Fuel

Hello LUFei, Tim and I are working on Apex together, Let me see if I can fill in some gaps for you to help understand some of the relationships of these projects and the game plan for their future. 1) You are correct both director and Apex are based on triple-o. The difference is that director

Re: [openstack-dev] [OpenStack-Infra] [Infra] Gerrit downtime on November 18 2015

Sorry this got posted to the infra mailing list and missed the dev mailing list. Anita. On 11/17/2015 08:04 PM, Spencer Krum wrote: > Hello, > > The infra team will not be upgrading gerrit tomorrow, as a result the > planned outage will not occur. We do not have a date yet that we will be >

[openstack-dev] [stable][neutron] How we handle Kilo backports

Hi all, as per [1] I imply that all projects under stable-maint-core team supervision must abide the stable policy [2] which limits the types of backports for N-2 branches (now it’s stable/kilo) to "Only critical bugfixes and security patches”. With that, I remind all stable core members

[openstack-dev] [Horizon] Redundant checks in form values

In file [1] in `class AddRule` in method `_clean_rule_icmp` why checkups are performed on if `icmp_type` or `icmp_code` is `None` or in range of `-1 to 255`. What I mean here is that in `class AddRule` while values are being accepted from form data and being stored, validators do their job of

Re: [openstack-dev] [oslo] [nova] default-next-release opt flag

With my operator hat on I think the release notes are the right place for these changes. Belmiro On Wed, Nov 18, 2015 at 4:58 PM, Alexis Lee wrote: > Sylvain Bauza said on Wed, Nov 18, 2015 at 04:48:50PM +0100: > > >This is just for the case of "we're going to change the default

[openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Hi everyone, The starting point for this post is a specific Neutron sub-project (networking-bgpvpn) but I believe the issues raised are shared with other neutron stadium project and possibly relevant beyond Neutron, to projects tagged release-independent in general. In the context of the

Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken

On 11/18/15 at 08:32am, Andrew Laski wrote: On 11/17/15 at 07:43pm, Jay Pipes wrote: On 11/17/2015 05:43 PM, Matt Riedemann wrote: I found some time to work on a reverse sort of nova's tables for the db archive command, that looks like [1]. It works fine in the unit tests, but fails because

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

On Wed, Nov 18, 2015 at 9:44 AM, Ihar Hrachyshka wrote: > Hi all, > > as per [1] I imply that all projects under stable-maint-core team > supervision must abide the stable policy [2] which limits the types of > backports for N-2 branches (now it’s stable/kilo) to "Only

Re: [openstack-dev] [oslo][All] Make CONF.set_override with paramter enforce_type=True by default

Excerpts from Markus Zoeller's message of 2015-11-17 18:10:14 +0100: > ChangBo Guo wrote on 11/17/2015 01:29:53 PM: > > > From: ChangBo Guo > > To: "OpenStack Development Mailing List (not for usage questions)" > > >

[openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

Hi, I think we all agree that it isn't OK to log credentials (like passwords) in DEBUG logs. However, what about other information that might be sensitive? A patch was recently submitted to log (in debug) the SWIFT temporary URL [1]. I agree that it would be useful for debugging, but since that

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

I missed this mailing thread. Thanks for coordinating the effort! Mon 1500UTC works for me too. 2015-11-18 23:36 GMT+09:00 Ihar Hrachyshka : > Thanks everyone for responses. > > It seems like Mon 15:00 UTC works for all of us, so I pushed the following > patch to book

Re: [openstack-dev] [oslo] [nova] default-next-release opt flag

Sylvain Bauza said on Wed, Nov 18, 2015 at 04:48:50PM +0100: > >This is just for the case of "we're going to change the default on the > >next release". I think in that case, a release note is the right thing. > >We don't need new fancy code for that. > > I usually hate saying just +1 in an

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo

On 11/17/2015 10:37 PM, Nikhil Manchanda wrote: Thanks for putting up that fix Matt. The dependency on trunk python-troveclient (for stable/kilo) definitely seems screwy-- but I'm wondering if this was done for backwards compatibility reasons? (i.e. to ensure the latest version of

Re: [openstack-dev] [oslo] [nova] default-next-release opt flag

On 11/17/2015 05:31 PM, Matt Riedemann wrote: > > > On 11/17/2015 2:05 PM, Sylvain Bauza wrote: >> >> >> Le 17/11/2015 20:25, Sean Dague a écrit : >>> On 11/17/2015 01:48 PM, Matt Riedemann wrote: On 11/17/2015 11:28 AM, Alexis Lee wrote: > Often in Nova we introduce an option

Re: [openstack-dev] [oslo] [nova] default-next-release opt flag

Le 18/11/2015 16:34, Sean Dague a écrit : On 11/17/2015 05:31 PM, Matt Riedemann wrote: On 11/17/2015 2:05 PM, Sylvain Bauza wrote: Le 17/11/2015 20:25, Sean Dague a écrit : On 11/17/2015 01:48 PM, Matt Riedemann wrote: On 11/17/2015 11:28 AM, Alexis Lee wrote: Often in Nova we

[openstack-dev] [ceilometer][libvirt] Libvirt error during instance disk allocation metering

Hi, folks! In our deployed envs we met with a libvirt error *"missing storage backend for network files using rbd protocol"* in *virDomainGetBlockInfo* call [1] . This exception is raised when Ceilometer are trying to get info about VM disk usage and

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo

On 18 November 2015 at 16:27, Matt Riedemann wrote: > > > On 11/17/2015 9:22 PM, Matt Riedemann wrote: >> >> I noticed this failing today: >> >> >> http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_061 >> >> >>

[openstack-dev] [magnum] Mesos Conductor

Hi all,I am working on the blueprint [1]. As per my understanding, we have two resources/objects in mesos+marathon:1)Apps: combination of instances/containers running on multiple hosts representing a service.[2]2)Application Groups: Group of apps, for example we can have database application

Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken

On 11/18/2015 7:32 AM, Andrew Laski wrote: On 11/17/15 at 07:43pm, Jay Pipes wrote: On 11/17/2015 05:43 PM, Matt Riedemann wrote: I found some time to work on a reverse sort of nova's tables for the db archive command, that looks like [1]. It works fine in the unit tests, but fails because

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo

On 11/18/2015 9:23 AM, Matt Riedemann wrote: On 11/17/2015 10:37 PM, Nikhil Manchanda wrote: Thanks for putting up that fix Matt. The dependency on trunk python-troveclient (for stable/kilo) definitely seems screwy-- but I'm wondering if this was done for backwards compatibility reasons?

Re: [openstack-dev] [QA][Tempest] Deprecate or drop about Tempest CLI

Dell - Internal Use - Confidential Normally I would say keep the original clis for a cycle but it also makes it more difficult to migrate them to using cliff. So I would vote for removing old entry points. Reworking any workflows consuming the old entry points, to use the new ones, should be

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

On Wed, Nov 18, 2015 at 12:38 PM, Carl Baldwin wrote: > On Wed, Nov 18, 2015 at 9:44 AM, Ihar Hrachyshka wrote: >> Hi all, >> >> as per [1] I imply that all projects under stable-maint-core team >> supervision must abide the stable policy [2] which limits

Re: [openstack-dev] [keystone][stable] nominating lin hua cheng for keystone-stable-maint

+1 On Tue, Nov 17, 2015 at 5:24 PM, Steve Martinelli wrote: > I'd like to nominate Lin Hua Cheng for keystone-stable-maint. He has been > doing reviews on keystone's liberty and kilo stable branches since mitaka > development has opened, and being a member of

Re: [openstack-dev] [All] Use of self signed certs in endpoints

Setting an env var seems like a very straightforward way to do this, and means the deployer can easily control the specifics of what they want without any code changes - that suits me perfectly. Adding some documentation somewhere to that effect might be handy but this is indeed a bit of an edge

Re: [openstack-dev] [Manila] Attach/detach semantics

On Wed, Nov 18, 2015 at 4:33 AM, Ben Swartzlander wrote: > On 11/17/2015 10:02 AM, John Spray wrote: >> >> Hi all, >> >> As you may know, there is ongoing work on a spec for Nova to define an >> "attach/detach" API for tighter integration with Manila. >> >> The concept here

Re: [openstack-dev] [stable][neutron] upper constraints for stable/liberty

Robert Collins wrote: On 14 November 2015 at 02:53, Ihar Hrachyshka wrote: Hi Sachi and all, I was recently looking into how stable/liberty branches are set for neutron in terms of requirements caps, and I realized that we don’t have

[openstack-dev] [openstack-ansible] Documentation update planning

Hi everyone, In the community meeting [1] this week we'll be having a facilitated discussion with regards to documentation improvements for OpenStack-Ansible. If you have any feedback you'd like considered, would like to be part of the conversation, or are keen to contribute then please add to

[openstack-dev] [keystone] HMT/Reseller - The Proposed Plan

Hi During our IRC meeting this week, we decided we needed a recap of this plan, so here goes: Phase 0 (already merged in Liberty): We already support a hierarchy of projects (using the parent_id attribute of the project entity). All the projects in a tree must be in the same domain. Role

Re: [openstack-dev] [networking-ovs-dpdk]

Hi All Reading through this thread I thought participants might be interested to know that Ubuntu now provides a DPDK enabled Open vSwitch package in Ubuntu 15.10 and for Ubuntu 14.04 using the Liberty UCA; you can use it as follows: sudo add-apt-repository cloud-archive:liberty # not

Re: [openstack-dev] [networking-ovs-dpdk]

Hi that is great to know. I will internally report this behavior to our dpdk team But I have already got a patch to change our default target to native-linuxapp https://review.openstack.org/#/c/246375/ which should merge shortly. Im glad it is now working for you. From: Prathyusha Guduri

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

I think all the filtering etc that exists on the current CLI should move over to OSC, I personally find things like --fields super useful. +1 to removing "chassis show --nodes" and making it part of node list. +1 to deploy, instead of activate. Jim also suggested provision. WDYT? I'd only

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

On Wed, Nov 18, 2015 at 06:46:58AM +1100, Ian Wienand wrote: > On 11/18/2015 06:10 AM, Markus Zoeller wrote: > This > >was a trigger to see if we can create a gate job which utilizes the > >latest, bleeding edge, version of libvirt to test such features. > > >* Is already someone working on

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

Hi Markus On Tue, Nov 17, 2015 at 7:10 PM, Markus Zoeller wrote: > Background > == > The blueprint [1] wants to utilize the *virtlogd* logging deamon from > libvirt. Among others to solve bug [2], one of our oldest ones. The > funny part is, that this libvirt

Re: [openstack-dev] [tc][all][osprofiler] OSprofiler is dead, long live OSprofiler

Hi stackers, I updated OSprofiler spec: https://review.openstack.org/#/c/103825/ reviews are required. Best regards, Boris Pavlovic On Mon, Nov 9, 2015 at 2:57 AM, Boris Pavlovic wrote: > Hi stackers, > > Intro > --- > > It's not a big secret that OpenStack is huge

Re: [openstack-dev] [networking-ovs-dpdk]

Hi James, Thanks for the information. Will experiment on it and share my observations. Sean - I guess this timing issue is fixed in DPDK 2.1. Will try with that and let you know. Anyway, thanks for the help Regards, Prathyusha On Wed, Nov 18, 2015 at 6:00 PM, Mooney, Sean K

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

On Wed, Nov 18, 2015 at 05:18:28PM +1100, Tony Breeds wrote: > On Tue, Nov 17, 2015 at 03:32:45PM -0800, Jay Pipes wrote: > > On 11/17/2015 11:10 AM, Markus Zoeller wrote: > > >Background > > >== > > >The blueprint [1] wants to utilize the *virtlogd* logging deamon from > > >libvirt. Among

Re: [openstack-dev] [Product] [nfv][telco][product] Future of telco working group and weekly meeting reminder

- Original Message - > From: "Shamail" > To: "Steve Gordon" > > Hi Steve, > > > On Nov 18, 2015, at 6:39 AM, Steve Gordon wrote: > > > > Hi all, > > > > Back in Vancouver [1] we began discussing the growing overlap

Re: [openstack-dev] [QA][Tempest] Deprecate or drop about Tempest CLI

On Wed, Nov 18, 2015 at 8:16 AM Masayuki Igawa wrote: > 2015年11月18日(水) 5:37 Matthew Treinish : > >> On Tue, Nov 17, 2015 at 01:39:34AM +, Masayuki Igawa wrote: >> > Hi tempest CLI users and developers, >> > >> > Now, we are improving Tempest

[openstack-dev] [ironic][inspector][documentation] any suggestions

Hi Stackers, I am going to help my team with the Inspector installation instruction. Any ideas or suggestions what and how to contribute back to the community? I see that Ironic Inspector could benefit from Documentation efforts. The repo hasn't got Doc folder or/and auto-generated

Re: [openstack-dev] [Heat]

Can somebody guide how to support heat coding for any new feature. any document for reference please share. On Tue, Nov 17, 2015 at 11:40 PM, Steven Hardy wrote: > On Tue, Nov 17, 2015 at 05:09:16PM +, Pratik Mallya wrote: > >Hello Heat team, > >I recently

[openstack-dev] [ironic][tempest]Tempest test plugin and microversions

Hi Ironic folks, As we discussed in Design Summit, we will move forward with tempest test tasks. I've posted a patch for tempest test plugin interface [1] (Now it fails because of flake8-ignore-difference, anyway). Then, I'd like to discuss about our tests migration procedure. As you know, we

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

Matt Riedemann wrote: > [...] > This is basically what I see for PTL of a stable maint team: > > 1. Helping projects deal with stable branch policy and process. We are > decentralizing now but I suspect there will still be a lot of learning > and cat herding needed in individual projects. This

Re: [openstack-dev] [keystone][stable] nominating lin hua cheng for keystone-stable-maint

Steve Martinelli wrote: > I'd like to nominate Lin Hua Cheng for keystone-stable-maint. He has > been doing reviews on keystone's liberty and kilo stable branches since > mitaka development has opened, and being a member of > horizon-stable-maint, he is already familiar with stable branch >

Re: [openstack-dev] Is there any way I can completely erase all the data when deleting a cinder volume

On 18/11, Young Yang wrote: > There are some sensitive data in my volume. > I hope openstack can completely erase all the data (e.g. overwrite the > whole volume will 0 bits) when deleting a cinder volume. > > I plan to write some code to make Openstack to mount that volume and > rewrite the

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

Dear Alexander and Murano developers and testers, Any suggestion for this? ☺ Thanks, Tony From: WANG, Ming Hao (Tony T) Sent: Tuesday, November 17, 2015 6:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [murano]How to use Murano to transmit

[openstack-dev] [QA][Tempest][Keystone] Re: [openstack-qa] [tempest][keystone]Inherit API was not found in API tempest.

Hi Koshiya-san, Actually, we don't use openstack-qa ML for discussion now. So I added openstack-dev ML to CC. 2015年11月18日(水) 16:31 koshiya maho : > > Hi all, > > I'm creating a tempest that conforms to operational environment > of OpenStack that we have built. > > So

[openstack-dev] [keystone] Auth-token expiration time

Hi All, I have an application which does some HEAT transactions of creating stack,polling for it and updating stack in a loop. In my setup, /etc/keystone/keystone.conf has below settings: expiration=3600 But my transaction loop takes more than 1 hr and AUTH token is expired in between and I am

[openstack-dev] [openstack-ansible] Fedora/CentOS/other Support

Hi everyone, There has been interest expressed from various corners to support more than just Ubuntu in OpenStack-Ansible. While the project is very happy to work on this, no-one has yet stepped up to take a lead role in the execution of this work. The current community has done some research

[openstack-dev] Is there any way I can completely erase all the data when deleting a cinder volume

There are some sensitive data in my volume. I hope openstack can completely erase all the data (e.g. overwrite the whole volume will 0 bits) when deleting a cinder volume. I plan to write some code to make Openstack to mount that volume and rewrite the whole volume with 0 bits. But I'm wondering

Re: [openstack-dev] [ironic][inspector][documentation] any suggestions

On 11/18/2015 10:10 AM, Serge Kovaleff wrote: Hi Stackers, I am going to help my team with the Inspector installation instruction. Hi, that's great! Any ideas or suggestions what and how to contribute back to the community? I see that Ironic Inspector could benefit from Documentation

Re: [openstack-dev] [QA][Tempest] Deprecate or drop about Tempest CLI

2015年11月18日(水) 5:37 Matthew Treinish : > On Tue, Nov 17, 2015 at 01:39:34AM +, Masayuki Igawa wrote: > > Hi tempest CLI users and developers, > > > > Now, we are improving Tempest CLI as we discussed at the summit[1] and > > migrating legacy commands to tempest cli[2].

Re: [openstack-dev] [Product] [nfv][telco][product] Future of telco working group and weekly meeting reminder

Hi Steve, > On Nov 18, 2015, at 6:39 AM, Steve Gordon wrote: > > Hi all, > > Back in Vancouver [1] we began discussing the growing overlap between OPNFV > requirements projects and the current mission of the telco working group. > During this period the product working

Re: [openstack-dev] [neutron][tap-as-a-service] weekly meeting

On Wed, Nov 18, 2015 at 8:31 AM, Takashi Yamamoto wrote: > hi, > > On Thu, Nov 12, 2015 at 2:11 AM, Vikram Hosakote (vhosakot) > wrote: > > Hi, > > > > TAAS looks great for traffic monitoring. > > > > Some questions about TAAS. > > > > 1) Can TAAS be

Re: [openstack-dev] Is there any way I can completely erase all the data when deleting a cinder volume

For the LVM and raw block device drivers, there is already an option to do that - set volume_clear to 'zero' in cinder.conf If you want this for other drivers, then the code could easily be adopted, however I would question whether it is a good idea - the I/O load of zeroing out volumes is very

Re: [openstack-dev] [keystone] HMT/Reseller - The Proposed Plan

Hi Henry, As you said before, this Reseller implementation is not simple, so this plan sounds reasonable for me. On Wed, Nov 18, 2015 at 9:53 AM Henry Nash wrote: > Hi > > During our IRC meeting this week, we decided we needed a recap of this > plan, so here goes: >

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

Hi all, I wonder if this is somehow in conflict with the modular l2 agent approach I'm currently following up for linuxbridge, macvtap and sriov? - RFE: [1] - Frist patchset [2] I don't think so, but to be sure I wanted to raise it up. [1] https://bugs.launchpad.net/neutron/+bug/1468803 [2]

Re: [openstack-dev] [keystone][stable] nominating lin hua cheng for keystone-stable-maint

On Tue, Nov 17, 2015 at 5:24 PM, Steve Martinelli wrote: > I'd like to nominate Lin Hua Cheng for keystone-stable-maint. He has been > doing reviews on keystone's liberty and kilo stable branches since mitaka > development has opened, and being a member of

Re: [openstack-dev] [Fuel][fuel] How can I install Redhat-OSP using Fuel

Hi Igor and Vladimir, Thank you guys for your help. And sorry for my late respond because I was preparing my exams. And another sorry for I have to put off this work. My company has taken Steven and Tim's, both from Redhat, suggestion to try OSP Director before making further decisions. Thank

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

I have to admin I forgot about this thread. Please find comments inline. On 11/06/2015 05:25 PM, Bruno Cornec wrote: Hello, Pavlo Shchelokovskyy said on Tue, Nov 03, 2015 at 09:41:51PM +: For auto-setting driver options on enrollment, I would vote for option 2 with default being fake

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

On 11/02/2015 05:07 PM, Sam Betts (sambetts) wrote: Auto discovery is a topic which has been discussed a few times in the past for Ironic, and its interesting to solve because its a bit of a chicken and egg problem. The ironic inspector allows us to inspect nodes that we don't know the mac

Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken

On 11/17/15 at 07:43pm, Jay Pipes wrote: On 11/17/2015 05:43 PM, Matt Riedemann wrote: I found some time to work on a reverse sort of nova's tables for the db archive command, that looks like [1]. It works fine in the unit tests, but fails because the deleted instances are referenced by

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

Andreas Scheuring wrote: Hi all, I wonder if this is somehow in conflict with the modular l2 agent approach I'm currently following up for linuxbridge, macvtap and sriov? - RFE: [1] - Frist patchset [2] I don't think so, but to be sure I wanted to raise it up. I

[openstack-dev] [sahara] no tempest tests are being run on -sahara jobs due to bad devstack plugin

When attempting to figure out why a jumbo tempest job with heat / trove / sahara was skipping sahara test jobs, I discovered that the sahara devstack plugin is wrong, and doesn't implement the required 'is_sahara_enabled' function. So tempest is never configured for it. It hasn't been running any

Re: [openstack-dev] [networking-ovs-dpdk]

Hi Sean On Wed, Nov 18, 2015 at 12:30 PM, Mooney, Sean K wrote: > Hi james > > Yes we are planning on testing the packaged release to see if it is > compatible with our ml2 driver and the > > Changes we are submitting upstream. If it is we will add a use binary flag >

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

Thanks everyone for responses. It seems like Mon 15:00 UTC works for all of us, so I pushed the following patch to book #openstack-meeting-2 room weekly: https://review.openstack.org/246949 Ihar Rossella Sblendido wrote: Hi Ihar, same for me, all options are ok!

Re: [openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

On Wed, Nov 18, 2015 at 9:48 AM, Ruby Loo wrote: > Hi, > > I think we all agree that it isn't OK to log credentials (like passwords) > in DEBUG logs. However, what about other information that might be > sensitive? A patch was recently submitted to log (in debug) the SWIFT >

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

Hi Bharath, I agree the "container" part. We can implement "magnum container-create .." for mesos bay in the way you mentioned. Personally, I don't like to introduce "apps" and "appgroups" resources to Magnum, because they are already provided by native tool [1]. I couldn't see the benefits to

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

Just want to input more for this topic, I was also thinking more for how we can unify the client interface for Magnum. Currently, the Kubernetes is using "kubectl create" to create all of k8s objects including pod, rc, service, pv, pvc, hpa etc using either yaml, json, yml, stdin file format; The

[openstack-dev] [Neutron] Call for review focus

Hi Neutrites, We are nearly two weeks away from the end of Mitaka 1. I am writing this email to invite you to be mindful to what you review, especially in the next couple of weeks. Whenever you have the time to review code, please consider giving priority to the following: - Patches that

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

Bharath, I agree with Hongbin on this. Let’s not expand magnum to deal with apps or appgroups in the near term. If there is a strong desire to add these things, we could allow it by having a plugin/extensions interface for the Magnum API to allow additional COE specific features. Honestly,

Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit

On Wed, Nov 18, 2015 at 3:33 AM James E. Blair wrote: > Sean Dague writes: > > > Given that it's on track for getting accepted upstream, it's probably > > something we could cherry pick into our deploy, as it won't be a > > divergence issue. > > Once it

Re: [openstack-dev] [QA][Tempest][Keystone] Re: [openstack-qa] [tempest][keystone]Inherit API was not found in API tempest.

Hi Igawa-san, Thanks for your reply. On Wed, 18 Nov 2015 09:00:03 + Masayuki Igawa wrote: > Hi Koshiya-san, > > Actually, we don't use openstack-qa ML for discussion now. So I added > openstack-dev ML to CC. Oh...sorry. I deleted openstack-qa ML from this mail.

[openstack-dev] How to add a periodic check for typos?

Hi stacker, We could use some 3rd tools like topy: pip install topy topy -a git commit & git review Here is an example: https://review.openstack.org/#/c/247261/ Could we have a periodic job like Jenkins users updating our requirement.txt? -- Gareth Cloud Computing, OpenStack,

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

@hongin, @adrian I agree with you. So can we go ahead with magnum container-create(delete) ... for mesos bay (which actually create mesos(marathon) app internally)? @jay, yes we multiple frameworks which are using mesos lib. But the mesos bay we are creating uses marathon. And we had

Re: [openstack-dev] How to add a periodic check for typos?

On 11/18/2015 8:00 PM, Gareth wrote: Hi stacker, We could use some 3rd tools like topy: pip install topy topy -a git commit & git review Here is an example: https://review.openstack.org/#/c/247261/ Could we have a periodic job like Jenkins users updating our requirement.txt?

Re: [openstack-dev] [magnum] Autoscaling both clusters andcontainers

Cool, thanks Ton! On Thu, Nov 19, 2015 at 7:07 AM, Ton Ngo wrote: > The slides for the Tokyo talk is available on slideshare: > > http://www.slideshare.net/huengo965921/exploring-magnum-and-senlin-integration-for-autoscaling-containers > > Ton, > > > [image: Inactive hide

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

@bharath, 1) actually, if you mean use container-create(delete) to do on mesos bay for apps. I am not sure how different the interface between docker interface and mesos interface. One point that when you introduce that feature, please not make docker container interface more complicated than

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

+1. One problem I want to mention is that for mesos integration, we cannot limited to Marathon + Mesos as there are many frameworks can run on top of Mesos, such as Chronos, Kubernetes etc, we may need to consider more for Mesos integration as there is a huge eco-system build on top of Mesos. On

Re: [openstack-dev] Learning to Debug the Gate

We had a mini tutorial today in #openstack-infra, were Clark Boylan explained how one can bring up an environment to debug logstash-2.0. This is tangential to "debugging the gate", but still could be useful to better understand logstash/es pipeline. I did condense the conversation into the doc,

[openstack-dev] [release] short pause/delay in new releases

Most of the members of the release team are off or traveling over the next couple of days, so anticipate delays with new releases until early next week. Sorry for any inconvenience this causes. Doug __ OpenStack Development

Re: [openstack-dev] [lbaas] [octavia] German + Brandon stepping down, Call for Candidates, and No Meeting 11/25

All, Brandon and I have decided to step down as Octavia Sub-Team-Leads (STL) [1] and we want to thank everybody who helped make Octavia the project it is today. Brandon will be dedicating more of his time to other parts of Neutron and I will be splitting my time between FWaaS, Octavia, and

Re: [openstack-dev] [Horizon] Redundant checks in form values

In the current AddRule form, validate_port_range is used as a validator, so a value from 1 to 65535 is accepted. I think this is the reason that _clean_rule_icmp check the exact value range. You can improve it as you think. bug 1511748 is a regression of validate_port_range change in

Re: [openstack-dev] [magnum] Autoscaling both clusters andcontainers

The slides for the Tokyo talk is available on slideshare: http://www.slideshare.net/huengo965921/exploring-magnum-and-senlin-integration-for-autoscaling-containers Ton, From: Jay Lau To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

On Wed, Nov 18, 2015 at 05:44:38PM +0100, Ihar Hrachyshka wrote: > Hi all, > > as per [1] I imply that all projects under stable-maint-core team > supervision must abide the stable policy [2] which limits the types of > backports for N-2 branches (now it’s stable/kilo) to "Only critical bugfixes

Re: [openstack-dev] [ironic][tempest]Tempest test plugin and microversions

Hi, Nice description for our situation. Yes, qa-spec of microversions testing is already approved. But as you said, we need time for the implementation. Your migration patch for ironic doesn't seem hard to be merged, I feel. So it is also nice option to merge the migration patch first.

[openstack-dev] [openstack][openstack-operators] IRC meeting(s)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey everyone! I've been seeing some interesting regressions in our community recently. Our IRC meetings, or at least the ones I've been attending, are extremely variable in quality. I believe this is a disservice to our community as a whole, so

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

On Wed, Nov 18, 2015 at 11:46:40AM +, Daniel P. Berrange wrote: > On Wed, Nov 18, 2015 at 05:18:28PM +1100, Tony Breeds wrote: > > On Tue, Nov 17, 2015 at 03:32:45PM -0800, Jay Pipes wrote: > > > On 11/17/2015 11:10 AM, Markus Zoeller wrote: > > > >Background > > > >== > > > >The

Re: [openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

On Nov 18, 2015 13:52, "Devananda van der Veen" wrote: > > > On Wed, Nov 18, 2015 at 9:48 AM, Ruby Loo wrote: >> >> Hi, >> >> I think we all agree that it isn't OK to log credentials (like passwords) in DEBUG logs. However, what about other

[openstack-dev] [neutron] [networking-sfc] Service Chain project IRC meeting Topic for 11/19/2015

Hi everyone, I have added some topics to the following link for our project meeting discussion tomorrow. Feel free to add topics you would like to discuss to this link. https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting Note that due to the day time change, the meeting

Re: [openstack-dev] [Fuel] Master node upgrade

We are going to address the problem using the following approach: 1. Backup settings from the Fuel 7.0 Master node, including configuration files for bootstrap script, data from state database, security keys and certs, etc 2. Restore settings on top of freshly installed Fuel 8.0 Master. 3. Upload

Re: [openstack-dev] Future of telco working group and weekly meeting reminder

Steve - Thanks for the update. Look forward to seeing the User Stories in the Repo and coming up to speed on them. If you have priorities around them, that would be good to know too as look for commonalities between these stories, the existing user stories and new ones under development. Carol

Re: [openstack-dev] [ironic][tempest]Tempest test plugin and microversions

Hi, Yea, IMO also we can merge Ironic patch in Tempest first but do not have much strong opinion. Ironic patch can be updated on top of microversion testing framework base patch [1] and we can test that while residing in Tempest which avoid updates in Ironic repo (if move Ironic tests first) if

Re: [openstack-dev] [releases] Release countdown for week R-19, Nov 23-27

On 11/18/2015 4:09 PM, Doug Hellmann wrote: Focus - We are currently working towards the Mitaka 1 milestone scheduled for Dec 1-3. Teams should be focusing on wrapping up incomplete work left over from the end of the Liberty cycle, finalizing and announcing plans from the summit, and

[openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

Hi, As we decided in the last weekly meeting, I'd like to use this mailing list to discuss a proposal about creating dedicated tunnel for carrying mirrored traffic between hosts. link: https://wiki.openstack.org/w/images/7/78/TrafficIsolation_20151116-01.pdf Best Regards,

Re: [openstack-dev] [Horizon] Redundant checks in form values

On Thu, Nov 19, 2015 at 3:10 AM, Akihiro Motoki wrote: > In the current AddRule form, validate_port_range is used as a validator, > so a value from 1 to 65535 is accepted. > I think this is the reason that _clean_rule_icmp check the exact value range. > You can improve it as

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

+1. Anything that lands in the high category is usually something that will have a big operational impact. On Wed, Nov 18, 2015 at 8:44 AM, Ihar Hrachyshka wrote: > Hi all, > > as per [1] I imply that all projects under stable-maint-core team > supervision must abide the

Re: [openstack-dev] [stable][neutron] upper constraints for stable/liberty

On Wed, 18 Nov 2015 02:07:45 PM Ihar Hrachyshka wrote: > Robert Collins wrote: > > On 14 November 2015 at 02:53, Ihar Hrachyshka wrote: > >> I was recently looking into how stable/liberty branches are set for > >> neutron > >> in terms of

  1   2   >