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

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 xuanlangj...@gmail.com > 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

[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

[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

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

[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:

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

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

[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

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

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:tony_t.w...@nokia.com] Sent: Wednesday, April 20, 2016 9:31 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re:

[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)

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

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

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

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

lebre.adr...@free.fr 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

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

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...

[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

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

[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

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

[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\)"

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

Re: [openstack-dev] [kolla] kolla-mesos development being scaled back

On Wed, Apr 20, 2016 at 2:40 PM, Steven Dake (stdake) wrote: > Unfortunately > the project implementors don't intend to continue its development in the > Open, but instead take it "internal" and work on it privately. I disagree > with this approach, but as the PTL of Kolla I

Re: [openstack-dev] [kolla] kolla-mesos development being scaled back

On Wed, Apr 20, 2016 at 4:43 PM Steven Dake (stdake) wrote: > Hey folks, > > I know a lot of folks are already aware of this, but as we head into > summit, in the interest of an Open Community, it is important to share this > information widely. The major implementors of the

[openstack-dev] [horizon][designate] : Facing problem in integrating Designate-Dashboard plugin on Horizon

Hi All, I have tried steps 1-2 from  https://github.com/openstack/designate-dashboard/blob/master/README.rst and also declared designate-dashboard in the horizon settings files as given on  https://github.com/openstack/designate-dashboard/tree/stable/liberty#howto  (step 2). Still, on devstack,

Re: [openstack-dev] [Openstack-operators] [all][log] Ideas to log request-ids in cross-projects

-Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Wednesday, March 16, 2016 8:35 PM To: openstack-operators Subject: Re: [Openstack-operators] [openstack-dev] [all][log] Ideas to log request-ids in cross-projects Excerpts from Kekane, Abhishek's message of

[openstack-dev] [kolla] kolla-mesos development being scaled back

Hey folks, I know a lot of folks are already aware of this, but as we head into summit, in the interest of an Open Community, it is important to share this information widely. The major implementors of the kolla-emsos repository listed in this specification [1] don't intend to continue its

Re: [openstack-dev] [keystone] Keystone commands

On 20 April 2016 at 14:02, Dolph Mathews wrote: > On Tue, Apr 19, 2016 at 10:40 PM, Kenny Ji-work > wrote: > >> Hi all, >> >> I have installed openstack mitaka, when I execute any keystone's commands >> with the result displayed below: >> But I

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

Elisha, Thanks for your detail explanation. I think I can understand how Vitrage works now. :) Since Vitrage needs to read data from different data sources and build one Entity Graph, the elasticity of vitrage-grpah process will be a big challenge per my understanding. :) Thanks again, Tony

Re: [openstack-dev] [kolla] How to get rpm locally during kolla build

Hi, On Wed, Apr 20, 2016 at 2:12 PM, wrote: > I have network problem, it is unstable. Then `kolla-build --registry > 127.0.0.1:4000 --push ` always fail when building openstack-base image > I wonder if there is any way to put those rpms into local directory then the >

[openstack-dev] [kolla] How to get rpm locally during kolla build

Hi, I have network problem, it is unstable. Then `kolla-build --registry 127.0.0.1:4000 --push ` always fail when building openstack-base image like this: INFO:kolla.cmd.build:openstack-base:

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

Hi, Can you send the local.conf file in your devstack folder ? Can you send the /etc/vitrage/vitrage.conf file ? If you do vitrage topology show do you get an error ? the log that you sent is it vitrage-api.log or vitrage.log ? Thanks Eyal On Wed, Apr 20, 2016 at 5:34 AM,

<    1   2