[openstack-dev] IMPORTANT: This list is retired

This mailing list was replaced by a new openstack-disc...@lists.openstack.org mailing list[0] as of Monday November 19, 2018 and starting now will no longer receive any new messages. The archive of prior messages will remain published in the expected location indefinitely for future reference.

Re: [openstack-dev] [magnum] kubernetes images for magnum rocky

Magnum queens, uses kubernetes 1.9.3 by default. You can upgrade to v1.10.11-1. From a quick test v1.11.5-1 is also compatible with 1.9.x. We are working to make this painless, sorry you have to ssh to the nodes for now. Cheers, Spyros On Mon, 3 Dec 2018 at 23:24, Spyros Trigazis wrote: >

[openstack-dev] [magnum] kubernetes images for magnum rocky

Hello all, Following the vulnerability [0], with magnum rocky and the kubernetes driver on fedora atomic you can use this tag "v1.11.5-1" [1] for new clusters. To upgrade the apiserver in existing clusters, on the master node(s) you can run: sudo atomic pull --storage ostree

Re: [openstack-dev] Stepping down from Neutron core team

On Sun, Dec 02, 2018 at 11:08:25PM +0900, Hirofumi Ichihara wrote: > I’m stepping down from the core team because my role changed and I cannot > have responsibilities of neutron core. Thank you very much for all of the insightful reviews over the years. Good luck on your next adventure! Nate

Re: [openstack-dev] Stepping down from Neutron core team

Hi all, Can any one help me to resvolve error 111 on keystone Thanks & Regards Ranjan Kumar Mob: 9284158762 > On 03-Dec-2018, at 1:39 PM, Slawomir Kaplonski wrote: > > Hi, > > Thanks for all Your work in Neutron and good luck in Your new role. > > — > Slawek Kaplonski > Senior software

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 12/3/18 10:34 AM, Bogdan Dobrelya wrote: Hi Kevin. Puppet not only creates config files but also executes a service dependent steps, like db sync, so neither '[base] -> [puppet]' nor '[base] -> [service]' would not be enough on its own. That requires some services specific code to be

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

Hi Kevin. Puppet not only creates config files but also executes a service dependent steps, like db sync, so neither '[base] -> [puppet]' nor '[base] -> [service]' would not be enough on its own. That requires some services specific code to be included into *config* images as well. PS. There

Re: [openstack-dev] Stepping down from Neutron core team

Hi, Thanks for all Your work in Neutron and good luck in Your new role. — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Hirofumi Ichihara w > dniu 02.12.2018, o godz. 15:08: > > Hi all, > > I’m stepping down from the core team because my role changed and I

Re: [openstack-dev] [nova] about notification in nova

This regarding keystone ? Thanks & Regards Ranjan Kumar Mob: 9284158762 > On 03-Dec-2018, at 8:01 AM, Zhenyu Zheng wrote: > > Hi, > > Are you using versioned notification? If you are using versioned > nofitication, you should get an ``action_initiator_user`` and an >

Re: [openstack-dev] [nova] about notification in nova

Hi, Are you using versioned notification? If you are using versioned nofitication, you should get an ``action_initiator_user`` and an ``action_initiator_project`` indicating who initiated this action, we had them since I649d8a27baa8840bc1bb567fef027c749c663432

[openstack-dev] [nova] about notification in nova

Hi, all： I have a question about the notification in nova, that is the actual operator is different from the operator was record in panko. Such as the delete action, we create the VM as user1, and we delete the VM as user2， but the operator is user1 who delete the VM in panko

Re: [openstack-dev] Stepping down from Neutron core team

Hi Team , I am getting error of Http 500 server not fullfill request by id please help me how to fix Thanks & Regards Ranjan Kumar Mob: 9284158762 > On 03-Dec-2018, at 2:27 AM, Miguel Lavalle wrote: > > Hi Hirofumi, > > Thanks for your contributions to the project over these years. You

Re: [openstack-dev] Stepping down from Neutron core team

Hi Hirofumi, Thanks for your contributions to the project over these years. You will be missed. We also wish the best in your future endeavors. Best regards Miguel On Sun, Dec 2, 2018 at 8:11 AM Hirofumi Ichihara < ichihara.hirof...@gmail.com> wrote: > Hi all, > > > I’m stepping down from the

