Dear stackers,
Vietnam OpenStack Community is very eager to announce the release of
Liberty automation deploy script:
1. Liberty deploy multi nodes using OVS in Neutron:
https://github.com/vietstacker/openstack-liberty-multinode
/blob/master/LIBERTY-U14.04-OVS/README-ENGLISH.md
2. Liberty deploy
Whether or not a restart is required is actually handled by oslo.policy.
Which is only included in Kilo and newer versions of Keystone. The work to
avoid restarting the service went in in commit [0] and was further worked
on in [1].
Juno and older versions are using the oslo-incubator code to han
On 12/08/2015 06:39 AM, Jamie Lennox wrote:
> The main problem I see with running Keystone (or any other service) in a
> web server, is that *I* (as a package maintainer) will loose the control
> over when the service is started. Let me explain why that is important
> for me.
>
>
It's worth pointing out, it looks like this only works in Kilo+, as it's
written. Sam pointed out earlier that this was what they'd run it on, but I
verified it won't work on earlier versions because, specifically, in the
migrate-secgroups.py it inserts into the default_security_group table, whi
We use RBAC in production but basically modify networking operations and some
compute ones. In our case we don’t need to restart the services if we modify
the policy.json file. I am surprise that keystone is not following the same
process.
Edgar
On 12/9/15, 9:06 AM, "Kris G. Lindgren" wro
I did not but more advanced could mean a lot of things for Neutron. There are
so many possible scenarios that expecting to have a “script” to cover all of
them is a whole new project. Not sure we want to explore than. In the past we
were recommending to make the migration in multiple steps, mayb
In other projects the policy.json file is read each time of api request. So
changes to the file take place immediately. I was 90% sure keystone was the
same way?
___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
On 12
Doesn't this script only solve the case of going from flatdhcp networks in
nova-network to same dchp/provider networks in neutron. Did anyone test to see
if it also works for doing more advanced nova-network configs?
___
Kris Lindg
Yes! We should but with a huge caveat that is not not supported officially by
the OpenStack community. At least the author wants to make a move with the
Neutron team to make it part of the tree.
Edgar
From: Matt Kassawara
Date: Wednesday, December 9, 2015 at 8:52 AM
To: "Kevin Bringard (kevinbr
Yea, I was considering updating the wiki
(https://wiki.openstack.org/wiki/Neutron/MigrationFromNovaNetwork/HowTo) to at
least make mention of it.
If it works (and it sounds like it does, at least for Juno) then I'm all for
adding it as a potential resource
On 12/9/15, 9:52 AM, "Matt Kassawa
Hi Salman,
Someone mentioned this same issue yesterday in relation to Terraform (maybe
a colleague of yours?), so given the two occurrences, I thought I'd look
into this.
I have a Liberty environment readily available, so I created a second set
of volume and volumev2 endpoints for a fictional reg
Anyone think we should make this script a bit more "official" ... perhaps
in the networking guide?
On Wed, Dec 9, 2015 at 9:01 AM, Kevin Bringard (kevinbri) <
kevin...@cisco.com> wrote:
> Thanks, Tom, Sam, and Edgar, that's really good info. If nothing else
> it'll give me a good blueprint for wh
Thanks, Tom, Sam, and Edgar, that's really good info. If nothing else it'll
give me a good blueprint for what to look for and where to start.
On 12/8/15, 10:37 PM, "Edgar Magana" wrote:
>Awesome code! I just did a small testbed test and it worked nicely!
>
>Edgar
>
>
>
>
>On 12/8/15, 7:16 PM,
Hi everyone,
At the Mitaka design summit in Tokyo we had some corridor discussions about
doing a mid-cycle meetup for the purpose of continuing some design
discussions and doing some specific sprint work.
***
I'd like indications of who would like to attend and what
locations/dates/topics/sprints
Hi,
I am using Kilo release on CentOS. We have recently enabled multiple regions
and it seems that Cinder have some problems with multiple endpoints.
Thinks are working fine with nova but cinder is behaving strange. Here are my
endpoints
[root@controller: ~] # openstack service list
+--
Hi,
Now I can also confirm that using v1 and v2 in the cinder endpoints work fine
for us in the Kilo release( we are using CentOS7).
Regards..
Salman.
PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
Visit
We had the Cinder services running on our controllers initially, but split them
off
to a separate set of (virtual) machines in order to allow for independent
upgrades.
Performance-wise that should not make a big difference, unless you expect an
enormous amount of requests. Nothing needs to be ins
Many thanks for your hints.
Ignazio
2015-12-09 9:50 GMT+01:00 Arne Wiebalck :
> We had the Cinder services running on our controllers initially, but split
> them off
> to a separate set of (virtual) machines in order to allow for independent
> upgrades.
> Performance-wise that should not make a b
Hi,
I am wondering whether there are people using RBAC at production. The
policy.json file has a structure that requires restart of the service
each time you edit the file. Is there and on the fly solution or tips
about it?
___
OpenStack-operator
On 12/08/2015 04:09 AM, Dolph Mathews wrote:
> In Debian, many services/daemons are run, then their API is used by the
> package. In the case of Keystone, for example, it is possible to ask,
> via Debconf, that Keystone registers itself in the service catalog. If
> we get Keystone w
20 matches
Mail list logo
