[Openstack] non public glance image can seen by all tenant

[Adhi Priharmanto]

Hi,
I have setup rocky release at my openstack lab, now all of tenant (user)
can see non-public glance image create by another tenant (user)

here is my glance policy.json :

> {
> "context_is_admin":  "role:admin",
> "default": "role:admin",
> "add_image": "",
> "delete_image": "",
> "get_image": "",
> "get_images": "",
> "modify_image": "",
> "publicize_image": "role:admin",
> "communitize_image": "",
> "copy_from": "",
> "download_image": "",
> "upload_image": "",
> "delete_image_location": "",
> "get_image_location": "",
> "set_image_location": "",
> "add_member": "",
> "delete_member": "",
> "get_member": "",
> "get_members": "",
> "modify_member": "",
> "manage_image_cache": "role:admin",
> "get_task": "",
> "get_tasks": "",
> "add_task": "",
> "modify_task": "",
> "tasks_api_access": "role:admin",
> "deactivate": "",
> "reactivate": "",
> "get_metadef_namespace": "",
> "get_metadef_namespaces":"",
> "modify_metadef_namespace":"",
> "add_metadef_namespace":"",
> "get_metadef_object":"",
> "get_metadef_objects":"",
> "modify_metadef_object":"",
> "add_metadef_object":"",
> "list_metadef_resource_types":"",
> "get_metadef_resource_type":"",
> "add_metadef_resource_type_association":"",
> "get_metadef_property":"",
> "get_metadef_properties":"",
> "modify_metadef_property":"",
> "add_metadef_property":"",
> "get_metadef_tag":"",
> "get_metadef_tags":"",
> "modify_metadef_tag":"",
> "add_metadef_tag":"",
> "add_metadef_tags":""
> }


any advice how to fix this ?


-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [Kolla] Implement upgrade/rolling-upgrade for services in Kolla-Ansible

[Ha Manh, Dong]

Hi all,

I'm working on the bp about implementing upgrade/rolling-upgrade for services 
in Kolla [1]. And there're three patch-sets remaining about developing the 
rolling upgrade logic:

Apply Swift rolling upgrade at https://review.openstack.org/#/c/582103/
Apply Neutron rolling upgrade logic https://review.openstack.org/#/c/407922/

The reviewing for two patch-sets above is nearly done, so could other core 
reviewers help to review them.

And the third patch-set is about rolling upgrade logic for Heat 
https://review.openstack.org/#/c/555199/ . This patch-set is under review by 
Eduardo. But any review is welcome.


Thx a lot in advance for any help :)

[1] 
https://blueprints.launchpad.net/kolla-ansible/+spec/apply-service-upgrade-procedure

--
Dong Ha-Manh
Fujitsu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Searchlight] Weekly report - Stein R-25

[Trinh Nguyen]

Hi team,

It's a little late but finally, I can find some time to write the report
for last week [1].

Just a reminder that at the end of this week we will release Stein-1 for
all of the Searchlight projects. It's not required but I would like to do
it to evaluate our team's effort.

Happy Searching!!! :)

[1]
https://www.dangtrinh.com/2018/10/searchlight-weekly-report-stein-r-25.html

-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Michael Johnson]

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 lot of troubleshooting we were able to narrow our issue down to
> our test environment running qemu virtualization, we moved our compute
> node to hardware and
> used kvm full virtualization instead.
>
> We could properly reproduce the issue where generating a CSR from a
> private key and then trying to verify the CSR would fail complaining about
> "Signature did not match the certificate request"
>
> We suspect qemu floating point emulation caused this, the same OpenSSL
> function that validates a CSR is the one used when validating the SSL
> handshake which caused our issue.
> After going through the whole stack, we have Octavia working flawlessly
> without any issues at all.
>
> Best regards
> Tobias
>
> On 10/23/2018 04:31 PM, Tobias Urdin wrote:
> > Hello Erik,
> >
> > Could you specify the DNs you used for all certificates just so that I
> > can rule it out on my side.
> > You can redact anything sensitive with some to just get the feel on how
> > it's configured.
> >
> > Best regards
> > Tobias
> >
> > On 10/22/2018 04:47 PM, Erik McCormick wrote:
> >> On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin  
> >> wrote:
> >>> Hello,
> >>>
> >>> I've been having a lot of issues with SSL certificates myself, on my
> >>> second trip now trying to get it working.
> >>>
> >>> Before I spent a lot of time walking through every line in the DevStack
> >>> plugin and fixing my config options, used the generate
> >>> script [1] and still it didn't work.
> >>>
> >>> When I got the "invalid padding" issue it was because of the DN I used
> >>> for the CA and the certificate IIRC.
> >>>
> >>>> 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
> >>> octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
> >>> to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
> >>> routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
> >>> ('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
> >>> ('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
> >>>> 19:47 < tobias-urdin> after a quick google "The problem was that my
> >>> CA DN was the same as the certificate DN."
> >>>
> >>> IIRC I think that solved it, but then again I wouldn't remember fully
> >>> since I've been at so many different angles by now.
> >>>
> >>> Here is my IRC logs history from the #openstack-lbaas channel, perhaps
> >>> it can help you out
> >>> http://paste.openstack.org/show/732575/
> >>>
> >> Tobias, I owe you a beer. This was precisely the issue. I'm deploying
> >> Octavia with kolla-ansible. It only deploys a single CA. After hacking
> >> the templates and playbook to incorporate a separate server CA, the
> >> amphorae now load and provision the required namespace. I'm adding a
> >> kolla tag to the subject of this in hopes that someone might want to
> >> take on changing this behavior in the project. Hopefully after I get
> >> through Upstream Institute in Berlin I'll be able to do it myself if
> >> nobody else wants to do it.
> >>
> >> For certificate generation, I extracted the contents of
> >> octavia_certs_install.yml (which sets up the directory structure,
> >> openssl.cnf, and the client CA), and octavia_certs.yml (which creates
> >> the server CA and the client certificate) and mashed them into a
> >> separate playbook just for this purpose. At the end I get:
> >>
> >> ca_01.pem - Client CA Certificate
> >> ca_01.key - Client CA Key
> >> ca_server_01.pem - Server CA Certificate
> >> cakey.pem - Server CA Key
> >> client.pem - Concatenated Client Key and Certificate
> >>
> >> If it would help to have the playbook, I can stick it up on github
> >> with a huge "This is a hack" disclaimer on it.
> >>
> >>> -
> >>>
> >>> Sorry for hijacking the thread but I'm stuck as well.
> >>>
> >>> I've in the past tried to generate the certificates with [1] but now
> >>> moved on to using the openstack-ansible way of generating them [2]
> >>> with some modifications.
> >>>
> >>> Right now I'm just getting: Could not connect to instance. Retrying.:
> >>> SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
> >>> from the amphoras, haven't got any further but I've eliminated a lot of
> >>> stuck in the middle.
> >>>
> >>> Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
> >>> wasn't an issue with CentOS and OpenSSL versions since it tends to lag
> >>> behind.
> >>> Checking the amphora with openssl s_client [3] it gives the same one,
> >>> but the verification is successful just that I don't understand what the
> >>> bad signature
> >>> part is about, from browsing some OpenSSL code it seems to be related to
> >>> RSA signatures somehow.
> >>>
> >>> 

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

[Michael Johnson]

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 lot of troubleshooting we were able to narrow our issue down to
> our test environment running qemu virtualization, we moved our compute
> node to hardware and
> used kvm full virtualization instead.
>
> We could properly reproduce the issue where generating a CSR from a
> private key and then trying to verify the CSR would fail complaining about
> "Signature did not match the certificate request"
>
> We suspect qemu floating point emulation caused this, the same OpenSSL
> function that validates a CSR is the one used when validating the SSL
> handshake which caused our issue.
> After going through the whole stack, we have Octavia working flawlessly
> without any issues at all.
>
> Best regards
> Tobias
>
> On 10/23/2018 04:31 PM, Tobias Urdin wrote:
> > Hello Erik,
> >
> > Could you specify the DNs you used for all certificates just so that I
> > can rule it out on my side.
> > You can redact anything sensitive with some to just get the feel on how
> > it's configured.
> >
> > Best regards
> > Tobias
> >
> > On 10/22/2018 04:47 PM, Erik McCormick wrote:
> >> On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin  
> >> wrote:
> >>> Hello,
> >>>
> >>> I've been having a lot of issues with SSL certificates myself, on my
> >>> second trip now trying to get it working.
> >>>
> >>> Before I spent a lot of time walking through every line in the DevStack
> >>> plugin and fixing my config options, used the generate
> >>> script [1] and still it didn't work.
> >>>
> >>> When I got the "invalid padding" issue it was because of the DN I used
> >>> for the CA and the certificate IIRC.
> >>>
> >>>> 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
> >>> octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
> >>> to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
> >>> routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
> >>> ('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
> >>> ('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
> >>>> 19:47 < tobias-urdin> after a quick google "The problem was that my
> >>> CA DN was the same as the certificate DN."
> >>>
> >>> IIRC I think that solved it, but then again I wouldn't remember fully
> >>> since I've been at so many different angles by now.
> >>>
> >>> Here is my IRC logs history from the #openstack-lbaas channel, perhaps
> >>> it can help you out
> >>> http://paste.openstack.org/show/732575/
> >>>
> >> Tobias, I owe you a beer. This was precisely the issue. I'm deploying
> >> Octavia with kolla-ansible. It only deploys a single CA. After hacking
> >> the templates and playbook to incorporate a separate server CA, the
> >> amphorae now load and provision the required namespace. I'm adding a
> >> kolla tag to the subject of this in hopes that someone might want to
> >> take on changing this behavior in the project. Hopefully after I get
> >> through Upstream Institute in Berlin I'll be able to do it myself if
> >> nobody else wants to do it.
> >>
> >> For certificate generation, I extracted the contents of
> >> octavia_certs_install.yml (which sets up the directory structure,
> >> openssl.cnf, and the client CA), and octavia_certs.yml (which creates
> >> the server CA and the client certificate) and mashed them into a
> >> separate playbook just for this purpose. At the end I get:
> >>
> >> ca_01.pem - Client CA Certificate
> >> ca_01.key - Client CA Key
> >> ca_server_01.pem - Server CA Certificate
> >> cakey.pem - Server CA Key
> >> client.pem - Concatenated Client Key and Certificate
> >>
> >> If it would help to have the playbook, I can stick it up on github
> >> with a huge "This is a hack" disclaimer on it.
> >>
> >>> -
> >>>
> >>> Sorry for hijacking the thread but I'm stuck as well.
> >>>
> >>> I've in the past tried to generate the certificates with [1] but now
> >>> moved on to using the openstack-ansible way of generating them [2]
> >>> with some modifications.
> >>>
> >>> Right now I'm just getting: Could not connect to instance. Retrying.:
> >>> SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
> >>> from the amphoras, haven't got any further but I've eliminated a lot of
> >>> stuck in the middle.
> >>>
> >>> Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
> >>> wasn't an issue with CentOS and OpenSSL versions since it tends to lag
> >>> behind.
> >>> Checking the amphora with openssl s_client [3] it gives the same one,
> >>> but the verification is successful just that I don't understand what the
> >>> bad signature
> >>> part is about, from browsing some OpenSSL code it seems to be related to
> >>> RSA signatures somehow.
> >>>
> >>> 

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

[Trinh Nguyen]

Hi Matt,

The Searchlight team decided to revive the required feature in Stein [1]
and We're working with Kevin to review the patch this weekend. If Nova team
needs some help, just let me know.

[1] https://review.openstack.org/#/c/453352/

Bests,

On Fri, Oct 26, 2018 at 12:58 AM Matt Riedemann  wrote:

> On 10/24/2018 6:55 PM, Sam Morrison wrote:
> > I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still have
> the top level api cell DB but the API would only ever read from it.
> Nova-api would only write to the compute cell DBs.
> > Then keep the nova-cells processes just doing instance_update_at_top to
> keep the nova-cell-api db up to date.
>
> There was also the "read from searchlight" idea [1] but that died in
> Boston.
>
> [1]
>
> https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/list-instances-using-searchlight.html
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]]

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())
return super(Enforcer, self).enforce(action, target,
 context.to_policy_values(),
 do_raise=True,
 exc=exception.Forbidden,
 action=action)

below is the output attempting to set an image that I own while being an admin 
to public via `openstack image set –public cirros`

2018-10-25 18:29:16.575 17561 DEBUG glance.api.policy 
[req-e343bb10-8ec8-40df-8c0c-47d1b217ca0d - - - - -] in enforce(), 
action='publicize_image', policyvalues='{'service_roles': [], 'user_id': None, 
'roles': [], 'user_domain_id': None, 'service_project_id': None, 
'service_user_id': None, 'service_user_domain_id': None, 
'service_project_domain_id': None, 'is_admin_project': True, 'user': None, 
'project_id': None, 'tenant': None, 'project_domain_id': None}' enforce 
/usr/lib/python2.7/site-packages/glance/api/policy.py:64

And here is what shows up when I `openstack image list`  as our test user 
(`jonathan`) that is NOT an admin

2018-10-25 18:32:24.841 17564 DEBUG glance.api.policy 
[req-22abdcf2-14cd-4680-8deb-e48902a7ddef - - - - -] in enforce(), 
action='get_images', policyvalues='{'service_roles': [], 'user_id': None, 
'roles': [], 'user_domain_id': None, 'service_project_id': None, 
'service_user_id': None, 'service_user_domain_id': None, 
'service_project_domain_id': None, 'is_admin_project': True, 'user': None, 
'project_id': None, 'tenant': None, 'project_domain_id': None}' enforce 
/usr/lib/python2.7/site-packages/glance/api/policy.py:64


The takeaway that I have is that in the case of get_images, is_admin_project is 
True, which is WRONG for that test but since it’s a read-only operation it’s 
content to shortcircuit and return all those images.

In the case of publicize_image, the is_admin_project being True isn’t enough, 
and when it checks user (which is None) it says NOPE.


So somehow for some reason glance APIs context is super duper wrong.


