Re: [openstack-dev] Kolla multinode , multi-region deployment support

Grzegorz, This is a technical question about our roadmap and should be sent to the openstack-dev mailing list. As such, ccing openstack-dev so everyone can benefit from my thinking on this matter and others can weigh in. From: Grzegorz Koper mailto:[email protected]>> Date: Monday, Ap

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: 答复: [probably forge email可能是仿冒邮件]Re: openstack-dev] [vitrage] vitrage alarms list

Hi, I exec all the vitrage cli and get the same error. The log error is from /var/log/apache2/vitrage.log Here is my config file.Thanks for your help~ BR dwj Eyal B 2016-04-20 14:10 请答复 给 "OpenStack Development Mailing List \(not for usage questions\)" 收件人 "OpenStack Development Mai

Re: [openstack-dev] [neutron][kilo] - vxlan's max bandwidth

Ian Wells wrote: Right. Note that custom MTU works out of the box only starting from Mitaka. It's been in from at least Kilo (give or take a some bugfixes, it seems, all of which deserve backporting). It never worked as you would expect, though indeed a lot of code to calculate MTU was

[openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Folks, We are considering whether Magnum can supports 2 Nova flavors to provision Kubernetes and other COE minion nodes. This requirement comes from the below use cases: - There are 2 kind of baremetal machines in customer site: one is legacy machines which doesn't support UEFI secu

Re: [openstack-dev] [neutron][release] neutron *-aas release notes are not linked.

On 2016-04-20 06:20, Akihiro Motoki wrote: > Hi, > > I noticed Mitaka release notes for neutron *-aas [1,2,3] are not > referred to from anywhere. > Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas), > but only the release note of the main neutron repo is linked. > > Is the right solu

[openstack-dev] [MassivelyDistributed] - Massively distributed Clouds Working Group - Proposal

Dear all We would like to propose the creation of a new working group to deal with the massively distributed cloud use-case (aka., the Fog/Edge Computing paradigm). The major difference w-r-t existing WGs such as the Large-Scale deployment one, is that we would like to address challenges relate

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Fox, Kevin M wrote: Thomas, I normally side with the distro's take on making sure there is no duplication, but I think Thierry's point comes from two differences coming up that the traditional distro's don't tend to account for. (and to be fair, I normally side with the distro's take too...

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Adrian Otto wrote: This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. The lowest common denominator of all COEs is an remarkably low value API that adds considerable complexity to Magnum that will not strategi

Re: [openstack-dev] [MassivelyDistributed] - Massively distributed Clouds Working Group - Proposal

[email protected] wrote: We would like to propose the creation of a new working group to deal with the massively distributed cloud use-case (aka., the Fog/Edge Computing paradigm). The major difference w-r-t existing WGs such as the Large-Scale deployment one, is that we would like to addres

Re: [openstack-dev] [MassivelyDistributed] - Massively distributed Clouds Working Group - Proposal

Dear Mathieu and Adrien, I think your commitment to the working group seems so exciting and it will be another excellent direction of discussion on the OpenStack technologies. As I introduced to the community in last Tokyo summit on the T-ROS project, SKT is also considering the All-IT 5G archite

Re: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: 答复: [probably forge email可能是仿冒邮件]Re: openstack-dev] [vitrage] vitrage alarms list

Hi, Can you send the vitrage-graph.log ? Is the vitrage-graph process running ? We fixed some bugs with the devstack installation Do you have the latest sources from the vitrage git repo ? Can you get the latest sources (just do git pull) delete the /etc/vitrage/vitrage.conf do unstack.sh and st

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For

[openstack-dev] [Heat] No IRC meeting next week

Hi all, As expected, no meeting during the summit next week. It will resume normally the week after, though I won't be around to run it. Thanks, -- Thomas __ OpenStack Development Mailing List (not for usage questions) Uns

Re: [openstack-dev] [Vitrage] questions about "relationships"

Hi Tony, I agree. Looking forward for those challenges - should be an interesting development process. Elisha From: EXT Wang, Tony T (Nokia - CN) [mailto:[email protected]] Sent: Wednesday, April 20, 2016 9:31 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re:

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Kannan, I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node. The scenario may like this: let say 2 flavors: * flavor_secure * flavor_none_secure For now, flavor-id in baymodel can only be set as one value, Duan Li's requi