[openstack-dev] Stepping down from Neutron core team

Hi all, I’m stepping down from the core team because my role changed and I cannot have responsibilities of neutron core. My start of neutron was 5 years ago. I had many good experiences from neutron team. Today neutron is great project. Neutron gets new reviewers, contributors and, users.

Re: [openstack-dev] [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful?

On Fri, 2018-11-30 at 09:40 -0500, Mohammed Naser wrote: > > > On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > > I have a request to do $SUBJECT in relation to a V2V workflow. The use > > case here is conversion of a VM/Physical which was previously powered > > off. We want to move its

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

Still confused by: [base] -> [service] -> [+ puppet] not: [base] -> [puppet] and [base] -> [service] ? Thanks, Kevin From: Bogdan Dobrelya [bdobr...@redhat.com] Sent: Friday, November 30, 2018 5:31 AM To: Dan Prince; openstack-dev@lists.openstack.org;

Re: [openstack-dev] [nova] Would an api option to create an instance without powering on be useful?

On 11/30/18 6:06 AM, Matthew Booth wrote: I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This

Re: [openstack-dev] [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful?

On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 11/30/18 1:52 PM, Dan Prince wrote: On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: On 11/29/18 6:42 PM, Jiří Stránský wrote: On 28. 11. 18 18:29, Bogdan Dobrelya wrote: On 11/28/18 6:02 PM, Jiří Stránský wrote: Reiterating again on previous points: -I'd be fine removing

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: > On 11/29/18 6:42 PM, Jiří Stránský wrote: > > On 28. 11. 18 18:29, Bogdan Dobrelya wrote: > > > On 11/28/18 6:02 PM, Jiří Stránský wrote: > > > > > > > > > > > > > Reiterating again on previous points: > > > > > > > > > > -I'd be fine

[openstack-dev] [nova] Would an api option to create an instance without powering on be useful?

I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 11/29/18 6:42 PM, Jiří Stránský wrote: On 28. 11. 18 18:29, Bogdan Dobrelya wrote: On 11/28/18 6:02 PM, Jiří Stránský wrote: Reiterating again on previous points: -I'd be fine removing systemd. But lets do it properly and not via 'rpm -ev --nodeps'. -Puppet and Ruby *are* required for

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

Hi, I checked that both of the methods you propose work well. After I add 'should_delete_outdated_entities' function to InstanceDriver, it took about 10 minutes to clear the old Instance. And I added two sentences you said to Nova-cpu.conf, so the vitrage collector get notifications well. Thank

[openstack-dev] [kuryr] can we start kuryr libnetwork in container inside the nova VM.

Hello Team, I have seen the steps of starting the kuryr libnetwork container on compute node. But If I need to run the same container inside the VM running on compute node, is't possible to do that? I am not sure how can I map the /var/run/openvswitch inside the nested VM because this is present

[openstack-dev] [kuryr] kuryr libnetwork installation inside the vm is failing

Started one Fedora 29 VM on openstack using official qcow2 image. I followed this doc for kuryr installation inside the VM. https://docs.openstack.org/kuryr-libnetwork/latest/readme.html My objective is to run the nested docker i.e inside the VM. While installing the kuryr-libbetwork from the

Re: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed

Hi Feilong, Thanks for your reply. Kindly find the below outputs. [root@packstack1 ~]# rpm -qa | grep -i magnum python-magnum-7.0.1-1.el7.noarch openstack-magnum-conductor-7.0.1-1.el7.noarch openstack-magnum-ui-5.0.1-1.el7.noarch openstack-magnum-api-7.0.1-1.el7.noarch

Re: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed

Hi Vikrant, Before we dig more, it would be nice if you can let us know the version of your Magnum and Heat. Cheers. On 30/11/18 12:12 AM, Vikrant Aggarwal wrote: > Hello Team, > > Trying to deploy on K8 on fedora atomic. > > Here is the output of cluster template: > ~~~ > [root@packstack1

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 29. 11. 18 20:20, Fox, Kevin M wrote: If the base layers are shared, you won't pay extra for the separate puppet container Yes, and that's the state we're in right now. unless you have another container also installing ruby in an upper layer. Not just Ruby but also Puppet and Systemd.

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

Oh, rereading the conversation again, the concern is having shared deps move up layers? so more systemd related then ruby? The conversation about --nodeps makes it sound like its not actually used. Just an artifact of how the rpms are built... What about creating a dummy package that

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

If the base layers are shared, you won't pay extra for the separate puppet container unless you have another container also installing ruby in an upper layer. With OpenStack, thats unlikely. the apparent size of a container is not equal to its actual size. Thanks, Kevin

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 28. 11. 18 18:29, Bogdan Dobrelya wrote: On 11/28/18 6:02 PM, Jiří Stránský wrote: Reiterating again on previous points: -I'd be fine removing systemd. But lets do it properly and not via 'rpm -ev --nodeps'. -Puppet and Ruby *are* required for configuration. We can certainly put them in

[openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed

Hello Team, Trying to deploy on K8 on fedora atomic. Here is the output of cluster template: ~~~ [root@packstack1 k8s_fedora_atomic_v1(keystone_admin)]# magnum cluster-template-show 16eb91f7-18fe-4ce3-98db-c732603f2e57 WARNING: The magnum client is deprecated and will be removed in a future

Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches

Hello, This got lost way down in my mailbox. I think we have a consensus about getting rid of the newton branches. Does anybody in Stable release team have time to deprecate the stable/newton branches? Best regards Tobias On 11/19/2018 06:21 PM, Alex Schultz wrote: On Mon, Nov 19, 2018 at

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 11/28/18 8:55 PM, Doug Hellmann wrote: I thought the preferred solution for more complex settings was config maps. Did that approach not work out? Regardless, now that the driver work is done if someone wants to take another stab at etcd integration it’ll be more straightforward today.

[openstack-dev] [mistral] Renat is on vacation until Dec 17th

Hi, I’ll be on vacation till Dec 17th. I’ll be replying emails but with delays. Thanks Renat Akhmerov @Nokia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On Wed, 2018-11-28 at 13:28 -0500, James Slagle wrote: > On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya > wrote: > > Long story short, we cannot shoot both rabbits with a single shot, > > not > > with puppet :) May be we could with ansible replacing puppet > > fully... > > So splitting config

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya wrote: > Long story short, we cannot shoot both rabbits with a single shot, not > with puppet :) May be we could with ansible replacing puppet fully... > So splitting config and runtime images is the only choice yet to address > the raised security

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 11/28/18 6:02 PM, Jiří Stránský wrote: Reiterating again on previous points: -I'd be fine removing systemd. But lets do it properly and not via 'rpm -ev --nodeps'. -Puppet and Ruby *are* required for configuration. We can certainly put them in a separate container outside of the runtime

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

Reiterating again on previous points: -I'd be fine removing systemd. But lets do it properly and not via 'rpm -ev --nodeps'. -Puppet and Ruby *are* required for configuration. We can certainly put them in a separate container outside of the runtime service containers but doing so would

Re: [openstack-dev] [tripleo] Workflows Squad changes

On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote: > Hi all, > > Recently, the workflows squad has been reorganized and people from the > squad are joining different squads. I would like to discuss how we are > going to adjust to this situation to make sure that tripleo-common > development is

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

Ok, so you have the workflow in place, but it sounds like the containers are not laid out to best use that workflow. Puppet is in the base layer. That means whenever puppet gets updated, all the other containers must be too. And other such update coupling issues. I'm with you, that binaries

Re: [openstack-dev] [tripleo] Workflows Squad changes

On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote: [...] > As a possible solution, I would like to propose Adriano as a core reviewer > to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common > patches. > [...] Not a member of the squad but +2 to the idea Thanks for

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

Hi, On Tue, Nov 27, 2018 at 7:13 PM Dan Prince wrote: > On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote: > > Changing the topic to follow the subject. > > > > [tl;dr] it's time to rearchitect container images to stop incluiding > > config-time only (puppet et al) bits, which are not

Re: [openstack-dev] [tripleo] Let's improve upstream docs

On Wed, Nov 28, 2018 at 4:19 PM Marios Andreou wrote: > great you are very welcome ! Thanks. > not really, I mean "anything goes" as long as it's an improvement ( and the > usual review process will determine if it is or not :) ). Could be as small > as typos or broken links/images, through

Re: [openstack-dev] [tripleo] Let's improve upstream docs

On Wed, Nov 28, 2018 at 4:33 PM Natal Ngétal wrote: > On Tue, Nov 27, 2018 at 4:50 PM Marios Andreou wrote: > > as just mentioned in the tripleo weekly irc meeting [1] some of us are > trying to make small weekly improvements to the tripleo docs [2]. We are > using this bug [3] for tracking

Re: [openstack-dev] [tripleo] Let's improve upstream docs

On Tue, Nov 27, 2018 at 4:50 PM Marios Andreou wrote: > as just mentioned in the tripleo weekly irc meeting [1] some of us are trying > to make small weekly improvements to the tripleo docs [2]. We are using this > bug [3] for tracking and this effort is a result of some feedback during the >

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On Wed, 2018-11-28 at 15:12 +0100, Bogdan Dobrelya wrote: > On 11/28/18 2:58 PM, Dan Prince wrote: > > On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote: > > > To follow up and explain the patches for code review: > > > > > > The "header" patch https://review.openstack.org/620310 -> > > >

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On 11/28/18 2:58 PM, Dan Prince wrote: On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote: To follow up and explain the patches for code review: The "header" patch https://review.openstack.org/620310 -> (requires) https://review.rdoproject.org/r/#/c/17534/, and also

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote: > To follow up and explain the patches for code review: > > The "header" patch https://review.openstack.org/620310 -> (requires) > https://review.rdoproject.org/r/#/c/17534/, and also > https://review.openstack.org/620061 -> (which in

Re: [openstack-dev] [TripleO][Edge][Kolla] Reduce base layer of containers for security and size of images (maintenance) sakes

Added Kolla tag as we all together might want to do something to that systemd included in containers via *multiple* package dependencies, like [0]. Ideally, that might be properly packaging all/some (like those names listed in [1]) of the places having it as a dependency, to stop doing that as

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On Wed, 2018-11-28 at 00:31 +, Fox, Kevin M wrote: > The pod concept allows you to have one tool per container do one > thing and do it well. > > You can have a container for generating config, and another container > for consuming it. > > In a Kubernetes pod, if you still wanted to do

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

To follow up and explain the patches for code review: The "header" patch https://review.openstack.org/620310 -> (requires) https://review.rdoproject.org/r/#/c/17534/, and also https://review.openstack.org/620061 -> (which in turn requires) https://review.openstack.org/619744 -> (Kolla change,

[openstack-dev] [tripleo] Workflows Squad changes

Hi all, Recently, the workflows squad has been reorganized and people from the squad are joining different squads. I would like to discuss how we are going to adjust to this situation to make sure that tripleo-common development is not going to be blocked in terms of feature work and reviews.

[openstack-dev] [Cyborg] IRC meeting still happens at usual time this Wednesday

Hi Team, I know there is a polling on the new IRC meeting time, but before we gather more inputs, let's keep using the old time slot for this week (10PM Beijing Time/9AM EST/6AM PST) Agenda for this week's meeting: 1. Status update on NOVA interaction spec 2. Status update on DB scheme spec 3.

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

The pod concept allows you to have one tool per container do one thing and do it well. You can have a container for generating config, and another container for consuming it. In a Kubernetes pod, if you still wanted to do puppet, you could have a pod that: 1. had an init container that ran

[openstack-dev] [pacemaker] Live migration with VirtualDomain resource-agent

Hi, I'm trying to setup pacemaker for live-migration when a compute node hosting the VM goes down. So, I created cluster resource for the compute-instance (demo1) with 'VirtualDomain' resource agent. >>> pcs resource create demo1 VirtualDomain migrateuri="qemu+tcp://:16509/system"

Re: [openstack-dev] IMPORTANT: We're combining the lists!

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote: > Changing the topic to follow the subject. > > [tl;dr] it's time to rearchitect container images to stop incluiding > config-time only (puppet et al) bits, which are not needed runtime > and > pose security issues, like CVEs, to

[openstack-dev] [tripleo] Let's improve upstream docs

Hi folks, as just mentioned in the tripleo weekly irc meeting [1] some of us are trying to make small weekly improvements to the tripleo docs [2]. We are using this bug [3] for tracking and this effort is a result of some feedback during the recent Berlin summit. The general idea is 1 per week

[openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes

Changing the topic to follow the subject. [tl;dr] it's time to rearchitect container images to stop incluiding config-time only (puppet et al) bits, which are not needed runtime and pose security issues, like CVEs, to maintain daily. Background: 1) For the Distributed Compute Node edge case,

[openstack-dev] [cyborg] New time for Cyborg weekly IRC meetings

Hi, The current time for the weekly Cyborg IRC meeting is 1400 UTC, which is 6 am Pacific and 10pm China time. That is a bad time for most people in the call. Please vote in this doodle for what time you prefer. If you need more options, please respond in this thread. [1]

Re: [openstack-dev] [Octavia] Multinode setup

At the moment that is all we have for a setup guide. That said, all of the Octavia controller processes are fully HA capable. The one setting I can think of is the controller_ip_port_list setting mentioned above. It will need to contain an entry for each health manager IP/port as Sa Pham

Re: [openstack-dev] [glance] about use shared image with each other

On 11/21/18 7:16 AM, Rambo wrote: > yes, but I also have a question, Do we have the quota limit for requests > to share the image to each other? For example, someone shares the image > with me without stop, how do we deal with it? Given that the producer-consumer notifications are not handled by

Re: [openstack-dev] [tripleo] Zuul Queue backlogs and resource usage

Here is a related bug [1] and implementation [1] for that. PTAL folks! [0] https://bugs.launchpad.net/tripleo/+bug/1804822 [1] https://review.openstack.org/#/q/topic:base-container-reduction Let's also think of removing puppet-tripleo from the base container. It really brings the world-in (and

Re: [openstack-dev] [Octavia] Multinode setup

Hi, The controller_ip_port_list option is list of all IP of node which is deployed octavia-health-manager. > On Nov 26, 2018, at 8:41 PM, Anna Taraday wrote: > > Hello everyone! > > I'm looking into how to run Octavia services (controller worker, housekeeper, > health manager) on several

[openstack-dev] [Octavia] Multinode setup

Hello everyone! I'm looking into how to run Octavia services (controller worker, housekeeper, health manager) on several network nodes and get confused with setup guide [1]. Is there any special config option for such case? (controller_ip_port_list probably) What manuals/docs/examples do we have

[openstack-dev] [nova][placement] Please help to review XenServer vgpu related patches

Hi, Sylvain, Jay, Eric and Matt, I saw the n-rp and reshaper patches in upstream have almost finished. Could you help to review XenServer vGPU related patches when you have the time? https://review.openstack.org/#/c/520313/ https://review.openstack.org/#/c/521041/

Re: [openstack-dev] [kolla] Berlin summit resume

thanks Eduardo Gonzalez From: Eduardo Gonzalez Date: 2018-11-22 01:07:40 To: "OpenStack Development Mailing List (not for usage questions)" ,OpenStack Operators ,openst...@lists.openstack.org Subject: [openstack-dev] [kolla] Berlin summit resume Hi kollagues, During the Berlin Summit

Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master

hi just following up form yesterday. i just finished testing the pci numa policy feature and i can confirm that the prefer policy which allow use of non local pci devices does not work. the test case was relitively simple 1 host with 2 numa nodes 1 pci device attach to numa node 0 and vcpu pin

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

Hi, A deleted instance should be removed from Vitrage in one of two ways: 1. By reacting to a notification from Nova 2. If no notification is received, then after a while the instance vertex in Vitrage is considered "outdated" and is deleted Regarding #1, it is clear from your logs that you

Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master

Hi Miguel, There is another RFE “Add l2pop support for floating IP resources” proposed to Launchpad. This RFE also comes from StarlingX and the link is below: https://bugs.launchpad.net/neutron/+bug/1803494 Could you please help review this RFE? I think this RFE can be added to the gap analysis.

Re: [openstack-dev] [ZUN] [kuryr-libnetwork]

Yes david thanks for reply, it was the problem with the command /bin/bash when i just modified with sh my container was up and running. Thanks for all the team openstack dev for the help . Best regards, Rania adouni Le jeu. 22 nov. 2018 à 00:57, David Ivey a écrit : > Hi Rania, > > I am

Re: [openstack-dev] [ZUN] [kuryr-libnetwork]

Hi Rania, I am assuming you are spinning up a cirros container still. Iirc the cirros container does not have /bin/bash. Try just executing /bin/sh. David On Wed, Nov 21, 2018, 6:26 PM Rania Adouni Hi hongbin, > > Finally , I had to move and using queens because after all I think when I > set

Re: [openstack-dev] [ZUN] [kuryr-libnetwork]

Hi hongbin, Finally , I had to move and using queens because after all I think when I set up ZUN , it has effect on my nova-compute service was down .and for more secure work I move to queens . and now my kuryr work fine , but when I try container I had this error : *Docker internal error: 400

Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master

On Wed, 21 Nov 2018 21:23:51 +0100, Melanie Witt wrote: On Wed, 21 Nov 2018 12:11:50 -0600, Miguel Lavalle wrote: One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering

[openstack-dev] [k8s] [manila] Manila CSI driver plan

[Robert Vasek, Red Hat colleagues working in this space: please correct any mis-understandings or omissions below] At the Berlin Summit SIG-K8s Working session [1] [2], we agreed to follow up with a note to the larger community summarizing our plan to enable Manila as RWX storage provider for

Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master

On Wed, 21 Nov 2018 12:11:50 -0600, Miguel Lavalle wrote: One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs

[openstack-dev] [manila] no meeting this week

Just a reminder that there will be no manila community meeting this week. Next manila meeting will be Thursday, 29 November, at 1500 UTC in #openstack-meeting-alt on freenode. Agenda here [1] - Feel free to add ... -- Tom Barron (tbarron) [1]

Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master

Thanks for doing this in the open and working with the upstream teams to reduce divergence! On Wed, Nov 21, 2018 at 1:17 PM Miguel Lavalle wrote: > Hi Stackers, > > One of the key goals of StarlingX during the current cycle is to converge > with the OpenStack projects master branches. In order

Re: [openstack-dev] [kolla] Berlin summit resume

Thanks for the write up Eduardo. I thought you and Surya did a good job of presenting and moderating those sessions. Mark On Wed, 21 Nov 2018 at 17:08, Eduardo Gonzalez wrote: > Hi kollagues, > > During the Berlin Summit kolla team had a few talks and forum discussions, > as well as other

[openstack-dev] New invoice

Dear Valued Waines, Greg Customer: Please advise payment actual date for this invoice. Thank you for your valued custom. Waines, Greg Direct #: 836-338-6252 870-188-1601 x247 e greg.wai...@windriver.com - This email transmission is intended only for the use of the individual or entity

[openstack-dev] [neutron] [drivers] Cancelling weekly meeting on November 23rd

Dear Neutron team, Due to the Thanksgiving Holiday in the USA, several members of the team will not be able to attend the weekly meeting. Let's cancel it and resume normally on the 30th of November Best regards Miguel __

[openstack-dev] [kolla] Berlin summit resume

Hi kollagues, During the Berlin Summit kolla team had a few talks and forum discussions, as well as other cross-project related topics [0] First session was ``Kolla project onboarding``, the room was full of people interested in contribute to kolla, many of them already using kolla in production

Re: [openstack-dev] [ZUN] [kuryr-libnetwork]

Hi Rania, See if this helps: http://lists.openstack.org/pipermail/openstack-dev/2018-November/136547.html Best regards, Hongbin On Wed, Nov 21, 2018 at 7:27 AM Rania Adouni wrote: > Hi everyone, > > I was trying to create container but I just ended up by this error : > *Docker internal

Re: [openstack-dev] [zun] Failed to create Container

Rania, For question #1, you can do the followings in *each compute node*: * In your kuryr config file (i.e. /etc/kuryr/kuryr.conf), change the config [DEFAULT]kuryr_uri . For example: [DEFAULT] kuryr_uri = http://192.168.1.10:23750 This config decides the IP address and port that the

Re: [openstack-dev] [horizon] Do we want new meeting time?

Hi all, Due to the low activity on our weekly meeting, I would like to raise this question again. Do we want a new meeting day and/or time? I'm available any day except Tuesday and Wednesday. I'm going to get some feedback before I create a new poll. Regards, Ivan Kolodyazhny,

[openstack-dev] VM stalls with the console log "Exiting boot services and installing virtual address map"

Hi, I am working with OpenStack stable/pike release in Ubuntu 18.04. When I am trying to spawn VM, which is worked in the earlier OpenStack releases, VM is stalled with the following log in the VM console logs: EFI stub: Booting Linux Kernel... EFI stub: Generating empty DTB EFI stub: Exiting

[openstack-dev] [ZUN] [kuryr-libnetwork]

Hi everyone, I was trying to create container but I just ended up by this error : *Docker internal error: 500 Server Error: Internal Server Error ("failed to update store for object type *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 : connect: connection

Re: [openstack-dev] [glance] about use shared image with each other

yes, but I also have a question, Do we have the quota limit for requests to share the image to each other? For example, someone shares the image with me without stop, how do we deal with it? -- Original -- From: "Brian Rosmaita"; Date: Mon, Nov 19, 2018 10:26

[openstack-dev] [cyborg] [weekly-meeting]

There is no weekly IRC meeting for the week of Nov 21st as most of the people are still recovering from the jetlag after the summit. I will follow up with individuals offline. -- Thank you Regards Li __ OpenStack

[openstack-dev] [tripleo] Feedback about our project at Summit

Hi folks, I wasn't at the Summit but I was interested by the feedback people gave about TripleO so I've discussed with a few people who made the trip. I would like to see what actions we can take on short and long term to address it. I collected some thoughts here:

Re: [openstack-dev] [zun] Failed to create Container

Hi Hongbin , thanks for your advice I did fix it with changing the kuryr-lib to 0.6.0 and my service just work fine and also with lsof -iTCP -sTCP:LISTEN -P I can see it in the list : *kuryr-ser 16581 root5u IPv4 91929 0t0 TCP localhost:23750 (LISTEN)* > that is

Re: [openstack-dev] [zun] Failed to create Container

Hi Hongbin, Yes the version of kuryr-lib is :0.8.0 , So I think I should remove it ! I should remove only the kuryr-lib ! if you have some command they can help me to unisntall it , it will be nice to provide it . Best Regards, Rania Le mer. 21 nov. 2018 à 02:27, Hongbin Lu a écrit : > Hi

Re: [openstack-dev] [zun] Failed to create Container

Hi Rania, The config option 'driver' was recently renamed, so I guess the problem is the version of kuryr-lib is not right. The Pike release of Zun is matched to kuryr-lib 0.6.0 so you might want to confirm the version of kuryr-lib. $ sudo pip freeze | grep kuryr If the version is not right,

Re: [openstack-dev] [zun] Failed to create Container

The important part of the error message seems to be: NoSuchOptError: no such option driver in group [binding] In my /etc/kuryr/kuryr.conf file, all the text is commented out in the [binding] section. Some of the commented options have "driver" in the name. Since they are commented, I guess

Re: [openstack-dev] [zun] Failed to create Container

hi , Thanks for your reply and yes the problem that kuryr-libnetwork is failed to start with the error : ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin for Neutron Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; enabled; vendor preset: enabled) Active:

Re: [openstack-dev] [zun] Failed to create Container

Your error message says it cannot connect to port 23750. That's the kuryr-libnetwork default listen port. On 192.168.1.10, run: lsof -iTCP -sTCP:LISTEN -P On my compute node, it outputs: COMMANDPIDUSER FD TYPE DEVICE SIZE/OFF NODE NAME … kuryr-ser 1976root6u IPv4

Re: [openstack-dev] [nova] about filter the flavor

On 11/19/2018 9:32 PM, Rambo wrote:       I have an idea.Now we can't filter the special flavor according to the property.Can we achieve it?If we achieved this,we can filter the flavor according the property's key and value to filter the flavor. What do you think of the idea?Can you tell me

[openstack-dev] [zun] Failed to create Container

Hi , I am starting to use zun on openstack pike , and when I try to lunch container with cirros image , I get this reason : Docker internal error: 500 Server Error: Internal Server Error ("legacy plugin: Post http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: connect:

Re: [openstack-dev] [Senlin] Does Senlin support Prometheus？

Senlin integrates with Aodh using webhooks. As shown in [1], you create a receiver of type webhook and then create a Aodh alarm to call this webhook [2] on the desired condition. Prometheus AlertManager supports notifications to webhooks [3]. While I have not tried this myself, I believe that it

  1   2   3   4   5   6   7   8   9   10   >