[Openstack-operators] 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-operators] [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-operators] [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-operators] [openstack-dev] [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-operators] [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-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-operators] Fwd: Nova hypervisor uuid

Many thks Matt. If the issue will happen again I hope openstack commands will show duplicate entries and let me clean them. When happened nova-hypervisor list command did not show duplcated entries but I saw them only in the database. Regards Ignazio Il giorno Gio 29 Nov 2018 17:28 Matt Riedemann

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

Hi Matt, I did in the DB directly. I am using queens now. Any python client command to delete hold records or I must use api ? Thanks & Regards Ignazio Il giorno gio 29 nov 2018 alle ore 16:28 Matt Riedemann ha scritto: > On 11/29/2018 12:49 AM, Ignazio Cassano wrote: > > Hello Mattm > > Yes

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

On 11/29/2018 10:27 AM, Ignazio Cassano wrote: I did in the DB directly. I am using queens now. Any python client command to delete hold records or I must use api ? You can use the CLI: https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-service-delete

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

On 11/29/2018 12:49 AM, Ignazio Cassano wrote: Hello Mattm Yes I mean sometimes I have same host/node names with different uuid in compute_nodes table in nova database I must delete nodes with uuid those not match with nova-hypervisor list command. At this time I have the following: MariaDB

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

Hello Mattm Yes I mean sometimes I have same host/node names with different uuid in compute_nodes table in nova database I must delete nodes with uuid those not match with nova-hypervisor list command. At this time I have the following: MariaDB [nova]> select hypervisor_hostname,uuid,deleted from

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

On 11/28/2018 4:19 AM, Ignazio Cassano wrote: Hi Matt, sorry but I lost your answer and Gianpiero forwarded it to me. I am sure kvm nodes names are note changed. Tables where uuid are duplicated are: dataresource_providers in nova_api db compute_nodes in nova db Regards Ignazio It would be

Re: [Openstack-operators] Fwd: Nova hypervisor uuid

Hi Matt, sorry but I lost your answer and Gianpiero forwarded it to me. I am sure kvm nodes names are note changed. Tables where uuid are duplicated are: dataresource_providers in nova_api db compute_nodes in nova db Regards Ignazio Il 28/Nov/2018 11:09 AM, "Gianpiero Ardissono" ha scritto: > >

Re: [Openstack-operators] 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-operators] Nova hypervisor uuid

On 11/27/2018 11:32 AM, Ignazio Cassano wrote: Hi  All, Please anyone know where hypervisor uuid is retrived? Sometime updating kmv nodes with yum update it changes and in nova database 2 uuids are assigned to the same node. regards Ignazio ___

[Openstack-operators] Nova hypervisor uuid

Hi All, Please anyone know where hypervisor uuid is retrived? Sometime updating kmv nodes with yum update it changes and in nova database 2 uuids are assigned to the same node. regards Ignazio ___ OpenStack-operators mailing list

[Openstack-operators] urlopen error [Errno 113] No route to host

Hi all, Has anyone come across this error with utility container.I am running CentOS7 with Queens. After running setup-infrastructure.yml getting into this error while rest is success.Any workaround ? internal_lb_vip_address: 172.25.30.101 fatal: [rmq-db_utility_container-8e503460]: FAILED! =>

Re: [Openstack-operators] Openstack zun on centos???

Hi Edoardo, It looks you gets your answer from others. I just want to add a few more comments. We (the Zun team) would like to have CentOS included in our installation guide and I have created a ticket for that: https://blueprints.launchpad.net/zun/+spec/installation-guide-for-centos . It will be

Re: [Openstack-operators] openstack-annsible networking layout before running playbooks

Hey there, You can just have one br-mgmt and skip the second one and everything will go over br-mgmt :) Thanks, Mohammed On Thu, Nov 22, 2018 at 5:05 AM Jawad Ahmed wrote: > Hi all, > I am deploying openstack-ansible in test environment where I need to use > br-mgmt bridge for both storage

[Openstack-operators] openstack-annsible networking layout before running playbooks

Hi all, I am deploying openstack-ansible in test environment where I need to use br-mgmt bridge for both storage and management traffic (same bridge for both) so that container interfaces eth1 and eth2 will connect to br-mgmt for mgmt and storage traffic at same time.Does it make sense if I ll