[openstack-dev] [Fuel][plugins] VIP addresses and network templates

Hi, I've got a question regarding network templates and VIP. Some of our users want to run the StackLight services (eg Elasticsearch/Kibana and InfluxDB/Grafana servers) on a dedicated network (lets call it 'monitoring'). People use network templates [0] to provision this additional network but how

Re: [openstack-dev] [Ironic][Neutron] Integration status

Hello Haomeng, You want to test VLAN aware instances that support trunk interfaces [0] or try Ironic provisioning in separate provision network? First case is not supported by networking-generic-switch at the moment and requires some modification. Second case is supported, we already have an expe

Re: [openstack-dev] [Neutron] L3 HA testing on scale

Unfortunately, I won't attend summit in Austin, that is why I decided to present these results in the mailing list instead. On Tue, Apr 19, 2016 at 7:29 PM, Edgar Magana wrote: > Is there any session presenting these results during the Summit? It will > be awesome to have a session on this. I co

[openstack-dev] [tricircle] http response code

Hi I read api source code recently and have a question. Do we uniform the "http response code"? such as, 404 means "Not Found". __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-

Re: [openstack-dev] [neutron][kilo] - vxlan's max bandwidth

2016-04-20 14:53 GMT+09:00 Ihar Hrachyshka : > Ian Wells wrote: > >> >> Right. Note that custom MTU works out of the box only starting from >> Mitaka. >> >> It's been in from at least Kilo (give or take a some bugfixes, it seems, >> all of which deserve backporting). > > > It never worked as you w

[openstack-dev] [tripleo] No IRC meeting next week

As so many of us will be in Austin next week, the weekly IRC meeting will be cancelled. The next meeting will be Tuesday 3rd May at 14.00 UTC: https://wiki.openstack.org/wiki/Meetings/TripleO Thanks, Steve __ OpenStack Dev

[openstack-dev] [tripleo] Proposed changes to TripleO project tags

All, We discussed some changes to our release cycle in the weekly meeting yesterday, namely to align with the intended direction of the puppet community to adopt the new cycle-trailing tag[1]. We have also discussed and agreed[2] to adopt the standard stable branch policy[3] for those repos where

Re: [openstack-dev] [tripleo][heat] Summit session clashes

Could we move Functional Tests to Thursday? I have a hands-on workshop at wed 4:30-6:00 pm. Best Regards, Ethan Lynn [email protected] > On Apr 20, 2016, at 09:26, Zane Bitter wrote: > > On 19/04/16 18:04, Steve Baker wrote: >> On 19/04/16 20:29, Steven Hardy wrote: >>> On Tue, Apr 19

Re: [openstack-dev] [Fuel] snapshot tool

Dmitry, You can create a non-root user account without root privileges but you need to add it to appropriate groups and configure sudo permissions (even though you add this user to root group, it will fail with iptables command for example) to get config files and launch requested commands.I suppo

[openstack-dev] [glance] Image import: operator plugins

Hi, As part of Glance's image import [1] work we need to define how operators can run site specific code as part of the import process. For example an operator may want to perform some site-specific validation on the image bits. Note that I'm not so much interested in what we use to do this (ie

Re: [openstack-dev] [tripleo][heat] Summit session clashes

On Wed, Apr 20, 2016 at 12:14 PM, Ethan Lynn wrote: > Could we move Functional Tests to Thursday? I have a hands-on workshop at > wed 4:30-6:00 pm. Sorry, I don't have anything to switch it with. -- Thomas __ OpenStack Dev

Re: [openstack-dev] [tricircle] http response code

This might be answer for your question. https://github.com/openstack/tricircle/blob/master/tricircle/api/controllers/pod.py Cheers, S On Wed, Apr 20, 2016 at 6:37 PM, 李戈 wrote: > Hi > I read api source code recently and have a question. Do we uniform the > "http response code"? > > > such

Re: [openstack-dev] [tripleo][heat] Summit session clashes

How about move functional tests to wed 3:30? If not, I will sync with you guys later :) Best Regards, Ethan Lynn [email protected] > On Apr 20, 2016, at 18:46, Thomas Herve wrote: > > On Wed, Apr 20, 2016 at 12:14 PM, Ethan Lynn wrote: >> Could we move Functional Tests to Thursday? I