Mike Moore, M.S.S.E.

Systems Engineer, Goddard Private Cloud
michael.d.mo...@nasa.gov

Hydrogen fusion brightens my day.

 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Dan Prince]

On Wed, Oct 17, 2018 at 11:15 AM Alex Schultz  wrote:
>
> Time to resurrect this thread.
>
> On Thu, Jul 5, 2018 at 12:14 PM James Slagle  wrote:
> >
> > On Thu, Jul 5, 2018 at 1:50 PM, Dan Prince  wrote:
> > > Last week I was tinkering with my docker configuration a bit and was a
> > > bit surprised that puppet/services/docker.yaml no longer used puppet to
> > > configure the docker daemon. It now uses Ansible [1] which is very cool
> > > but brings up the question of how should we clearly indicate to
> > > developers and users that we are using Ansible vs Puppet for
> > > configuration?
> > >
> > > TripleO has been around for a while now, has supported multiple
> > > configuration ans service types over the years: os-apply-config,
> > > puppet, containers, and now Ansible. In the past we've used rigid
> > > directory structures to identify which "service type" was used. More
> > > recently we mixed things up a bit more even by extending one service
> > > type from another ("docker" services all initially extended the
> > > "puppet" services to generate config files and provide an easy upgrade
> > > path).
> > >
> > > Similarly we now use Ansible all over the place for other things in
> > > many of or docker and puppet services for things like upgrades. That is
> > > all good too. I guess the thing I'm getting at here is just a way to
> > > cleanly identify which services are configured via Puppet vs. Ansible.
> > > And how can we do that in the least destructive way possible so as not
> > > to confuse ourselves and our users in the process.
> > >
> > > Also, I think its work keeping in mind that TripleO was once a multi-
> > > vendor project with vendors that had different preferences on service
> > > configuration. Also having the ability to support multiple
> > > configuration mechanisms in the future could once again present itself
> > > (thinking of Kubernetes as an example). Keeping in mind there may be a
> > > conversion period that could well last more than a release or two.
> > >
> > > I suggested a 'services/ansible' directory with mixed responces in our
> > > #tripleo meeting this week. Any other thoughts on the matter?
> >
> > I would almost rather see us organize the directories by service
> > name/project instead of implementation.
> >
> > Instead of:
> >
> > puppet/services/nova-api.yaml
> > puppet/services/nova-conductor.yaml
> > docker/services/nova-api.yaml
> > docker/services/nova-conductor.yaml
> >
> > We'd have:
> >
> > services/nova/nova-api-puppet.yaml
> > services/nova/nova-conductor-puppet.yaml
> > services/nova/nova-api-docker.yaml
> > services/nova/nova-conductor-docker.yaml
> >
> > (or perhaps even another level of directories to indicate
> > puppet/docker/ansible?)
> >
> > Personally, such an organization is something I'm more used to. It
> > feels more similar to how most would expect a puppet module or ansible
> > role to be organized, where you have the abstraction (service
> > configuration) at a higher directory level than specific
> > implementations.
> >
> > It would also lend itself more easily to adding implementations only
> > for specific services, and address the question of if a new top level
> > implementation directory needs to be created. For example, adding a
> > services/nova/nova-api-chef.yaml seems a lot less contentious than
> > adding a top level chef/services/nova-api.yaml.
> >
> > It'd also be nice if we had a way to mark the default within a given
> > service's directory. Perhaps services/nova/nova-api-default.yaml,
> > which would be a new template that just consumes the default? Or
> > perhaps a symlink, although it was pointed out symlinks don't work in
> > swift containers. Still, that could possibly be addressed in our plan
> > upload workflows. Then the resource-registry would point at
> > nova-api-default.yaml. One could easily tell which is the default
> > without having to cross reference with the resource-registry.
> >
>
> So since I'm adding a new ansible service, I thought I'd try and take
> a stab at this naming thing. I've taken James's idea and proposed an
> implementation here:
> https://review.openstack.org/#/c/588111/
>
> The idea would be that the THT code for the service deployment would
> end up in something like:
>
> deployment//-.yaml

A matter of preference but I can live with this.

>
> Additionally I took a stab at combining the puppet/docker service
> definitions for the aodh services in a similar structure to start
> reducing the overhead we've had from maintaining the docker/puppet
> implementations seperately.  You can see the patch
> https://review.openstack.org/#/c/611188/ for an additional example of
> this.
>
> Please let me know what you think.

I'm okay with it in that it consolidates some things (which we greatly
need to do). It does address my initial concern in that people are now
putting Ansible services into the puppet/services directory albeit a
bit heavy handed in that it changes everything (rather than just 

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Dan Prince]

On Thu, Oct 25, 2018 at 11:26 AM Alex Schultz  wrote:
>
> On Thu, Oct 25, 2018 at 9:16 AM Bogdan Dobrelya  wrote:
> >
> >
> > On 10/19/18 8:04 PM, Alex Schultz wrote:
> > > On Fri, Oct 19, 2018 at 10:53 AM James Slagle  
> > > wrote:
> > >>
> > >> On Wed, Oct 17, 2018 at 11:14 AM Alex Schultz  
> > >> wrote:
> > >> > Additionally I took a stab at combining the puppet/docker service
> > >> > definitions for the aodh services in a similar structure to start
> > >> > reducing the overhead we've had from maintaining the docker/puppet
> > >> > implementations seperately.  You can see the patch
> > >> > https://review.openstack.org/#/c/611188/ for an additional example of
> > >> > this.
> > >>
> > >> That patch takes the approach of removing baremetal support. Is that
> > >> what we agreed to do?
> > >>
> > >
> > > Since it's deprecated since Queens[0], yes? I think it is time to stop
> > > continuing this method of installation.  Given that I'm not even sure
> >
> > My point and concern retains as before, unless we fully dropped the
> > docker support for Queens (and downstream LTS released for it), we
> > should not modify the t-h-t directory tree, due to associated
> > maintenance of backports complexity reasons
> >
>
> This is why we have duplication of things in THT.  For environment
> files this is actually an issue due to the fact they are the end user
> interface. But these service files should be internal and where they
> live should not matter.  We already have had this in the past and have
> managed to continue to do backports so I don't think this as a reason
> not to do this clean up.  It feels like we use this as a reason not to
> actually move forward on cleanup and we end up carrying the tech debt.
> By this logic, we'll never be able to cleanup anything if we can't
> handle moving files around.

Yeah. The environment files would contain some level of duplication
until we refactor our plan storage mechanism to use a plain old
tarball (stored in Swift still) instead of storing files in the
expanded format. Swift does not support softlinks, but a tarball would
and thus would allow us to de-dup things in the future.

The patch is here but it needs some love:

https://review.openstack.org/#/c/581153/

Dan

>
> I think there are some patches to do soft links (dprince might be able
> to provide the patches) which could at least handle this backward
> compatibility around locations, but I think we need to actually move
> forward on the simplification of the service definitions unless
> there's a blocking technical issue with this effort.
>
> Thanks,
> -Alex
>
> > > the upgrade process even works anymore with baremetal, I don't think
> > > there's a reason to keep it as it directly impacts the time it takes
> > > to perform deployments and also contributes to increased complexity
> > > all around.
> > >
> > > [0] 
> > > http://lists.openstack.org/pipermail/openstack-dev/2017-September/122248.html
> > >
> > >> I'm not specifically opposed, as I'm pretty sure the baremetal
> > >> implementations are no longer tested anywhere, but I know that Dan had
> > >> some concerns about that last time around.
> > >>
> > >> The alternative we discussed was using jinja2 to include common
> > >> data/tasks in both the puppet/docker/ansible implementations. That
> > >> would also result in reducing the number of Heat resources in these
> > >> stacks and hopefully reduce the amount of time it takes to
> > >> create/update the ServiceChain stacks.
> > >>
> > >
> > > I'd rather we officially get rid of the one of the two methods and
> > > converge on a single method without increasing the complexity via
> > > jinja to continue to support both. If there's an improvement to be had
> > > after we've converged on a single structure for including the base
> > > bits, maybe we could do that then?
> > >
> > > Thanks,
> > > -Alex
> >
> >
> > --
> > Best regards,
> > Bogdan Dobrelya,
> > Irc #bogdando
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposal for a process to keep up with Python releases

[Zane Bitter]

On 25/10/18 1:38 PM, William M Edmonds wrote:

Zane Bitter  wrote on 10/22/2018 03:12:46 PM:
 > On 22/10/18 10:33 AM, Thomas Goirand wrote:
 > > On 10/19/18 5:17 PM, Zane Bitter wrote:



 > >> Integration Tests
 > >> -
 > >>
 > >> Integration tests do test, amongst other things, integration with
 > >> non-openstack-supplied things in the distro, so it's important that we
 > >> test on the actual distros we have identified as popular.[2] It's also
 > >> important that every project be testing on the same distro at the 
end of

 > >> a release, so we can be sure they all work together for users.
 > >
 > > I find very disturbing to see the project only leaning toward these 
only

 > > 2 distributions. Why not SuSE & Debian?
 >
 > The bottom line is it's because targeting those two catches 88% of our
 > users. (For once I did not make this statistic up.)
 >
 > Also note that in practice I believe almost everything is actually
 > tested on Ubuntu LTS, and only TripleO is testing on CentOS. It's
 > difficult to imagine how to slot another distro into the mix without
 > doubling up on jobs.

I think you meant 78%, assuming you were looking at the latest User 
Survey results [1], page 55. Still a hefty number.


I never know how to read those weird 3-way bar charts they have in the 
user survey, but that actually adds up to 91% by the looks of it (I 
believe you forgot to count RHEL). The numbers were actually slightly 
lower in the full-year data for 2017 that I used (from 
https://www.openstack.org/analytics - I can't give you a direct link 
because Javascript ).


It is important to note that the User Survey lumps all versions of a 
given OS together, whereas the TC reference [2] only considers the 
latest LTS/stable version. If the User Survey split out latests 
LTS/stable versions vs. others (e.g. Ubuntu 16.04 LTS), I expect we'd 
see Ubuntu 18.04 LTS + Centos 7 adding up to much less than 78%.


This is true, although we don't know by how much. (FWIW I can almost 
guarantee that virtually all of the CentOS/RHEL users are on 7, but I'm 
sure the same is not the case for Ubuntu 16.04.)



[1] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[2] 
https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[melanie witt]

On Thu, 25 Oct 2018 15:06:38 -0500, Matt Riedemann wrote:

On 10/25/2018 2:55 PM, Chris Friesen wrote:

2) The main benefit (as I see it) of the quota class API is to allow
dynamic adjustment of the default quotas without restarting services.


I could be making this up, but I want to say back at the Pike PTG people
were also complaining that not having an API to change this, and only do
it via config, was not good. But if the keystone limits API solves that
then it's a non-issue.


Right, the default limits are "registered limits" [1] in the keystone 
API. And "project limits" can be set to override "registered limits".


So the keystone limits API does solve that case.

-melanie

[1] 
https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html#registered-limits







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

On 10/25/2018 2:55 PM, Chris Friesen wrote:
2) The main benefit (as I see it) of the quota class API is to allow 
dynamic adjustment of the default quotas without restarting services.


I could be making this up, but I want to say back at the Pike PTG people 
were also complaining that not having an API to change this, and only do 
it via config, was not good. But if the keystone limits API solves that 
then it's a non-issue.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Friesen]

On 10/25/2018 12:00 PM, Jay Pipes wrote:

On 10/25/2018 01:38 PM, Chris Friesen wrote:

On 10/24/2018 9:10 AM, Jay Pipes wrote:
Nova's API has the ability to create "quota classes", which are 
basically limits for a set of resource types. There is something 
called the "default quota class" which corresponds to the limits in 
the CONF.quota section. Quota classes are basically templates of 
limits to be applied if the calling project doesn't have any stored 
project-specific limits.


Has anyone ever created a quota class that is different from "default"?


The Compute API specifically says:

"Only ‘default’ quota class is valid and used to set the default 
quotas, all other quota class would not be used anywhere."


What this API does provide is the ability to set new default quotas 
for *all* projects at once rather than individually specifying new 
defaults for each project.


It's a "defaults template", yes.


Chris, are you advocating for *keeping* the os-quota-classes API?


Nope.  I had two points:

1) It's kind of irrelevant whether anyone has created a quota class 
other than "default" because nova wouldn't use it anyways.


2) The main benefit (as I see it) of the quota class API is to allow 
dynamic adjustment of the default quotas without restarting services.


I totally agree that keystone limits should replace it.  I just didn't 
want the discussion to be focused on the non-default class portion 
because it doesn't matter.


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[melanie witt]

On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote:

On 10/25/2018 01:38 PM, Chris Friesen wrote:

On 10/24/2018 9:10 AM, Jay Pipes wrote:

Nova's API has the ability to create "quota classes", which are
basically limits for a set of resource types. There is something
called the "default quota class" which corresponds to the limits in
the CONF.quota section. Quota classes are basically templates of
limits to be applied if the calling project doesn't have any stored
project-specific limits.

Has anyone ever created a quota class that is different from "default"?


The Compute API specifically says:

"Only ‘default’ quota class is valid and used to set the default quotas,
all other quota class would not be used anywhere."

What this API does provide is the ability to set new default quotas for
*all* projects at once rather than individually specifying new defaults
for each project.


It's a "defaults template", yes.

The alternative is, you know, to just set the default values in
CONF.quota, which is what I said above. Or, if you want project X to
have different quota limits from those CONF-driven defaults, then set
the quotas for the project to some different values via the
os-quota-sets API (or better yet, just use Keystone's /limits API when
we write the "limits driver" into Nova). The issue is that the
os-quota-classes API is currently blocking *me* writing that "limits
driver" in Nova because I don't want to port nova-specific functionality
(like quota classes) to a limits driver when the Keystone /limits
endpoint doesn't have that functionality and nobody I know of has ever
used it.


When you say it's blocking you from writing the "limits driver" in nova, 
are you saying you're picking up John's unified limits spec [1]? It's 
been in -W mode and hasn't been updated in 4 weeks. In the spec, 
migration from quota classes => registered limits and deprecation of the 
existing quota API and quota classes is described.