Re: [Openstack-operators] [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-operators] [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-operators] [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-operators] 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] is open for posts from subscribers starting now, and the old lists will be

Re: [Openstack-operators] Openstack zun on centos???

Hello again, I read zun documents very fastly. After zun installation (with or without kolla) , do containers run directly in compute nodes or in virtual machines ? Magnum can run them in both but Magnum seems very different. Ignazio Il giorno Mer 14 Nov 2018 20:00 Fox, Kevin M ha scritto: >

Re: [Openstack-operators] Openstack zun on centos???

Thanks Kevin and Edoardo. unfortunately I installed openstack using ansible playbooks and some projects are already in production. PROBALY KOLLA MIGRATION MEANS OPENSTACK REINSTALLATION ;-( Ignazio Il giorno Mer 14 Nov 2018 20:00 Fox, Kevin M ha scritto: > kolla installs it via containers. > >

Re: [Openstack-operators] Openstack zun on centos???

kolla installs it via containers. Thanks, Kevin From: Ignazio Cassano [ignaziocass...@gmail.com] Sent: Wednesday, November 14, 2018 10:48 AM To: Eduardo Gonzalez Cc: OpenStack Operators Subject: Re: [Openstack-operators] Openstack zun on centos??? Hi Edoardo,

Re: [Openstack-operators] Openstack zun on centos???

You are right, zun is not included in RDO yet. I will be happy to help anyone interested in add and maintain it!! There is some info about how to add new packages in [1] [1] https://www.rdoproject.org/documentation/add-packages/ On Wed, Nov 14, 2018 at 7:53 PM Eduardo Gonzalez wrote: > yes,

Re: [Openstack-operators] Openstack zun on centos???

yes, only source code (pip) is supported, there is not any rpm available for it yet. Regards El mié., 14 nov. 2018 19:48, Ignazio Cassano escribió: > Hi Edoardo, > does it mean openstack kolla installs zun using pip ? > I did not find any zun rpm package > Regards > Ignazio > > Il giorno Mer

Re: [Openstack-operators] Openstack zun on centos???

Hi Edoardo, does it mean openstack kolla installs zun using pip ? I did not find any zun rpm package Regards Ignazio Il giorno Mer 14 Nov 2018 18:38 Eduardo Gonzalez ha scritto: > Hi Cassano, you can use zun in centos deployed by kolla-ansible. > >

Re: [Openstack-operators] Openstack zun on centos???

Hi Cassano, you can use zun in centos deployed by kolla-ansible. https://docs.openstack.org/kolla-ansible/latest/reference/zun-guide.html Regards El mié., 14 nov. 2018 17:11, Ignazio Cassano escribió: > Hi All, > I'd like to know if openstack zun will be released for centos. > Reading

[Openstack-operators] Openstack zun on centos???

Hi All, I'd like to know if openstack zun will be released for centos. Reading documentation at docs.openstack.org only ubuntu installation is reported. Many thanks Ignazio ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org

[Openstack-operators] [charms] Issues with cinder and ceph

Hi everyone, I am deploying OpenStack using Juju at my workplace. Everything works well, except the fact cinder is unable to connect to the ceph cluster; it is a bit hard to debug from my side (I don't have previous Ceph experience) but what I noticed is that: - *ceph.conf* is practically empty,

Re: [Openstack-operators] [openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train

Hi, I think it was published, see http://lists.openstack.org/pipermail/openstack/2018-November/047172.html > Wiadomość napisana przez Jeremy Freudberg w dniu > 14.11.2018, o godz. 06:12: > > Hey Tony, > > What's the reason for the results of the poll not being public? > > Thanks, > Jeremy

[Openstack-operators] [all] All Hail our Newest Release Name - OpenStack Train

Hi everybody! As the subject reads, the "T" release of OpenStack is officially "Train". Unlike recent choices Train was the popular choice so congrats! Thanks to everybody who participated and help with the naming process. Lets make OpenStack Train the release so awesome that people can't

Re: [Openstack-operators] [Openstack-sigs] new SIGs to cover use cases

Wondering if we should *up level* to Multi-Cloud, where Hybrid Cloud can be a subset of Multi-Cloud. I think Scientific SIG can still focus on Scientific and HPC, whereas Multi/Hybrid Cloud will support broader use cases. On Tue, Nov 13, 2018 at 8:22 AM Stig Telfer wrote: > You are right to

Re: [Openstack-operators] new SIGs to cover use cases

You are right to make the connection - this is a subject that regularly comes up in the discussions of the Scientific SIG, though it’s just one of many use cases for hybrid cloud. If a new SIG was created around hybrid cloud, it would be useful to have it closely connected with the Scientific

Re: [Openstack-operators] operators get-together today at the Berlin Summit

On Tue, Nov 13, 2018 at 12:57:02PM +0100, Chris Morgan wrote: : We never did come up with a good plan for a separate event for : operators this evening, so I think maybe we should just meet up at the : marketplace mixer, so may I propose meet at the front at 6pm? : Chris : -- : Chris

[Openstack-operators] operators get-together today at the Berlin Summit

We never did come up with a good plan for a separate event for operators this evening, so I think maybe we should just meet up at the marketplace mixer, so may I propose meet at the front at 6pm? Chris -- Chris Morgan ___ OpenStack-operators mailing

[Openstack-operators] upgrade pike to queens get `xxx DBConnectionError SELECT 1`

Hi all, upgradig from pike to queens I got a lot of errors in nova-api.log: upgrade pike to queens get `xxx DBConnectionError SELECT 1` My issue is the same reported at: https://bugs.launchpad.net/oslo.db/+bug/1774544 The difference is that I am using centos 7. I am also using haproxy to

[Openstack-operators] queens: vnc password console does not work anymore

Hi All, before upgrading to queens, we used in qemu.conf the vnc_passwd parameter. Using the dashboard console asked me for the password. Upgrading to queens it does not work anymore (unable to negotiote security with server). Removing the vnc_password from qemu.conf e restart libvirt and virtual

Re: [Openstack-operators] new SIGs to cover use cases

Good point. Adding SIG list. -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: Monday, November 12, 2018 4:46 PM To: openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] new SIGs to cover use cases [EXTERNAL EMAIL] Please report any

Re: [Openstack-operators] Queens metadata agent error 500

Hi Chris, many thanks for your answer. It solved the issue. Regards Ignazio Il giorno mar 13 nov 2018 alle ore 03:46 Chris Apsey < bitskr...@bitskrieg.net> ha scritto: > Did you change the nova_metadata_ip option to nova_metadata_host in > metadata_agent.ini? The former value was deprecated

Re: [Openstack-operators] Queens metadata agent error 500

Hello, I am going to check it. Thanks Ignazio Il giorno Mar 13 Nov 2018 03:46 Chris Apsey ha scritto: > Did you change the nova_metadata_ip option to nova_metadata_host in > metadata_agent.ini? The former value was deprecated several releases ago > and now no longer functions as of pike. The

Re: [Openstack-operators] RabbitMQ and SSL

On the off chance that others see this or there is talk about this in Berlin I have tracked this down to versions of python-amqp and python-kombu More information at the bug report https://bugs.launchpad.net/oslo.messaging/+bug/1800957

Re: [Openstack-operators] Queens metadata agent error 500

Did you change the nova_metadata_ip option to nova_metadata_host in metadata_agent.ini? The former value was deprecated several releases ago and now no longer functions as of pike. The metadata service will throw 500 errors if you don't change it. On November 12, 2018 19:00:46 Ignazio

Re: [Openstack-operators] Queens metadata agent error 500

Any other suggestion ? It does not work. Nova metatada is on port 8775 in listen but no way to solve this issue. Thanks Ignazio Il giorno lun 12 nov 2018 alle ore 22:40 Slawomir Kaplonski < skapl...@redhat.com> ha scritto: > Hi, > > From logs which You attached it looks that Your

Re: [Openstack-operators] new SIGs to cover use cases

On 2018-11-12 15:46:38 + (+), arkady.kanev...@dell.com wrote: [...] > 1. Do we have or want to create a user community around Hybrid cloud. [...] > 2. As we target AI/ML as 2019 target application domain do we > want to create a SIG for it? Or do we extend scientific > community

Re: [Openstack-operators] Queens metadata agent error 500

Yes, sorry. Also the 8775 port is reachable from neutron metadata agent Regards Ignazio Il giorno lun 12 nov 2018 alle ore 23:08 Slawomir Kaplonski < skapl...@redhat.com> ha scritto: > Hi, > > > Wiadomość napisana przez Ignazio Cassano w > dniu 12.11.2018, o godz. 22:55: > > > > Hello, > > the

Re: [Openstack-operators] Queens metadata agent error 500

I tried 1 minute ago to create another instance. Nova api reports the following: RROR oslo_db.sqlalchemy.engines [req-cac96dee-d91b-48cb-831b-31f95cffa2f4 89f76bc5de5545f381da2c10c7df7f15 59f1f232ce28409593d66d8f6495e434 - default default] Database connection was found disconnected;

Re: [Openstack-operators] Queens metadata agent error 500

Hi, > Wiadomość napisana przez Ignazio Cassano w dniu > 12.11.2018, o godz. 22:55: > > Hello, > the nova api in on the same controller on port 8774 and it can be reached > from the metadata agent Nova-metadata-api is running on port 8775 IIRC. > No firewall is present > Regards > > Il

Re: [Openstack-operators] Queens metadata agent error 500

Hello again, ath the same time I tried to create an instance nova-api log reports: 2018-11-12 21:30:42.225 4226 ERROR oslo_db.sqlalchemy.engines [req-e4799f40-eeab-482d-9717-cb41be8ffde2 89f76bc5de5545f381da2c10c7df7f15 59f1f232ce28409593d66d8f6495e434 - default default] Database connection was

Re: [Openstack-operators] Queens metadata agent error 500

Hello, the nova api in on the same controller on port 8774 and it can be reached from the metadata agent No firewall is present Regards Il giorno lun 12 nov 2018 alle ore 22:40 Slawomir Kaplonski < skapl...@redhat.com> ha scritto: > Hi, > > From logs which You attached it looks that Your

Re: [Openstack-operators] Queens metadata agent error 500

Hi, From logs which You attached it looks that Your neutron-metadata-agent can’t connect to nova-api service. Please check if nova-metadata-api is reachable from node where Your neutron-metadata-agent is running. > Wiadomość napisana przez Ignazio Cassano w dniu > 12.11.2018, o godz. 22:34:

Re: [Openstack-operators] Queens metadata agent error 500

Hello again, I have another installation of ocata . On ocata the metadata for a network id is displayed by ps -afe like this: /usr/bin/python2 /bin/neutron-ns-metadata-proxy --pid_file=/var/lib/neutron/external/pids/c4731392-9b91-4663-adb3-b10b5ebcc4f1.pid

Re: [Openstack-operators] Queens metadata agent error 500

PS Thanks for your help Il giorno lun 12 nov 2018 alle ore 22:15 Ignazio Cassano < ignaziocass...@gmail.com> ha scritto: > Hello, > attached here there is the log file. > > Connecting to an instance created befor upgrade I also tried: > wget

Re: [Openstack-operators] Queens metadata agent error 500

Hi, Can You share logs from Your haproxy-metadata-proxy service which is running in qdhcp namespace? There should be some info about reason of those errors 500. > Wiadomość napisana przez Ignazio Cassano w dniu > 12.11.2018, o godz. 19:49: > > Hi All, > I upgraded manually my centos 7

[Openstack-operators] Queens metadata agent error 500

Hi All, I upgraded manually my centos 7 openstack ocata to pike. All worked fine. Then I upgraded from pike to Queens and instances stopped to reach metadata on 169.254.169.254 with error 500. I am using isolated metadata true in my dhcp conf and in dhcp namespace the port 80 is in listen.

[Openstack-operators] new SIGs to cover use cases

Team, At today Board and joint TC and UC meetings 2 questions come up: 1. Do we have or want to create a user community around Hybrid cloud. This is one of the major push of OpenStack for the communities. With 70+% of questionnaire responders told that they deploy and use hybrid cloud. We do

[Openstack-operators] [openstack-operators] [radosgw] Adding user type attribute in radosGW admin operations API to simplify quota operations

Dear all, At CERN, we are currently adding the radosgw component in our private cloud OpenStack based offering. In order to ease the integration with lifecycle management, we are proposing to enable the possibility to add users with the keystone type through the radosgw Admin Ops API. During the

Re: [Openstack-operators] [openstack-dev] [all] We're combining the lists!

On 2018-11-10 11:02:15 +0100 (+0100), Thierry Carrez wrote: [...] > As we are ultimately planning to move lists to mailman3 (which decided > to drop the "topics" concept altogether), I don't think we planned to > add serverside mailman topics to the new list. Correct, that was covered in more

Re: [Openstack-operators] [openstack-dev] [openstack-operators] [qa] [berlin] QA Team & related sessions at berlin summit

Hello Everyone, I have created the below etherpads to use during QA Forum sessions: - Users / Operators adoption of QA tools: https://etherpad.openstack.org/p/BER-qa-ops-user-feedback - QA Onboarding: https://etherpad.openstack.org/p/BER-qa-onboarding-vancouver -gmann On Fri, 09 Nov

Re: [Openstack-operators] [openstack-dev] [all] We're combining the lists!

Robert Collins wrote: > There don't seem to be any topics defined for -discuss yet, I hope > there will be, as I'm certainly not in a position of enough bandwidth > to handle everything *stack related. > > I'd suggest one for each previously list, at minimum. As we are ultimately planning to

Re: [Openstack-operators] [all] We're combining the lists!

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday

[Openstack-operators] [openstack-dev] [openstack-operators] [qa] [berlin] QA Team & related sessions at berlin summit

Hello everyone, Along with project updates & onboarding sessions, QA team will host QA feedback sessions in berlin summit. Feel free to catch us next week for any QA related questions or if you need help to contribute in QA (we are really looking forward to onbaord new contributor in QA).

[Openstack-operators] [puppet] openstack providers - endpoint not configurable

Hi, I've been recently working on separating management and client traffic onto different endpoints. We have different endpoint URLs configured for "public", "admin" and "internal". For openstack itself, this is working well. However, puppet providers don't seem to cater for this.

Re: [Openstack-operators] [openstack-dev] [nova] about resize the instance

When I resize the instance, the compute node report that "libvirtError: internal error: qemu unexpectedly closed the monitor: 2018-11-08T09:42:04.695681Z qemu-kvm: cannot set up guest memory 'pc.ram': Cannot allocate memory".Has anyone seen this situation?And the ram_allocation_ratio is set 3

[Openstack-operators] [all] Results of the T release naming poll. open

Hello all! The results of the naming poll are in! **PLEASE REMEMBER** that these now have to go through legal vetting. So it is too soon to say 'OpenStack Train' is our next release, given that previous polls have had some issues with the top choice. In any case, the names will be sent off

[Openstack-operators] Diversity and Inclusion at OpenStack Summit

I just wanted to pass on a few things we have going on during Summit that might be of interest! *Diversity and Inclusion GroupMe* - Is it your first summit and you don't know anyone else? Maybe you just don't want to travel to and from the venue alone? In the tradition of WoO, I have created a

[Openstack-operators] Question about path in disk file

Hi, I have a question about the "disk" file from the instances, I searched about it but didn't find any infos. At the beginning of the file the is a path to the baseimage which was used to create the instance, and I want to knwo what this ist for? The problem behind is, that we changed the

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] Dropping lazy translation support

On 11/6/2018 5:24 PM, Rochelle Grober wrote: Maybe the fastest way to get info would be to turn it off and see where the code barfs in a long run (to catch as many projects as possible)? There is zero integration testing for lazy translation, so "turning it off and seeing what breaks"

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] Dropping lazy translation support