Re: [openstack-dev] [Neutron] L3 HA testing on scale

Folks, I think Ann's report is super cool and 100% worth publishing on OpenStack performance-docs . This is really good information to share community-wide. Ann, please think if you would like to contribute to performance documentation. Che

Re: [openstack-dev] [Fuel][plugins] VIP addresses and network templates

Hi Simon, When network template is in use, network roles to endpoints mapping is specified in section "roles" (in the template). So, "default_mapping" from network role description is overridden in the network template. E.g.: network_assignments: monitoring: ep: br-mon ... networ

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

On 20 April 2016 at 08:08, koshiya maho wrote: > This design was discussed, reviewed and approved in cross-projects [1] and > already implemented in nova, cinder and neutron. > At this point if we change the implementation then it will not be > consistent across core OpenStack projects. > For ma

Re: [openstack-dev] [Cinder] API features discoverability

On 19 April 2016 at 23:42, Michał Dulko wrote: > On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote: > > Hi Michal, > > > > This seemed like a good idea when I first read it. What more, the server > code for extension listing [1] does not do any authorization, so it can be > used for any logged in

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 04/19/2016 11:03 PM, Dean Troyer wrote: > > > On Tue, Apr 19, 2016 at 8:17 PM, Adam Young > wrote: > > Maybe it is time to revamp Devstack. Is there some way that, > without a major rewrite, it could take better advantage of the CLI? > Could we group co

[openstack-dev] [telemetry][nova] Versioned notification with JSON schema

Hi, Just want to give telemetry a heads up that top of the versioned notification transformation in nova [1] we are planning to provide JSON schemas for the versioned notifications [2]. I hope telemetry project has a view how they want to consume those schemas. Any comments are welcome in the sp

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

Sorry, I just saw, FC = flow classifier :-), I made it a multi purpose abrev. now ;) On Wed, Apr 20, 2016 at 2:12 PM, Miguel Angel Ajo Pelayo wrote: > I think this is an interesting topic. > > What do you mean exactly by FC ? (feature chaining?) > > I believe we have three things to look at: (so

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

I think this is an interesting topic. What do you mean exactly by FC ? (feature chaining?) I believe we have three things to look at: (sorry for the TL) 1) The generalization of traffic filters / traffic classifiers. Having common models, some sort of common API or common API structure availabl

Re: [openstack-dev] [ironic] upgrade support between which versions of ironic?

On 2016-04-19 11:29 PM, Tan, Lin wrote: I agree this is reasonable to support all these cases in “cold upgrades” but in supports-rolling-upgrade (live upgrade in another word) case it is different and complicated and not necessary, During rolling upgrade, we will have old/new services co-exi

Re: [openstack-dev] Kolla multinode , multi-region deployment support

On Wed, 2016-04-20 at 06:57 +, Steven Dake (stdake) wrote: > Grzegorz, > > This is a technical question about our roadmap and should be sent to > the openstack-dev mailing list.  As such, ccing openstack-dev so > everyone can benefit from my thinking on this matter and others can > weigh in. >

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

Inline update. On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo wrote: > On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes wrote: >> On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: [...] >> Yes, Nova's conductor gathers information about the requested networks >> *before* asking the sche

Re: [openstack-dev] [Magnum]Cache docker images

Hongbin, Both of approaches you suggested may only work for one binary format. If you try to use docker on a different system architecture, the pre-cache of images makes it even more difficult to get the correct images built and loaded. I suggest we take an approach that allows the Baymodel cre

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

