[openstack-dev] [tacker] tacker rocky vPTG summary

hi, tacker team has held a vPTG via zoom, which is recorded at https://etherpad.openstack.org/p/Tacker-PTG-Rocky in summary: P1 tasks: 1. web studio for vnf resources 2. sfc across k8s with openstack vims 3. make tacker server with monitoring features scaleable other tasks: 1. policy for

Re: [openstack-dev] [refstack] Full list of API Tests versus 'OpenStack Powered' Tests

Submission is no longer anonymous, but the results are not public, still. The submitter decides whether the guideline results are public, but if they do, only the guideline tests are made public. If the submitter does not actively select public availability for the test results, all results

Re: [openstack-dev] [tripleo] storyboard evaluation

On 03/02/2018 02:24 AM, Emilien Macchi wrote: > A quick update: > > - Discussed with Jiri Tomasek from TripleO UI squad and he agreed that his > squad would start to use Storyboard, and experiment it. > - I told him I would take care of making sure all UI bugs created in > Launchpad would be

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

On Fri, Mar 16, 2018 at 5:34 PM, Jeremy Stanley wrote: > On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote: > [...] >> It seems mod_wsgi doesn't want python applications catching SIGHUP, >> as Apache expects to be able to catch that. By default, it even ensures >>

Re: [openstack-dev] [nova] New image backend: StorPool

On Fri, Mar 16, 2018 at 09:39:14AM -0700, Dan Smith wrote: > > Can you be more specific about what is limiting you when you use > > volume-backed instances? > > Presumably it's because you're taking a trip over iscsi instead of using > the native attachment mechanism for the technology that

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote: [...] > It seems mod_wsgi doesn't want python applications catching SIGHUP, > as Apache expects to be able to catch that. By default, it even ensures > signal handlers do not get registered.[0] [...] > Given we just had a goal to make

Re: [openstack-dev] [Release-job-failures][neutron][arista] Release of openstack/networking-arista failed

This Arista release is failing because the packaging job can't run "tox -e venv" because neutron is listed in the requirements.txt for the Arista code and in the constraints file. Excerpts from zuul's message of 2018-03-16 19:50:48 +: > Build failed. > > - release-openstack-python >

Re: [openstack-dev] Zuul project evolution

Awesome! Might IMHO be useful to also start doing this with other projects. James E. Blair wrote: Hi, To date, Zuul has (perhaps rightly) often been seen as an OpenStack-specific tool. That's only natural since we created it explicitly to solve problems we were having in scaling the testing

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

knikolla brought up an interesting wedge in this goal in #openstack-keystone today. It seems mod_wsgi doesn't want python applications catching SIGHUP, as Apache expects to be able to catch that. By default, it even ensures signal handlers do not get registered.[0] I can't quickly find uwsgi's

Re: [openstack-dev] [nova] New image backend: StorPool

On 16 March 2018 at 16:39, Dan Smith wrote: >> Can you be more specific about what is limiting you when you use >> volume-backed instances? > > Presumably it's because you're taking a trip over iscsi instead of using > the native attachment mechanism for the technology that

Re: [openstack-dev] [charms] [tripleo] [puppet] [fuel] [kolla] [openstack-ansible] [cloudcafe] [magnum] [mogan] [sahara] [shovel] [watcher] [helm] [rally] Heads up: ironic classic drivers deprecation

Hello, Thanks for the notice! JP On 16 March 2018 at 12:09, Dmitry Tantsur wrote: > Hi all, > > If you see your project name in the subject that is because a global search > revived usage of "pxe_ipmitool", "agent_ipmitool" or "pxe_ssh" drivers in > the non-unit-test

[openstack-dev] [Qos]Unable to apply qos policy with dscp marking rule to a port

Hi Manjeet / Isaku, I am unable to apply qos policy with dscp marking rule to a port. 1.Create a Qos Policy 2.Create a dscp marking rule on to create qos policy 3.Apply above created policy to a port openstack network qos rule set --dscp-mark 22 dscp-marking

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