I seem to recall list discussion on this quite a ways back. I think most of it happened on the Docs ml, though. Maybe Juno/Kilo timeframe? If possible, it would be good to search over the code bases for places it was called to see its current footprint. I'm pretty sure it was the docs folks

[Openstack-operators] no formal ops meetups team meeting today

Hello Ops, It appears there will not be enough attendance on IRC today for a useful ops meetups team meeting. I think everyone is getting ready for berlin next week, which at this stage is likely a better use of the time. We'll try to find a good venue for a social get-together on the Tuesday,

Re: [Openstack-operators] FIPS Compliance

Sean McGinnis writes: > I'm interested in some feedback from the community, particularly those running > OpenStack deployments, as to whether FIPS compliance [0][1] is something folks > are looking for. > > I've been seeing small changes starting to be proposed here and there for > things like

Re: [Openstack-operators] [openstack-dev] [all]Naming the T release of OpenStack -- Poll open

Hi all, Time is running out for you to have your say in the T release name poll. We have just under 3 days left. If you haven't voted please do! On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote: > Hi folks, > > It is time again to cast your vote for the naming of the T Release.

[Openstack-operators] FIPS Compliance

I'm interested in some feedback from the community, particularly those running OpenStack deployments, as to whether FIPS compliance [0][1] is something folks are looking for. I've been seeing small changes starting to be proposed here and there for things like MD5 usage related to its

