Re: [openstack-dev] [kolla] [requirements] Stepping down as core reviewer
On Tue, Oct 16, 2018 at 06:03:54PM +0530, ʂʍɒρƞįł Ҟưȴķɒʁʉɨ wrote: > Dear OpenStackers, > > For a few months now, I am not able to contribute to code or reviewing > Kolla and Requirements actively given my current responsibilities, I > would like to take a step back and release my core reviewer ability > for the Kolla and Requirements repositories. Swapnil, I'm sorry to see you go. It was a blast working with you and your generous nature. Safe travels and great luck with your path takes you. Yours Tony. signature.asc Description: PGP signature __ 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] [horizon][plugins] Horizon plugins validation on CI
On Wed, Oct 17, 2018 at 04:18:26PM +0300, Ivan Kolodyazhny wrote: > Hi all, > > We discussed this topic at PTG both with Horizon and other teams. Sounds > like everybody is interested to have some cross-project CI jobs to verify > that plugins are not broken with the latest Horizon changes. > > The initial idea was to use tempest plugins for this effort like we do for > Horizon [1]. We've got a very simple test to verify that Horizon is up and > running and a user is able to login. > > It's easy to implement such tests for any existing horizon plugin. I tried > it for Heat and Manila dashboards. Given that I know very little about this but isn't it just as simple as running the say the octavia-dashboard[1] npm tests on all horizon changes? This would be similar to the way we run the nova[2] functional tests on all constraints changes in openstack/requirements. Yours Tony. [1] Of course all dashbaords/plugins [2] Not just nova but you get the idea signature.asc Description: PGP signature __ 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][ui][tempest][oooq] Refreshing plugins from git
Hello folks, I'm working on the automated ui testing blueprint[1], and I think we need to change the way we ship our tempest tests. Here is where things stand at the moment: * We have a kolla image for tempest * This image contains the tempest rpm, and the openstack-tempest-all rpm * The openstack-tempest-all package in turn contains all of the openstack tempest plugins * Each of the plugins is shipped as an rpm So, in order for a new test in tempest-tripleo-ui to appear in CI we have to go through at least the following tests: * New tempest-tripleo-ui rpm * New openstack-tempest-all rpm * New tempest kolla image This could easily take a week, if not more. What I would like to build is something like the following: * Add an option to the tempest-setup.sh script in tripleo-quickstart to refresh all tempest plugins from git before running any tests * Optionally specify a zuul change for any of the plugins being refreshed * Hook up the test job to patches in tripleo-ui (which tests in tempest-tripleo-ui are testing) so that I can run a fix and its test in a single CI job This would allow the tripleo-ui team to develop code and tests at the same time, and prevent breakage before a patch is even merged. Here are a few questions: * Do you think this is a good idea? * Could we accomplish this by some other, simple mechanism? Any helpful suggestions, corrections, and feedback are much appreciated. Thanks Honza Pokorny [1]: https://blueprints.launchpad.net/tripleo/+spec/automated-ui-testing __ 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] [qa][vmware-nsx-tempest-plugin][networking-vsphere] Dependency of Tempest changes
Hi A tempest patch[1] removes the deprecated library method and some projects are still using the method. Tempest provides another method instead and we have patches to swith it. The following patches are not merged yet at this time: - vmware-nsx-tempest-plugin: https://review.openstack.org/#/c/578166 - networking-vsphere: https://review.openstack.org/#/c/578168 Happy if they all are merged soon. Thanks Kenichi Omichi --- [1]: https://review.openstack.org/#/c/578169 __ 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] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints
On 17.10.2018 15:45, Florian Engelmann wrote: On 10.10.2018 09:06, Florian Engelmann wrote: Now I get you. I would say all configuration templates need to be changed to allow, eg. $ grep http /etc/kolla/cinder-volume/cinder.conf glance_api_servers = http://10.10.10.5:9292 auth_url = http://internal.somedomain.tld:35357 www_authenticate_uri = http://internal.somedomain.tld:5000 auth_url = http://internal.somedomain.tld:35357 auth_endpoint = http://internal.somedomain.tld:5000 to look like: glance_api_servers = http://glance.service.somedomain.consul:9292 auth_url = http://keystone.service.somedomain.consul:35357 www_authenticate_uri = http://keystone.service.somedomain.consul:5000 auth_url = http://keystone.service.somedomain.consul:35357 auth_endpoint = http://keystone.service.somedomain.consul:5000 The idea with Consul looks interesting. But I don't get your issue with VIP address and spine-leaf network. What we have: - controller1 behind leaf1 A/B pair with MLAG - controller2 behind leaf2 A/B pair with MLAG - controller3 behind leaf3 A/B pair with MLAG The VIP address is active on one controller server. When the server fail then the VIP will move to another controller server. Where do you see a SPOF in this configuration? So leaf1 2 and 3 have to share the same L2 domain, right (in IPv4 network)? Yes, they share L2 domain but we have ARP and ND suppression enabled. It is an EVPN network where there is a L3 with VxLANs between leafs and spines. So we don't care where a server is connected. It can be connected to any leaf. But we wanna deploy a layer3 spine-leaf network were every leaf is it's own L2 domain and everything above is layer3. eg: leaf1 = 10.1.1.0/24 leaf2 = 10.1.2.0/24 leaf2 = 10.1.3.0/24 So a VIP like, eg. 10.1.1.10 could only exist in leaf1 In my opinion it's a very constrained environment, I don't like the idea. Regards, Piotr __ 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] [python3] Enabling py37 unit tests
On Wed, Oct 17, 2018 at 3:43 PM William M Edmonds wrote: > > Corey Bryant wrote on 10/15/2018 05:34:24 PM: > ... > > From an ubuntu perspective, ubuntu is going to support stein on 18. > > 04 LTS (3.6) and 19.04 (3.7) only. > ... > > So folks with Ubuntu 16.04 LTS compute nodes will have to upgrade them all > to 18.04 before upgrading to Stein? Of course this would be a distro > statement,and would not preclude someone from building their own > environment from source/pypi on Ubuntu 16.04. And 16.04 is still pretty > heavily used, right? > > All true statements, and the answers to your questions is yes. > Ubuntu 18.04 LTS is not supported on PowerVM compute nodes, so the PowerVM > CI will not be able to switch to running under py3 if code that doesn't > work in py35 is introduced. At least until RHEL 8 comes out, at which point > we could switch to using that in our CI. But please don't allow such > changes before the RHEL 8 release. > This sounds like an orthogonal problem but maybe I'm confused. Corey > > > __ > 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] [senlin] Senlin Monthly(ish) Newsletter Oct 2018
HTML: https://dkt26111.wordpress.com/2018/10/17/senlin-monthlyish-newsletter-october-2018/ This is the October edition of the Senlin monthly(ish) newsletter. The goal of the newsletter is to highlight happenings in the Senlin project. If you have any feedback or questions regarding the contents, please feel free to reach out to me in the #senlin IRC channel. News * There will be no Senlin meeting this week (Friday October 19, 2018) because I'm unavailable this week. We will resume regular meetings next week. * Autoscaling forum has been scheduled for the Berlin Summit (https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22753/autoscaling-integration-improvement-and-feedback). Add your comments/feedback to this etherpad: https://etherpad.openstack.org/p/autoscaling-integration-and-feedback Blueprint Status * Fail fast locked resource - https://blueprints.launchpad.net/senlin/+spec/fail-fast-locked-resource - Implementation is completed and has been merged. - Working on documentation and release notes. * Multiple detection modes - https://blueprints.launchpad.net/senlin/+spec/multiple-detection-modes - Implementation is completed and has been merged. - Working on documentation and release notes. * Fail-fast on cooldown for scaling operations - https://blueprints.launchpad.net/senlin/+spec/scaling-action-acceptance - Implementation is completed. - Waiting for more reviews: https://review.openstack.org/#/c/585573/ * OpenStackSDK support senlin function test - Basic test cases have been implemented and merged: https://review.openstack.org/#/c/607061/ * Senlin add support use limit return - Waiting for blueprint submission. * Add zun driver in senlin, use zun manager container - Waiting for blueprint submission. Community Goal Status - * Python 3 - All patches by Python 3 goal champions for zuul migration, documentation and unit test changes have been merged. * Upgrade Checkers - No work has started on this. If you like to help out with this task, please let me know. Recently Merged Changes --- * Multiple detection mode support was added as part of the same blueprint: https://review.openstack.org/#/c/589990/. This change introduces version 1.1 of the health policy that includes breaking changes affecting clusters using the health policy version 1.0. We are working to address this issue. __ 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] [python3] Enabling py37 unit tests
Corey Bryant wrote on 10/15/2018 05:34:24 PM: ... > From an ubuntu perspective, ubuntu is going to support stein on 18. > 04 LTS (3.6) and 19.04 (3.7) only. ... So folks with Ubuntu 16.04 LTS compute nodes will have to upgrade them all to 18.04 before upgrading to Stein? Of course this would be a distro statement, and would not preclude someone from building their own environment from source/pypi on Ubuntu 16.04. And 16.04 is still pretty heavily used, right? Ubuntu 18.04 LTS is not supported on PowerVM compute nodes, so the PowerVM CI will not be able to switch to running under py3 if code that doesn't work in py35 is introduced. At least until RHEL 8 comes out, at which point we could switch to using that in our CI. But please don't allow such changes before the RHEL 8 release. __ 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] [horizon][plugins] Horizon plugins validation on CI
Hi Ivan, As Octavia PTL I have no issue with adding a tempest-plugin repository for the octavia-dashboard. I think we have had examples with the main tempest tests and plugins where trying to do a suite of tests in one repository becomes messy. We may also want to consider doing a horizon-tempest-lib type of repository that can host common code/tools for the dashboard plugins to leverage. I'm thinking things like login code, etc. Michael On Wed, Oct 17, 2018 at 6:19 AM Ivan Kolodyazhny wrote: > > Hi all, > > We discussed this topic at PTG both with Horizon and other teams. Sounds like > everybody is interested to have some cross-project CI jobs to verify that > plugins are not broken with the latest Horizon changes. > > The initial idea was to use tempest plugins for this effort like we do for > Horizon [1]. We've got a very simple test to verify that Horizon is up and > running and a user is able to login. > > It's easy to implement such tests for any existing horizon plugin. I tried it > for Heat and Manila dashboards. > > If I understand correctly how tempest plugins work, for such case we've got > such options: > > a) to create the same tempest plugins for each plugin - it this case, we need > to maintain new repos for tempest plugins > b) add these tests to Horizon tempest plugin - in such case, it will be > harder for plugin maintainers to support these tests. > > If we don't want to go forward with tempest plugins, we can create similar > tests based on Horizon functional tests. > > I want to get more feedback both from Horizon and plugins teams on which > direction we should go and start implementation. > > > [1] > https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py#L138 > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > __ > 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] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints
No, I mean, Consul would be an extra dependency in a big list of dependencies OpenStack already has. OpenStack has so many it is causing operators to reconsider adoption. I'm asking, if existing dependencies can be made to solve the problem without adding more? Stateful dependencies are much harder to deal with then stateless ones, as they take much more operator care/attention. Consul is stateful as is etcd, and etcd is already a dependency. Can etcd be used instead so as not to put more load on the operators? Thanks, Kevin From: Florian Engelmann [florian.engelm...@everyware.ch] Sent: Wednesday, October 10, 2018 12:18 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints by "another storage system" you mean the KV store of consul? That's just someting consul brings with it... consul is very strong in doing health checks Am 10/9/18 um 6:09 PM schrieb Fox, Kevin M: > etcd is an already approved openstack dependency. Could that be used instead > of consul so as to not add yet another storage system? coredns with the > https://coredns.io/plugins/etcd/ plugin would maybe do what you need? > > Thanks, > Kevin > > From: Florian Engelmann [florian.engelm...@everyware.ch] > Sent: Monday, October 08, 2018 3:14 AM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [kolla] add service discovery, proxysql, vault, > fabio and FQDN endpoints > > Hi, > > I would like to start a discussion about some changes and additions I > would like to see in in kolla and kolla-ansible. > > 1. Keepalived is a problem in layer3 spine leaf networks as any floating > IP can only exist in one leaf (and VRRP is a problem in layer3). I would > like to use consul and registrar to get rid of the "internal" floating > IP and use consuls DNS service discovery to connect all services with > each other. > > 2. Using "ports" for external API (endpoint) access is a major headache > if a firewall is involved. I would like to configure the HAProxy (or > fabio) for the external access to use "Host:" like, eg. "Host: > keystone.somedomain.tld", "Host: nova.somedomain.tld", ... with HTTPS. > Any customer would just need HTTPS access and not have to open all those > ports in his firewall. For some enterprise customers it is not possible > to request FW changes like that. > > 3. HAProxy is not capable to handle "read/write" split with Galera. I > would like to introduce ProxySQL to be able to scale Galera. > > 4. HAProxy is fine but fabio integrates well with consul, statsd and > could be connected to a vault cluster to manage secure certificate access. > > 5. I would like to add vault as Barbican backend. > > 6. I would like to add an option to enable tokenless authentication for > all services with each other to get rid of all the openstack service > passwords (security issue). > > What do you think about it? > > All the best, > Florian > > __ > 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 > -- EveryWare AG Florian Engelmann Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: mailto:florian.engelm...@everyware.ch web: http://www.everyware.ch __ 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] [goals][upgrade-checkers] Call for Volunteers to work on upgrade-checkers stein goal
On 10/16/2018 9:43 AM, Ghanshyam Mann wrote: I was discussing with mriedem [1] about idea of building a volunteer team which can work with him on upgrade-checkers goal [2]. There are lot of work needed for this goal[3], few projects which does not have upgrade impact yet needs CLI framework with placeholder only and other projects with upgrade impact need actual upgrade checks implementation. Idea is to build the volunteer team who can work with goal champion to finish the work early. This will help to share some work from goal champion as well from project side. - This email is request to call for volunteers (upstream developers from any projects) who can work closely with mriedem on upgrade-checkers goal. - Currently two developers has volunteered. 1. Akhil Jain (IRC: akhil_jain, email:akhil.j...@india.nec.com) 2. Rajat Dhasmana (IRC: whoami-rajat email:rajatdhasm...@gmail.com) - Anyone who would like to help on this work, feel free to reply this email or ping mriedem on IRC. - As next step, mriedem will plan the work distribution to volunteers. Thanks Ghanshyam. As can be seen from the cyborg [1] and congress [2] changes posted by Rajat and Akhil, the initial framework changes are pretty trivial. The harder part is working with core teams / PTLs to determine which real upgrade checks should be added based on the release notes. But having the framework done as a baseline across all service projects is a great start. [1] https://review.openstack.org/#/c/611368/ [2] https://review.openstack.org/#/c/66/ -- 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] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
Dmitry Tantsur wrote: On 10/10/18 7:41 PM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the futurist and automaton libraries that are primarily used by taskflow. Just for completeness: futurist and automaton are also heavily relied on by ironic without using taskflow. When did futurist get used??? nice :) (I knew automaton was, but maybe I knew futurist was to and I forgot, lol). The idea would be to just host them on github and use the regular Github features for Issues, PRs, wiki, etc, in the hopes that this would spur more development. Taskflow hasn't had any substantial contributions in several years and it doesn't really seem that the current openstack devs have a vested interest in moving it forward. I would like to move it forward, but I don't have an interest in being bound by the openstack workflow (this is why the project stagnated as core reviewers were pulled on to other projects and couldn't keep up with the review backlog, so contributions ground to a halt). I guess I'm putting it forward to the larger community. Does anyone have any objections to us doing this? Are there any non-obvious technicalities that might make such a transition difficult? Who would need to be made aware so they could adjust their own workflows? Or would it be preferable to just fork and rename the project so openstack can continue to use the current taskflow version without worry of us breaking features? Greg __ 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] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps
On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote: As you may know, unfortunately, Horizon doesn't support all features provided by APIs. That's why we created feature gaps list [1]. I'd got a lot of great conversations with projects teams during the PTG and we tried to figure out what should be done prioritize these tasks. It's really helpful for Horizon to get feedback from other teams to understand what features should be implemented next. While I'm filling launchpad with new bugs and blueprints for [1], it would be good to review this list again and find some volunteers to decrease feature gaps. [1] https://etherpad.openstack.org/p/horizon-feature-gap Thanks everybody for any of your contributions to Horizon. +openstack-sigs +openstack-operators I've left some notes for nova. This looks very similar to the compute API OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what to really work on without some user/operator feedback - maybe we can get the user work group involved in trying to help prioritize what people really want that is missing from horizon, at least for compute? [1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc -- 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] [TripleO] easily identifying how services are configured
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
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.
Thanks,
-Alex
>
> --
> -- James Slagle
> --
>
> __
> 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
[openstack-dev] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps
Hi teams, As you may know, unfortunately, Horizon doesn't support all features provided by APIs. That's why we created feature gaps list [1]. I'd got a lot of great conversations with projects teams during the PTG and we tried to figure out what should be done prioritize these tasks. It's really helpful for Horizon to get feedback from other teams to understand what features should be implemented next. While I'm filling launchpad with new bugs and blueprints for [1], it would be good to review this list again and find some volunteers to decrease feature gaps. [1] https://etherpad.openstack.org/p/horizon-feature-gap Thanks everybody for any of your contributions to Horizon. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints
currently we are testing what is needed to get consul + registrator and kolla/kolla-ansible play together nicely. To get the services created in consul by registrator all kolla containers running relevant services (eg. keystone, nova, cinder, ... but also mariadb, memcached, es, ...) need to "--expose" their ports. Registrator will use those "exposed" ports to add a service to consul. I there any (existing) option to add those ports to the container bootstrap? What about "docker_common_options"? command should look like: docker run -d --expose 5000/tcp --expose 35357/tcp --name=keystone ... Am 10/10/18 um 9:18 AM schrieb Florian Engelmann: by "another storage system" you mean the KV store of consul? That's just someting consul brings with it... consul is very strong in doing health checks Am 10/9/18 um 6:09 PM schrieb Fox, Kevin M: etcd is an already approved openstack dependency. Could that be used instead of consul so as to not add yet another storage system? coredns with the https://coredns.io/plugins/etcd/ plugin would maybe do what you need? Thanks, Kevin From: Florian Engelmann [florian.engelm...@everyware.ch] Sent: Monday, October 08, 2018 3:14 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints Hi, I would like to start a discussion about some changes and additions I would like to see in in kolla and kolla-ansible. 1. Keepalived is a problem in layer3 spine leaf networks as any floating IP can only exist in one leaf (and VRRP is a problem in layer3). I would like to use consul and registrar to get rid of the "internal" floating IP and use consuls DNS service discovery to connect all services with each other. 2. Using "ports" for external API (endpoint) access is a major headache if a firewall is involved. I would like to configure the HAProxy (or fabio) for the external access to use "Host:" like, eg. "Host: keystone.somedomain.tld", "Host: nova.somedomain.tld", ... with HTTPS. Any customer would just need HTTPS access and not have to open all those ports in his firewall. For some enterprise customers it is not possible to request FW changes like that. 3. HAProxy is not capable to handle "read/write" split with Galera. I would like to introduce ProxySQL to be able to scale Galera. 4. HAProxy is fine but fabio integrates well with consul, statsd and could be connected to a vault cluster to manage secure certificate access. 5. I would like to add vault as Barbican backend. 6. I would like to add an option to enable tokenless authentication for all services with each other to get rid of all the openstack service passwords (security issue). What do you think about it? All the best, Florian __ 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 -- EveryWare AG Florian Engelmann Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: mailto:florian.engelm...@everyware.ch web: http://www.everyware.ch smime.p7s Description: S/MIME cryptographic signature __ 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] [Cyborg] Cyborg will have regular IRC meeting this week
Hi Folks, We will be having our regular IRC meeting this week at the usual time. We will mainly discuss the demo plan for the summit. -- Thank you Regards Li __ 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] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints
On 10.10.2018 09:06, Florian Engelmann wrote: Now I get you. I would say all configuration templates need to be changed to allow, eg. $ grep http /etc/kolla/cinder-volume/cinder.conf glance_api_servers = http://10.10.10.5:9292 auth_url = http://internal.somedomain.tld:35357 www_authenticate_uri = http://internal.somedomain.tld:5000 auth_url = http://internal.somedomain.tld:35357 auth_endpoint = http://internal.somedomain.tld:5000 to look like: glance_api_servers = http://glance.service.somedomain.consul:9292 auth_url = http://keystone.service.somedomain.consul:35357 www_authenticate_uri = http://keystone.service.somedomain.consul:5000 auth_url = http://keystone.service.somedomain.consul:35357 auth_endpoint = http://keystone.service.somedomain.consul:5000 The idea with Consul looks interesting. But I don't get your issue with VIP address and spine-leaf network. What we have: - controller1 behind leaf1 A/B pair with MLAG - controller2 behind leaf2 A/B pair with MLAG - controller3 behind leaf3 A/B pair with MLAG The VIP address is active on one controller server. When the server fail then the VIP will move to another controller server. Where do you see a SPOF in this configuration? So leaf1 2 and 3 have to share the same L2 domain, right (in IPv4 network)? But we wanna deploy a layer3 spine-leaf network were every leaf is it's own L2 domain and everything above is layer3. eg: leaf1 = 10.1.1.0/24 leaf2 = 10.1.2.0/24 leaf2 = 10.1.3.0/24 So a VIP like, eg. 10.1.1.10 could only exist in leaf1 smime.p7s Description: S/MIME cryptographic signature __ 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] [horizon][plugins] Horizon plugins validation on CI
Hi all, We discussed this topic at PTG both with Horizon and other teams. Sounds like everybody is interested to have some cross-project CI jobs to verify that plugins are not broken with the latest Horizon changes. The initial idea was to use tempest plugins for this effort like we do for Horizon [1]. We've got a very simple test to verify that Horizon is up and running and a user is able to login. It's easy to implement such tests for any existing horizon plugin. I tried it for Heat and Manila dashboards. If I understand correctly how tempest plugins work, for such case we've got such options: a) to create the same tempest plugins for each plugin - it this case, we need to maintain new repos for tempest plugins b) add these tests to Horizon tempest plugin - in such case, it will be harder for plugin maintainers to support these tests. If we don't want to go forward with tempest plugins, we can create similar tests based on Horizon functional tests. I want to get more feedback both from Horizon and plugins teams on which direction we should go and start implementation. [1] https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py#L138 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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