Thanks! On 16 March 2018 at 16:56, Doug Hellmann wrote: > Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +: >> On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote: >> > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard >> >

[openstack-dev] [kolla] Dropping off kolla-kubernetes core reviewer team

Hey folks, As many core reviewers in Kolla core teams may already know, I am focused on OpenStack board of director work and adjacent community work. This involves bridging the OpenStack ecosystem and its various strategic focus areas with adjacent community projects that make sense. My work

Re: [openstack-dev] [nova] New image backend: StorPool

On Fri, Mar 16, 2018 at 09:23:11AM -0700, melanie witt wrote: > On Fri, 16 Mar 2018 17:33:30 +0200, Peter Penchev wrote: > > Would there be any major opposition to adding a StorPool shared > > storage image backend, so that our customers are not limited to > > volume-backed instances? Right now,

[openstack-dev] [keystone] Keystone Team Update - Week of 12 March 2018

# Keystone Team Update - Week of 12 March 2018 ## News ### Keystone Admin-ness: the Future At the Denver PTG, while grappling with the concept of admin-ness, we had a moment of clarity when we realized that there were some classes of admin actions that could be described as "global" across

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +: > On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote: > > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard > > wrote: > > > > > For OpenStack-Ansible, we don't need to do anything for that > > >

Re: [openstack-dev] [nova] New image backend: StorPool

> Can you be more specific about what is limiting you when you use > volume-backed instances? Presumably it's because you're taking a trip over iscsi instead of using the native attachment mechanism for the technology that you're using? If so, that's a valid argument, but it's hard to see the

Re: [openstack-dev] [nova] New image backend: StorPool

I can provide some insights from the Dell EMC ScaleIO side. As you can see from the patch that Matt pointed to, it is possible to add ephemeral/image backend support to Nova. That said, it is not easy and [IMHO] prone to error. There is no ‘driver model’ like there is in Cinder, where you just

Re: [openstack-dev] [nova] New image backend: StorPool

On Fri, Mar 16, 2018 at 11:04:06AM -0500, Sean McGinnis wrote: > Just updating the subject line tag to glance. ;) Errr, sorry, but no, this is for a Nova image backend (yes, namespace overload, I know) - the driver that lets a Nova host create "local" images for non-volume-backed instances. > On

Re: [openstack-dev] [nova] New image backend: StorPool

On Fri, 16 Mar 2018 17:33:30 +0200, Peter Penchev wrote: Would there be any major opposition to adding a StorPool shared storage image backend, so that our customers are not limited to volume-backed instances? Right now, creating a StorPool volume and snapshot from a Glance image and then

Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s

> On Mar 16, 2018, at 7:40 AM, Simon Leinen wrote: > > Joe Topjian writes: >> Terraform hat! I want to slightly nit-pick this one since the words >> "leak" and "admin-priv" can sound scary: Terraform technically wasn't >> doing anything wrong. The problem was that

Re: [openstack-dev] [glance] New image backend: StorPool

Just updating the subject line tag to glance. ;) On Fri, Mar 16, 2018 at 05:33:30PM +0200, Peter Penchev wrote: > Hi, > > A couple of years ago I created a Nova spec for the StorPool image > backend: https://review.openstack.org/#/c/137830/ There was some > discussion, but then our company

Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s

What about the other way around? An Octavia plugin that simply manages k8s Ingress objects on a k8s cluster? Depending on how operators are deploying openstack, this might be a much easier way to deploy Octavia. Thanks, Kevin From: Lingxian Kong

Re: [openstack-dev] [nova] New image backend: StorPool

On 3/16/2018 10:33 AM, Peter Penchev wrote: Would there be any major opposition to adding a StorPool shared storage image backend, so that our customers are not limited to volume-backed instances? Right now, creating a StorPool volume and snapshot from a Glance image and then booting instances