Cheers,
-melanie

[1] https://review.openstack.org/602201




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

On 10/25/2018 01:38 PM, Chris Friesen wrote:

On 10/24/2018 9:10 AM, Jay Pipes wrote:
Nova's API has the ability to create "quota classes", which are 
basically limits for a set of resource types. There is something 
called the "default quota class" which corresponds to the limits in 
the CONF.quota section. Quota classes are basically templates of 
limits to be applied if the calling project doesn't have any stored 
project-specific limits.


Has anyone ever created a quota class that is different from "default"?


The Compute API specifically says:

"Only ‘default’ quota class is valid and used to set the default quotas, 
all other quota class would not be used anywhere."


What this API does provide is the ability to set new default quotas for 
*all* projects at once rather than individually specifying new defaults 
for each project.


It's a "defaults template", yes.

The alternative is, you know, to just set the default values in 
CONF.quota, which is what I said above. Or, if you want project X to 
have different quota limits from those CONF-driven defaults, then set 
the quotas for the project to some different values via the 
os-quota-sets API (or better yet, just use Keystone's /limits API when 
we write the "limits driver" into Nova). The issue is that the 
os-quota-classes API is currently blocking *me* writing that "limits 
driver" in Nova because I don't want to port nova-specific functionality 
(like quota classes) to a limits driver when the Keystone /limits 
endpoint doesn't have that functionality and nobody I know of has ever 
used it.


Chris, are you advocating for *keeping* the os-quota-classes API?

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Friesen]

On 10/24/2018 9:10 AM, Jay Pipes wrote:
Nova's API has the ability to create "quota classes", which are 
basically limits for a set of resource types. There is something called 
the "default quota class" which corresponds to the limits in the 
CONF.quota section. Quota classes are basically templates of limits to 
be applied if the calling project doesn't have any stored 
project-specific limits.


Has anyone ever created a quota class that is different from "default"?


The Compute API specifically says:

"Only ‘default’ quota class is valid and used to set the default quotas, 
all other quota class would not be used anywhere."


What this API does provide is the ability to set new default quotas for 
*all* projects at once rather than individually specifying new defaults 
for each project.


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposal for a process to keep up with Python releases

[William M Edmonds]

Zane Bitter  wrote on 10/22/2018 03:12:46 PM:
> On 22/10/18 10:33 AM, Thomas Goirand wrote:
> > On 10/19/18 5:17 PM, Zane Bitter wrote:



> >> Integration Tests
> >> -
> >>
> >> Integration tests do test, amongst other things, integration with
> >> non-openstack-supplied things in the distro, so it's important that we
> >> test on the actual distros we have identified as popular.[2] It's also
> >> important that every project be testing on the same distro at the end
of
> >> a release, so we can be sure they all work together for users.
> >
> > I find very disturbing to see the project only leaning toward these
only
> > 2 distributions. Why not SuSE & Debian?
>
> The bottom line is it's because targeting those two catches 88% of our
> users. (For once I did not make this statistic up.)
>
> Also note that in practice I believe almost everything is actually
> tested on Ubuntu LTS, and only TripleO is testing on CentOS. It's
> difficult to imagine how to slot another distro into the mix without
> doubling up on jobs.

I think you meant 78%, assuming you were looking at the latest User Survey
results [1], page 55. Still a hefty number.

It is important to note that the User Survey lumps all versions of a given
OS together, whereas the TC reference [2] only considers the latest
LTS/stable version. If the User Survey split out latests LTS/stable
versions vs. others (e.g. Ubuntu 16.04 LTS), I expect we'd see Ubuntu 18.04
LTS + Centos 7 adding up to much less than 78%.

[1] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[2]
https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo][openstack-ansible][nova][placement] Owners needed for placement extraction upgrade deployment tooling

[Matt Riedemann]

Hello OSA/TripleO people,

A plan/checklist was put in place at the Stein PTG for extracting 
placement from nova [1]. The first item in that list is done in grenade 
[2], which is the devstack-based upgrade project in the integrated gate. 
That should serve as a template for the necessary upgrade steps in 
deployment projects. The related devstack change for extracted placement 
on the master branch (Stein) is [3]. Note that change has some dependencies.


The second point in the plan from the PTG was getting extracted 
placement upgrade tooling support in a deployment project, notably 
TripleO (and/or OpenStackAnsible).


Given the grenade change is done and passing tests, TripleO/OSA should 
be able to start coding up and testing an upgrade step when going from 
Rocky to Stein. My question is who can we name as an owner in either 
project to start this work? Because we really need to be starting this 
as soon as possible to flush out any issues before they are too late to 
correct in Stein.


So if we have volunteers or better yet potential patches that I'm just 
not aware of, please speak up here so we know who to contact about 
status updates and if there are any questions with the upgrade.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html

[2] https://review.openstack.org/#/c/604454/
[3] https://review.openstack.org/#/c/600162/

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[William M Edmonds]

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
> > custom code in
> >
> > production which tracks the quota for such instances separately and for

> > the same reason
> >
> > we have *rich_instances* custom quota class same as *instances* quota
class.
>
> Please see the last reply I recently sent on this thread. I have been
> thinking the same as you about how we could use quota classes to
> implement the quota piece of preemptible instances. I think we can
> achieve the same thing using unified limits, specifically registered
> limits [1], which span across all projects. So, I think we are covered
> moving forward with migrating to unified limits and deprecation of quota
> classes. Let me know if you spot any issues with this idea.

And we could finally close https://bugs.launchpad.net/nova/+bug/1602396
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[William M Edmonds]

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
> > custom code in
> >
> > production which tracks the quota for such instances separately and for

> > the same reason
> >
> > we have *rich_instances* custom quota class same as *instances* quota
class.
>
> Please see the last reply I recently sent on this thread. I have been
> thinking the same as you about how we could use quota classes to
> implement the quota piece of preemptible instances. I think we can
> achieve the same thing using unified limits, specifically registered
> limits [1], which span across all projects. So, I think we are covered
> moving forward with migrating to unified limits and deprecation of quota
> classes. Let me know if you spot any issues with this idea.

And we could finally close https://bugs.launchpad.net/nova/+bug/1602396
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)

[Adam Spiers]

Hi Tim,

Tim Bell  wrote: 

Adam,

Personally, I would prefer the approach where the OpenStack resource agents are part of the repository in which they are used. 


Thanks for chipping in. 

Just checking - by this you mean the resource-agents rather than 
openstack-resource-agents, right?  Obviously the agents aren't usable 
as standalone components in either context, without a cloud's worth of 
dependencies including Pacemaker. 

This is also the approach taken in other open source projects such as Kubernetes and avoids the inconsistency where, for example, Azure resource agents are in the Cluster Labs repository but OpenStack ones are not. 


Right.  I suspect there's no clearly defined scope for the 
resource-agents repository at the moment, so it's probably hard to say 
"agent X belongs here but agent Y doesn't".  Although has been alluded 
to elsewhere in this thread, that in itself could be problematic in 
terms of the repository constantly growing. 

This can mean that people miss there is OpenStack integration available. 


Yes, discoverability is important, although I think we can make more 
impact on that via better documentation (another area I am struggling 
to make time for ...) 

This does not reflect, in any way, the excellent efforts and results made so far. I don't think it would negate the possibility to include testing in the OpenStack gate since there are other examples where code is pulled in from other sources. 


There are a number of technical barriers, or at very least 
inconveniences, here - because the resource-agents repository is 
hosted on GitHub, therefore none of the normal processes based around 
Gerrit apply.  I guess it's feasible that since Zuul v3 gained GitHub 
support, it could orchestrate running OpenStack CI on GitHub pull 
requests, although it would have to make sure to only run on PRs which 
affect the OpenStack RAs, and none of the others. 

Additionally, we'd probably need tags / releases corresponding to each 
OpenStack release, which means polluting a fundamentally 
non-OpenStack-specific repository with OpenStack-specific metadata. 

I think either way we go, there is ugliness.  Personally I'm still 
leaning towards continued use of openstack-resource-agents, but I'm 
happy to go with the majority consensus if we can get a 
semi-respectable number of respondees :-) 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Fox, Kevin M]

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

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? 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 tenant?)
>
> Thanks,
> Kevin
> 
> From: Florian Engelmann [florian.engelm...@everyware.ch]
> Sent: Thursday, October 25, 2018 7:39 AM
> To: openstack-operators@lists.openstack.org
> Subject: Re: [Openstack-operators] [octavia][rocky] Octavia and VxLAN without 
> DVR
>
> It looks like devstack implemented some o-hm0 interface to connect the
> physical control host to a VxLAN.
> In our case there is no VxLAN at the control nodes nor is OVS.
>
> Is it a option to deploy those Octavia services needing this conenction
> to the compute or network nodes and use o-hm0?
>
> Am 10/25/18 um 10:22 AM schrieb Florian Engelmann:
>> Or could I create lb-mgmt-net as VxLAN and connect the control nodes to
>> this VxLAN? How to do something like that?
>>
>> Am 10/25/18 um 10:03 AM schrieb Florian Engelmann:
>>> Hmm - so right now I can't see any routed option because:
>>>
>>> The gateway connected to the VLAN provider networks (bond1 on the
>>> network nodes) is not able to route any traffic to my control nodes in
>>> the spine-leaf layer3 backend network.
>>>
>>> And right now there is no br-ex at all nor any "streched" L2 domain
>>> connecting all compute nodes.
>>>
>>>
>>> So the only solution I can think of right now is to create an overlay
>>> VxLAN in the spine-leaf backend network, connect all compute and
>>> control nodes to this overlay L2 network, create a OVS bridge
>>> connected to that network on the compute nodes and allow the Amphorae
>>> to get an IPin this network as well.
>>> Not to forget about DHCP... so the network nodes will need this bridge
>>> as well.
>>>
>>> Am 10/24/18 um 10:01 PM schrieb Erik McCormick:


 On Wed, Oct 24, 2018, 3:33 PM Engelmann Florian
 >>> > wrote:

  On the network nodes we've got a dedicated interface to deploy VLANs
  (like the provider network for internet access). What about creating
  another VLAN on the network nodes, give that bridge a IP which is
  part of the subnet of lb-mgmt-net and start the octavia worker,
  healthmanager and controller on the network nodes binding to that
 IP?

 The problem with that is you can't out an IP in the vlan interface
 and also use it as an OVS bridge, so the Octavia processes would have
 nothing to bind to.


 
  *From:* Erik McCormick >>>  >
  *Sent:* Wednesday, October 24, 2018 6:18 PM
  *To:* Engelmann Florian
  *Cc:* openstack-operators
  *Subject:* Re: [Openstack-operators] [octavia][rocky] Octavia and
  VxLAN without DVR


  On Wed, Oct 24, 2018, 12:02 PM Florian Engelmann
  >>>  > wrote:

  Am 10/24/18 um 2:08 PM schrieb Erik McCormick:
   >
   >
   > On Wed, Oct 24, 2018, 3:14 AM Florian Engelmann
   > >>>  
  >>
   > wrote:
   >
   > Ohoh - thank you for your empathy :)
   > And those great details about how to setup this mgmt
 network.
   > I will try to do so this afternoon but solving that
  routing "puzzle"
   > (virtual network to control nodes) I will need our
  network guys to help
   > me out...
   >
   > But I will need to tell all Amphorae a static route to
  the gateway that
   > is routing to the control nodes?
   >
   >
   > Just set the default gateway when you create the neutron
  subnet. No need
   > for excess static routes. The route on the other connection
  won't
   > interfere with it as it lives in a namespace.

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

[Matt Riedemann]

On 10/24/2018 6:55 PM, Sam Morrison wrote:

I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still have the 
top level api cell DB but the API would only ever read from it. Nova-api would 
only write to the compute cell DBs.
Then keep the nova-cells processes just doing instance_update_at_top to keep 
the nova-cell-api db up to date.


There was also the "read from searchlight" idea [1] but that died in Boston.

[1] 
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/list-instances-using-searchlight.html


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] Where Monasca stores collected Data?

[Bedyk, Witold]

Hi Amal,

please check if you collect and persist the measurements correctly.
Check agent forwarder logs.
Check the logs of API, with DEBUG log level you should see all the messages 
sent to Kafka.
Check persister logs. You should see information about consuming messages from 
`metrics` topic.

Hope it helps
Witek

From: amal kammoun 
Sent: Donnerstag, 25. Oktober 2018 17:10
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Monasca] Where Monasca stores collected Data?

Hello Monasca team,

I'm experiencing several problems with monasca.
I have Monasca running with OpenStack.
I added alarms to my system but I cannot see where monasca stores the collected 
data.
With Grafana I cannot see any datapoints from the influxdb datasource.
In the influxdb I have all the tables with the measurments that monasca will 
collect but with no vlues.

How can I fix this problem?

Thank you!
Amal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Florian Engelmann]

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 tenant?)

Thanks,
Kevin

From: Florian Engelmann [florian.engelm...@everyware.ch]
Sent: Thursday, October 25, 2018 7:39 AM
To: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [octavia][rocky] Octavia and VxLAN without 
DVR

It looks like devstack implemented some o-hm0 interface to connect the
physical control host to a VxLAN.
In our case there is no VxLAN at the control nodes nor is OVS.

Is it a option to deploy those Octavia services needing this conenction
to the compute or network nodes and use o-hm0?

Am 10/25/18 um 10:22 AM schrieb Florian Engelmann:

Or could I create lb-mgmt-net as VxLAN and connect the control nodes to
this VxLAN? How to do something like that?

Am 10/25/18 um 10:03 AM schrieb Florian Engelmann:

Hmm - so right now I can't see any routed option because:

The gateway connected to the VLAN provider networks (bond1 on the
network nodes) is not able to route any traffic to my control nodes in
the spine-leaf layer3 backend network.

And right now there is no br-ex at all nor any "streched" L2 domain
connecting all compute nodes.


