November 2018 - openstack-discuss

[Interop-wg] [dev] [cinder] [qa] Strict Validation for Volume API using JSON Schema
by Ghanshyam Mann 08 Mar '19

08 Mar '19

Hello everyone, Tempest is planning to add the strict API validation using JSON schema for Volume test [1]. We do the same for all the compute test. With *Strict* JSON schema validation, all the API response will be validated with predefined schema with additionalProperties=False. additionalProperties=False will not allow any additional attribute in API response than what upstream APIs has in their current version. For example: If any vendor has modified the API response and returning additional attributes then Tempest tests going to fail. This will help: - To improve the OpenStack interoperability. Strict validation of API response is always helpful to maintain the interoperability. - To improve the volume API testing to avoid the backward compatible changes. Sometime we accidentally change the API in backward incompatible way and strict validation with JSON schema help to block those. We want to hear from cinder and interop team about any impact of this change to them. [1] https://blueprints.launchpad.net/tempest/+spec/volume-response-schema-valid… -gmann

4 6

[kayobe] IRC meetings
by Mark Goddard 09 Jan '19

09 Jan '19

Hi, The community has requested that we start holding regular IRC meetings for kayobe, and I agree. I suggest we start with meeting every other week, in the #openstack-kayobe channel. I've created a Doodle poll [1] with each hour between 2pm and 6pm UTC available every weekday. Please respond on the poll with your availability. Thanks, Mark [1] https://doodle.com/poll/6di3pddsahg6h66k

1 1

[loci] Release management for LOCI
by Thierry Carrez 08 Jan '19

08 Jan '19

Hi, loci folks, The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". In that context, the situation of the loci deliverable (openstack/loci repository) is unclear. Is it: 1. meant to be released through the openstack/releases repository, but just not ready yet (any hint of when it will be ?) 2. not meant to be "released" or tagged but more like continuously published (in which case we should add "release-management:none" to it) 3. meant to be released, but on a 3rd-party platform like the Docker Hub and not using openstack/releases to drive it (in which case we should add "release-management:external" to it) From previous discussions it appears (2) would best describe the loci situation, but I wanted to doublecheck it was still the case. Thanks, -- Thierry Carrez (ttx)

4 7