Re: [Openstack-operators] [Openstack-sigs] Dropping lazy translation support

Matt Riedemann writes: > On 11/5/2018 1:36 PM, Doug Hellmann wrote: >> I think the lazy stuff was all about the API responses. The log >> translations worked a completely different way. > > Yeah maybe. And if so, I came across this in one of the blueprints: > >

Re: [Openstack-operators] [Openstack-sigs] Dropping lazy translation support

On 11/5/2018 1:36 PM, Doug Hellmann wrote: I think the lazy stuff was all about the API responses. The log translations worked a completely different way. Yeah maybe. And if so, I came across this in one of the blueprints: https://etherpad.openstack.org/p/disable-lazy-translation Which says

Re: [Openstack-operators] [Openstack-sigs] Dropping lazy translation support

Matt Riedemann writes: > This is a follow up to a dev ML email [1] where I noticed that some > implementations of the upgrade-checkers goal were failing because some > projects still use the oslo_i18n.enable_lazy() hook for lazy log message > translation (and maybe API responses?). > > The

[Openstack-operators] Dropping lazy translation support

This is a follow up to a dev ML email [1] where I noticed that some implementations of the upgrade-checkers goal were failing because some projects still use the oslo_i18n.enable_lazy() hook for lazy log message translation (and maybe API responses?). The very old blueprints related to this