So the only solution I can think of right now is to create an overlay
VxLAN in the spine-leaf backend network, connect all compute and
control nodes to this overlay L2 network, create a OVS bridge
connected to that network on the compute nodes and allow the Amphorae
to get an IPin this network as well.
Not to forget about DHCP... so the network nodes will need this bridge
as well.

Am 10/24/18 um 10:01 PM schrieb Erik McCormick:



On Wed, Oct 24, 2018, 3:33 PM Engelmann Florian
mailto:florian.engelm...@everyware.ch>> wrote:

 On the network nodes we've got a dedicated interface to deploy VLANs
 (like the provider network for internet access). What about creating
 another VLAN on the network nodes, give that bridge a IP which is
 part of the subnet of lb-mgmt-net and start the octavia worker,
 healthmanager and controller on the network nodes binding to that
IP?

The problem with that is you can't out an IP in the vlan interface
and also use it as an OVS bridge, so the Octavia processes would have
nothing to bind to.



 *From:* Erik McCormick mailto:emccorm...@cirrusseven.com>>
 *Sent:* Wednesday, October 24, 2018 6:18 PM
 *To:* Engelmann Florian
 *Cc:* openstack-operators
 *Subject:* Re: [Openstack-operators] [octavia][rocky] Octavia and
 VxLAN without DVR


 On Wed, Oct 24, 2018, 12:02 PM Florian Engelmann
 mailto:florian.engelm...@everyware.ch>> wrote:

 Am 10/24/18 um 2:08 PM schrieb Erik McCormick:
  >
  >
  > On Wed, Oct 24, 2018, 3:14 AM Florian Engelmann
  > mailto:florian.engelm...@everyware.ch>
 >>
  > wrote:
  >
  > Ohoh - thank you for your empathy :)
  > And those great details about how to setup this mgmt
network.
  > I will try to do so this afternoon but solving that
 routing "puzzle"
  > (virtual network to control nodes) I will need our
 network guys to help
  > me out...
  >
  > But I will need to tell all Amphorae a static route to
 the gateway that
  > is routing to the control nodes?
  >
  >
  > Just set the default gateway when you create the neutron
 subnet. No need
  > for excess static routes. The route on the other connection
 won't
  > interfere with it as it lives in a namespace.


 My compute nodes have no br-ex and there is no L2 domain spread
 over all
 compute nodes. As far as I understood lb-mgmt-net is a provider
 network
 and has to be flat or VLAN and will need a "physical" gateway
 (as there
 is no virtual router).
 So the question - is it possible to get octavia up and running
 without a
 br-ex (L2 domain spread over all compute nodes) on the compute
 nodes?


 Sorry, I only meant it was *like* br-ex on your network nodes. You
 don't need that on your computes.

 The router here would be whatever does routing in your physical
 network. Setting the gateway in the neutron subnet simply adds that
 to the DHCP information sent to the amphorae.

 This does bring up another thingI forgot  though. You'll probably
 want to add the management network / bridge to your network nodes or
 wherever you run the DHCP agents. 

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

[Florian Engelmann]

I managed to configure o-hm0 on the compute nodes and I am able to 
communicate with the amphorae:



# create Octavia management net
openstack network create lb-mgmt-net -f value -c id
# and the subnet
openstack subnet create --subnet-range 172.31.0.0/16 --allocation-pool 
start=172.31.17.10,end=172.31.255.250 --network lb-mgmt-net lb-mgmt-subnet

# get the subnet ID
openstack subnet show lb-mgmt-subnet -f value -c id
# create a port in this subnet for the compute node (ewos1-com1a-poc2)
openstack port create --security-group octavia --device-owner 
Octavia:health-mgr --host=ewos1-com1a-poc2 -c id -f value --network 
lb-mgmt-net --fixed-ip 
subnet=b4c70178-949b-4d60-8d9f-09d13f720b6a,ip-address=172.31.0.101 
octavia-health-manager-ewos1-com1a-poc2-listen-port

openstack port show 6fb13c3f-469e-4a81-a504-a161c6848654
openstack network show lb-mgmt-net -f value -c id
# edit octavia_amp_boot_network_list: 3633be41-926f-4a2c-8803-36965f76ea8d
vi /etc/kolla/globals.yml
# reconfigure octavia
kolla-ansible -i inventory reconfigure -t octavia


# create o-hm0 on the compute node
docker exec ovs-vsctl -- --may-exist add-port br-int o-hm0 -- \
set Interface o-hm0 type=internal -- \
set Interface o-hm0 external-ids:iface-status=active -- \
set Interface o-hm0 external-ids:attached-mac=fa:16:3e:51:e9:c3 -- \
set Interface o-hm0 
external-ids:iface-id=6fb13c3f-469e-4a81-a504-a161c6848654 -- \

set Interface o-hm0 external-ids:skip_cleanup=true

# fix MAC of o-hm0
ip link set dev o-hm0 address fa:16:3e:51:e9:c3

# get IP from neutron DHCP agent (should get IP: 172.31.0.101 in this 
example)

ip link set dev o-hm0 up
dhclient -v o-hm0

# create a loadbalancer and test connectivity, eg. amphorae IP is 
172.31.17.15

root@ewos1-com1a-poc2:~# ping 172.31.17.15

But

octavia_worker
octavia_housekeeping
octavia_health_manager

are running on our control nodes and those are not running any OVS networks.

Next test is to deploy those three services to my network nodes and 
configure o-hm0 on the network nodes. I will have to fix


bind_port = 
bind_ip = 10.33.16.11
controller_ip_port_list = 10.33.16.11:

to bind to all IPs or the IP of o-hm0.





Am 10/25/18 um 4:39 PM schrieb Florian Engelmann:
It looks like devstack implemented some o-hm0 interface to connect the 
physical control host to a VxLAN.

In our case there is no VxLAN at the control nodes nor is OVS.

Is it a option to deploy those Octavia services needing this conenction 
to the compute or network nodes and use o-hm0?


Am 10/25/18 um 10:22 AM schrieb Florian Engelmann:
Or could I create lb-mgmt-net as VxLAN and connect the control nodes 
to this VxLAN? How to do something like that?


Am 10/25/18 um 10:03 AM schrieb Florian Engelmann:

Hmm - so right now I can't see any routed option because:

The gateway connected to the VLAN provider networks (bond1 on the 
network nodes) is not able to route any traffic to my control nodes 
in the spine-leaf layer3 backend network.


And right now there is no br-ex at all nor any "streched" L2 domain 
connecting all compute nodes.



So the only solution I can think of right now is to create an overlay 
VxLAN in the spine-leaf backend network, connect all compute and 
control nodes to this overlay L2 network, create a OVS bridge 
connected to that network on the compute nodes and allow the Amphorae 
to get an IPin this network as well.
Not to forget about DHCP... so the network nodes will need this 
bridge as well.


Am 10/24/18 um 10:01 PM schrieb Erik McCormick:



On Wed, Oct 24, 2018, 3:33 PM Engelmann Florian 
> wrote:


    On the network nodes we've got a dedicated interface to deploy 
VLANs
    (like the provider network for internet access). What about 
creating

    another VLAN on the network nodes, give that bridge a IP which is
    part of the subnet of lb-mgmt-net and start the octavia worker,
    healthmanager and controller on the network nodes binding to 
that IP?


The problem with that is you can't out an IP in the vlan interface 
and also use it as an OVS bridge, so the Octavia processes would 
have nothing to bind to.



 


    *From:* Erik McCormick mailto:emccorm...@cirrusseven.com>>
    *Sent:* Wednesday, October 24, 2018 6:18 PM
    *To:* Engelmann Florian
    *Cc:* openstack-operators
    *Subject:* Re: [Openstack-operators] [octavia][rocky] Octavia and
    VxLAN without DVR


    On Wed, Oct 24, 2018, 12:02 PM Florian Engelmann
    mailto:florian.engelm...@everyware.ch>> wrote:

    Am 10/24/18 um 2:08 PM schrieb Erik McCormick:
 >
 >
 > On Wed, Oct 24, 2018, 3:14 AM Florian Engelmann
 > mailto:florian.engelm...@everyware.ch>
    >>
 > wrote:
 >
 >     Ohoh - thank you for your empathy :)
 >     And those great details about 

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

[Fox, Kevin M]

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: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [octavia][rocky] Octavia and VxLAN without 
DVR

It looks like devstack implemented some o-hm0 interface to connect the
physical control host to a VxLAN.
In our case there is no VxLAN at the control nodes nor is OVS.

Is it a option to deploy those Octavia services needing this conenction
to the compute or network nodes and use o-hm0?

Am 10/25/18 um 10:22 AM schrieb Florian Engelmann:
> Or could I create lb-mgmt-net as VxLAN and connect the control nodes to
> this VxLAN? How to do something like that?
>
> Am 10/25/18 um 10:03 AM schrieb Florian Engelmann:
>> Hmm - so right now I can't see any routed option because:
>>
>> The gateway connected to the VLAN provider networks (bond1 on the
>> network nodes) is not able to route any traffic to my control nodes in
>> the spine-leaf layer3 backend network.
>>
>> And right now there is no br-ex at all nor any "streched" L2 domain
>> connecting all compute nodes.
>>
>>
>> So the only solution I can think of right now is to create an overlay
>> VxLAN in the spine-leaf backend network, connect all compute and
>> control nodes to this overlay L2 network, create a OVS bridge
>> connected to that network on the compute nodes and allow the Amphorae
>> to get an IPin this network as well.
>> Not to forget about DHCP... so the network nodes will need this bridge
>> as well.
>>
>> Am 10/24/18 um 10:01 PM schrieb Erik McCormick:
>>>
>>>
>>> On Wed, Oct 24, 2018, 3:33 PM Engelmann Florian
>>> >> > wrote:
>>>
>>> On the network nodes we've got a dedicated interface to deploy VLANs
>>> (like the provider network for internet access). What about creating
>>> another VLAN on the network nodes, give that bridge a IP which is
>>> part of the subnet of lb-mgmt-net and start the octavia worker,
>>> healthmanager and controller on the network nodes binding to that
>>> IP?
>>>
>>> The problem with that is you can't out an IP in the vlan interface
>>> and also use it as an OVS bridge, so the Octavia processes would have
>>> nothing to bind to.
>>>
>>>
>>> 
>>> *From:* Erik McCormick >> >
>>> *Sent:* Wednesday, October 24, 2018 6:18 PM
>>> *To:* Engelmann Florian
>>> *Cc:* openstack-operators
>>> *Subject:* Re: [Openstack-operators] [octavia][rocky] Octavia and
>>> VxLAN without DVR
>>>
>>>
>>> On Wed, Oct 24, 2018, 12:02 PM Florian Engelmann
>>> >> > wrote:
>>>
>>> Am 10/24/18 um 2:08 PM schrieb Erik McCormick:
>>>  >
>>>  >
>>>  > On Wed, Oct 24, 2018, 3:14 AM Florian Engelmann
>>>  > >> 
>>> >> >>
>>>  > wrote:
>>>  >
>>>  > Ohoh - thank you for your empathy :)
>>>  > And those great details about how to setup this mgmt
>>> network.
>>>  > I will try to do so this afternoon but solving that
>>> routing "puzzle"
>>>  > (virtual network to control nodes) I will need our
>>> network guys to help
>>>  > me out...
>>>  >
>>>  > But I will need to tell all Amphorae a static route to
>>> the gateway that
>>>  > is routing to the control nodes?
>>>  >
>>>  >
>>>  > Just set the default gateway when you create the neutron
>>> subnet. No need
>>>  > for excess static routes. The route on the other connection
>>> won't
>>>  > interfere with it as it lives in a namespace.
>>>
>>>
>>> My compute nodes have no br-ex and there is no L2 domain spread
>>> over all
>>> compute nodes. As far as I understood lb-mgmt-net is a provider
>>> network
>>> and has to be flat or VLAN and will need a "physical" gateway
>>> (as there
>>> is no virtual router).
>>> So the question - is it possible to get octavia up and running
>>> without a
>>> br-ex (L2 domain spread over all compute nodes) on the compute
>>> nodes?
>>>
>>>
>>> Sorry, I only meant it was *like* br-ex on your network nodes. You
>>> don't need that on your computes.
>>>
>>> The router here would be whatever does routing in your physical
>>> network. Setting the gateway in the neutron subnet simply adds that
>>> to the DHCP information sent to the amphorae.
>>>
>>> This does bring up another thingI 

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Alex Schultz]

On Thu, Oct 25, 2018 at 9:16 AM Bogdan Dobrelya  wrote:
>
>
> On 10/19/18 8:04 PM, Alex Schultz wrote:
> > On Fri, Oct 19, 2018 at 10:53 AM James Slagle  
> > wrote:
> >>
> >> On Wed, Oct 17, 2018 at 11:14 AM Alex Schultz  
> >> wrote:
> >> > Additionally I took a stab at combining the puppet/docker service
> >> > definitions for the aodh services in a similar structure to start
> >> > reducing the overhead we've had from maintaining the docker/puppet
> >> > implementations seperately.  You can see the patch
> >> > https://review.openstack.org/#/c/611188/ for an additional example of
> >> > this.
> >>
> >> That patch takes the approach of removing baremetal support. Is that
> >> what we agreed to do?
> >>
> >
> > Since it's deprecated since Queens[0], yes? I think it is time to stop
> > continuing this method of installation.  Given that I'm not even sure
>
> My point and concern retains as before, unless we fully dropped the
> docker support for Queens (and downstream LTS released for it), we
> should not modify the t-h-t directory tree, due to associated
> maintenance of backports complexity reasons
>

This is why we have duplication of things in THT.  For environment
files this is actually an issue due to the fact they are the end user
interface. But these service files should be internal and where they
live should not matter.  We already have had this in the past and have
managed to continue to do backports so I don't think this as a reason
not to do this clean up.  It feels like we use this as a reason not to
actually move forward on cleanup and we end up carrying the tech debt.
By this logic, we'll never be able to cleanup anything if we can't
handle moving files around.

I think there are some patches to do soft links (dprince might be able
to provide the patches) which could at least handle this backward
compatibility around locations, but I think we need to actually move
forward on the simplification of the service definitions unless
there's a blocking technical issue with this effort.