On Wed, Apr 20, 2016 at 4:25 PM, Miguel Angel Ajo Pelayo < [email protected]> wrote: > Inline update. > > On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo > wrote: > > On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes wrote: > >> On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: > [...]

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On Tue, Apr 19, 2016 at 12:24 PM, Ian Cordasco wrote: > > > -Original Message- > From: Thomas Goirand > Reply: OpenStack Development Mailing List (not for usage questions) < > [email protected]> > Date: April 18, 2016 at 17:21:36 > To: OpenStack Development Mailing List (

Re: [openstack-dev] [glance] Image import: operator plugins

On 20/04/16 11:39 +0100, [email protected] wrote: Hi, As part of Glance's image import [1] work we need to define how operators can run site specific code as part of the import process. For example an operator may want to perform some site-specific validation on the image bits. Note that I'

Re: [openstack-dev] [Fuel][plugins] VIP addresses and network templates

Many thanks Alexey! That's exactly the information I needed. Simon On Wed, Apr 20, 2016 at 1:19 PM, Aleksey Kasatkin wrote: > Hi Simon, > > When network template is in use, network roles to endpoints mapping is > specified in section "roles" (in the template). So, "default_mapping" > from networ

[openstack-dev] Neutron: No DVR meeting for this week and week after.

Hi Folks, We will not be having our regular DVR meeting this week and for next week. We will resume our meeting on May 4th 2016. Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax:

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

Excerpts from Steve Baker's message of 2016-04-20 16:38:25 +1200: > On 20/04/16 06:17, Monty Taylor wrote: > > On 04/19/2016 10:16 AM, Daniel P. Berrange wrote: > >> On Tue, Apr 19, 2016 at 09:57:56AM -0500, Dean Troyer wrote: > >>> On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote: > >>> > I

[openstack-dev] [ironic-staging-drivers] Tests at the gates

Hello Ironic-staging-drivers team, At the moment there is no tests for ironic-staging-drivers at the gates. I think we need to have a simple test that install drivers with theirs dependencies and ensures that ironic-conductor is able to start. It may be performed in the following way. Each staging

Re: [openstack-dev] [Swift] Erasure coding and geo replication

There's no significant change with the global EC clusters story in the 2.7 release. That's something we're discussing next week at the summit. --John On 19 Apr 2016, at 22:47, Mark Kirkwood wrote: > Hi, > > Has the release of 2.7 significantly changed the assessment here? > > Thanks > > Mark

[openstack-dev] [TripleO]: landing code faster

We've had a run of really spotty CI in TripleO. This is making it really hard to land patches if reviewers aren't online. Specifically we seem to get better CI results when the queue is less full (nights and weekends)... often when core reviewers aren't around. One thing that would help is if core

Re: [openstack-dev] [Magnum]Cache docker images

If the ops are deploying a cloud big enough to run into that problem, I think they can deploy a scaled out docker registry of some kind too, that the images can point to? Last I looked, it didn't seem very difficult. The native docker registry has ceph support now, so if your running ceph for th

Re: [openstack-dev] [neutron][release] neutron *-aas release notes are not linked.

On 20 April 2016 at 00:39, Andreas Jaeger wrote: > On 2016-04-20 06:20, Akihiro Motoki wrote: > > Hi, > > > > I noticed Mitaka release notes for neutron *-aas [1,2,3] are not > > referred to from anywhere. > > Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas), > > but only the release

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

So, location of unified api is an interesting topic... Can things be arranged in such a way that the abstraction largely exists only on the client in its own project? So, what about a change of ideas The three pain points in the abstraction are: * Authentication * Connectivity * Differen

[openstack-dev] summit tools

A couple of questions about our Austin-related planning tools... - Can one's calendar at https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 be exported as .ics, or otherwise integrated into a wider calendaring system? - Is the app working for anyone else? All I get i

Re: [openstack-dev] [neutron][release] neutron *-aas release notes are not linked.

Excerpts from Akihiro Motoki's message of 2016-04-20 13:20:40 +0900: > Hi, > > I noticed Mitaka release notes for neutron *-aas [1,2,3] are not > referred to from anywhere. > Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas), > but only the release note of the main neutron repo is link

[openstack-dev] [neutron][sfc] A standards-compliant SFC API

Dear OpenStack Community, We've been investigating options in/around OpenStack for supporting Service Function Chaining. The networking-sfc project has made significant progress in this space, and we see lots of value in what has been completed. However, when we looked at the related IETF specs

Re: [openstack-dev] [TripleO]: landing code faster