[Openstack-operators] [nova][placement] Placement requests and caching in the resource tracker

All- Based on a (long) discussion yesterday [1] I have put up a patch [2] whereby you can set [compute]resource_provider_association_refresh to zero and the resource tracker will never* refresh the report client's provider cache. Philosophically, we're removing the "healing" aspect of the

[Openstack-operators] OpenStack Diversity and Inclusion Survey

The Diversity and Inclusion WG is still looking for your assistance in reaching and including data from as many members of our community as possible. We revised the Diversity Survey that was originally distributed to the Community in the Fall of 2015 and reached out in August with our new survey.

[Openstack-operators] [goals] selecting community-wide goals for T series

I have started a thread on the -dev list [1] to discuss the community-wide goals for the T series, prior to the Forum session in Berlin in a couple of weeks. Please join the conversation in that thread if you have any input. Thanks! Doug [1]

[Openstack-operators] [nova] Is anyone running their own script to purge old instance_faults table entries?

I came across this bug [1] in triage today and I thought this was fixed already [2] but either something regressed or there is more to do here. I'm mostly just wondering, are operators already running any kind of script which purges old instance_faults table records before an instance is

[Openstack-operators] [openlab] October Report

Hi everyone, Here are some highlights from OpenLab for the month of October: CI additions - cluster-api-provider-openstack - AdoptOpenJDK - very important open source project - many Java developers - strategic for open source ecosystem Website redesign completed - fielding