[all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback
by Rico Lin 02 Jan '19

02 Jan '19

Dear all Tl;dr; I gonna use this ML to give a summary of the forum [1] and asking for feedback for the idea of new SIG. We have a plan to create a new SIG for autoscaling which to cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. So if you have any thoughts for the new SIG (good or bad) please share it here. Here I summarize our discussion in the forum session `Autoscaling Integration, improvement, and feedback`. If you like to learn more or input your thoughts, feel free to put it in etherpad [1] or simply reply to this email. In the forum, we have been discussed the scope and possibility to integrate effort from Heat, Senlin, and also autoscaling across OpenStack to K8s. There are some long-term goals that we can start on like create a document for general Autoscaling on OpenStack, Common library for cross-project usage, or create real scenario cases to test on our CI. And the most important part is how can we help users and satisfied use cases without confuse them or making too much duplication effort across communities/projects. So here's an action we agree on, is to trigger discussion for either we need to create a new SIG for autoscaling. We need to define the scope and the goal for this new SIG before we go ahead and create one. The new SIG will cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. For example, we can have a document about do autoscaling in OpenStack, but we need a place to put it and keep maintain it. And we can even have a place to set up CI to test all scenario for autoscaling. I think it's possible to extend the definition of this SIG, but we have to clear our goal and make sure we actually doing a good thing and make everyone's life easier. On the other hand we also need to make sure we do not duplicate the effort of other SIGs/WGs. Also The reason I add `ptl` tag for this ML is that this SIG or the concept of `autoscaling` might be very deferent to different projects. So I really wish to hear from anyone and any projects who are interested in this topic. [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

4 3

[Openstack] unexpected distribution of compute instances in queens
by Zufar Dhiyaulhaq 19 Dec '18

19 Dec '18

Hi, I am deploying OpenStack with 3 compute node, but I am seeing an abnormal distribution of instance, the instance is only deployed in a specific compute node, and not distribute among other compute node. this is my nova.conf from the compute node. (template jinja2 based) [DEFAULT] osapi_compute_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1'][ 'ipv4']['address'] }} metadata_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ 'address'] }} enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver [api] auth_strategy = keystone [api_database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api [barbican] [cache] backend=oslo_cache.memcache_pool enabled=true memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 [cells] [cinder] os_region_name = RegionOne [compute] [conductor] [console] [consoleauth] [cors] [crypto] [database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova [devices] [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://{{ vip }}:9292 [guestfs] [healthcheck] [hyperv] [ironic] [key_manager] [keystone] [keystone_authtoken] auth_url = http://{{ vip }}:5000/v3 memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = {{ nova_pw }} [libvirt] [matchmaker_redis] [metrics] [mks] [neutron] url = http://{{ vip }}:9696 auth_url = http://{{ vip }}:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = {{ neutron_pw }} service_metadata_proxy = true metadata_proxy_shared_secret = {{ metadata_secret }} [notifications] [osapi_v21] [oslo_concurrency] lock_path = /var/lib/nova/tmp [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] [pci] [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://{{ vip }}:5000/v3 username = placement password = {{ placement_pw }} [quota] [rdp] [remote_debug] [scheduler] discover_hosts_in_cells_interval = 300 [serial_console] [service_user] [spice] [upgrade_levels] [vault] [vendordata_dynamic_auth] [vmware] [vnc] enabled = true keymap=en-us novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html novncproxy_host = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ 'address'] }} [workarounds] [wsgi] [xenserver] [xvp] [placement_database] connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement what is the problem? I have lookup the openstack-nova-scheduler in the controller node but it's running well with only warning nova-scheduler[19255]: /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: NotSupportedWarning: Configuration option(s) ['use_tpool'] not supported the result I want is the instance is distributed in all compute node. Thank you. -- *Regards,* *Zufar Dhiyaulhaq* _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

9 23

[openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed
by Vikrant Aggarwal 12 Dec '18

12 Dec '18

Hello Team, Trying to deploy on K8 on fedora atomic. Here is the output of cluster template: ~~~ [root@packstack1 k8s_fedora_atomic_v1(keystone_admin)]# magnum cluster-template-show 16eb91f7-18fe-4ce3-98db-c732603f2e57 WARNING: The magnum client is deprecated and will be removed in a future release. Use the OpenStack client to avoid seeing this message. +-----------------------+--------------------------------------+ | Property | Value | +-----------------------+--------------------------------------+ | insecure_registry | - | | labels | {} | | updated_at | - | | floating_ip_enabled | True | | fixed_subnet | - | | master_flavor_id | - | | user_id | 203617849df9490084dde1897b28eb53 | | uuid | 16eb91f7-18fe-4ce3-98db-c732603f2e57 | | no_proxy | - | | https_proxy | - | | tls_disabled | False | | keypair_id | kubernetes | | project_id | 45a6706c831c42d5bf2da928573382b1 | | public | False | | http_proxy | - | | docker_volume_size | 10 | | server_type | vm | | external_network_id | external1 | | cluster_distro | fedora-atomic | | image_id | f5954340-f042-4de3-819e-a3b359591770 | | volume_driver | - | | registry_enabled | False | | docker_storage_driver | devicemapper | | apiserver_port | - | | name | coe-k8s-template | | created_at | 2018-11-28T12:58:21+00:00 | | network_driver | flannel | | fixed_network | - | | coe | kubernetes | | flavor_id | m1.small | | master_lb_enabled | False | | dns_nameserver | 8.8.8.8 | +-----------------------+--------------------------------------+ ~~~ Found couple of issues in the logs of VM started by magnum. - etcd was not getting started because of incorrect permission on file "/etc/etcd/certs/server.key". This file is owned by root by default have 0440 as permission. Changed the permission to 0444 so that etcd can read the file. After that etcd started successfully. - etcd DB doesn't contain anything: [root@kube-cluster1-qobaagdob75g-master-0 ~]# etcdctl ls / -r [root@kube-cluster1-qobaagdob75g-master-0 ~]# - Flanneld is stuck in activating status. ~~~ [root@kube-cluster1-qobaagdob75g-master-0 ~]# systemctl status flanneld ● flanneld.service - Flanneld overlay address etcd agent Loaded: loaded (/usr/lib/systemd/system/flanneld.service; enabled; vendor preset: disabled) Active: activating (start) since Thu 2018-11-29 11:05:39 UTC; 14s ago Main PID: 6491 (flanneld) Tasks: 6 (limit: 4915) Memory: 4.7M CPU: 53ms CGroup: /system.slice/flanneld.service └─6491 /usr/bin/flanneld -etcd-endpoints=http://127.0.0.1:2379 -etcd-prefix=/atomic.io/network Nov 29 11:05:44 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:44.569376 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:45 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:45.584532 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:46 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:46.646255 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:47 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:47.673062 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:48 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:48.686919 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:49 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:49.709136 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:50 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:50.729548 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:51 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:51.749425 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:52 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:52.776612 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:53 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:53.790418 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] ~~~ - Continuously in the jouralctl logs following messages are printed. ~~~ Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-apiserver[6888]: F1129 11:06:39.338416 6888 server.go:269] Invalid Authorization Config: Unknown authorization mode Node specified Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Main process exited, code=exited, status=255/n/a Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.408272 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:463: Failed to list *api.Node: Get http://127.0.0.1:8080/api/v1/nodes?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.444737 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:460: Failed to list *api.Pod: Get http://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName%21%3D%2Cstatu…: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.445793 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:466: Failed to list *api.PersistentVolume: Get http://127.0.0.1:8080/api/v1/persistentvolumes?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=kube-apiserver comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: Failed to start Kubernetes API Server. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Unit entered failed state. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Failed with result 'exit-code'. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.611699 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:481: Failed to list *extensions.ReplicaSet: Get http://127.0.0.1:8080/apis/extensions/v1beta1/replicasets?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused ~~~ Any help on above issue is highly appreciated. Thanks & Regards, Vikrant Aggarwal __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

2 5

Re: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)
by Ghanshyam Mann 12 Dec '18

12 Dec '18

Hi All, Let's go with approach 1 means migrating the Devstack and Tempest base jobs to Bionic. This will move most of the jobs to Bionic. We have two patches up which move all Devstack and Tempest jobs to Bionic and it's working fine. 1. All DevStack jobs to Bionic - https://review.openstack.org/#/c/610977/ - This will move devstack-minimal, devstack, devstack-ipv6, devstack-multinode jobs to bionic only for master which means it will be stein onwards. All these jobs will use xenial till stable/rocky. 2. All Tempest base jobs (except stable branches job running on master) to Bionic - https://review.openstack.org/#/c/618169/ - This will move devstack-tempest, tempest-all, devstack-tempest-ipv6, tempest-full, tempest-full-py3, tempest-multinode-full, tempest-slow jobs to bionic. Note- Even Tempest is branchless and these tempest jobs have been moved to Bionic, they will still use xenial for all stable branches(till stable/rocky) testing. with zuulv3 magic and devstack base jobs nodeset for stable branch (xenial) and master (stein onwards -bionic) will take care of that. Tested on [1] and working fine. Thanks corvus and clarkb for guiding to this optimized way. 3. Legacy jobs are not migrated to bionic. They should get migrated to Bionic while they are moved to zuulv3 native. So if your projects have many legacy jobs then, they will still run on xenial. Any job inherits from those base jobs will behave the same way (running on bionic from stein onwards and xenial till stable/rocky). I am writing the plan and next action item to complete this migration activity: 1 Project teams: need to test their jobs 1. which are inherited from devstack/tempest base jobs and should pass as it is 2. Any zuulv3 jobs not using devstack/tempest base job required to migrate to use bionic (Devstack patch provide the bionic nodeset) and test it. Start writing the results on etherpad[2] 2 QA team will merge the above patches by 10th Dec so that we can find and fix any issues as early and to avoid the same during release time. Let's finish the pre-testing till 10th Dec and then merge the bionic migration patches. [1] https://review.openstack.org/#/c/618181/ https://review.openstack.org/#/c/618176/ [2] https://etherpad.openstack.org/p/devstack-bionic -gmann ---- On Wed, 07 Nov 2018 08:45:45 +0900 Doug Hellmann <doug(a)doughellmann.com> wrote ---- > Ghanshyam Mann <gmann(a)ghanshyammann.com> writes: > > > ---- On Wed, 07 Nov 2018 06:51:32 +0900 Slawomir Kaplonski <skaplons(a)redhat.com> wrote ---- > > > Hi, > > > > > > > Wiadomość napisana przez Jeremy Stanley <fungi(a)yuggoth.org> w dniu 06.11.2018, o godz. 22:25: > > > > > > > > On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote: > > > > [...] > > > >> also add jobs like "devstack-xenial" and "tempest-full-xenial" > > > >> which projects can use still for some time if their job on Bionic > > > >> would be broken now? > > > > [...] > > > > > > > > That opens the door to piecemeal migration, which (as we similarly > > > > saw during the Trusty to Xenial switch) will inevitably lead to > > > > projects who no longer gate on Xenial being unable to integration > > > > test against projects who don't yet support Bionic. At the same > > > > time, projects which have switched to Bionic will start merging > > > > changes which only work on Bionic without realizing it, so that > > > > projects which test on Xenial can't use them. In short, you'll be > > > > broken either way. On top of that, you can end up with projects that > > > > don't get around to switching completely before release comes, and > > > > then they're stuck having to manage a test platform transition on a > > > > stable branch. > > > > > > I understand Your point here but will option 2) from first email lead to the same issues then? > > > > seems so. approach 1 is less risky for such integrated testing issues and requires less work. In approach 1, we can coordinate the base job migration with project side testing with bionic. > > > > -gmann > > I like the approach of updating the devstack jobs to move everything to > Bionic at one time because it sounds like it presents less risk of us > ending up with something that looks like it works together but doesn't > actually because it's tested on a different platform, as well as being > less likely to cause us to have to do major porting work in stable > branches after the release. > > We'll need to take the same approach when updating the version of Python > 3 used inside of devstack. > > Doug >

4 8

[ops] [nova] How to get CPUtime and wallclokctime consumed by a project (without using ceilometer) ?
by Massimo Sgaravatto 12 Dec '18

12 Dec '18

Hi I was wondering if nova allows to get the CPUtime and wallclocktime consumed by a project in a certain time period, without using ceilometer Among the data returned by the command "openstack usage show" there is also a "CPU Hours" but, if I am not wrong, this is actually the WallClockTime. Did I get it right ? If so, it is also possible to get the CPUTime ? Thanks, Massimo

3 4

[all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus, Session Summary: Autoscaling Integration, improvement, and feedback
by Joseph Davis 11 Dec '18

11 Dec '18

I agree with Duc and Witek that this communication could be really good. One of the first items for a new SIG would be to define the relationship with the Self-Healing SIG. The two SIGs have a lot in common but some important differences. They can both use some of the same tools and data (Heat, Monasca, Senlin, Vitrage, etc) to achieve their purpose, but Self-Healing is about recovering a cloud when something goes wrong, while Autoscaling is about adjusting resources to avoid something going wrong. Having a clear statement may help a new user or contributor understand where there interests lie and how they can be part of the group. Writing some clear use cases will be really valuable for all the component teams to reference. It may also be of value to identify a few reference architectures or configurations to illustrate how the use cases could be addressed. I'm thinking of stories like "A cloud with Monasca and Senlin services has 20 active VMs. When Monasca recognizes the 20 VMs have hit 90% utilization each it raises an alarm and Senlin triggers the creation of 5 more VMs to meet expected loads." Plus lots of details I just skipped over. :) joseph On Wed, Nov 28, 2018 at 4:00 AM Rico Lin<rico.lin.guanyu(a)gmail.com> wrote: > > I gonna use this ML to give a summary of the forum [1] and asking for > feedback for the idea of new SIG. > > So if you have any thoughts for the new SIG (good or bad) please share it > here. > > [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback On Thu, 29 Nov 2018 09:32:17 "Bedyk, Witold"<witold.bedyk(a)est.fujitsu.com> wrote: > Hi Rico, > > Thanks for this initiative. I think the SIG could be a good channel to coordinate this work across the projects. > > From Monasca perspective, I would like to make sure that we provide all necessary monitoring data to cover the defined use cases and that Monasca alarms can be seamlessly consumed by the integrated services. > We’re also interested in contributing documentation in the central place. > > I’m sure operators will be thankful for having a channel for providing dedicated feedback. > > Cheers > Witek

3 2

[ops][docs] The Contributor Guide: Ops Feedback Session Summary
by Kendall Nelson 07 Dec '18

07 Dec '18

Hello! For the long version, feel free to look over the etherpad[1]. It should be noted that this session was in relation to the operator section of the contributor guide, not the operations guide, though they should be closely related and link to one another. Basically the changes requested can be boiled down to two types of changes: cosmetic and missing content. Cosmetic Changes: - Timestamps so people can know when the last change was made to a given doc (dhellmann volunteered to help here)[2] - Floating bug report button and some mechanism for auto populating which page a bug is on so that the reader doesn’t have to know what rst file in what repo has the issue to file a bug[3] - Maybe not cosmetic exactly, but it was requested that the entirety of the contributor guide be translated into as many languages as possible (stevenK volunteered to help get the framework setup so that things could be imported into Zanata for translation)[4] - Link to source somewhere on the page so those interested in fixing issues that don’t know the repo structure can find and fix issues right away[5] Missing Content: - Links to the docs in the Operator guide (HA guide, etc)[6] - A guide to ‘I fixed this bug locally, how do I get it upstream?’[7] If there are any unclaimed items you are interested in working on, please do! The contributor guide work items are tracked in StoryBoard here[8]! -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/BER-Contrib-Guide-Ops [2] https://storyboard.openstack.org/#!/story/2004436 [3] https://storyboard.openstack.org/#!/story/2004437 [4] https://storyboard.openstack.org/#!/story/2004438 [5] https://storyboard.openstack.org/#!/story/2004439 [6] https://storyboard.openstack.org/#!/story/2004441 [7] https://storyboard.openstack.org/#!/story/2004442 [8]https://storyboard.openstack.org/#!/project/openstack/contributor-guide

5 7