On 04/20/2016 11:44 AM, Dan Prince wrote: We've had a run of really spotty CI in TripleO. This is making it really hard to land patches if reviewers aren't online. Specifically we seem to get better CI results when the queue is less full (nights and weekends)... often when core reviewers aren't a

[openstack-dev] [heat]informal meetup during summit

Hi team Let plan for more informal meetup(relax) time! Let all heaters and any other projects can have fun and chance for technical discussions together. After discuss in meeting, we will have a pre-meetup-meetup on Friday morning to have a cup of cafe or some food. Would like to ask if anyone kno

Re: [openstack-dev] [neutron][sfc] A standards-compliant SFC API

On 20 April 2016 at 09:31, Duarte Cardoso, Igor < [email protected]> wrote: > Dear OpenStack Community, > > > > We've been investigating options in/around OpenStack for supporting > Service Function Chaining. The networking-sfc project has made significant > progress in this space, and

Re: [openstack-dev] [Fuel] snapshot tool

Dmitry, I mean, currently shotgun fetches services' configuration along with astute.yaml. These files contain passwords, keys, tokens. I beleive, these should be sanitized. Or, better yet, there should be an option to sanitize sensitive data from fetched files. Aleksandr, Currently Fuel has a s

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 2016-04-19 11:30:38 -0500 (-0500), Ian Cordasco wrote: [...] > I've argued with different downstream distributors about their own > judgment of what portions of the patch to apply in order to fix an > issue with an assigned CVE. It took much longer than should have > been necessary in at least o

[openstack-dev] [glance] weekly meeting on apr 21st

Hi all, Last week when I asked if we needed a meeting for this week, the poll [1] resulted in "maybe". I currently do not see any 'specific' agenda [2] items posted for this week's meeting. I am assuming everyone is busy going into the summit and the updates can be shared then or the meeting after

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On Wed, Apr 20, 2016 at 9:43 AM, Doug Hellmann wrote: > Cliff looks for commands on demand. If we modify it's command loader to > support some "built in" commands, and then implement the commands in OSC > that way, we can avoid scanning the real plugin system until we hit a > command that isn't b

[openstack-dev] [openstack-operators] [glance] [Austin summit] Glance session for operator feedback

Hi all, At the Austin summit, I've scheduled a Glance work session [1] for gathering input on Glance deployments and feedback surrounding the same. Also, I've taken the liberty to propose a few topics related to the same at the discussion etherpad [2]. These are general discussion items that you m

Re: [openstack-dev] [openstack-operators] [glance] [Austin summit] Glance session for operator feedback

NOTE: this is a operator focused session and has been tagged for ops for it to appear in cross track! On 4/20/16 1:39 PM, Nikhil Komawar wrote: > Hi all, > > At the Austin summit, I've scheduled a Glance work session [1] for > gathering input on Glance deployments and feedback surrounding the same

[openstack-dev] [Freezer] No IRC meeting next week and summit details

Hello, There will be no IRC meeting next week due to the OpenStack summit. Feel free to join us at one of the four Design summit session we will be holding: - Wed: 9:50 - 10:30: Backup your OpenStack infrastructure [1] - Wed: 11:00 - 11:40: Backup as a service [2] - Wed: 11:50 - 12:30: Disas

Re: [openstack-dev] [ironic] upgrade support between which versions of ironic?

On Wed, Apr 20, 2016 at 5:38 AM, Mathieu Mitchell wrote: > > > On 2016-04-19 11:29 PM, Tan, Lin wrote: > >> I agree this is reasonable to support all these cases in “cold upgrades” >> but in supports-rolling-upgrade (live upgrade in another word) case it is >> different and complicated and not ne

Re: [openstack-dev] [heat]informal meetup during summit

On 4/20/16 1:00 PM, Rico Lin wrote: Hi team Let plan for more informal meetup(relax) time! Let all heaters and any other projects can have fun and chance for technical discussions together. After discuss in meeting, we will have a pre-meetup-meetup on Friday morning to have a cup of cafe or so

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

-Original Message- From: Adrian Otto Reply: OpenStack Development Mailing List (not for usage questions) Date: April 19, 2016 at 19:11:07 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstractio

[openstack-dev] [release][quality] hacking 0.11.0 release