[Openstack-operators] RabbitMQ and SSL

Hi all, We’ve been battling an issue after an upgrade to pike which essentially makes using rabbit with ssl impossible https://bugs.launchpad.net/oslo.messaging/+bug/1800957 We use ubuntu cloud archives so it might no exactly be olso

Re: [Openstack-operators] [openstack-dev] [all]Naming the T release of OpenStack -- Poll open

On Tue, Oct 30, 2018 at 11:25:02AM -0700, iain macdonnell wrote: > I must be losing it. On what planet is "Tiny Town" a single word, and > "Troublesome" not more than 10 characters? Sorry for the mistake. Should either of these names win the popular vote clearly they would not be viable. Yours

[Openstack-operators] Ops Meetups team meeting 2018-10-30

Brief meeting today on #openstack-operators, minutes below. If you are attending Berlin, please start contributing to the Forum by selecting sesions of interest and then adding to the etherpads (see https://wiki.openstack.org/wiki/Forum/Berlin2018). I hear there's going to be a really great one

[Openstack-operators] [all]Naming the T release of OpenStack -- Poll open

Hi folks, It is time again to cast your vote for the naming of the T Release. As with last time we'll use a public polling option over per user private URLs for voting. This means, everybody should proceed to use the following URL to cast their vote:

[Openstack-operators] [user-committee] UC Meeting Reminder

UC meeting in #openstack-uc at 1800UTC -- Kind regards, Melvin Hillsman mrhills...@gmail.com mobile: (832) 264-2646 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org

[Openstack-operators] Fwd: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

-- Forwarded message - From: Samuel Cassiba Date: Fri, Sep 21, 2018 at 12:15 AM Subject: Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...) To: openstack-dev On Thu, Sep 20, 2018 at 2:48 PM Doug Hellmann wrote: >

Re: [Openstack-operators] [all] We're combining the lists! (was: Bringing the community together...)

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday

[Openstack-operators] [neutron] Automatically allow incoming DHCP traffic for networks which uses external dhcp server

Hi, Some time ago we had in Neutron reported RFE to allow automatically incoming DHCP traffic to the VM [1]. Basically it can be done today by adding proper security group rule that will allow such incoming traffic to the VM but idea of this RFE was to add some flag, called e.g.

Re: [Openstack-operators] [SOLVED] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

Hi Mike, Interesting - nice detective work! FWIW, I do have that explicitly set in my config, based on the recommendation at: https://docs.openstack.org/glance/latest/install/install-rdo.html#install-and-configure-components Your github PR will no go anywhere - all changes must go through

Re: [Openstack-operators] [SOLVED] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

TL;DR: glance config doesn’t honor documented default setting for paste_deploy.flavor. Solution is to add setting to glance-api.conf. Patch to be submitted. After the deep debugging yesterday Jonathan did a deep compare of our Mitaka configuration compared to Queens. He noted that this

Re: [Openstack-operators] [openstack-dev] [Octavia] [Kolla] SSL errors polling amphorae and missing tenant network interface

FYI, I took some time out this afternoon and wrote a detailed certificate configuration guide. Hopefully this will help. https://review.openstack.org/613454 Reviews would be welcome! Michael On Thu, Oct 25, 2018 at 7:00 AM Tobias Urdin wrote: > > Might as well throw it out here. > > After a

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

I have dug deep into the code for glance, shoving debug outputs to see what I can find in our queens environment. Here is my debug code (I have a lot more but this is the salient part) LOG.debug("in enforce(), action='%s', policyvalues='%s'", action, context.to_policy_values())

Re: [Openstack-operators] [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

melanie witt wrote on 10/25/2018 02:14:40 AM: > On Thu, 25 Oct 2018 14:12:51 +0900, ボーアディネシュ[bhor Dinesh] wrote: > > We were having a similar use case like *Preemptible Instances* called as > > *Rich-VM’s* which > > > > are high in resources and are deployed each per hypervisor. We have a > >

Re: [Openstack-operators] [octavia][rocky] Octavia and VxLAN without DVR

Can you use a provider network to expose galera to the vm? alternately, you could put a db out in the vm side. You don't strictly need to use the same db for every component. If crossing the streams is hard, maybe avoiding crossing at all is easier? Thanks, Kevin

Re: [Openstack-operators] [octavia][rocky] Octavia and VxLAN without DVR

you mean deploy octavia into an openstack project? But I will than need to connect the octavia services with my galera DBs... so same problem. Am 10/25/18 um 5:31 PM schrieb Fox, Kevin M: Would it make sense to move the control plane for this piece into the cluster? (vm in a mangement

  1   2   3   4   5   6   7   8   9   10   >