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,
From: Florian Engelmann [florian.engelm...@everyware.ch]
Sent: Thursday, October 25, 2018 8:37 AM
To: Fox, Kevin M; openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [octavia][rocky] Octavia and VxLAN without
DVR
you mean deploy octavia into an openstack project
Would it make sense to move the control plane for this piece into the cluster?
(vm in a mangement tenant?)
Thanks,
Kevin
From: Florian Engelmann [florian.engelm...@everyware.ch]
Sent: Thursday, October 25, 2018 7:39 AM
To:
+1 :)
From: Tim Bell [tim.b...@cern.ch]
Sent: Wednesday, September 26, 2018 11:55 AM
To: OpenStack Development Mailing List (not for usage questions);
openstack-operators; openstack-sigs
Subject: Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc]
How about stated this way,
Its the tc's responsibility to get it done. Either by delegating the activity,
or by doing it themselves. But either way, it needs to get done. Its a ball
that has been dropped too much in OpenStacks history. If no one is ultimately
responsible, balls will keep
I don't think openstack itself can meet full zero downtime requirements. But if
it can, then I also think none of the deployment tools try and support that use
case either.
Thanks,
Kevin
From: Amit Kumar [ebiib...@gmail.com]
Sent: Friday, May 18, 2018 3:46 AM
14, 2017 at 6:00 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
>>> The pressure for #2 comes from the inability to skip upgrades and the fact
>>> that upgrades are hugely time consuming still.
>>>
>>> If you want to reduce the push for number #2 and help d
The pressure for #2 comes from the inability to skip upgrades and the fact that
upgrades are hugely time consuming still.
If you want to reduce the push for number #2 and help developers get their wish
of getting features into users hands sooner, the path to upgrade really needs
to be much
kolla has various containerization tools. one based on ansible, another based
on kubernetes.
From: Imtiaz Chowdhury [imtiaz.chowdh...@workday.com]
Sent: Monday, August 28, 2017 5:24 PM
To: Curtis
Cc: openstack-operators@lists.openstack.org
Subject: Re:
Oh, yes please! We've had to go through a lot of hoops to migrate ceph-mon's
around while keeping their ip's consistent to avoid vm breakage. All the rest
of the ceph ecosystem (at least that we've dealt with) works fine without the
level of effort the current nova/cinder implementation
its a flag like noout. set with the ceph cli command.
Make sure all clients are to jewel (all vms restarted after the client
iupgraded) before you set it though. We ran into some issues with that.
Thanks,
Kevin
From: Grant Morley [gr...@absolutedevops.io]
Sent:
I think the really short answer is something like: It greatly simplifies
scheduling and billing.
From: Vladimir Prokofev [v...@prokofev.me]
Sent: Wednesday, March 15, 2017 2:41 PM
To: OpenStack Operators
Subject: [Openstack-operators] Flavors
A question of
We've run it in a test cloud meant to identify production issues before
supporting them on our production cloud.
We ran into a few issues that may or may not apply in your situation:
There's a security issue with the Trove Rabbitmq. The easiest way around it is
to use the feature that lets the
The issue is, as I understand it, that there are no tests currently to check if
changes to the Kolla code base will break the Debian based containers, and no
one has stepped up to write the tests in a long time.
So, no one can rely on the containers being in a usable state.
If someone is
too.
which has bitten us on multiple occasions.
Thanks,
Kevin
From: Xav Paice [xavpa...@gmail.com]
Sent: Wednesday, October 05, 2016 12:39 PM
To: Fox, Kevin M
Cc: George Mihaiescu; OpenStack Operators
Subject: Re: [Openstack-operators] Rados Gateway to Swift
Did you try it with jewel? If not, what version?
Thanks,
Kevin
From: Xav Paice [xavpa...@gmail.com]
Sent: Wednesday, October 05, 2016 12:12 PM
To: George Mihaiescu
Cc: OpenStack Operators
Subject: Re: [Openstack-operators] Rados Gateway to Swift migration
OpenStack really needs a way to have a control api for selecting a swift
"flavor", and letting you have multiple swift endpoints within, so swift the
software, radowgw, and vendor endpoints can all co'exist.
Kevin
From: Xav Paice [xavpa...@gmail.com]
I'd also add it depends on feature set of the cloud. If you have extra
services, or your users keep asking for more and more openstack features to be
added to the cloud (dnsaas, dbaas, hadoopaas, coeaas,) then the ratio is much
higher then say, with just a basic cloud with vmaas & naas.
+1
From: Tim Bell [tim.b...@cern.ch]
Sent: Thursday, August 18, 2016 10:50 AM
To: Jonathan D. Proulx
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Shelving
I was interested to establish a consensus that
- Shelved instances
we run 3, one per controller. 40 seems like you might run into some issues and
really shouldn't hit your controllers that hard at only 40 nodes.
Thanks,
Kevin
From: David Wahlstrom [david.wahlst...@gmail.com]
Sent: Wednesday, August 17, 2016 2:27 PM
To: OpenStack
+1
From: Melvin Hillsman
Sent: Friday, July 29, 2016 9:22:02 PM
To: Steven Dake (stdake); openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [kolla] question of default users for
operators
Personally, if OpenStack default is to have a
shut
things down properly? Seems like its a cross project issue? Should a spec be
submitted?
Thanks,
Kevin
From: Dmitry Mescheryakov [dmescherya...@mirantis.com]
Sent: Tuesday, July 26, 2016 11:01 AM
To: Fox, Kevin M
Cc: Sam Morrison; OpenStack Operators
Subject: Re
Yeah, we've experienced it but hadn't had time yet to really dig in like this,
or gotten a good workaround. If you file a bug, please let me know what number.
Thanks,
Kevin
From: Sam Morrison [sorri...@gmail.com]
Sent: Sunday, July 24, 2016 11:27 PM
To:
Ah. Interesting.
The graceful shutdown would really help the Kubernetes situation too.
Kubernetes can do easy rolling upgrades and having the processes being able to
clean up after themselves as they are upgraded is important. Is this something
that needs to go into oslo.messaging or does it
Cool. Maybe this could be contributed to the Kolla project?
Thanks,
Kevin
From: Gerard Braad
Sent: Monday, June 27, 2016 8:58:18 PM
To: openst...@lists.openstack.org; openstack-operators
Subject: [Openstack-operators] [openstack] [tools] OpenStack client in a
Is there a copy-from-url method that's not deprecated yet?
The app catalog is still pointing users at the command line in v1 mode
Thanks,
Kevin
From: Matt Fischer [m...@mattfischer.com]
Sent: Thursday, May 12, 2016 4:43 PM
To: Flavio Percoco
Cc:
There are a couple of reasons I think this may cause you problems even if it
was technically feasible:
* VMs deployed on vmware are built as pets and really need/benifit from the
features of vmware. if migrating to anything but a vmware openstack cloud then
those underlying expectations built
: Mathieu Gagné [mga...@calavera.ca]
Sent: Tuesday, May 03, 2016 3:25 PM
To: Fox, Kevin M
Cc: Michael Still; openstack-operators@lists.openstack.org; Sean Dague
Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in
nova.conf?
On Tue, May 3, 2016 at 5:51 PM, Fox, Kevin M <ke
[mikalst...@gmail.com] on behalf of Michael Still
[mi...@stillhq.com]
Sent: Tuesday, May 03, 2016 2:37 PM
To: Fox, Kevin M
Cc: David Medberry; Ned Rhudy; openstack-operators@lists.openstack.org; Sean
Dague
Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in
nova.conf?
Hey,
I just
We've used it too to work around the lack of instance users in nova. Please
keep it until a viable solution can be reached.
Thanks,
Kevin
From: David Medberry [openst...@medberry.net]
Sent: Monday, April 18, 2016 7:16 AM
To: Ned Rhudy
Cc:
Kolla folks, the word opinionated in the deploymentbconfig tool is usually seen
by ops as heavily tieing your hands to the point of being very painful or a
show stopper. I get that your trying to say that now its "opinionated" for easy
install but supports being unopinionated, but some ops wont
We saw a problem recently with layer3+4. We're still working on it, but a
possible datapoint:
We had them connected through a cisco switch and saw iperf only use 50% of
capacity about 50% of the runs, and most of the rest of the time full.
Seemingly randomly.
We connected the two nodes
You can just rotate without restarting services.
We're rotating currently only once a day.
We rotate on one machine, then rsync the data to the others in a cron job. Has
been working well for a couple of months now.
Thanks,
Kevin
From: Ajay Kalambur
We use them all the time, and openstack in one version actually broke them on
us. (I wrote and contributed a unit test so it shouldn't happen again.)
Use case:
You have two external networks.
1. Internet - One that's directly connected to the internet.
2. One that is a private network space and
I guess my current focus is on network HA, since these popped into my head
right away and all seem to be network related:
* l3+dvr in neutron's a huge, huge thing.
* neutron external rbac. (https://review.openstack.org/#/c/282295/ really
useful for more then one reason)
* Octavia anti-affinity
We usually use two vips.
Thanks,
Kevin
From: Steven Dake (stdake)
Sent: Friday, February 12, 2016 6:04:45 AM
To: openstack-operators@lists.openstack.org
Subject: [Openstack-operators] [kolla] Question about how Operators deploy
Hi folks,
Unfortunately I won't
They were used indirectly I think when you had some services configured for v2
only authentication support because the service didn't work with v2. For
example nova->neutron was v2 only for a while. I think all services are
supporting v3 these days so that would no longer be necessary?
Thanks,
them for tenant networks for similar reasons. Them
only working on external networks is limiting.
Thanks,
Kevin
From: Robert Starmer [rob...@kumul.us]
Sent: Friday, January 29, 2016 1:21 AM
To: Fox, Kevin M
Cc: Carl Baldwin; OpenStack Operators; Tomas Vondra
center. No BGP L3VPN tunnels,
which cannot be done in open-source.
Tomas
>
> On Wed, Jan 27, 2016 at 3:33 PM, Fox, Kevin M
<kevin.fox-mijbx5db...@public.gmane.org> wrote:
>
>
>
>
>
> But there already is a second external address, the fip address that's
nating.
code to function the way it
always has, greatly simplifying implementation?
Thanks,
Kevin
From: Robert Starmer [rob...@kumul.us]
Sent: Wednesday, January 27, 2016 8:34 PM
To: Fox, Kevin M
Cc: Carl Baldwin; OpenStack Operators; Tomas Vondra
Subject: Re: [Openstack
But there already is a second external address, the fip address that's nating.
Is there a double nat? I'm a little confused.
Thanks,
Kevin
From: Robert Starmer [rob...@kumul.us]
Sent: Wednesday, January 27, 2016 3:20 PM
To: Carl Baldwin
Cc: OpenStack Operators;
ceph would work pretty well for that use case too. We've run a ceph with two
ost's, with the replication set to 2, to back both cinder and glance for HA.
Nothing complicated needed to get it working. Less complicated then drbd I
think. You can then also easily scale it out as needed.
Thanks,
There is a "feature" where cinder-backup and cinder-volume must be running on
the same node. If they are not, you get an error like that. I tripped over it
myself.
Thanks,
Kevin
From: raju [raju.r...@gmail.com]
Sent: Tuesday, January 26, 2016 8:16 AM
To:
crank up debugging and look in the logs? anything interesting?
Thanks,
Kevin
From: raju [raju.r...@gmail.com]
Sent: Tuesday, January 26, 2016 9:55 AM
To: Fox, Kevin M
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Cinder-backup
great. thanks for letting us know. :)
Kevin
From: raju [raju.r...@gmail.com]
Sent: Tuesday, January 26, 2016 11:25 AM
To: Fox, Kevin M
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Cinder-backup to swift
Kevin/Swami,
Now
Awsome news. Should there be a tag added for gallera multimaster safe to let us
ops know about these things?
Thanks,
Kevin
From: Kevin Benton
Sent: Monday, December 07, 2015 6:08:12 PM
To: Matteo Panella
Cc: OpenStack Operators
Subject: Re: [Openstack-operators]
Yeah, switching them that way makes a lot of sense.
Thanks,
Kevin
From: Dan Sneddon
Sent: Thursday, December 03, 2015 12:39:25 PM
To: Fox, Kevin M; Jesse Keating; Sean Dague
Cc: openstack-operators
Subject: Re: [Openstack-operators] Service Catalog TNG urls
We use internal to be a private network between the controllers and the compute
nodes that no one else has access to. Without that, we'd be stuck.
An OpenStack network that's where all the public services go, that isn't
external to the cloud for billing purposes does make sense too though.
Did you try launching the docker container with the privilege flag? dib does a
lot of privileged things last I looked.
Thanks,
Kevin
From: Clint Byrum [cl...@fewbar.com]
Sent: Wednesday, December 02, 2015 3:49 PM
To: openstack-operators
Subject: Re:
Kind of related, as an op, we see a lot of 3rd party repositories that recently
only supported rhel5 move to finally supporting rhel6 because rhel7 came out
and rhel5 went to long term support contract only. This caused us to have to
support rhel5 way longer then we would have liked. Now, we're
Awesome. Thanks for the link. :)
Kevin
From: jonathan.pro...@gmail.com [jonathan.pro...@gmail.com] on behalf of
Jonathan Proulx [j...@jonproulx.com]
Sent: Thursday, May 28, 2015 12:59 PM
To: Fox, Kevin M
Cc: Dmitry Borodaenko; David Medberry; openstack
As an Op, I've ran into this problem and keep running into it. I would very
much like a solution.
Its also quite related to the nova instance user issue I've been working on,
that's needed by the App Catalog project.
So, yes, please keep fighting the good fight.
Thanks,
Kevin
The nova instance user workflow could be used for that?
https://review.openstack.org/#/c/186617/
A template could start the vm, register the instance user id with the IdP, and
then the instance can call the IdP to register.
Thanks,
Kevin
From: Adam Young
Awesome. Are they ready enough that they should go into the app catalog?
(http://apps.openstack.org)
Thanks,
Kevin
From: Matthew Thode [prometheanf...@gentoo.org]
Sent: Monday, June 08, 2015 8:26 AM
To: openstack-operators@lists.openstack.org
Subject:
From: Tom Fifield
Sent: Sunday, June 07, 2015 6:54:42 PM
To: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [Tags] Tags Team Repo our first tags!
On 06/06/15 03:12, Fox, Kevin M wrote:
With my op hat on, I'd very much prefer packaged-in-ubuntu
With my op hat on, I'd very much prefer packaged-in-ubuntu/packaged-in-centos
or packaged=ubuntu,centos. If its just packaged=True, I'd still have to go look
up if its in my distro of choice.
Thanks,
Kevin
From: Jeremy Stanley [fu...@yuggoth.org]
Sent:
Since you are passing the tagged physical network device eth1.803 into the
bridge, I think you need to use a flat network in the config/ external network
create command. Otherwise it may do nested vlan tags.
Thanks,
Kevin
From: Geo Varghese
Sent: Friday, June
To: Fox, Kevin M
Cc: openstack-operators@lists.openstack.org; openst...@lists.openstack.org
Subject: Re: Help with multiple external network in openstack
Kevin,
Thanks. Can you please explain these values
pub:br-pub,scz:br-scz,osg:br-osg,mgmt:br-mgmt
These 4 networks are external networks? How you
Great. Thanks for sharing. I'll have to try it myself. :)
Kevin
From: Cynthia Lopes [clsacrame...@gmail.com]
Sent: Thursday, June 04, 2015 9:08 AM
To: Fox, Kevin M
Cc: Steve Gordon; OpenStack Operations Mailing List
Subject: Re: [Openstack-operators] Venom
For the record, what version of ceph are you using before and after?
Thanks,
Kevin
From: Cynthia Lopes
Sent: Thursday, June 04, 2015 1:27:53 AM
To: Steve Gordon
Cc: OpenStack Operations Mailing List
Subject: Re: [Openstack-operators] Venom vulnerability
Hi guys,
If you disable discovery/unknown hosts on both of the pxe servers, you should
be able to define the machine in only one of the pxe servers and boot it
reliably. I've mixed Ironic and Cobbler managed hosts on the same network this
way.
Thanks,
Kevin
From: Adam
I would agree from the standpoint that most users don't want to care about the
network but the majority of the users are folks that want a higher level of
service then just raw compute resources too.
They want an app catalog where they can get fully featured, reliable, scalable,
and secure
Have you looked at the kolla project?
Thanks,
Kevin
From: CoreOS
Sent: Wednesday, April 29, 2015 5:08:12 AM
To: openstack-operators@lists.openstack.org
Subject: [Openstack-operators] OpenStack Dockerizing on CoreOS
Hello,
I’m trying to develop fault tolerance
Some folks have been discussing an app store model. perhaps in Murano, but more
global, that would allow images/template to be registered somewhere like on
openstack.org and show up on all clouds that have the global repo enabled.
Murano would be extended to fetch the images/templates to the
-Original Message-
From: Richard Raseley [mailto:rich...@raseley.com]
Sent: Thursday, April 23, 2015 2:34 PM
To: Fox, Kevin M
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Sharing resources across OpenStack
instances
Fox, Kevin M wrote:
I'm
PM
To: Fox, Kevin M
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Sharing resources across OpenStack instances
Fox, Kevin M wrote:
Some folks have been discussing an app store model. perhaps in
Murano, but more global, that would allow images/template
This is a case for a cross project cloud (institutional?). It costs more to run
two little clouds then one bigger one. Both in terms of man power, and in cases
like these. under utilized resources.
#3 is interesting though. If there is to be an openstack app catalog, it would
be inportant to
Its part of the keystone v3 api I think. I've only seen it show up when I
configure horizon to specifically talk v3 to keystone.
Thanks,
Kevin
From: Mike Smith [mism...@overstock.com]
Sent: Wednesday, April 15, 2015 4:33 PM
To:
, 2015 9:36 AM
To: Fox, Kevin M
Cc: maishsk+openst...@maishsk.com; openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Hypervisor decision
I was under the impression hyper-v didn't charge a per seat license on non
windows instances?
On Thu, Mar 19, 2015 at 12:05 PM, Fox
What about the other glance logfiles? It looks like it may be calling out to a
different server and thats failing...
Thanks,
Kevin
From: Nathan Stratton [nat...@robotics.net]
Sent: Friday, March 06, 2015 11:42 AM
To: openstack-oper.
Subject: [Openstack-operators]
See the id_mapping table.
Thanks,
Kevin
From: Antonio Messina [antonio.s.mess...@gmail.com]
Sent: Tuesday, March 03, 2015 11:28 AM
To: Fox, Kevin M
Cc: Caius Howcroft; openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Migrating
You can leave the roles/projects outside of ldap by just using the LDAP
identity plugin, leaving the rest in sql. It sounds like they will be
deprecating putting roles/projects in LDAP in the future anyway.
That leaves identity mapping. There is a table of ldap users to unique id's in
the
72 matches
Mail list logo