Thanks,
-Alex

> > the upgrade process even works anymore with baremetal, I don't think
> > there's a reason to keep it as it directly impacts the time it takes
> > to perform deployments and also contributes to increased complexity
> > all around.
> >
> > [0] 
> > http://lists.openstack.org/pipermail/openstack-dev/2017-September/122248.html
> >
> >> I'm not specifically opposed, as I'm pretty sure the baremetal
> >> implementations are no longer tested anywhere, but I know that Dan had
> >> some concerns about that last time around.
> >>
> >> The alternative we discussed was using jinja2 to include common
> >> data/tasks in both the puppet/docker/ansible implementations. That
> >> would also result in reducing the number of Heat resources in these
> >> stacks and hopefully reduce the amount of time it takes to
> >> create/update the ServiceChain stacks.
> >>
> >
> > I'd rather we officially get rid of the one of the two methods and
> > converge on a single method without increasing the complexity via
> > jinja to continue to support both. If there's an improvement to be had
> > after we've converged on a single structure for including the base
> > bits, maybe we could do that then?
> >
> > Thanks,
> > -Alex
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Bogdan Dobrelya]

On 10/19/18 8:04 PM, Alex Schultz wrote:

On Fri, Oct 19, 2018 at 10:53 AM James Slagle  wrote:


On Wed, Oct 17, 2018 at 11:14 AM Alex Schultz  wrote:
> Additionally I took a stab at combining the puppet/docker service
> definitions for the aodh services in a similar structure to start
> reducing the overhead we've had from maintaining the docker/puppet
> implementations seperately.  You can see the patch
> https://review.openstack.org/#/c/611188/ for an additional example of
> this.

That patch takes the approach of removing baremetal support. Is that
what we agreed to do?



Since it's deprecated since Queens[0], yes? I think it is time to stop
continuing this method of installation.  Given that I'm not even sure


My point and concern retains as before, unless we fully dropped the 
docker support for Queens (and downstream LTS released for it), we 
should not modify the t-h-t directory tree, due to associated 
maintenance of backports complexity reasons



the upgrade process even works anymore with baremetal, I don't think
there's a reason to keep it as it directly impacts the time it takes
to perform deployments and also contributes to increased complexity
all around.

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122248.html


I'm not specifically opposed, as I'm pretty sure the baremetal
implementations are no longer tested anywhere, but I know that Dan had
some concerns about that last time around.

The alternative we discussed was using jinja2 to include common
data/tasks in both the puppet/docker/ansible implementations. That
would also result in reducing the number of Heat resources in these
stacks and hopefully reduce the amount of time it takes to
create/update the ServiceChain stacks.



I'd rather we officially get rid of the one of the two methods and
converge on a single method without increasing the complexity via
jinja to continue to support both. If there's an improvement to be had
after we've converged on a single structure for including the base
bits, maybe we could do that then?

Thanks,
-Alex



--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Where Monasca stores collected Data?

[amal kammoun]

Hello Monasca team,

I'm experiencing several problems with monasca.
I have Monasca running with OpenStack.
I added alarms to my system but I cannot see where monasca stores the
collected data.
With Grafana I cannot see any datapoints from the influxdb datasource.
In the influxdb I have all the tables with the measurments that monasca
will collect but with no vlues.

How can I fix this problem?

Thank you!
Amal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

[Dan Smith]

> I guess our architecture is pretty unique in a way but I wonder if
> other people are also a little scared about the whole all DB servers
> need to up to serve API requests?

When we started down this path, we acknowledged that this would create a
different access pattern which would require ops to treat the cell
databases differently. The input we were getting at the time was that
the benefits outweighed the costs here, and that we'd work on caching to
deal with performance issues if/when that became necessary.

> I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still
> have the top level api cell DB but the API would only ever read from
> it. Nova-api would only write to the compute cell DBs.
> Then keep the nova-cells processes just doing instance_update_at_top to keep 
> the nova-cell-api db up to date.

I'm definitely not in favor of doing more replication in python to
address this. What was there in cellsv1 was lossy, even for the subset
of things it actually supported (which didn't cover all nova features at
the time and hasn't kept pace with features added since, obviously).

About a year ago, I proposed that we add another "read only mirror"
field to the cell mapping, which nova would use if and only if the
primary cell database wasn't reachable, and only for read
operations. The ops, if they wanted to use this, would configure plain
old one-way mysql replication of the cell databases to a
highly-available server (probably wherever the api_db is) and nova could
use that as a read-only cache for things like listing instances and
calculating quotas. The reaction was (very surprisingly to me) negative
to this option. It seems very low-effort, high-gain, and proper re-use
of existing technologies to me, without us having to replicate a
replication engine (hah) in python. So, I'm curious: does that sound
more palatable to you?

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Florian Engelmann]

It looks like devstack implemented some o-hm0 interface to connect the 
physical control host to a VxLAN.

In our case there is no VxLAN at the control nodes nor is OVS.

Is it a option to deploy those Octavia services needing this conenction 
to the compute or network nodes and use o-hm0?


Am 10/25/18 um 10:22 AM schrieb Florian Engelmann:
Or could I create lb-mgmt-net as VxLAN and connect the control nodes to 
this VxLAN? How to do something like that?


Am 10/25/18 um 10:03 AM schrieb Florian Engelmann:

Hmm - so right now I can't see any routed option because:

The gateway connected to the VLAN provider networks (bond1 on the 
network nodes) is not able to route any traffic to my control nodes in 
the spine-leaf layer3 backend network.


And right now there is no br-ex at all nor any "streched" L2 domain 
connecting all compute nodes.



So the only solution I can think of right now is to create an overlay 
VxLAN in the spine-leaf backend network, connect all compute and 
control nodes to this overlay L2 network, create a OVS bridge 
connected to that network on the compute nodes and allow the Amphorae 
to get an IPin this network as well.
Not to forget about DHCP... so the network nodes will need this bridge 
as well.


Am 10/24/18 um 10:01 PM schrieb Erik McCormick:



On Wed, Oct 24, 2018, 3:33 PM Engelmann Florian 
> wrote:


    On the network nodes we've got a dedicated interface to deploy VLANs
    (like the provider network for internet access). What about creating
    another VLAN on the network nodes, give that bridge a IP which is
    part of the subnet of lb-mgmt-net and start the octavia worker,
    healthmanager and controller on the network nodes binding to that 
IP?


The problem with that is you can't out an IP in the vlan interface 
and also use it as an OVS bridge, so the Octavia processes would have 
nothing to bind to.




    *From:* Erik McCormick mailto:emccorm...@cirrusseven.com>>
    *Sent:* Wednesday, October 24, 2018 6:18 PM
    *To:* Engelmann Florian
    *Cc:* openstack-operators
    *Subject:* Re: [Openstack-operators] [octavia][rocky] Octavia and
    VxLAN without DVR


    On Wed, Oct 24, 2018, 12:02 PM Florian Engelmann
    mailto:florian.engelm...@everyware.ch>> wrote:

    Am 10/24/18 um 2:08 PM schrieb Erik McCormick:
 >
 >
 > On Wed, Oct 24, 2018, 3:14 AM Florian Engelmann
 > mailto:florian.engelm...@everyware.ch>
    >>
 > wrote:
 >
 >     Ohoh - thank you for your empathy :)
 >     And those great details about how to setup this mgmt 
network.

 >     I will try to do so this afternoon but solving that
    routing "puzzle"
 >     (virtual network to control nodes) I will need our
    network guys to help
 >     me out...
 >
 >     But I will need to tell all Amphorae a static route to
    the gateway that
 >     is routing to the control nodes?
 >
 >
 > Just set the default gateway when you create the neutron
    subnet. No need
 > for excess static routes. The route on the other connection
    won't
 > interfere with it as it lives in a namespace.


    My compute nodes have no br-ex and there is no L2 domain spread
    over all
    compute nodes. As far as I understood lb-mgmt-net is a provider
    network
    and has to be flat or VLAN and will need a "physical" gateway
    (as there
    is no virtual router).
    So the question - is it possible to get octavia up and running
    without a
    br-ex (L2 domain spread over all compute nodes) on the compute
    nodes?


    Sorry, I only meant it was *like* br-ex on your network nodes. You
    don't need that on your computes.

    The router here would be whatever does routing in your physical
    network. Setting the gateway in the neutron subnet simply adds that
    to the DHCP information sent to the amphorae.

    This does bring up another thingI forgot  though. You'll probably
    want to add the management network / bridge to your network nodes or
    wherever you run the DHCP agents. When you create the subnet, be
    sure to leave some space in the address scope for the physical
    devices with static IPs.

    As for multiple L2 domains, I can't think of a way to go about that
    for the lb-mgmt network. It's a single network with a single subnet.
    Perhaps you could limit load balancers to an AZ in a single rack?
    Seems not very HA friendly.



 >
 >
 >
 >     Am 10/23/18 um 6:57 PM schrieb Erik McCormick:
 >      > So in your other email you said asked if there was a
    guide for
 >      > deploying it with Kolla ansible...
  

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

[Tobias Urdin]

Might as well throw it out here.

After a lot of troubleshooting we were able to narrow our issue down to 
our test environment running qemu virtualization, we moved our compute 
node to hardware and

used kvm full virtualization instead.

We could properly reproduce the issue where generating a CSR from a 
private key and then trying to verify the CSR would fail complaining about

"Signature did not match the certificate request"

We suspect qemu floating point emulation caused this, the same OpenSSL 
function that validates a CSR is the one used when validating the SSL 
handshake which caused our issue.
After going through the whole stack, we have Octavia working flawlessly 
without any issues at all.


Best regards
Tobias

On 10/23/2018 04:31 PM, Tobias Urdin wrote:

Hello Erik,

Could you specify the DNs you used for all certificates just so that I
can rule it out on my side.
You can redact anything sensitive with some to just get the feel on how
it's configured.

Best regards
Tobias

On 10/22/2018 04:47 PM, Erik McCormick wrote:

On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin  wrote:

Hello,

I've been having a lot of issues with SSL certificates myself, on my
second trip now trying to get it working.

Before I spent a lot of time walking through every line in the DevStack
plugin and fixing my config options, used the generate
script [1] and still it didn't work.

When I got the "invalid padding" issue it was because of the DN I used
for the CA and the certificate IIRC.

   > 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
   > 19:47 < tobias-urdin> after a quick google "The problem was that my
CA DN was the same as the certificate DN."

IIRC I think that solved it, but then again I wouldn't remember fully
since I've been at so many different angles by now.

Here is my IRC logs history from the #openstack-lbaas channel, perhaps
it can help you out
http://paste.openstack.org/show/732575/


Tobias, I owe you a beer. This was precisely the issue. I'm deploying
Octavia with kolla-ansible. It only deploys a single CA. After hacking
the templates and playbook to incorporate a separate server CA, the
amphorae now load and provision the required namespace. I'm adding a
kolla tag to the subject of this in hopes that someone might want to
take on changing this behavior in the project. Hopefully after I get
through Upstream Institute in Berlin I'll be able to do it myself if
nobody else wants to do it.

For certificate generation, I extracted the contents of
octavia_certs_install.yml (which sets up the directory structure,
openssl.cnf, and the client CA), and octavia_certs.yml (which creates
the server CA and the client certificate) and mashed them into a
separate playbook just for this purpose. At the end I get:

ca_01.pem - Client CA Certificate
ca_01.key - Client CA Key
ca_server_01.pem - Server CA Certificate
cakey.pem - Server CA Key
client.pem - Concatenated Client Key and Certificate

If it would help to have the playbook, I can stick it up on github
with a huge "This is a hack" disclaimer on it.


-

Sorry for hijacking the thread but I'm stuck as well.

I've in the past tried to generate the certificates with [1] but now
moved on to using the openstack-ansible way of generating them [2]
with some modifications.

Right now I'm just getting: Could not connect to instance. Retrying.:
SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
from the amphoras, haven't got any further but I've eliminated a lot of
stuck in the middle.

Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
wasn't an issue with CentOS and OpenSSL versions since it tends to lag
behind.
Checking the amphora with openssl s_client [3] it gives the same one,
but the verification is successful just that I don't understand what the
bad signature
part is about, from browsing some OpenSSL code it seems to be related to
RSA signatures somehow.

140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad
signature:s3_clnt.c:2032:

So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS
(openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm
back to something related
to the certificates or the communication between the endpoints, or what
actually responds inside the amphora (gunicorn IIUC?). Based on the
"verify" functions actually causing that bad signature error I would
assume it's the generated certificate that the amphora presents that is
causing it.

I'll have to continue the troubleshooting to the inside of the amphora,
I've used the test-only amphora image before but have now built my own
one that is
using the amphora-agent from the actual 

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

[Tobias Urdin]

Might as well throw it out here.

After a lot of troubleshooting we were able to narrow our issue down to 
our test environment running qemu virtualization, we moved our compute 
node to hardware and

used kvm full virtualization instead.

We could properly reproduce the issue where generating a CSR from a 
private key and then trying to verify the CSR would fail complaining about

"Signature did not match the certificate request"

We suspect qemu floating point emulation caused this, the same OpenSSL 
function that validates a CSR is the one used when validating the SSL 
handshake which caused our issue.
After going through the whole stack, we have Octavia working flawlessly 
without any issues at all.


Best regards
Tobias

On 10/23/2018 04:31 PM, Tobias Urdin wrote:

Hello Erik,

Could you specify the DNs you used for all certificates just so that I
can rule it out on my side.
You can redact anything sensitive with some to just get the feel on how
it's configured.

Best regards
Tobias

On 10/22/2018 04:47 PM, Erik McCormick wrote:

On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin  wrote:

Hello,

I've been having a lot of issues with SSL certificates myself, on my
second trip now trying to get it working.

Before I spent a lot of time walking through every line in the DevStack
plugin and fixing my config options, used the generate
script [1] and still it didn't work.

When I got the "invalid padding" issue it was because of the DN I used
for the CA and the certificate IIRC.

   > 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
   > 19:47 < tobias-urdin> after a quick google "The problem was that my
CA DN was the same as the certificate DN."

IIRC I think that solved it, but then again I wouldn't remember fully
since I've been at so many different angles by now.

Here is my IRC logs history from the #openstack-lbaas channel, perhaps
it can help you out
http://paste.openstack.org/show/732575/


Tobias, I owe you a beer. This was precisely the issue. I'm deploying
Octavia with kolla-ansible. It only deploys a single CA. After hacking
the templates and playbook to incorporate a separate server CA, the
amphorae now load and provision the required namespace. I'm adding a
kolla tag to the subject of this in hopes that someone might want to
take on changing this behavior in the project. Hopefully after I get
through Upstream Institute in Berlin I'll be able to do it myself if
nobody else wants to do it.

For certificate generation, I extracted the contents of
octavia_certs_install.yml (which sets up the directory structure,
openssl.cnf, and the client CA), and octavia_certs.yml (which creates
the server CA and the client certificate) and mashed them into a
separate playbook just for this purpose. At the end I get:

ca_01.pem - Client CA Certificate
ca_01.key - Client CA Key
ca_server_01.pem - Server CA Certificate
cakey.pem - Server CA Key
client.pem - Concatenated Client Key and Certificate

If it would help to have the playbook, I can stick it up on github
with a huge "This is a hack" disclaimer on it.


-

Sorry for hijacking the thread but I'm stuck as well.

I've in the past tried to generate the certificates with [1] but now
moved on to using the openstack-ansible way of generating them [2]
with some modifications.

Right now I'm just getting: Could not connect to instance. Retrying.:
SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
from the amphoras, haven't got any further but I've eliminated a lot of
stuck in the middle.

Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
wasn't an issue with CentOS and OpenSSL versions since it tends to lag
behind.
Checking the amphora with openssl s_client [3] it gives the same one,
but the verification is successful just that I don't understand what the
bad signature
part is about, from browsing some OpenSSL code it seems to be related to
RSA signatures somehow.

140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad
signature:s3_clnt.c:2032:

So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS
(openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm
back to something related
to the certificates or the communication between the endpoints, or what
actually responds inside the amphora (gunicorn IIUC?). Based on the
"verify" functions actually causing that bad signature error I would
assume it's the generated certificate that the amphora presents that is
causing it.

I'll have to continue the troubleshooting to the inside of the amphora,
I've used the test-only amphora image before but have now built my own
one that is
using the amphora-agent from the actual 

[Openstack] Server names vs. DNS: Can I restrict server names to match a regex?

[Andrew Bogott]

    A fair bit of my setup uses service names for automatic naming 
elsewhere.  For example, we have NFS mounts like /path/to/ 
and automatic DNS like .example.org


    Of course, if a user is determined to to create a less useful 
instance, they can create one with a name like ""  or "../../.." 
which will result in hilarity.


    I'm sure that I'm not the only one who regards a server name as 
useful for naming other resources.  What solutions do you use? Is there 
a way to tell nova or Horizon to restrict server names to a given pattern?



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [barbican][tc] Seeking feedback on the OpenStack cloud vision

[Dave McCowan (dmccowan)]

Hello Zane--
   Yes, this vision is consistent with the Barbican team's vision.

   Barbican provides an abstraction layer over HSMs and other secret
storage services.  We have a plugin architecture to enable this
abstraction over a variety of backends.  Vault is a recent addition to our
supported options.  Barbican uses Keystone for authentication and
oslo.policy for RBAC, which allows for multi-tenancy and makes secret
storage consistent with other OpenStack services.

   The topic of cross-project dependencies is one we've been wrestling
with for a while.  At the Pike PTG[1], we had discussions with the
Architecture Working Group on how to address this.  We concluded that the
cross-project requirement should not be on Barbican, but on a "Castellan
compatible secret store".  At the time, Barbican was the only choice, but
we wanted to encourage new development.

  We shifted ownership of Castellan (a python key manager abstraction
layer) from the Barbican team to the Oslo team.  The idea was that people
would write Castellan plugins for key managers other than Barbican.  Later
that year, a Castellan plugin for Vault was contributed.[2]  At this time,
the direct-to-vault plugin does not use Keystone for authentication or
oslo.policy for RBAC.  Users can configure the Barbican-to-Vault
architecture if they need to meet those requirements.
   
tl;dr: This vision looks good.  The Castellan and Barbican software
provides abstraction for either the key storage or the key manager, so the
cross project dependency can be "a key manager", instead of specifically
Barbican.

--Dave


[1] https://etherpad.openstack.org/p/barbican-pike-ptg-barbican-discussion
[2] https://review.openstack.org/#/c/483080/


On 10/24/18, 11:16 AM, "Zane Bitter"  wrote:

>Greetings, Barbican team!
>As you may be aware, I've been working with other folks in the community
>on documenting a vision for OpenStack clouds (formerly known as the
>'Technical Vision') - essentially to interpret the mission statement in
>long-form, in a way that we can use to actually help guide decisions.
>You can read the latest draft here: https://review.openstack.org/592205
>
>We're trying to get feedback from as many people as possible - in many
>ways the value is in the process of coming together to figure out what
>we're trying to achieve as a community with OpenStack and how we can
>work together to build it. The document is there to help us remember
>what we decided so we don't have to do it all again over and over.
>
>The vision is structured with two sections that apply broadly to every
>project in OpenStack - describing the principles that we believe are
>essential to every cloud, and the ones that make OpenStack different
>from some other clouds. The third section is a list of design goals that
>we want OpenStack as a whole to be able to meet - ideally each project
>would be contributing toward one or more of these design goals.
>
>Barbican provides an abstraction over HSMs and software equivalents
>(like Vault), so the immediate design goal that it meets is the
>'Hardware Virtualisation' one. However, the most interesting part of the
>document for the Barbican team is probably the section on cross-project
>dependencies. In discussions at the PTG, the TC concluded that we
>shouldn't force projects to adopt hard dependencies on other services
>(like Barbican), but recommend that they do so when there is a benefit
>to the user. The challenge here I think is that not duplicating
>security-sensitive code such as secret storage is well known to be
>something that is both of great benefit to the user and highly tempting
>to take a shortcut on. Your feedback on whether we have got the right
>balance is important.
>
>If you would like me or another TC member to join one of your team IRC
>meetings to discuss further what the vision means for your team, please
>reply to this thread to set it up. You are also welcome to bring up any
>questions in the TC IRC channel, #openstack-tc - there's more of us
>around during Office Hours
>(https://governance.openstack.org/tc/#office-hours), but you can talk to
>us at any time.
>
>Feedback can also happen either in this thread or on the review
>https://review.openstack.org/592205
>
>If the team is generally happy with the vision as it is and doesn't have
>any specific feedback, that's cool but I'd like to request that at least
>the PTL leave a vote on the review. It's important to know whether we
>are actually developing a consensus in the community or just talking to
>ourselves :)
>
>many thanks,
>Zane.
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)

[Openstack] [Pike][Neutron] L3 metering with DVR doesn't work

[Alexandru Sorodoc]

Hello,

I'm trying to set up metering for neutron in Pike. I tested it with a
centralized router and it works, but when I try with a distributed router it
doesn't record any usage samples. I have one compute node and one 
network node

and I've created an instance with a floating ip.

openstack router show public-router2
+-++
| Field   | 
Value  |

+-++
| admin_state_up  | 
UP |
| availability_zone_hints 
|    |
| availability_zones  | 
nova   |
| created_at  | 
2018-10-05T12:07:32Z   |

| description |    |
| distributed | 
True   |
| external_gateway_info   | {"network_id": 
"b96473ce-  |
| | 94f6-464f-a703-5285fb8ff3d3", "enable_snat": 
true, |
| | "external_fixed_ips": 
[{"subnet_id":   |
| | 
"6c08c3d9-7df1-4bec-b847-19f80b9d1764",    |
| | "ip_address": 
"192.168.252.102"}]} |
| flavor_id   | 
None   |
| ha  | 
False  |
| id  | 
37c1794b-58d1-4d0d-b34b-944ca411b86b   |
| name    | 
public-router2 |
| project_id  | 
fe203109e67f4e39b066c9529f9fc35d   |
| revision_number | 
5  |

| routes |    |
| status  | 
ACTIVE |

| tags |    |
| updated_at  | 
2018-10-05T12:09:36Z   |

+-++

openstack network agent list
+---++---+---+---+---+--+
| ID    | Agent Type | Host  | Availability Zone | Alive | State 
| Binary   |

+---++---+---+---+---+--+
| 14b9ea75- | L3 agent   | compute1. | nova | :-)   | UP    | neutron-l3-a |
| 1dc1-4e37 |    | localdoma | |   |   | gent |
| -a2b0-508 |    | in    | |   |   |  |
| 3d336916d |    |   | |   |   |  |
| 26139ec1- | Metering   | compute1. | None | :-)   | UP    | neutron- |
| f4f9-4bb3 | agent  | localdoma | |   |   | metering-    |
| -aebb-c35 |    | in    | |   |   | agent    |
| 3a36ed79c |    |   | |   |   |  |
| 2a54971f- | DHCP agent | network1. | nova | :-)   | UP    | neutron- |
| 9849-4ed2 |    | localdoma | |   |   | dhcp-agent   |
| -b009-00e |    | in    | |   |   |  |
| 45eb4d255 |    |   | |   |   |  |
| 443c0b49- | Open   | compute1. | None | :-)   | UP    | neutron- |
| 4484-44d2 | vSwitch    | localdoma | |   |   | openvswitch- |
| -a704-32a | agent  | in    | |   |   | agent    |
| 92ffe6982 |    |   | |   |   |  |
| 5d00a219  | L3 agent   | network1. | nova | :-)   | UP    | neutron-vpn- |
| -abce-    |    | localdoma | |   |   | agent    |
| 48ca- |    | in    | |   |   |  |
| ba1e-d962 |    |   | |   |   |  |
| 01bd7de3  |    |   | |   |   |  |
| bc3458b4  | Open   | network1. | None | :-)   | UP    | neutron- |
| -250e-    | vSwitch    | localdoma | |   |   | openvswitch- |
| 4adf-90e0 | agent  | in    | |   |   | agent    |
| -110a1a7f |    |   | |   |   |  |
| 6ccb  |    |   | |   |   |  |
| c29f9da8- | Metering   | network1. | None | :-)   | UP    | neutron- |
| ca58-4a11 | agent  | localdoma | |   |   | metering-    |
| -b500-a25 |    | in    | |   |   | agent    |
| 3f820808e |    |   | |   |   |  |
| cdce667d- | Metadata   | network1. | None | :-)   | UP    | neutron- |
| faa4  | agent  | localdoma | |   |   | metadata-    |
| -49ed-    |    | 

[Openstack] Working on a Android app for Openstack client

[Adrián Campos Garrido]

Hello,

Since months agos, I am working on a Openstack Client application for Android 
whose objective is to managa your own openstack cloud or you instances if your 
are a client from a Openstack Cloud Provider.

Last version was 0.7 and i think that basic bugs for connection and starting 
manage is fixed.
In fact in last version the changelog is:

Fix problem with AUTH on new releases.
Fix instances hostname for users without permissions.
Fix all problems when there isn't any data.
Re-desing interface to use all screen.
Change some logo to use Openstack logo instead of stars logo.

It's a fork from an old project which it's called stackerz, I made some 
arrangements on login to adapt it for new Keystone V3 and some improvements on 
calls to certain Openstack API calls.

I would like to to ask to list if you see an useful project to continue or 
maybe not.

https://play.google.com/store/apps/details?id=com.alefnode.openstack=en_US

Regards,
Adrian Campos

[https://lh3.googleusercontent.com/XBT2ArGBP5nAbG0RRySrJPcv-koCPYgxfHzDeeUVgcMKG9x8ZuYHdByQGGY71Yjifw]

Openstack Client - Apps on Google 
Play
Openstack client for Android. Tested on Openstack Queens (2018.02) and 
Openstack Pike (2017.08) With this application you can manage all your 
openstack platform. - Servers - Networks - Subnets - Security Groups - Flavors 
This is a beta release and only for Keystone V3 authentication.
play.google.com


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova][NFS] Inexplicable utime permission denied when launching instance

[Neil Jerram]

I'm still seeing the same problem after disabling AppArmor, so I think
it must be some other root problem.

On Wed, Oct 24, 2018 at 2:41 PM Neil Jerram  wrote:
>
> Thanks so much for these hints, Erlon.  I will look closer at AppArmor.
>
> Neil
>
> On Wed, Oct 24, 2018 at 1:41 PM Erlon Cruz  wrote:
> >
> > PS. Don't forget that if you change or disable AppArmor you will have to 
> > reboot the host so the kernel gets reloaded.
> >
> > Em qua, 24 de out de 2018 às 09:40, Erlon Cruz  
> > escreveu:
> >>
> >> I think that there's a change that AppArmor is blocking the access. Have 
> >> you checked the dmesg messages related with apparmor?
> >>
> >> Em sex, 19 de out de 2018 às 09:38, Neil Jerram  escreveu:
> >>>
> >>> Wracking my brains over this one, would appreciate any pointers...
> >>>
> >>> Setup: Small test deployment with just 3 compute nodes, Queens on Ubuntu 
> >>> Bionic. The first compute node is an NFS server for 
> >>> /var/lib/nova/instances, and the other compute nodes mount that as NFS 
> >>> clients.
> >>>
> >>> Problem: Sometimes, when launching an instance which is scheduled to one 
> >>> of the client nodes, nova-compute (in imagebackend.py) gets Permission 
> >>> Denied (errno 13) when calling utime to touch the timestamp on the 
> >>> instance file.
> >>>
> >>> Through various bits of debugging and hackery, I've established that:
> >>>
> >>> - it looks like the problem never occurs when this is the call that 
> >>> bootstraps the privsep setup; but it does occur quite frequently on later 
> >>> calls
> >>>
> >>> - when the problem occurs, retrying doesn't help (5 times, with 0.5s in 
> >>> between)
> >>>
> >>> - the instance file does exist, and is owned by root with read/write 
> >>> permission for root
> >>>
> >>> - the privsep helper is running as root
> >>>
> >>> - the privsep helper receives and executes the request - so it's not a 
> >>> problem with communication between nova-compute and the helper
> >>>
> >>> - root is uid 0 on both NFS server and client
> >>>
> >>> - NFS setup does not have the root_squash option
> >>>
> >>> - there is some AppArmor setup, on both client and server, and I haven't 
> >>> yet worked out whether that might be relevant.
> >>>
> >>> Any ideas?
> >>>
> >>> Many thanks,
> >>>   Neil
> >>>
> >>> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Searchlight] Team meeting today reminder