[openstack-dev] [chef] State of the Kitchen - 2nd Edition

This is the second edition of what is going on in Chef OpenStack. The goal is to give a quick overview to see our progress and what is on the menu. Feedback is always welcome, as this is an iterative thing. Appetizers => Pike has been branched! Supermarket has also received a round of

[openstack-dev] [glance] bug squad meetings start Monday

The Glance Bug Squad will meet biweekly on Monday of even-numbered ISO weeks at 10:00 UTC in #openstack-glance. The meeting will last 45 minutes. The first meeting will be 19 March 2018. Agenda and notes: https://etherpad.openstack.org/p/glance-bug-squad-meeting

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

On Mar 15, 2018, at 10:31 PM, Gilles Dubreuil wrote: > > Any chance we can progress on this one? > > I believe there are not enough participants to split the API SIG meeting in > 2, and also more likely because of the same lack of people across the 2 it > could make it

[openstack-dev] [nova] New image backend: StorPool

Hi, A couple of years ago I created a Nova spec for the StorPool image backend: https://review.openstack.org/#/c/137830/ There was some discussion, but then our company could not immediately allocate the resources to write the driver itself, so the spec languished and was eventually abandoned.

Re: [openstack-dev] [nova] Does not hook for validating resource name (name/hostname for instance) required?

On 3/16/2018 1:22 AM, 양유석 wrote: Our company operates Openstack clusters and we had legacy DNS system, and it needs to check hostname check more strictly including RFC952. Also our operators demands for unique hostname in a region (we do not have tenant network yet using l3 only network). So

Re: [openstack-dev] [devstack] stable/queens: How to configure devstack to use openstacksdk===0.11.3 and os-service-types===1.1.0

On 3/16/2018 9:29 AM, Kwan, Louie wrote: In the stable/queens branch, since openstacksdk0.11.3 and os-service-types1.1.0 are described in openstack's upper-constraints.txt, https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L411

Re: [openstack-dev] [nova][placement] update_provider_tree design updates

> > ...then there's no way I can know ahead of time what all those might be. > (In particular, if I want to support new devices without updating my > code.) I.e. I *can't* write the corresponding > provider_tree.remove_trait(...) condition. Maybe that never becomes a > real problem because

Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s

Joe Topjian writes: > Terraform hat! I want to slightly nit-pick this one since the words > "leak" and "admin-priv" can sound scary: Terraform technically wasn't > doing anything wrong. The problem was that Octavia was creating > resources but not setting ownership to the tenant. When it came time

[openstack-dev] [devstack] stable/queens: How to configure devstack to use openstacksdk===0.11.3 and os-service-types===1.1.0

In the stable/queens branch, since openstacksdk0.11.3 and os-service-types1.1.0 are described in openstack's upper-constraints.txt, https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L411

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote: > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard > wrote: > > > For OpenStack-Ansible, we don't need to do anything for that > > community goal. I am not sure how we can remove our name from > > the

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

> On Mar 16, 2018, at 04:02, Jean-Philippe Evrard > wrote: > > Hello, > > For OpenStack-Ansible, we don't need to do anything for that community > goal. I am not sure how we can remove our name from the storyboard, > so I just inform you here. > > Jean-Philippe

Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s

On Fri, Mar 16, 2018 at 5:01 AM, Joe Topjian wrote: > Hi Chris, > > I wear a number of hats related to this discussion, so I'll add a few > points of view :) > > It turns out that with >> Terraform, it's possible to tear down resources in a way that causes >> Neutron to >> leak

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

On 2018-03-16 13:22, Jeffrey Zhang wrote: > kolla install openstack packages through master tarball file on kolla > master branch[0]. > > On stable branch, kolla install through neutron tag tarball. But i think > there will be also > some issue here. How about i want to install

Re: [openstack-dev] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints

kolla install openstack packages through master tarball file on kolla master branch[0]. like pip install -c upper-constraints.txt neutron-master.tar.gz On stable branch, kolla install through neutron tag tarball. so it should work. But i think there will be also some issue here. How about i

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

kolla install openstack packages through master tarball file on kolla master branch[0]. On stable branch, kolla install through neutron tag tarball. But i think there will be also some issue here. How about i want to install neutron-12.0.1.tar.gz, whereas neutron===12.0.0 exist in the

Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s

Just FYI, l7 policy/rule support for Neutron LBaaS V2 and Octavia is on its way[1], because we will have both octavia and magnum deployed on our openstack based public cloud this year, an ingress controller for openstack(octavia) is also on our TODO list, any kind of collaboration are welcomed :-)

[openstack-dev] [charms] [tripleo] [puppet] [fuel] [kolla] [openstack-ansible] [cloudcafe] [magnum] [mogan] [sahara] [shovel] [watcher] [helm] [rally] Heads up: ironic classic drivers deprecation

Hi all, If you see your project name in the subject that is because a global search revived usage of "pxe_ipmitool", "agent_ipmitool" or "pxe_ssh" drivers in the non-unit-test context in one or more of your repositories. The classic drivers, such as pxe_ipmitool, were deprecated in Queens,

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

Hi Andreas, In the documentation for networking-bgpvpn, we suggest to install these packages with "pip install -c https://git.openstack.org/cgit/openstack/ requirements/plain/upper-constraints.txtt networking-bgpvpn=8.0.0" .In many cases this can work well enough for people wanting to try this

[openstack-dev] [nova] [placement] placement update 18-11

Here's a placement update! # Most Important While work has started on some of the already approved specs, there are still a fair few under review, and a couple yet to be written. Given the number of specs we've got going it's entirely likely we've bitten off more than we can chew, but we'll

Re: [openstack-dev] [mistral][tempest][congress] import or retain mistral tempest service client

On 13 March 2018 at 18:51, Eric K wrote: > Hi Mistral folks and others, > > I'm working on Congress tempest tests [1] for integration with Mistral. In > the tests, we use a Mistral service client to call Mistral APIs and > compare results against those obtained by

[openstack-dev] [tc] Technical Committee Status update, March 16th

Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) governance-related that is not

Re: [openstack-dev] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints

On 2018-03-16 11:49, Jeffrey Zhang wrote: > Now it breaks the kolla's master branch jobs. And have to remove the > "horizon" > and "neutron" in the upper-constraints.txt file. check[1][2].  > > i wanna know what's the correct way to install horizon develop > branch with upper-constraints.txt

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

On 2018-03-16 11:42, Thomas Morin wrote: > This is related to the topic in "[horizon][neutron] tools/tox_install > changes - breakage with constraints". > > proposes to remove these projects from upper-constraints (for a > different reason) > https://review.openstack.org/#/c/552865 >

Re: [openstack-dev] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints

Now it breaks the kolla's master branch jobs. And have to remove the "horizon" and "neutron" in the upper-constraints.txt file. check[1][2]. i wanna know what's the correct way to install horizon develop branch with upper-constraints.txt file? [1]

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

thanks Thomas, i will move my question into that topics. anyone who are interesting this issue, please reply in "[horizon][neutron] tools/tox_install changes - breakage with constraints". On Fri, Mar 16, 2018 at 6:42 PM, Thomas Morin wrote: > This is related to the

Re: [openstack-dev] [Neutron] Dublin PTG Summary

Miguel Lavalle, 2018-03-12 13:45: > * Ruijing Guo proposed to support VLAN transparency in Neutron OVS > agent. > > [...] - While on this topic, the conversation temporarily forked to > the use of registers instead of ovsdb port tags in L2 agent br-int > and possibly remove br-tun. Thomas Morin

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

This is related to the topic in "[horizon][neutron] tools/tox_install changes - breakage with constraints". proposes to remove these projects from upper-constraints (for a different reason)https://review.openstack.org/#/c/552865 that adds other projects to global-requirements, explicitly postpone

[openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

recently, a new patch is merged[0]. It adds neutron and horizon itself into upper-constraints.txt. But this will break installing horizon and neutron with upper-constraints.txt. Now it breaks the kolla's master branch patch. And have to remove the "horizon" and "neutron" in the files.

[openstack-dev] [ptg][sig][upgrades] Upgrade SIG

Hi All I finally got round to writing up my summary of the Upgrades session at the PTG in Dublin (see [0]). One outcome of that session was to form a new SIG centered on Upgrading OpenStack - I'm pleased to announce that the SIG has been formally accepted! The objective of the Upgrade SIG is to

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

thanks for the proposal, Doug. I need an example to understand how things will work out... so, let me use a real-life example (version numbers are made up): openstackdocstheme uses sphinx and needs sphinx 1.6.0 or higher but knows version 1.6.7 is broken. So, openstackdocstheme would add to its

Re: [openstack-dev] OpenStack Ansible Disk requirements [docs] [osa]

Right, that's a little absurd, 1TB? :-) , I completely agree. They could live with anything, but I'd try to estimate minimums across distributions for example, an RDO test deployment with containers looks like: (undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.24.8 "sudo df -h ; sudo

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

Interesting. I'll take a look as well (Winstackers). Just an FYI, SIGHUP doesn't exist in Windows, so for services like nova-compute, neutron-hyperv-agent, neutron-ovs-agent, ceilometer-polling we'd have to use something else. Best regards, Claudiu Belu

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

Hello, For OpenStack-Ansible, we don't need to do anything for that community goal. I am not sure how we can remove our name from the storyboard, so I just inform you here. Jean-Philippe Evrard (evrardjp) On 28 February 2018 at 05:27, ChangBo Guo wrote: > Hi ALL, > > TC

Re: [openstack-dev] [all][api] POST /api-sig/news

Meta: When responding to lists, please do not cc individuals, just repond to the list. Thanks, response within. On Fri, 16 Mar 2018, Gilles Dubreuil wrote: In order to continue and progress on the API Schema guideline [1] as mentioned in [2] to make APIs more machine-discoverable and also

Re: [openstack-dev] [infra][all] Anyone using our ubuntu-mariadb mirror?

Hello, We were using it until a couple of weeks ago, when 10.1.31 got out. 10.1.31 got issues with clustering and we moved to use a mirror of 10.1. (here 10.1.30), instead of 10.1. We haven't decided if we'll move back to 10.1 when 10.1.32 will be out. You can remove it for now, I think we can

Re: [openstack-dev] OpenStack Ansible Disk requirements [docs] [osa]

Hello, That's what it always was, but it was hidden in the pages. Now that I refactored the pages to be more visible, you spotted it :) Congratulations! More seriously, I'd like to remove that requirement, showing people can do whatever they like. It all depends on how/where they store images,

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

+1 From: Jeffrey Zhang [mailto:zhang.lei@gmail.com] Sent: Monday, March 12, 2018 9:07 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [kolla][vote] core nomination for caoyuan ​​Kolla core reviewer team, It is my pleasure to nominate

Re: [openstack-dev] [Tatu][Nova] Handling instance destruction

Having an interface for vendordata that gets deletes would be quite nice. Right now for novajoin we listen to the nova notifications for updates and deletes; if this could be handled natively by vendordata, it would simplify our codebase. BR On Fri, Mar 16, 2018 at 7:34 AM, Michael Still

[openstack-dev] [nova] Does not hook for validating resource name (name/hostname for instance) required?

Hi. I have a question for operating Openstack cluster. Since it's my first mail to mailing list, if it's not a right place to do, sorry for that and please let me know the right one. :) Our company operates Openstack clusters and we had legacy DNS system, and it needs to check hostname check