We are content to announce the release of: hacking 0.11.0: OpenStack Hacking Guideline Enforcement With package available at: https://pypi.python.org/pypi/hacking For more details, please see below. Changes in hacking 0.10.1..0.11.0 - c3b03a9 Updated from g

Re: [openstack-dev] [tripleo][heat] Summit session clashes

[snip] I need to be at both of those Heat ones anyway, so this doesn't really help me. I'd rather have the DLM session in this slot instead. (The only sessions I can really skip are the Release Model, Functional Tests and DLM.) That would give us: HeatTripleO

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) [mailto:[email protected]] Sent: April-20-16 3:39 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Folks, We are considering whet

Re: [openstack-dev] [puppet] Stepping down from puppet-openstack-core

> On Apr 18, 2016, at 8:37 AM, Sebastien Badia wrote: > > Hello here, > > I would like to ask to be removed from the core reviewers team on the > Puppet for OpenStack project. > > I lack dedicated time to contribute on my spare time to the project. And I > don't work anymore on OpenStack deploy

Re: [openstack-dev] [ironic-staging-drivers] Tests at the gates

On 04/20/2016 04:57 PM, Vasyl Saienko wrote: > Hello Ironic-staging-drivers team, > > At the moment there is no tests for ironic-staging-drivers at the gates. > I think we need to have a simple test that install drivers with theirs > dependencies and ensures that ironic-conductor is able to start.

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -Original Message- > From: Ian Cordasco [mailto:[email protected]] > Sent: April-20-16 1:56 PM > To: Adrian Otto; OpenStack Development Mailing List (not for usage > questions) > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > > -

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

I'll go ahead and be the guy to ask for N flavors. :) AZ zones are kind of restrictive in what they can do, so we usually use flavors, which are much more flexable. I can totally see a project with 3 different types of flavors and want them all in the same k8s cluster managed by labels. Thanks

Re: [openstack-dev] [Magnum]Cache docker images

From: Adrian Otto [mailto:[email protected]] Sent: April-20-16 9:39 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum]Cache docker images Hongbin, Both of approaches you suggested may only work for one binary format. If you try to

Re: [openstack-dev] [Magnum]Cache docker images

Hi. On Wed, Apr 20, 2016 at 5:43 PM, Fox, Kevin M wrote: > If the ops are deploying a cloud big enough to run into that problem, I > think they can deploy a scaled out docker registry of some kind too, that > the images can point to? Last I looked, it didn't seem very difficult. The > native dock

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Hongbin. On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu wrote: > > > > > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) > [mailto:[email protected]] > Sent: April-20-16 3:39 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Magnum] Magnum supp

Re: [openstack-dev] [neutron] [networking-sfc] A standards-compliant SFC API

Thanks for the feedback Armando, Adding missing tag. Best regards, Igor. From: Armando M. [mailto:[email protected]] Sent: Wednesday, April 20, 2016 6:03 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][sfc] A standards-compliant SFC AP

[openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Today there are a number of places in nova, neutron and perhaps elsewhere that employ backoff + timeout strategies (see [1] - [4]). While we are working towards a unified approach in neutron for RPC [5], it appears such logic could benefit the greater community as a reusable oslo implementation. I

Re: [openstack-dev] [tripleo] Proposed changes to TripleO project tags

On Wed, Apr 20, 2016 at 6:16 AM, Steven Hardy wrote: > All, > > We discussed some changes to our release cycle in the weekly meeting > yesterday, namely to align with the intended direction of the puppet > community to adopt the new cycle-trailing tag[1]. > > We have also discussed and agreed[2] t

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On Wed, Apr 20, 2016 at 10:28 AM, Dean Troyer wrote: > On Wed, Apr 20, 2016 at 9:43 AM, Doug Hellmann > wrote: > >> Cliff looks for commands on demand. If we modify it's command loader to >> support some "built in" commands, and then implement the commands in OSC >> that way, we can avoid scanni

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Sounds good to me Boden. -- Dims On Wed, Apr 20, 2016 at 4:10 PM, Boden Russell wrote: > Today there are a number of places in nova, neutron and perhaps > elsewhere that employ backoff + timeout strategies (see [1] - [4]). > While we are working towards a unified approach in neutron for RPC [5],

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On Wed, 2016-04-20 at 14:10 -0600, Boden Russell wrote: > Anyone adverse to me crafting an initial oslo patch to kick-off the > details on this one? Have you evaluated any existing solutions in this space? A quick search on PyPi turns up "backoff", which seems to provide several backoff strategie

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

tl;dr: You're right, but the point I was making was that all distros are understaff. Longer version: On 04/19/2016 06:24 PM, Ian Cordasco wrote: >> You can also add "Ubuntu" in the list here, as absolutely all OpenStack >> dependencies are maintained mostly by me, within Debian, and then later >

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Boden, Are you thinking of implementing something which would perform exponentially backed off calls to some arbitrary function till that method returns with something other than a timeout? I think that would be very versatile, and useful in a wide variety of places. Thanks, -amrith > -O

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Will the already existing retrying[1] do the job or is it missing features (the namespacing thing seems like it could be an issue) or perhaps too generic? [1] https://pypi.python.org/pypi/retrying -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Excerpts from Chris Dent's message of 2016-04-20 22:16:10 +0100: > > Will the already existing retrying[1] do the job or is it missing > features (the namespacing thing seems like it could be an issue) > or perhaps too generic? > > [1] https://pypi.python.org/pypi/retrying > Yes, please, let's

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Feel free to take the following (if its similar to what u are thinking) https://github.com/openstack/anvil/blob/master/anvil/utils.py#L90 IMHO though if its a decorator, the retrying library can already perform this: https://pypi.python.org/pypi/retrying And a couple of the oslo-cores (jd, m

[openstack-dev] [magnum] Seek advices for a licence issue

Hi Mark, I have went though the announcement in details, From my point of view, it seems to resolve the license issue that was blocking us in before. I have included the Magnum team in ML to see if our team members have any comment. Thanks for the support from foundation. Best regards, Hongbin

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Thierry Carrez wrote: Adrian Otto wrote: This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. The lowest common denominator of all COEs is an remarkably low value API that adds considerable complexity to Magnum th

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

On Wed, Apr 20, 2016 at 6:31 AM, Duncan Thomas wrote: > On 20 April 2016 at 08:08, koshiya maho > wrote: > > >> This design was discussed, reviewed and approved in cross-projects [1] and >> already implemented in nova, cinder and neutron. >> At this point if we change the implementation then it

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Magnum doesn¹t have to preclude tight integration for single COEs you speak of. The heavy lifting of tight integration of the COE in to OpenStack (so that it performs optimally with the infra) can be modular (where the work is performed by plug-in models to Magnum, not performed by Magnum itself.

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

On 4/20/2016 8:25 AM, Miguel Angel Ajo Pelayo wrote: Inline update. On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo wrote: On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes wrote: On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: [...] Yes, Nova's conductor gathers information about

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On Wed, Apr 20, 2016 at 3:10 PM, Boden Russell wrote: > Today there are a number of places in nova, neutron and perhaps > elsewhere that employ backoff + timeout strategies (see [1] - [4]). > While we are working towards a unified approach in neutron for RPC [5], > it appears such logic could ben

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

+1 to plugins. it has suited nova/trove/sahara/etc well. Thanks, Kevin From: Keith Bray [[email protected]] Sent: Wednesday, April 20, 2016 3:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum]

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

If Magnum will be focused on installation and management for COE it will be unclear how much it is different from Heat and other generic orchestrations. It looks like most of the current Magnum functionality is provided by Heat. Magnum focus on deployment will potentially lead to another Heat-like

Re: [openstack-dev] summit tools

On Wed, Apr 20, 2016 at 04:13:38PM +, Neil Jerram wrote: > A couple of questions about our Austin-related planning tools... > > - Can one's calendar at > https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 > be exported as .ics, or otherwise integrated into a wider c

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -Original Message- > From: Keith Bray [mailto:[email protected]] > Sent: April-20-16 6:13 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > > Magnum doesn¹t h

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I think Magnum much is much closer to Sahara or Trove in its workings. Heat's orchestration. Thats what the COE does. Sahara is and has plugins to deploy various Hadoopy like clusters, get them assembled into something useful, and has a few abstraction api's like "submit a job to the deployed h

  1   2   >