[Trinh Nguyen]

Hi team,

It's a kindly reminder that we will have the team meeting at 12:00 UTC
today on #openstack-meeting-4 channel.

Hope to see you there :)

-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][OVN] Switching the default network backend to ML2/OVN

[Miguel Angel Ajo Pelayo]

Daniel, thank you very much for the extensive and detailed email.

The plan looks good to me and it makes sense, also the OVS option will
still be
tested, and available when selected.



On Wed, Oct 24, 2018 at 4:41 PM Daniel Alvarez Sanchez 
wrote:

> Hi Stackers!
>
> The purpose of this email is to share with the community the intention
> of switching the default network backend in TripleO from ML2/OVS to
> ML2/OVN by changing the mechanism driver from openvswitch to ovn. This
> doesn’t mean that ML2/OVS will be dropped but users deploying
> OpenStack without explicitly specifying a network driver will get
> ML2/OVN by default.
>
> OVN in Short
> ==
>
> Open Virtual Network is managed under the OVS project, and was created
> by the original authors of OVS. It is an attempt to re-do the ML2/OVS
> control plane, using lessons learned throughout the years. It is
> intended to be used in projects such as OpenStack and Kubernetes.


Also oVirt / RHEV.


> OVN
> has a different architecture, moving us away from Python agents
> communicating with the Neutron API service via RabbitMQ to daemons
> written in C communicating via OpenFlow and OVSDB.
>
> OVN is built with a modern architecture that offers better foundations
> for a simpler and more performant solution. What does this mean? For
> example, at Red Hat we executed some preliminary testing during the
> Queens cycle and found significant CPU savings due to OVN not using
> RabbitMQ (CPU utilization during a Rally scenario using ML2/OVS [0] or
> ML2/OVN [1]). Also, we tested API performance and found out that most
> of the operations are significantly faster with ML2/OVN. Please see
> more details in the FAQ section.
>
> Here’s a few useful links about OpenStack’s integration of OVN:
>
> * OpenStack Boston Summit talk on OVN [2]
> * OpenStack networking-ovn documentation [3]
> * OpenStack networking-ovn code repository [4]
>
> How?
> 
>
> The goal is to merge this patch [5] during the Stein cycle which
> pursues the following actions:
>
> 1. Switch the default mechanism driver from openvswitch to ovn.
> 2. Adapt all jobs so that they use ML2/OVN as the network backend.
> 3. Create legacy environment file for ML2/OVS to allow deployments based
> on it.
> 4. Flip scenario007 job from ML2/OVN to ML2/OVS so that we continue
> testing it.
> 5. Continue using ML2/OVS in the undercloud.
> 6. Ensure that updates/upgrades from ML2/OVS don’t break and don’t
> switch automatically to the new default. As some parity gaps exist
> right now, we don’t want to change the network backend automatically.
> Instead, if the user wants to migrate from ML2/OVS to ML2/OVN, we’ll
> provide an ansible based tool that will perform the operation.
> More info and code at [6].
>
> Reviews, comments and suggestions are really appreciated :)
>
>
> FAQ
> ===
>
> Can you talk about the advantages of OVN over ML2/OVS?
>
> ---
>
> If asked to describe the ML2/OVS control plane (OVS, L3, DHCP and
> metadata agents using the messaging bus to sync with the Neutron API
> service) one would not tend to use the term ‘simple’. There is liberal
> use of a smattering of Linux networking technologies such as:
> * iptables
> * network namespaces
> * ARP manipulation
> * Different forms of NAT
> * keepalived, radvd, haproxy, dnsmasq
> * Source based routing,
> * … and of course OVS flows.
>
> OVN simplifies this to a single process running on compute nodes, and
> another process running on centralized nodes, communicating via OVSDB
> and OpenFlow, ultimately setting OVS flows.
>
> The simplified, new architecture allows us to re-do features like DVR
> and L3 HA in more efficient and elegant ways. For example, L3 HA
> failover is faster: It doesn’t use keepalived, rather OVN monitors
> neighbor tunnel endpoints. OVN supports enabling both DVR and L3 HA
> simultaneously, something we never supported with ML2/OVS.
>
> We also found out that not depending on RPC messages for agents
> communication brings a lot of benefits. From our experience, RabbitMQ
> sometimes represents a bottleneck and it can be very intense when it
> comes to resources utilization.
>
>
> What about the undercloud?
> --
>
> ML2/OVS will be still used in the undercloud as OVN has some
> limitations with regards to baremetal provisioning mainly (keep
> reading about the parity gaps). We aim to convert the undercloud to
> ML2/OVN to provide the operator a more consistent experience as soon
> as possible.
>
> It would be possible however to use the Neutron DHCP agent in the
> short term to solve this limitation but in the long term we intend to
> implement support for baremetal provisioning in the OVN built-in DHCP
> server.
>
>
> What about CI?
> -
>
> * networking-ovn has:
> * Devstack based Tempest (API, scenario from Tempest and Neutron
> Tempest plugin) against the latest released OVS 

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

[Boxiang Zhu]

Great, Jon. Thanks for your reply. I am looking forward to your report.


Cheers,
Boxiang
On 10/23/2018 22:01，Jon Bernard wrote：
* melanie witt  wrote:
On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote:
I created a new vm and a new volume with type 'ceph'[So that the volume
will be created on one of two hosts. I assume that the volume created on
host dev@rbd-1#ceph this time]. Next step is to attach the volume to the
vm. At last I want to migrate the volume from host dev@rbd-1#ceph to
host dev@rbd-2#ceph, but it failed with the exception
'NotImplementedError(_("Swap only supports host devices")'.

So that, my real problem is that is there any work to migrate
volume(*in-use*)(*ceph rbd*) from one host(pool) to another host(pool)
in the same ceph cluster?
The difference between the spec[2] with my scope is only one is
*available*(the spec) and another is *in-use*(my scope).


[1] http://docs.ceph.com/docs/master/rbd/rbd-openstack/
[2] https://review.openstack.org/#/c/296150

Ah, I think I understand now, thank you for providing all of those details.
And I think you explained it in your first email, that cinder supports
migration of ceph volumes if they are 'available' but not if they are
'in-use'. Apologies that I didn't get your meaning the first time.

I see now the code you were referring to is this [3]:

if volume.status not in ('available', 'retyping', 'maintenance'):
LOG.debug('Only available volumes can be migrated using backend '
'assisted migration. Falling back to generic migration.')
return refuse_to_migrate

So because your volume is not 'available', 'retyping', or 'maintenance',
it's falling back to generic migration, which will end up with an error in
nova because the source_path is not set in the volume config.

Can anyone from the cinder team chime in about whether the ceph volume
migration could be expanded to allow migration of 'in-use' volumes? Is there
a reason not to allow migration of 'in-use' volumes?

Generally speaking, Nova must facilitate the migration of a live (or
in-use) volume.  A volume attached to a running instance requires code
in the I/O path to correctly route traffic to the correct location - so
Cinder must refuse (or defer) a migrate operation if the volume is
attached.  Until somewhat recently Qemu and Libvirt did not support the
migration to non-block (RBD) targets which is the reason for lack of
support.  I believe we now have all of the pieces to perform this
operation successfully, but I suspect it will require a setup with
correct versions of all the related software.  I will try to verify this
during the current release cycle and report back.

--
Jon


[3] 
https://github.com/openstack/cinder/blob/c42fdc470223d27850627fd4fc9d8cb15f2941f8/cinder/volume/drivers/rbd.py#L1618-L1621

Cheers,
-melanie






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [publiccloud-wg] Reminder weekly meeting Public Cloud WG

[Tobias Rydberg]

Hi everyone,

Time for a new meeting for PCWG - today 1400 UTC in 
#openstack-publiccloud! Agenda found at 
https://etherpad.openstack.org/p/publiccloud-wg


Cheers,
Tobias

--
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [publiccloud-wg] Reminder weekly meeting Public Cloud WG

[Tobias Rydberg]

Hi everyone,

Time for a new meeting for PCWG - today 1400 UTC in 
#openstack-publiccloud! Agenda found at 
https://etherpad.openstack.org/p/publiccloud-wg


Cheers,
Tobias

--
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Florian Engelmann]

Or could I create lb-mgmt-net as VxLAN and connect the control nodes to 
this VxLAN? How to do something like that?


Am 10/25/18 um 10:03 AM schrieb Florian Engelmann:

Hmm - so right now I can't see any routed option because:

The gateway connected to the VLAN provider networks (bond1 on the 
network nodes) is not able to route any traffic to my control nodes in 
the spine-leaf layer3 backend network.


And right now there is no br-ex at all nor any "streched" L2 domain 
connecting all compute nodes.



So the only solution I can think of right now is to create an overlay 
VxLAN in the spine-leaf backend network, connect all compute and control 
nodes to this overlay L2 network, create a OVS bridge connected to that 
network on the compute nodes and allow the Amphorae to get an IPin this 
network as well.
Not to forget about DHCP... so the network nodes will need this bridge 
as well.


Am 10/24/18 um 10:01 PM schrieb Erik McCormick:



On Wed, Oct 24, 2018, 3:33 PM Engelmann Florian 
> wrote:


    On the network nodes we've got a dedicated interface to deploy VLANs
    (like the provider network for internet access). What about creating
    another VLAN on the network nodes, give that bridge a IP which is
    part of the subnet of lb-mgmt-net and start the octavia worker,
    healthmanager and controller on the network nodes binding to that IP?

The problem with that is you can't out an IP in the vlan interface and 
also use it as an OVS bridge, so the Octavia processes would have 
nothing to bind to.






    *From:* Erik McCormick mailto:emccorm...@cirrusseven.com>>
    *Sent:* Wednesday, October 24, 2018 6:18 PM
    *To:* Engelmann Florian
    *Cc:* openstack-operators
    *Subject:* Re: [Openstack-operators] [octavia][rocky] Octavia and
    VxLAN without DVR


    On Wed, Oct 24, 2018, 12:02 PM Florian Engelmann
    mailto:florian.engelm...@everyware.ch>> wrote:

    Am 10/24/18 um 2:08 PM schrieb Erik McCormick:
 >
 >
 > On Wed, Oct 24, 2018, 3:14 AM Florian Engelmann
 > mailto:florian.engelm...@everyware.ch>
    >>
 > wrote:
 >
 >     Ohoh - thank you for your empathy :)
 >     And those great details about how to setup this mgmt 
network.

 >     I will try to do so this afternoon but solving that
    routing "puzzle"
 >     (virtual network to control nodes) I will need our
    network guys to help
 >     me out...
 >
 >     But I will need to tell all Amphorae a static route to
    the gateway that
 >     is routing to the control nodes?
 >
 >
 > Just set the default gateway when you create the neutron
    subnet. No need
 > for excess static routes. The route on the other connection
    won't
 > interfere with it as it lives in a namespace.


    My compute nodes have no br-ex and there is no L2 domain spread
    over all
    compute nodes. As far as I understood lb-mgmt-net is a provider
    network
    and has to be flat or VLAN and will need a "physical" gateway
    (as there
    is no virtual router).
    So the question - is it possible to get octavia up and running
    without a
    br-ex (L2 domain spread over all compute nodes) on the compute
    nodes?


    Sorry, I only meant it was *like* br-ex on your network nodes. You
    don't need that on your computes.

    The router here would be whatever does routing in your physical
    network. Setting the gateway in the neutron subnet simply adds that
    to the DHCP information sent to the amphorae.

    This does bring up another thingI forgot  though. You'll probably
    want to add the management network / bridge to your network nodes or
    wherever you run the DHCP agents. When you create the subnet, be
    sure to leave some space in the address scope for the physical
    devices with static IPs.

    As for multiple L2 domains, I can't think of a way to go about that
    for the lb-mgmt network. It's a single network with a single subnet.
    Perhaps you could limit load balancers to an AZ in a single rack?
    Seems not very HA friendly.



 >
 >
 >
 >     Am 10/23/18 um 6:57 PM schrieb Erik McCormick:
 >      > So in your other email you said asked if there was a
    guide for
 >      > deploying it with Kolla ansible...
 >      >
 >      > Oh boy. No there's not. I don't know if you've seen my
    recent
 >     mails on
 >      > Octavia, but I am going through this deployment
    process with
 >      > kolla-ansible right now and it is lacking in a few 
areas.

 >      >
 >      > If you 

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

[Florian Engelmann]

Hmm - so right now I can't see any routed option because:

The gateway connected to the VLAN provider networks (bond1 on the 
network nodes) is not able to route any traffic to my control nodes in 
the spine-leaf layer3 backend network.


And right now there is no br-ex at all nor any "streched" L2 domain 
connecting all compute nodes.



So the only solution I can think of right now is to create an overlay 
VxLAN in the spine-leaf backend network, connect all compute and control 
nodes to this overlay L2 network, create a OVS bridge connected to that 
network on the compute nodes and allow the Amphorae to get an IPin this 
network as well.
Not to forget about DHCP... so the network nodes will need this bridge 
as well.


Am 10/24/18 um 10:01 PM schrieb Erik McCormick:



On Wed, Oct 24, 2018, 3:33 PM Engelmann Florian 
mailto:florian.engelm...@everyware.ch>> 
wrote:


On the network nodes we've got a dedicated interface to deploy VLANs
(like the provider network for internet access). What about creating
another VLAN on the network nodes, give that bridge a IP which is
part of the subnet of lb-mgmt-net and start the octavia worker,
healthmanager and controller on the network nodes binding to that IP?

The problem with that is you can't out an IP in the vlan interface and 
also use it as an OVS bridge, so the Octavia processes would have 
nothing to bind to.




*From:* Erik McCormick mailto:emccorm...@cirrusseven.com>>
*Sent:* Wednesday, October 24, 2018 6:18 PM
*To:* Engelmann Florian
*Cc:* openstack-operators
*Subject:* Re: [Openstack-operators] [octavia][rocky] Octavia and
VxLAN without DVR


On Wed, Oct 24, 2018, 12:02 PM Florian Engelmann
mailto:florian.engelm...@everyware.ch>> wrote:

Am 10/24/18 um 2:08 PM schrieb Erik McCormick:
 >
 >
 > On Wed, Oct 24, 2018, 3:14 AM Florian Engelmann
 > mailto:florian.engelm...@everyware.ch>
>>
 > wrote:
 >
 >     Ohoh - thank you for your empathy :)
 >     And those great details about how to setup this mgmt network.
 >     I will try to do so this afternoon but solving that
routing "puzzle"
 >     (virtual network to control nodes) I will need our
network guys to help
 >     me out...
 >
 >     But I will need to tell all Amphorae a static route to
the gateway that
 >     is routing to the control nodes?
 >
 >
 > Just set the default gateway when you create the neutron
subnet. No need
 > for excess static routes. The route on the other connection
won't
 > interfere with it as it lives in a namespace.


My compute nodes have no br-ex and there is no L2 domain spread
over all
compute nodes. As far as I understood lb-mgmt-net is a provider
network
and has to be flat or VLAN and will need a "physical" gateway
(as there
is no virtual router).
So the question - is it possible to get octavia up and running
without a
br-ex (L2 domain spread over all compute nodes) on the compute
nodes?


Sorry, I only meant it was *like* br-ex on your network nodes. You
don't need that on your computes.

The router here would be whatever does routing in your physical
network. Setting the gateway in the neutron subnet simply adds that
to the DHCP information sent to the amphorae.

This does bring up another thingI forgot  though. You'll probably
want to add the management network / bridge to your network nodes or
wherever you run the DHCP agents. When you create the subnet, be
sure to leave some space in the address scope for the physical
devices with static IPs.

As for multiple L2 domains, I can't think of a way to go about that
for the lb-mgmt network. It's a single network with a single subnet.
Perhaps you could limit load balancers to an AZ in a single rack?
Seems not very HA friendly.



 >
 >
 >
 >     Am 10/23/18 um 6:57 PM schrieb Erik McCormick:
 >      > So in your other email you said asked if there was a
guide for
 >      > deploying it with Kolla ansible...
 >      >
 >      > Oh boy. No there's not. I don't know if you've seen my
recent
 >     mails on
 >      > Octavia, but I am going through this deployment
process with
 >      > kolla-ansible right now and it is lacking in a few areas.
 >      >
 >      > If you plan to use different CA certificates for
client and server in
 >      > Octavia, you'll need to add that into the playbook.
Presently it only
 >  

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

[melanie witt]

On Thu, 25 Oct 2018 10:55:15 +1100, Sam Morrison wrote:




On 24 Oct 2018, at 4:01 pm, melanie witt  wrote:

On Wed, 24 Oct 2018 10:54:31 +1100, Sam Morrison wrote:

Hi nova devs,
Have been having a good look into cellsv2 and how we migrate to them (we’re 
still on cellsv1 and about to upgrade to queens and still run cells v1 for now).
One of the problems I have is that now all our nova cell database servers need 
to respond to API requests.
With cellsv1 our architecture was to have a big powerful DB cluster (3 physical 
servers) at the API level to handle the API cell and then a smallish non HA DB 
server (usually just a VM) for each of the compute cells.
This architecture won’t work with cells V2 and we’ll now need to have a lot of 
highly available and responsive DB servers for all the cells.
It will also mean that our nova-apis which reside in Melbourne, Australia will 
now need to talk to database servers in Auckland, New Zealand.
The biggest issue we have is when a cell is down. We sometimes have cells go 
down for an hour or so planned or unplanned and with cellsv1 this does not 
affect other cells.
Looks like some good work going on here 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/handling-down-cell
But what about quota? If a cell goes down then it would seem that a user all of 
a sudden would regain some quota from the instances that are in the down cell?
Just wondering if anyone has thought about this?


Yes, we've discussed it quite a bit. The current plan is to offer a policy-driven 
behavior as part of the "down" cell handling which will control whether nova 
will:

a) Reject a server create request if the user owns instances in "down" cells

b) Go ahead and count quota usage "as-is" if the user owns instances in "down" 
cells and allow quota limit to be potentially exceeded

We would like to know if you think this plan will work for you.

Further down the road, if we're able to come to an agreement on a consumer 
type/owner or partitioning concept in placement (to be certain we are counting 
usage our instance of nova owns, as placement is a shared service), we could 
count quota usage from placement instead of querying cells.


OK great, always good to know other people are thinking for you :-) , I don’t 
really like a or b but the idea about using placement sounds like a good one to 
me.


Your honesty is appreciated. :) We do want to get to where we can use 
placement for quota usage. There is a significant amount of higher 
priority placement-related work in flight right now (getting nested 
resource providers working end-to-end, for one) for it to receive 
adequate attention at this moment. We've been discussing it on the spec 
[1] the past few days, if you're interested.



I guess our architecture is pretty unique in a way but I wonder if other people 
are also a little scared about the whole all DB servers need to up to serve API 
requests?


You are not alone. At CERN, they are experiencing the same challenges. 
They too have an architecture where they had deployed less powerful 
database servers in cells and also have cell sites that are located 
geographically far away. They have been driving the "handling of a down 
cell" work.



I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still have the 
top level api cell DB but the API would only ever read from it. Nova-api would 
only write to the compute cell DBs.
Then keep the nova-cells processes just doing instance_update_at_top to keep 
the nova-cell-api db up to date.

We’d still have syncing issues but we have that with placement now and that is 
more frequent than nova-cells-v1 is for us.


I have had similar thoughts, but keep ending up at the syncing/racing 
issues, like you said. I think it's something we'll need to discuss and 
explore more, to see if we can come up with a reasonable way to address 
the increased demand on cell databases as it's been a considerable pain 
point for deployments like yours and CERN's.


Cheers,
-melanie

[1] https://review.openstack.org/509042


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[melanie witt]

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 
custom code in


production which tracks the quota for such instances separately and for 
the same reason


we have *rich_instances* custom quota class same as *instances* quota class.


Please see the last reply I recently sent on this thread. I have been 
thinking the same as you about how we could use quota classes to 
implement the quota piece of preemptible instances. I think we can 
achieve the same thing using unified limits, specifically registered 
limits [1], which span across all projects. So, I think we are covered 
moving forward with migrating to unified limits and deprecation of quota 
classes. Let me know if you spot any issues with this idea.


Cheers,
-melanie

[1] 
https://developer.openstack.org/api-ref/identity/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-registered-limits





___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[melanie witt]

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 
custom code in


production which tracks the quota for such instances separately and for 
the same reason


we have *rich_instances* custom quota class same as *instances* quota class.


Please see the last reply I recently sent on this thread. I have been 
thinking the same as you about how we could use quota classes to 
implement the quota piece of preemptible instances. I think we can 
achieve the same thing using unified limits, specifically registered 
limits [1], which span across all projects. So, I think we are covered 
moving forward with migrating to unified limits and deprecation of quota 
classes. Let me know if you spot any issues with this idea.


Cheers,
-melanie

[1] 
https://developer.openstack.org/api-ref/identity/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-registered-limits





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[melanie witt]

On Wed, 24 Oct 2018 12:54:00 -0700, Melanie Witt wrote:

On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote:

On 10/24/2018 10:10 AM, Jay Pipes wrote:

I'd like to propose deprecating this API and getting rid of this
functionality since it conflicts with the new Keystone /limits endpoint,
is highly coupled with RAX's turnstile middleware and I can't seem to
find anyone who has ever used it. Deprecating this API and functionality
would make the transition to a saner quota management system much easier
and straightforward.

I was trying to do this before it was cool:

https://review.openstack.org/#/c/411035/

I think it was the Pike PTG in ATL where people said, "meh, let's just
wait for unified limits from keystone and let this rot on the vine".

I'd be happy to restore and update that spec.


Yeah, we were thinking the presence of the API and code isn't harming
anything and sometimes we talk about situations where we could use them.

Quota classes come up occasionally whenever we talk about preemptible
instances. Example: we could create and use a quota class "preemptible"
and decorate preemptible flavors with that quota_class in order to give
them unlimited quota. There's also talk of quota classes in the "Count
quota based on resource class" spec [1] where we could have leveraged
quota classes to create and enforce quota limits per custom resource
class. But I think the consensus there was to hold off on quota by
custom resource class until we migrate to unified limits and oslo.limit.

So, I think my concern in removing the internal code that is capable of
enforcing quota limit per quota class is the preemptible instance use
case. I don't have my mind wrapped around if/how we could solve it using
unified limits yet.

And I was just thinking, if we added a project_id column to the
quota_classes table and correspondingly added it to the
os-quota-class-sets API, we could pretty simply implement quota by
flavor, which is a feature operators like Oath need. An operator could
create a quota class limit per project_id and then decorate flavors with
quota_class to enforce them per flavor.

I recognize that maybe it would be too confusing to solve use cases with
quota classes given that we're going to migrate to united limits. At the
same time, I'm hesitant to close the door on a possibility before we
have some idea about how we'll solve them without quota classes. Has
anyone thought about how we can solve the use cases with unified limits
for things like preemptible instances and quota by flavor?

[1] https://review.openstack.org/56901


After I sent this, I realized that I _have_ thought about how to solve 
these use cases with unified limits before and commented about it on the 
"Count quota based on resource class" spec some months ago.


For preemptible instances, we could leverage registered limits in 
keystone [2] (registered limits span across all projects) by creating a 
limit with resource_name='preemptible', for example. Then we could 
decorate a flavor with quota_resource_name='preemptible' which would 
designate a preemptible instance type. Then we use the 
quota_resource_name from the flavor to check the quota for the 
corresponding registered limit in keystone. This way, preemptible 
instances can be assigned their own special quota (probably unlimited).


And for quota by flavor, same concept. I think we could use registered 
limits and project limits [3] by creating limits with 
resource_name='flavorX', for example. We could decorate flavors with 
quota_resource_name='flavorX' and check quota for special quota for flavorX.


Unified limits provide all of the same ability as quota classes, as far 
as I can tell. Given that, I think we are OK to deprecate quota classes.


Cheers,
-melanie

[2] 
https://developer.openstack.org/api-ref/identity/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-registered-limits
[3] 
https://developer.openstack.org/api-ref/identit/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-limits





___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[melanie witt]

On Wed, 24 Oct 2018 12:54:00 -0700, Melanie Witt wrote:

On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote:

On 10/24/2018 10:10 AM, Jay Pipes wrote:

I'd like to propose deprecating this API and getting rid of this
functionality since it conflicts with the new Keystone /limits endpoint,
is highly coupled with RAX's turnstile middleware and I can't seem to
find anyone who has ever used it. Deprecating this API and functionality
would make the transition to a saner quota management system much easier
and straightforward.

I was trying to do this before it was cool:

https://review.openstack.org/#/c/411035/

I think it was the Pike PTG in ATL where people said, "meh, let's just
wait for unified limits from keystone and let this rot on the vine".

I'd be happy to restore and update that spec.


Yeah, we were thinking the presence of the API and code isn't harming
anything and sometimes we talk about situations where we could use them.

Quota classes come up occasionally whenever we talk about preemptible
instances. Example: we could create and use a quota class "preemptible"
and decorate preemptible flavors with that quota_class in order to give
them unlimited quota. There's also talk of quota classes in the "Count
quota based on resource class" spec [1] where we could have leveraged
quota classes to create and enforce quota limits per custom resource
class. But I think the consensus there was to hold off on quota by
custom resource class until we migrate to unified limits and oslo.limit.

So, I think my concern in removing the internal code that is capable of
enforcing quota limit per quota class is the preemptible instance use
case. I don't have my mind wrapped around if/how we could solve it using
unified limits yet.

And I was just thinking, if we added a project_id column to the
quota_classes table and correspondingly added it to the
os-quota-class-sets API, we could pretty simply implement quota by
flavor, which is a feature operators like Oath need. An operator could
create a quota class limit per project_id and then decorate flavors with
quota_class to enforce them per flavor.

I recognize that maybe it would be too confusing to solve use cases with
quota classes given that we're going to migrate to united limits. At the
same time, I'm hesitant to close the door on a possibility before we
have some idea about how we'll solve them without quota classes. Has
anyone thought about how we can solve the use cases with unified limits
for things like preemptible instances and quota by flavor?

[1] https://review.openstack.org/56901


After I sent this, I realized that I _have_ thought about how to solve 
these use cases with unified limits before and commented about it on the 
"Count quota based on resource class" spec some months ago.


For preemptible instances, we could leverage registered limits in 
keystone [2] (registered limits span across all projects) by creating a 
limit with resource_name='preemptible', for example. Then we could 
decorate a flavor with quota_resource_name='preemptible' which would 
designate a preemptible instance type. Then we use the 
quota_resource_name from the flavor to check the quota for the 
corresponding registered limit in keystone. This way, preemptible 
instances can be assigned their own special quota (probably unlimited).


And for quota by flavor, same concept. I think we could use registered 
limits and project limits [3] by creating limits with 
resource_name='flavorX', for example. We could decorate flavors with 
quota_resource_name='flavorX' and check quota for special quota for flavorX.


Unified limits provide all of the same ability as quota classes, as far 
as I can tell. Given that, I think we are OK to deprecate quota classes.


Cheers,
-melanie

[2] 
https://developer.openstack.org/api-ref/identity/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-registered-limits
[3] 
https://developer.openstack.org/api-ref/identit/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-limits





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev