[openstack-dev] [tripleo] blockquotes in docs
Just a short reminder that rst puts stuff in blockquotes when you're not careful with the spacing. Example: * item 1 * item 2 That's in blockquotes because of the 1 blank at the beginning. The TripleO docs are full with them, which looks a bit ugly, to be frank. This change removes all unintentional blockquotes in the tripleo docs: https://review.openstack.org/#/c/504518/ You can find them by yourself with: $ tox -e docs $ grep -rn blockquote doc/build/html/ --include *.html I often use http://rst.aaroniles.net/ for a quick check. -- Regards, Markus Zoeller (markus_z) __ 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] [infra] nodepool: statsd metric details?
Is there a doc I didn't find which explains the metrics nodepool is emitting to statsd? Zuul has this: https://docs.openstack.org/infra/zuul/admin/monitoring.html Nodepool only documents this: https://docs.openstack.org/infra/nodepool/installation.html?#statsd-and-graphite Any pointer is appreciated. -- Regards, Markus Zoeller (markus_z) __ 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] [infra] zuul/nodepool: ansible roles: statsd config?
We use the Ansible roles for nodepool and zuul In our 3rd party CI. We cannot set the *statsd* config in those roles. Namely the environment variables `STATSD_HOST` and `STATSD_PORT`. I didn't find the correct place where I can propose this, that's why I'm asking on this ML. Is it possible to add that to those Ansible roles? https://github.com/openstack/ansible-role-nodepool https://github.com/openstack/ansible-role-zuul -- Regards, Markus Zoeller (markus_z) __ 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] [openstack-ansible] group/host specific config file overrides: how-to?
On 23.08.2017 00:16, Jean-Philippe Evrard wrote: > Hello, > > The variables documented in each of the roles defaults/ are generally what > you can consider a user level interface (i.e.: what you can modify), while > the variables from vars/ are generally what's best to avoid overriding. > > We've been slowly phasing out variables insides templates, to exclusively > rely on config_template overrides (See also: [1] and [2]) > Please note that if a variable is deprecated, we are issuing a release note. > > [1]: https://github.com/openstack/openstack-ansible-os_nova/blob/ > 4b9100a612ba0e9449d792b2783b9ec50a8fb28e/tasks/nova_post_install.yml#L40 > [2]: https://docs.openstack.org/project-deploy-guide/ > openstack-ansible/ocata/app-advanced-config-override.html > > Best regards, > JP That helps resolving my issues. Thanks a lot! -- Regards, Markus Zoeller (markus_z) > > On Tue, Aug 22, 2017 at 1:24 PM, Markus Zoeller <mzoel...@linux.vnet.ibm.com >> wrote: > >> On 22.08.2017 09:46, Flávio Ramalho wrote: >>> Hi Markus, >>> >>> I think you can achieve what you want by simple overriding the host >>> variables, for example: >>> >>> In /etc/openstack_deploy/openstack_user_config.yml: >>> compute_hosts: >>>compute1: >>> ip: 192.168.100.12 >>> host_vars: >>>nova_reserved_host_memory_mb: 256 >>>compute2: >>> ip: 192.168.100.10 >>> >>> In this case you would have compute1 with reserved_host_memory_mb = 256 >> and >>> compute2 with the default value set for nova_reserved_host_memory_mb. >>> >>> >>> Flávio >> >> Oh, I didn't see those variables, good hint! I'll give it a try, maybe >> that's good enough for me. Thanks a lot Flavio! >> >> http://git.openstack.org/cgit/openstack/openstack-ansible-os >> _nova/tree/templates/nova.conf.j2 >> >> Despite that this will probably work, is that an "interface" I'm allowed >> to touch or is it considered an "internal/private" part of >> OpenStack-Ansible (and/or its roles)? >> >> -- >> Regards, Markus Zoeller (markus_z) >> >> >>> On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller < >> mzoel...@linux.vnet.ibm.com> >>> wrote: >>> >>>> On 21.08.2017 16:40, Andy McCrae wrote: >>>>> Hey Markus, >>>>> >>>>> >>>>>> I'm wondering which possibilities I have to do group/host specific >>>>>> config file overrides. After reading [1], I'm still a little clueless. >>>>>> To be specific, I have this setup (expressed as Ansible inventory >> file): >>>>>> >>>>>> [z_compute_nodes] >>>>>> compute1 >>>>>> # more nodes >>>>>> [x_compute_nodes] >>>>>> compute2 >>>>>> # more nodes >>>>>> [computes:children] >>>>>> z_compute_nodes >>>>>> x_compute_nodes >>>>>> >>>>>> As an example, I want to set Nova's config option >>>>>> `reserved_host_memory_mb` of the `DEFAULT` config file section: >>>>>> >>>>>> ### nova.conf >>>>>> [DEFAULT] >>>>>> reserved_host_memory_mb=$VALUE >>>>>> >>>>>> My goal is this: >>>>>> >>>>>> | reserved_host_memory_mb >>>>>> -- >>>>>> compute1 | 256 >>>>>> compute2 | 512 >>>>>> >>>>>> I know there are overrides like `nova_nova_conf_overrides`. >>>>>> So I tried to set a default override in `user_variables.yml`: >>>>>> >>>>>> ### /etc/openstack_deploy/user_variables.yml >>>>>> >>>>>> nova_nova_conf_overrides: >>>>>> DEFAULT: >>>>>> reserved_host_memory_mb: 512 >>>>>> >>>>>> But I wanted to override this depending on the host in >>>>>> `openstack_user_config.yml`: >>>>>> >>>>>> ### /etc/openstack_deploy/openstack_user_config.yml >>>>>> # [...] >>>>>> # nova hypervisors >>>>>> compute_hosts: >>>>>> compute1: >>>>&g
Re: [openstack-dev] [glance] docs: architecture or hw_architecture
On 23.08.2017 14:47, Brian Rosmaita wrote: > 'architecture' is one of the "common image properties" that was > introduced in Folsom in an effort to standardize use of image > metadata. It's not a mistake in the Glance docs, it's just that Nova > is looking for a differently named property. > > Glance has had a metadata definitions service [0,1] since Juno. It > provides a common API for vendors, admins, services, and users to > meaningfully define available key / value pair metadata that can be > used on different types of resources (images, artifacts, volumes, > flavors, aggregates, and other resources). A definition includes a > property’s key, its description, its constraints, and the resource > types to which it can be associated. It's probably a better place to > store this kind of information than in documentation. I think it's > under-utilized. > > [0] https://developer.openstack.org/api-ref/image/v2/metadefs-index.html > [1] https://docs.openstack.org/glance/latest/user/metadefs-concepts.html OK, I agree that the information to do it right is available: "The keys have different prefixes on images than on flavors. On flavors keys are prefixed with hw:, but on images the keys are prefixed with hw_." It's just not *that* easy to find and to deduct. I was looking for that information as an operator, to allow the Nova scheduler to do its work in a mixed arch environment (x86 + s390x) based on image properties. I still don't fully get it. In which use-case is `architecture` the correct property to set? -- Regards, Markus Zoeller (markus_z) > On Wed, Aug 23, 2017 at 5:45 AM, Markus Zoeller > <mzoel...@linux.vnet.ibm.com> wrote: >> On 22.08.2017 17:10, Markus Zoeller wrote: >>> I'm wondering if there is an issue in the docs which describe the >>> possible image metadata properties: >>> https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html# >>> >>> This document says to use `architecture` (e.g. x86_64 or s390x or ppc64) >>> but the Nova scheduler image properties filter uses `hw_architecture` >>> (note the *hw_* prefix): >>> https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44 >>> >>> Is that simply a mistake in the Glance docs or do I miss some kind of >>> conversion between those metadata keys? >>> >> >> Looks like only `hw_architecture` works in my x86 + s390x environment. >> I'm going to push an update to the Glance docs + an update to the >> `os_image` Ansible module which uses `cpu_arch` in its documentation: >> http://docs.ansible.com/ansible/latest/os_image_module.html >> >> -- >> Regards, Markus Zoeller (markus_z) >> >> __ 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] [glance] docs: architecture or hw_architecture
On 22.08.2017 17:10, Markus Zoeller wrote: > I'm wondering if there is an issue in the docs which describe the > possible image metadata properties: > https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html# > > This document says to use `architecture` (e.g. x86_64 or s390x or ppc64) > but the Nova scheduler image properties filter uses `hw_architecture` > (note the *hw_* prefix): > https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44 > > Is that simply a mistake in the Glance docs or do I miss some kind of > conversion between those metadata keys? > Looks like only `hw_architecture` works in my x86 + s390x environment. I'm going to push an update to the Glance docs + an update to the `os_image` Ansible module which uses `cpu_arch` in its documentation: http://docs.ansible.com/ansible/latest/os_image_module.html -- Regards, Markus Zoeller (markus_z) __ 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] [glance] docs: architecture or hw_architecture
I'm wondering if there is an issue in the docs which describe the possible image metadata properties: https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html# This document says to use `architecture` (e.g. x86_64 or s390x or ppc64) but the Nova scheduler image properties filter uses `hw_architecture` (note the *hw_* prefix): https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44 Is that simply a mistake in the Glance docs or do I miss some kind of conversion between those metadata keys? -- Regards, Markus Zoeller (markus_z) __ 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] [openstack-ansible] group/host specific config file overrides: how-to?
On 22.08.2017 09:46, Flávio Ramalho wrote: > Hi Markus, > > I think you can achieve what you want by simple overriding the host > variables, for example: > > In /etc/openstack_deploy/openstack_user_config.yml: > compute_hosts: >compute1: > ip: 192.168.100.12 > host_vars: >nova_reserved_host_memory_mb: 256 >compute2: > ip: 192.168.100.10 > > In this case you would have compute1 with reserved_host_memory_mb = 256 and > compute2 with the default value set for nova_reserved_host_memory_mb. > > > Flávio Oh, I didn't see those variables, good hint! I'll give it a try, maybe that's good enough for me. Thanks a lot Flavio! http://git.openstack.org/cgit/openstack/openstack-ansible-os_nova/tree/templates/nova.conf.j2 Despite that this will probably work, is that an "interface" I'm allowed to touch or is it considered an "internal/private" part of OpenStack-Ansible (and/or its roles)? -- Regards, Markus Zoeller (markus_z) > On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller <mzoel...@linux.vnet.ibm.com> > wrote: > >> On 21.08.2017 16:40, Andy McCrae wrote: >>> Hey Markus, >>> >>> >>>> I'm wondering which possibilities I have to do group/host specific >>>> config file overrides. After reading [1], I'm still a little clueless. >>>> To be specific, I have this setup (expressed as Ansible inventory file): >>>> >>>> [z_compute_nodes] >>>> compute1 >>>> # more nodes >>>> [x_compute_nodes] >>>> compute2 >>>> # more nodes >>>> [computes:children] >>>> z_compute_nodes >>>> x_compute_nodes >>>> >>>> As an example, I want to set Nova's config option >>>> `reserved_host_memory_mb` of the `DEFAULT` config file section: >>>> >>>> ### nova.conf >>>> [DEFAULT] >>>> reserved_host_memory_mb=$VALUE >>>> >>>> My goal is this: >>>> >>>> | reserved_host_memory_mb >>>> -- >>>> compute1 | 256 >>>> compute2 | 512 >>>> >>>> I know there are overrides like `nova_nova_conf_overrides`. >>>> So I tried to set a default override in `user_variables.yml`: >>>> >>>> ### /etc/openstack_deploy/user_variables.yml >>>> >>>> nova_nova_conf_overrides: >>>> DEFAULT: >>>> reserved_host_memory_mb: 512 >>>> >>>> But I wanted to override this depending on the host in >>>> `openstack_user_config.yml`: >>>> >>>> ### /etc/openstack_deploy/openstack_user_config.yml >>>> # [...] >>>> # nova hypervisors >>>> compute_hosts: >>>> compute1: >>>> ip: 192.168.100.12 >>>> host_vars: >>>> nova_nova_conf_overrides: >>>> DEFAULT: >>>> reserved_host_memory_mb: 256 >>>> compute2: >>>> ip: 192.168.100.10 >>>> >>> >>> Try change "host_vars" to "container_vars". >>> If that doesn't work let me know, I'll spin up a test to recreate the >>> actual problem, but at a glance that looks correct otherwise. >>> >> >> >> Replacing `host_vars` with `container_vars` didn't have an effect: >> >> ### controller1: /etc/openstack_deploy/openstack_user_config.yml >> # nova hypervisors >> compute_hosts: >> compute1: >> ip: 192.168.100.12 >> container_vars: >> nova_nova_conf_overrides: >> DEFAULT: >> reserved_host_memory_mb: 256 >> compute2: >> ip: 192.168.100.10 >> >> Both compute nodes still have the same $VALUE, although `compute1` >> should have 256: >> >> ### compute1: /etc/nova/nova.conf >> root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf >> reserved_host_memory_mb = 512 >> >> >> ### compute2: /etc/nova/nova.conf >> root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf >> reserved_host_memory_mb = 512 >> >> I'd like to avoid to introduce some "clever" dict merging algorithm I >> won't understand anymore after a few weeks. :/ >> >> Any hint is appreci
Re: [openstack-dev] [openstack-ansible] group/host specific config file overrides: how-to?
On 21.08.2017 16:40, Andy McCrae wrote:
> Hey Markus,
>
>
>> I'm wondering which possibilities I have to do group/host specific
>> config file overrides. After reading [1], I'm still a little clueless.
>> To be specific, I have this setup (expressed as Ansible inventory file):
>>
>> [z_compute_nodes]
>> compute1
>> # more nodes
>> [x_compute_nodes]
>> compute2
>> # more nodes
>> [computes:children]
>> z_compute_nodes
>> x_compute_nodes
>>
>> As an example, I want to set Nova's config option
>> `reserved_host_memory_mb` of the `DEFAULT` config file section:
>>
>> ### nova.conf
>> [DEFAULT]
>> reserved_host_memory_mb=$VALUE
>>
>> My goal is this:
>>
>> | reserved_host_memory_mb
>> --
>> compute1 | 256
>> compute2 | 512
>>
>> I know there are overrides like `nova_nova_conf_overrides`.
>> So I tried to set a default override in `user_variables.yml`:
>>
>> ### /etc/openstack_deploy/user_variables.yml
>>
>> nova_nova_conf_overrides:
>> DEFAULT:
>> reserved_host_memory_mb: 512
>>
>> But I wanted to override this depending on the host in
>> `openstack_user_config.yml`:
>>
>> ### /etc/openstack_deploy/openstack_user_config.yml
>> # [...]
>> # nova hypervisors
>> compute_hosts:
>> compute1:
>> ip: 192.168.100.12
>> host_vars:
>> nova_nova_conf_overrides:
>> DEFAULT:
>> reserved_host_memory_mb: 256
>> compute2:
>> ip: 192.168.100.10
>>
>
> Try change "host_vars" to "container_vars".
> If that doesn't work let me know, I'll spin up a test to recreate the
> actual problem, but at a glance that looks correct otherwise.
>
Replacing `host_vars` with `container_vars` didn't have an effect:
### controller1: /etc/openstack_deploy/openstack_user_config.yml
# nova hypervisors
compute_hosts:
compute1:
ip: 192.168.100.12
container_vars:
nova_nova_conf_overrides:
DEFAULT:
reserved_host_memory_mb: 256
compute2:
ip: 192.168.100.10
Both compute nodes still have the same $VALUE, although `compute1`
should have 256:
### compute1: /etc/nova/nova.conf
root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf
reserved_host_memory_mb = 512
### compute2: /etc/nova/nova.conf
root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf
reserved_host_memory_mb = 512
I'd like to avoid to introduce some "clever" dict merging algorithm I
won't understand anymore after a few weeks. :/
Any hint is appreciated!
--
Regards, Markus Zoeller (markus_z)
>>
>> After testing this locally, it turned out that *both* hosts will
>> have 512 for $VALUE. which was not my intended configuration.
>>
>> Please note that I only used 2 hosts here as an example but I'm looking
>> for a solution which scales with much more hosts. I'm also applying
>> those settings in a templated way like this:
>>
>> ### /etc/openstack_deploy/openstack_user_config.yml
>> # [...]
>> # nova hypervisors
>> compute_hosts:
>> {% for host in groups['computes'] %}
>> {{ hostvars[host]['inventory_hostname'] }}:
>> ip: {{ hostvars[host]['ansible_host'] }}
>> {% endfor %}
>>
>> The reason is, that I use the same steps for different environments
>> (dev, test, prod) with a different amount of nodes.
>>
>> Any tips how to do this properly?
>>
>>
> Andy
>
>
>
> __
> 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] [openstack-ansible] group/host specific config file overrides: how-to?
I'm wondering which possibilities I have to do group/host specific
config file overrides. After reading [1], I'm still a little clueless.
To be specific, I have this setup (expressed as Ansible inventory file):
[z_compute_nodes]
compute1
# more nodes
[x_compute_nodes]
compute2
# more nodes
[computes:children]
z_compute_nodes
x_compute_nodes
As an example, I want to set Nova's config option
`reserved_host_memory_mb` of the `DEFAULT` config file section:
### nova.conf
[DEFAULT]
reserved_host_memory_mb=$VALUE
My goal is this:
| reserved_host_memory_mb
--
compute1 | 256
compute2 | 512
I know there are overrides like `nova_nova_conf_overrides`.
So I tried to set a default override in `user_variables.yml`:
### /etc/openstack_deploy/user_variables.yml
nova_nova_conf_overrides:
DEFAULT:
reserved_host_memory_mb: 512
But I wanted to override this depending on the host in
`openstack_user_config.yml`:
### /etc/openstack_deploy/openstack_user_config.yml
# [...]
# nova hypervisors
compute_hosts:
compute1:
ip: 192.168.100.12
host_vars:
nova_nova_conf_overrides:
DEFAULT:
reserved_host_memory_mb: 256
compute2:
ip: 192.168.100.10
After testing this locally, it turned out that *both* hosts will
have 512 for $VALUE. which was not my intended configuration.
Please note that I only used 2 hosts here as an example but I'm looking
for a solution which scales with much more hosts. I'm also applying
those settings in a templated way like this:
### /etc/openstack_deploy/openstack_user_config.yml
# [...]
# nova hypervisors
compute_hosts:
{% for host in groups['computes'] %}
{{ hostvars[host]['inventory_hostname'] }}:
ip: {{ hostvars[host]['ansible_host'] }}
{% endfor %}
The reason is, that I use the same steps for different environments
(dev, test, prod) with a different amount of nodes.
Any tips how to do this properly?
References:
[1]
https://docs.openstack.org/project-deploy-guide/openstack-ansible/draft/app-advanced-config-override.html
--
Regards, Markus Zoeller (markus_z)
__
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] Proposal to require bugs for tech debt
On 16.08.2017 18:40, Alex Schultz wrote: > On Wed, Aug 16, 2017 at 8:24 AM, Markus Zoeller > <mzoel...@linux.vnet.ibm.com> wrote: >> On 16.08.2017 02:59, Emilien Macchi wrote: >>> On Tue, Aug 15, 2017 at 5:46 PM, Alex Schultz <aschu...@redhat.com> wrote: >>>> Hey folks, >>>> >>>> I'm proposing that in order to track tech debt that we're adding in as >>>> part of development that we create a way to track these items and not >>>> approve them without a bug (and a reference to said bug)[0]. Please >>>> take a moment to review the proposed policy and comment. I would like >>>> to start this for the queens cycle. >>> >>> I also think we should frequently review the status of these bugs. >>> Maybe unofficially from time to time and officially during milestone-3 >>> of each cycle. >>> >>> I like the proposal so far, thanks. >>> >> >> FWIW, for another (in-house) project, I create a page called "technical >> debt" in the normal docs directory of the project. That way, I can add >> the "reminder" with the same commit which introduced the technical debt >> in the code. Similar to what OpenStack already does with the >> release-notes. The list of technical debt items is then always visible >> in the docs and not a query in the bug-tracker with tags (or something >> like that). >> Just an idea, maybe it applicable here. >> > > Yea that would a good choice if we only had a single or a low number > of projects under the tripleo umbrella. The problem is we have many > different components which contribute to tech debt so storing it in > each repo would be hard to track. I proposed bugs because it would be > a singular place for reporting. For projects with fewer deliverable > storing it like release notes is a good option. > > Thanks, > -Alex > No biggie. A single project was my implicit assumption, that's true. Wish you good luck. -- Regards, Markus Zoeller (markus_z) >> -- >> Regards, Markus Zoeller (markus_z) >> >>>> A real world example of where this would beneficial would be the >>>> workaround we had for buggy ssh[1]. This patch was merged 6 months ago >>>> to work around an issue in ssh that was recently fixed. However we >>>> would most likely never have remembered to revert this. It was only >>>> because someone[2] spotted it and mentioned it that it is being >>>> reverted now. >>>> >>>> Thanks, >>>> -Alex >>>> >>>> [0] https://review.openstack.org/#/c/494044/ >>>> [1] >>>> https://review.openstack.org/#/q/6e8e27488da31b3b282fe1ce5e07939b3fa11b2f,n,z >>>> [2] Thanks pabelanger >>>> __ 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] Proposal to require bugs for tech debt
On 16.08.2017 02:59, Emilien Macchi wrote: > On Tue, Aug 15, 2017 at 5:46 PM, Alex Schultz <aschu...@redhat.com> wrote: >> Hey folks, >> >> I'm proposing that in order to track tech debt that we're adding in as >> part of development that we create a way to track these items and not >> approve them without a bug (and a reference to said bug)[0]. Please >> take a moment to review the proposed policy and comment. I would like >> to start this for the queens cycle. > > I also think we should frequently review the status of these bugs. > Maybe unofficially from time to time and officially during milestone-3 > of each cycle. > > I like the proposal so far, thanks. > FWIW, for another (in-house) project, I create a page called "technical debt" in the normal docs directory of the project. That way, I can add the "reminder" with the same commit which introduced the technical debt in the code. Similar to what OpenStack already does with the release-notes. The list of technical debt items is then always visible in the docs and not a query in the bug-tracker with tags (or something like that). Just an idea, maybe it applicable here. -- Regards, Markus Zoeller (markus_z) >> A real world example of where this would beneficial would be the >> workaround we had for buggy ssh[1]. This patch was merged 6 months ago >> to work around an issue in ssh that was recently fixed. However we >> would most likely never have remembered to revert this. It was only >> because someone[2] spotted it and mentioned it that it is being >> reverted now. >> >> Thanks, >> -Alex >> >> [0] https://review.openstack.org/#/c/494044/ >> [1] >> https://review.openstack.org/#/q/6e8e27488da31b3b282fe1ce5e07939b3fa11b2f,n,z >> [2] Thanks pabelanger >> >> __ >> 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] [all] review.openstack.org downtime and Gerrit upgrade
On 03.08.2017 00:57, Clark Boylan wrote: > Hello, > > The Infra team is planning to upgrade review.openstack.org from Gerrit > 2.11 to Gerrit 2.13 on September 18, 2017. > [...] > > If you have any concerns or feedback please let the Infra team know. > > Thank you, > Clark Does this maybe include the "hashtag" feature [1] to assign a custom taxonomy to changes? We talked about that back in 2015 [2]. After reading [3] I was still a little clueless, TBH. [1] https://en.wikipedia.org/wiki/Tag_(metadata) [2] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079835.html [3] https://phabricator.wikimedia.org/T37534 -- Regards, Markus Zoeller (markus_z) __ 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] [openstack-ansible] restrictive umask / file permissions in target hosts
On 25.07.2017 16:20, Major Hayden wrote: > On 07/25/2017 08:36 AM, Markus Zoeller wrote: >> A short grep in 'openstack-ansible' shows that the file permissions are >> often not set. I used these commands: >> >> $ grep -n -R "template:" --include \*.yml -A 5 >> $ grep -n -R "copy:" --include \*.yml -A 5 >> >> IIUC, we're using 'ansible-lint' for style checks. Does it make sense to >> add a new rule which warns/enforces to set the mode (or group/user)? > > I'd definitely be in support of that. We should be as explicit as possible > when we deploy files and templates. > > -- > Major Hayden To close the loop, I've added a bug report to track this effort: https://bugs.launchpad.net/openstack-ansible/+bug/1706595 TBH, I'm not sure when/if I can work on that. I also don't know how the effort prioritization works within the openstack-ansible project. -- Regards, Markus Zoeller (markus_z) __ 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] [openstack-ansible] restrictive umask / file permissions in target hosts
On 17.07.2017 23:13, Major Hayden wrote: > On 07/04/2017 03:54 AM, Markus Zoeller wrote: >> How do you deal with hosts which have a restrictive umask of 077 >> *before* openstack-ansible starts the setup? Do you start with the >> default umask of 022 and opt-in later to that security hardening[1]? > > We don't test for that in the OpenStack-Ansible gates since those settings > from openstack-ansible-security/ansible-hardening are disabled by default. > It's possible to start with 022 and switch to 077 later, but that could cause > additional problems. > >> What's the development policy of openstack-ansible regarding setting >> file or directory permissions in tasks? >> >> * is a umask value of 022 assumed for tasks to work? > > Yes. > >> * should tasks always explicitly set the file/dir mode? > > They certainly should, and if they don't, we should adjust those tasks. I'd > rather be as explicit as possible to reduce the chances of problems down the > road if distribution defaults change. > A short grep in 'openstack-ansible' shows that the file permissions are often not set. I used these commands: $ grep -n -R "template:" --include \*.yml -A 5 $ grep -n -R "copy:" --include \*.yml -A 5 IIUC, we're using 'ansible-lint' for style checks. Does it make sense to add a new rule which warns/enforces to set the mode (or group/user)? -- Regards, Markus Zoeller (markus_z) > -- > Major Hayden > > __ > 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] [openstack-ansible] restrictive umask / file permissions in target hosts
How do you deal with hosts which have a restrictive umask of 077 *before* openstack-ansible starts the setup? Do you start with the default umask of 022 and opt-in later to that security hardening[1]? What's the development policy of openstack-ansible regarding setting file or directory permissions in tasks? * is a umask value of 022 assumed for tasks to work? * should tasks always explicitly set the file/dir mode? * other options I'm not aware of? Background -- The (internal) folks who gave me the target hosts for openstack-ansible set the umask to 077 *before* I started the installation and I wasn't aware of that setting. So I spent some time figuring out why the nginx server in the repo container can't serve files like the requirements file "requirements_absolute_requirements.txt"[2] because of file permissions like this: -rw--- 1 root root [...] requirements_absolute_requirements.txt This also affects the nginx config files (which, for example, set the 'autoindex' behavior, which is needed to serve the python wheels): cd /etc/nginx/sites-available/ ll openstack-slushee.vhost -rw--- 1 root root [...] openstack-slushee.vhost Not sure if that was also the root cause of [3]. References -- [1] https://github.com/openstack/openstack-ansible-security/blob/40c744c86dd7e5e53e88a5ddd7389333a26f92d2/defaults/main.yml#L340-L363 [2] https://github.com/openstack/openstack-ansible-repo_build/blob/fe3ae20f74a912925d5c78040984957a6d55f9de/tasks/repo_post_build.yml#L43-L46 [3] https://stackoverflow.com/questions/42286765/using-repo-other-then-pypi-with-pip -- Regards, Markus Zoeller (markus_z) __ 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] bug triage experimentation
On 28.06.2017 16:50, Sean Dague wrote: > On 06/28/2017 10:33 AM, Ben Nemec wrote: >> >> >> On 06/23/2017 11:52 AM, Sean Dague wrote: >>> The Nova bug backlog is just over 800 open bugs, which while >>> historically not terrible, remains too large to be collectively usable >>> to figure out where things stand. We've had a few recent issues where we >>> just happened to discover upgrade bugs filed 4 months ago that needed >>> fixes and backports. >>> >>> Historically we've tried to just solve the bug backlog with volunteers. >>> We've had many a brave person dive into here, and burn out after 4 - 6 >>> months. And we're currently without a bug lead. Having done a big giant >>> purge in the past >>> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html) >>> >>> I know how daunting this all can be. >>> >>> I don't think that people can currently solve the bug triage problem at >>> the current workload that it creates. We've got to reduce the smart >>> human part of that workload. >>> >>> But, I think that we can also learn some lessons from what active github >>> projects do. >>> >>> #1 Bot away bad states >>> >>> There are known bad states of bugs - In Progress with no open patch, >>> Assigned but not In Progress. We can just bot these away with scripts. >>> Even better would be to react immediately on bugs like those, that helps >>> to train folks how to use our workflow. I've got some starter scripts >>> for this up at - https://github.com/sdague/nova-bug-tools >> >> Just saw the update on https://bugs.launchpad.net/nova/+bug/1698010 and >> I don't agree that assigned but not in progress is an invalid state. If >> it persists for a period of time then sure, but to me assigning yourself >> a bug is a signal that you're working on it and nobody else needs to. >> Otherwise you end up with multiple people working a bug without >> realizing someone else already was. I've seen that happen more than once. > > The other case, where folks assign themselves and never do anything, > happens about 100 times a month. > > We don't live in an exclusive lock environment, anyone can push a fix > for a bug, and gerrit assigns it to them. I don't see why we'd treat LP > any differently. Yes, this sometimes leads to duplicate fixes, however > in the current model it's far more frequent for bugs to be blocked away > as "assigned" when no one is working on them. > > A future version might be smarter and give folks a 7 day window or > something, but parsing back the history to understand the right logic > there is tricky enough that it's a future enhancement at best. > > -Sean > +1 That happened so frequently I made a query for that: http://45.55.105.55:8082/bugs-dashboard.html#tabInProgressStale After poking people to get the actual state, 99% of the time the answer was "I couldn't work on it, please remove my assignment.". -- Regards, Markus Zoeller (markus_z) __ 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] bug triage experimentation
gs >> under various tags. This will help visualize how we are doing >> (hopefully) and where the biggest piles of issues are. >> >> The intent is the normal unit of interaction would be one of these >> smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36 >> vmware bugs. It would also highlight the rates of change in these piles, >> and what's getting attention and what is not. >> > > I do wonder if Markus already wrote such reporting tools. AFAIR, he had > a couple of very interesting reportings (and he also worked hard on the > bugs taxonomy) so we could potentially leverage those. > > -Sylvain > The things I had/have are: * a Grafana dashboard: http://45.55.105.55:3000/dashboard/db/openstack-bugs * a script to collect the metrics and store them in statsd: http://markuszoeller.github.io/posts/2016/03/06/grafana-graphite-statsd/#collect-and-push-custom-metrics * a bunch of "helper scripts" for various use-cases: https://github.com/markuszoeller/openstack/tree/master/scripts/launchpad * a dashboard which shows the results of some of those scripts: http://45.55.105.55:8082/bugs-dashboard.html Most of the time in the past, I asked for logs, versions and configuration. Tooling for that could save some back-and-forth. >> >> This is going to be kind of an ongoing experiment, but as we currently >> have no one spear heading bug triage, it seemed like a good time to try >> this out. >> >> Comments and other suggestions are welcomed. The tooling will have the >> nova flow in mind, but I'm trying to make it so it takes a project name >> as params on all the scripts, so anyone can use it. It's a little hack >> and slash right now to discover what the right patterns are. >> >> -Sean >> > > __ > 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 > -- Regards, Markus Zoeller (markus_z) __ 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] [glance] [cinder] [neutron] - Global Request ID progress
On 06.06.2017 13:49, Sean Dague wrote: > Some good progress has been made so far on Global Request ID work in the > core IaaS layer, here is where we stand. > > STATUS > > oslo.context / oslo.middleware - everything DONE > > devstack logging additional global_request_id - DONE > > cinder: > - client supports global_request_id - DONE > - Cinder calls Nova with global_request_id - TODO (waiting on Novaclient > release) > - Cinder calls Glance with global_request_id - TODO > > neutron: > - client supports global_request_id - IN PROGRESS (this landed, > released, but the neutron client release had to be blocked for unrelated > issues). > - Neutron calls Nova with global_request_id - TODO (waiting on > Novaclient release) > > nova: > - Convert to oslo.middleware (to accept global_request_id) - DONE > - client supports global_request_id - IN PROGRESS (waiting for release > here - https://review.openstack.org/#/c/471323/) > - Nova calls cinder with global_request_id - DONE > - Nova calls neutron with global_request_id - TODO (waiting on working > neutronclient release) > - Nova calls Glance with global request id - IN PROGRESS (review needs > final +2 here https://review.openstack.org/#/c/467242/) > > glance: > - client supports global_request_id - DONE > - Glance supports setting global_request_id - IN REVIEW > (https://review.openstack.org/#/c/468443/) *(some debate on this). > > > Everything except the last glance change is uncontroversial, and it's > just mechanics and project management to get things through in the > correct order. > > > The Glance support for global_request_id has hit a bump in the review > process as there is a concern that it's changing the API. Though from an > end user perspective that's not happening, it's just changing which > field things get logged into. We'll see if we can work through that. > > -Sean > FWIW, I *really* appreciate such crisp updates on the ML. Thanks a lot for your time writing them. -- Regards, Markus Zoeller (markus_z) __ 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] [devstack] systemd + ENABLED_SERVICES + user_init_file
On 11.05.2017 15:56, Markus Zoeller wrote: > I'm working on a nova live-migration hook which configures and starts > the nova-serialproxy service, runs a subset of tempest tests, and tears > down the previously started service. > >https://review.openstack.org/#/c/347471/47 > > After the change to "systemd", I thought all I have to do was to start > the service with: > >systemctl enable devstack@n-sproxy >systemctl restart devstack@n-sproxy > > But this results in the error "Failed to execute operation: No such file > or directory". The reason is, that there is no systemd "user unit file". > This file gets written in Devstack at: > > https://github.com/openstack-dev/devstack/blob/37a6b0b2d7d9615b9e89bbc8e8848cffc3bddd6d/functions-common#L1512-L1529 > > For that to happen, a service must be in the list "ENABLED_SERVICES": > > https://github.com/openstack-dev/devstack/blob/37a6b0b2d7d9615b9e89bbc8e8848cffc3bddd6d/functions-common#L1572-L1574 > > Which is *not* the case for the "n-sproxy" service: > > https://github.com/openstack-dev/devstack/blob/8b8441f3becbae2e704932569bff384dcc5c6713/stackrc#L55-L56 > > I'm not sure how to approach this problem. I could: > 1) add "n-sproxy" to the default ENABLED_SERVICES list for Nova in >Devstack > 2) always write the systemd user unit file in Devstack >(despite being an enabled service) > 3) Write the "user unit file" on the fly in the hook (in Nova). > 4) ? > > Right now I tend to option 2, as I think it brings more flexibility (for > other services too) with less change in the set of default enabled > services in the gate. > > Is this the right direction? Any other thoughts? > > FWIW, here's my attempt to implement 2): https://review.openstack.org/#/c/469390/ -- Regards, Markus Zoeller (markus_z) __ 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] [devstack] systemd + ENABLED_SERVICES + user_init_file
I'm working on a nova live-migration hook which configures and starts the nova-serialproxy service, runs a subset of tempest tests, and tears down the previously started service. https://review.openstack.org/#/c/347471/47 After the change to "systemd", I thought all I have to do was to start the service with: systemctl enable devstack@n-sproxy systemctl restart devstack@n-sproxy But this results in the error "Failed to execute operation: No such file or directory". The reason is, that there is no systemd "user unit file". This file gets written in Devstack at: https://github.com/openstack-dev/devstack/blob/37a6b0b2d7d9615b9e89bbc8e8848cffc3bddd6d/functions-common#L1512-L1529 For that to happen, a service must be in the list "ENABLED_SERVICES": https://github.com/openstack-dev/devstack/blob/37a6b0b2d7d9615b9e89bbc8e8848cffc3bddd6d/functions-common#L1572-L1574 Which is *not* the case for the "n-sproxy" service: https://github.com/openstack-dev/devstack/blob/8b8441f3becbae2e704932569bff384dcc5c6713/stackrc#L55-L56 I'm not sure how to approach this problem. I could: 1) add "n-sproxy" to the default ENABLED_SERVICES list for Nova in Devstack 2) always write the systemd user unit file in Devstack (despite being an enabled service) 3) Write the "user unit file" on the fly in the hook (in Nova). 4) ? Right now I tend to option 2, as I think it brings more flexibility (for other services too) with less change in the set of default enabled services in the gate. Is this the right direction? Any other thoughts? -- Regards, Markus Zoeller (markus_z) __ 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] [all] Yakumo: Pythonic, unified OpenStack client library
On 03.05.2017 04:46, Akira Yoshiyama wrote: > Hello all, > > I'm pleased to announce Yakumo, yet another unified OpenStack client > library with an interactive shell. You can find Yakumo below: > >PyPI: https://pypi.python.org/pypi/yakumo/ >Github: https://github.com/yosshy/python-yakumo/ > > Yakumo development focuses to: > > * Pythonic: handles each cloud resource as an object in the same manner > * Unified: handles all OpenStack APIs at once > * Less dependency: no import of other OpenStack client libraries > > Why do we have to specify IDs of cloud resources in Python > programming? Python is an object-oriented programming language. IMO, > we should use objects to represent cloud resources, including method > arguments. It's one of the reasons I've started Yakumo project. > > Yakumo 0.11.0 suports OpenStack APIs below: > > * Identity API v2/v3 > * Compute API v2 > * Networking v2 > * Image Service API v1/v2 > * Block Storage v1/v2 > * Object Storage v1 > > Yakumo has 23 sample smoke tests below for the APIs now. It's useful > to test your cloud and learn usage of Yakumo. > >https://github.com/yosshy/python-yakumo/tree/master/yakumo/smoketests > > And also you can use 'ossh', an interactive python shell in Yakumo. > It's a good example. > # ossh --os-cloud=mypackstack > > Finding existing resources: > (c is an client object automatically generated for mypackstack environment) >>>> i = c.image.find_one(name="trusty") >>>> f = c.flavor.find_one(name='m1.small') >>>> k = c.key_pair.find_one(name='key1') >>>> n = c.network.find_one(name='private') >>>> i, f, k, n > ( (id="887b0393-5065-4bcf-941d-623100baa06e", name="trusty")>, > , > , > (id="22e3fa30-11c0-4065-bbf7-8d8bbb50f63b", name="private")>) > > Creating a server: >>>> s = c.server.create(name='vm1', image=i, flavor=f, networks=[n], >>>> key_pair=k) >>>> s > (id="b1477f6c-bbc4-4c37-ba05-14b935a5d08c" empty)> > > Waiting for building task finished: >>>> s.wait_for_finished() >>>> s.status > u'ACTIVE' > > Deleting the server: >>>> s.delete() > > See README for more usage and details: > >https://github.com/yosshy/python-yakumo/blob/master/README.md > > Feedback is welcome! > > Cheers, > Akira Yoshiyama > > __ > 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 > The interface looks nice! The docs too! I like the openstack-client for CLI stuff, but I think I will give your client a shot when I have to hack functional tests in python scripts which don't need to be in Tempest. -- Regards, Markus Zoeller (markus_z) __ 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] about usage of /consoles
On 21.04.2017 12:12, Chen CH Ji wrote: > > Per https://bugs.launchpad.net/nova/+bug/1682303 , POST with return 200 > while GET returns [] is weird > what's the purpose of /consoles? looks like > https://github.com/openstack/nova/blob/master/nova/console/rpcapi.py#L72 > will send a rpc message and which service is the reciever of this message > and handle it? Thanks > > Best Regards! > > Kevin (Chen) Ji 纪 晨 Looks like this API works for the "Xen VNC proxy" service only. The console manager triggers the console creation here: https://github.com/openstack/nova/blob/66c661258873e2544e286099c4bc027c26c851c4/nova/console/manager.py#L79 The XVPConsoleProxy implements it here: https://github.com/openstack/nova/blob/46b3a3ca1ac3a5ffdc7c5420263223f2d3b9a660/nova/console/xvp.py#L56-L58 Looks like that service runs with default Devstack settings as service "nova-xvpvncproxy": https://github.com/openstack-dev/devstack/blob/f3b2f4c85307b14f115a020f5eaf6c92026b55b4/lib/nova#L892-L892 The API microversion 2.6 introduced a consolidation of the remote consoles: https://github.com/openstack/nova/blob/3e032fd45be28c6098235ce336e675d03ebc6619/nova/api/openstack/compute/schemas/remote_consoles.py#L101-L102 Could it be that the "GET /console" API shouldn't be available anymore since microversion 2.6? api-ref about the consoles: https://developer.openstack.org/api-ref/compute/?expanded=get-vnc-console-os-getvncconsole-action-deprecated-detail,create-remote-console-detail -- Regards, Markus Zoeller (markus_z) __ 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] Launchpad bugs cleaning day on Tuesday 4/25
On 20.04.2017 00:44, Maciej Szankin wrote: > We are going to have a Launchpad bugs cleaning day for Nova on Tuesday 4/25. > > This day will be purely about cleaning the garbage out of the Launchpad - > it is not the bug squashing day where people propose patches. > > If you are not familiar with bug triage, please refer to [1]. > > As indicated by the dashboard [2] created by Markus, we currently have: > > * 75 bugs that are inconsistent > * 44 bugs that are incomplete > * 44 bugs that are stale incomplete > * 170 bugs that are stale in progress > > We also currently have 787 open bug reports (291 confirmed, 63 new), which > is a lot. > Keeping the bug queue ordered is just as important as doing reviews and > contributes > to overall development of Nova. > > All help is more than welcome. > > [1] https://wiki.openstack.org/wiki/Nova/BugTriage > [2] http://45.55.105.55:8082/bugs-dashboard.html > > Cheers, > Maciej > > You might also like to consider to expire some of the old bug reports (>18months): https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py I did that back in July 2016 (be aware that some people may not like that): http://openstack.markmail.org/thread/i4drtyqddluwnp2m -- Regards, Markus Zoeller (markus_z) __ 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] Config option cleanup burndown
On 03.02.2017 21:37, Szankin, Maciej wrote: > On 2/3/17 2:26 PM, Singh, Sarafraj wrote: >> Matt, >> This chart is quite accurate. We are almost finished with this work. We have >> ~10 outstanding patches that did not land in Ocata. There are few more >> TODO’s left in the code to clean up and that should be it. >> >> -Raj >> >> On 2/3/17, 2:08 PM, "Matt Riedemann" <mrie...@linux.vnet.ibm.com> wrote: >> >> This is sort of a direct question to Markus, but how accurate is this >> burndown chart now? >> >> http://45.55.105.55:8082/config-options.html >> >> I think there is still work for this in Pike, but would like to get an >> idea of how much of the work is left from those more involved (maybe >> johnthetubaguy or sfinucan can respond to that?). >> >> -- >> >> Thanks, >> >> Matt Riedemann >> >> >> >> __ >> 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 >> > It is up-to-date for the categories/tags that it tracks, but there is > still a bit more underneath - there are few TODOs left in comments that > still require resolving, but we are close. I did not decide to put a > burndown chart up for them as there can be multiple reviews per file and > the whole thing can be messy. We have an etherpad [0] that tries to keep > track of every work item that is left for this bp. TODOs are up-to-date, > deprecation list requires an update (which I will do this evening or > Monday morning). > > There are 50 TODOs left in code (10 [it is not a 1-1 relation, this is a > coincidence] of them resolved in outstanding patches that Raj > mentioned), so it leaves 40 to resolve. Some of them are invalid, as the > code base has changed infinite number of times during this release, so I > have a WIP patch that tries to remove all no longer valid TODOs. > > [0] https://etherpad.openstack.org/p/config-options > > Cheers, > macsz > > > __ > 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 > Unfortunately, non-upstream work keeps me busy and I lost track what's happening upstream. :( @macsz: After you removed the no longer valid TODOs, would you ping me? I'll try to free some hours per week for upstream again. -- Regards, Markus Zoeller (markus_z) __ 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] [nova][dpm] multiple nova-compute services on *one* host?
TL;DR:
Is it advisable to run multiple nova-compute services within the same
operating system while each nova-compute service manages a different
(remote) hypervisor?
The longer version:
Co-workers and I are working on a new (out-of-tree [1]) driver for a
system z hypervisor [2]. A model of what we came up with looks like this:
compute-node(hostname=hansel)
+-+
| ++ ++++ |
| |nova1.conf | |nova2.conf ||nova3.conf | |
| | host=foo | | host=bar || host=baz | |
| +-^--+ +-^--++-^--+ |
| | | ||
| +-+--+ +-+--++-+--+ |
| || |||| |
| |nova-compute| |nova-compute||nova-compute| |
| || |||| |
| ++ ++++ |
+-+
| | |
| +--v--+ |
+---> HMC <--+
+--+--+
|
++
cpc1| | | cpc2
+---+ +--+
| | || | ||
| +-v--+ +-v--+ | | +--v-+ |
| || || | | || |
| | cpc-subset | | cpc-subset | | | | cpc-subset | |
| | name=foo | | name=bar | | | | name=baz | |
| || || | | || |
| ++ ++ | | ++ |
| | | |
+---+ +--+
The hypervisor itself is running inside a CPC [3]. All communication
with these hypervisors need to go via the REST API of a so-called "HMC".
A cpc-subset is a logical constraint of the overall available resources
inside a CPC. That's where the Nova instances will live in, as so-called
"partitions".
This sub-setting means, there is no 1-to-1 relationship of nova-compute
service to host/hypervisor anymore. We already tested that this works
in a small testing environment.
The diagram above shows, that we configured the `host` config option
with a value which is *not* related to the hostname of the compute node
(neither its IP address or FQDN).
The docs of the config option `[DEFAULT].host` makes me believe this is
*not* valid, as is says:
"Hostname, FQDN or IP address of this host. Must be valid within
AMQP key."
The first sentence is the one which raised doubts if our model is a
valid one. The second sentence "weakens" the first one a little. A valid
AMQP name could also be totally different from hostname, FQDN or IP
address.
The functional tests (e.g. [4]) on the other hand, make me believe our
model is a valid one, as the tests have code like this:
self.start_service('compute', host='fake-host')
self.start_service('compute', host='fake-host2')
Also, the developer docs [5] say:
"The one major exception is nova-compute, where a single process
runs on the hypervisor it is managing (except when using the VMware
or Ironic drivers)."
Our model is close to the one of Ironic IMO.
We also spent thought about using one single nova-compute service for
all CPCs. We rejected that idea, as we came to the conclusion that this
would be a single-point-of-failure which is also complicated to
configure. The interaction with the neutron networking-agent was also
not straight forward.
Long story short, are we bending the rules here or did I overlook code
usages of `[DEFAULT].host` where it *has to be* a network related
attribute like IP address / FQDN / hostname?
References:
[1] https://github.com/openstack/nova-dpm
[2] https://blueprints.launchpad.net/nova/+spec/dpm-driver
[3]
https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zmainframe/zconc_mfhwterms.htm
[4]
https://github.com/openstack/nova/blob/bcbfee183e74f696085fcd5c18aff333fc5f1403/nova/tests/unit/conductor/test_conductor.py#L1468-L1469
[5] http://docs.openstack.org/developer/nova/architecture.html
--
Regards, Markus Zoeller (markus_z)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
Re: [openstack-dev] [nova][bugs] Useful metrics?
On 13.12.2016 19:29, Augustina Ragwitz wrote: > Previously Markus Z. did some great work in putting together a dashboard > we've been using for bug queue maintenance. Are there additional reports > or visualizations of the bug queue that might be interesting or useful > for the team? Is there some information that might make bug skimming, > triaging, or even bug searching easier? > The code I used to create metrics for a stats/graphite/grafana setup can be taken from: https://gist.github.com/markuszoeller/3baa24ce1eccf1e05b5efb518e896a20 The configuration is done via: https://gist.github.com/markuszoeller/c4235ec08c3e6d4550a4ab28e93e6866 My (unstable and badly maintained) Grafana dashboard is at: http://45.55.105.55:3000/dashboard/db/openstack-bugs It has historical data starting from March 2016. My experiences with setting up a local test env for that is at: http://markuszoeller.github.io/posts/2016/03/06/grafana-graphite-statsd/ Would love to have that for Openstack (at least the core projects). It would give that area more visibility which could incentivize people to work there. -- Regards, Markus Zoeller (markus_z) __ 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] [devstack] devstack-plugin additional-pkg-repos: ocata summit working session?
On 11.10.2016 16:09, Kashyap Chamarthy wrote: > On Tue, Oct 11, 2016 at 02:09:33PM +0200, Markus Zoeller wrote: > > [Snip well-written backrgound detail] > >> Request >> --- >> My question is, if you have interest in this plugin and its >> capabilities, are you at the Summit in Barcelona and do you have time >> for a short working session there? Maybe on Friday during the >> contributors meetup? >> >> https://etherpad.openstack.org/p/ocata-nova-summit-meetup > > I've made a note to be present there. > >> Possible action/discussion items >> >> * How to create a "*.deb" package out of the source code of >> libvirt/qemu? (surprisingly enough, I'm still struggling with this) > > Probably check with some of the Debian packagers on the list? > > FWIW, I'm familiar with producing RPM builds for libvirt / QEMU for > Fedora from their respective Git sources, as I make scratch builds for > testing often. > >> * How should we specify the packages and versions to install in the gate >> job? >> * When do we build new packages and increase the version in the gate? >> * Actually hack some code and push it > > Another point for working there > >https://review.openstack.org/#/c/313568/4 -- Plugin to setup >libvirt/QEMU from tar releases > Good pointer. I borrowed some of that for my Vagrant setup I mentioned. It still does a "make && make install" which can take some time. -- Regards, Markus Zoeller (markus_z) __ 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] [devstack] devstack-plugin additional-pkg-repos: ocata summit working session?
On 12.10.2016 10:52, Kashyap Chamarthy wrote: > On Tue, Oct 11, 2016 at 05:53:24PM +0200, Thomas Goirand wrote: >> On 10/11/2016 02:09 PM, Markus Zoeller wrote: >>> * How to create a "*.deb" package out of the source code of >>> libvirt/qemu? (surprisingly enough, I'm still struggling with this) >> >> What version of libvirt / qemu are you trying to build? libvirt 2.3.0 >> was released 6 days ago, and uploaded to Debian unstable 3 days ago. I >> don't think you need to manage the packaging yourself > > I think what Markus is talking about is to the ability to produce > packages from arbitrary Git commits to be able to test Nova with certain > new features from libvirt / QEMU which won't be available until a formal > release is pushed out. > > Somewhat analogus to the Fedora virt-preview-repository[1]: > > "The Virtualization Preview Repository is for people who would like > to test the very latest virtualization related packages. This > repository is intended primarily as an aid to testing / early > experimentation. It is not intended for 'production' deployment." > > > [1] https://fedoraproject.org/wiki/Virtualization_Preview_Repository > > [...] > Yes, exactly what kashyap said. At the Nova Mitaka midcycle we talked shortly about that and came to the conclusion that having packages saves a lot of (overall) time in the gate queue, compared to the usual "make && make install" every time. I'm new to the packaging topic and don't know the common tool-chain for such tasks. -- Regards, Markus Zoeller (markus_z) __ 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] [devstack] devstack-plugin additional-pkg-repos: ocata summit working session?
Backstory - Some time ago, tonyb and I started the work on a gate testing job which can install additional packages onto the testing node: https://github.com/openstack-infra/project-config/blob/b18a8a6cd1ed3865ff46e654e41b4959c342dc15/jenkins/jobs/devstack-gate.yaml#L536 The installation of the additional packages is done via a devstack-plugin called "addition-pkg-repos" (apr): https://github.com/openstack/devstack-plugin-additional-pkg-repos/ The inital trigger for this was the need to test newer versions of libvirt and qemu. The plugin itself was supposed to be generic for other packages too, which makes it also useful for Cinder and Neutron (and probably others too). Long story short, I couldn't make any progress there lately due to other responsibilities. I still see the need for such a plugin though. Right now I help myself with a Vagrant setup: https://github.com/markuszoeller/openstack/tree/master/scripts/vagrant/libvirt-qemu-source-U1404-VB With that, I could successfully test the "virtlogd" feature in Nova which needs (the 5 week old) Qemu 2.7.0: https://blueprints.launchpad.net/nova/+spec/libvirt-virtlogd Request --- My question is, if you have interest in this plugin and its capabilities, are you at the Summit in Barcelona and do you have time for a short working session there? Maybe on Friday during the contributors meetup? https://etherpad.openstack.org/p/ocata-nova-summit-meetup Possible action/discussion items * How to create a "*.deb" package out of the source code of libvirt/qemu? (surprisingly enough, I'm still struggling with this) * How should we specify the packages and versions to install in the gate job? * When do we build new packages and increase the version in the gate? * Actually hack some code and push it -- Regards, Markus Zoeller (markus_z) __ 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] resignation from bug czar role
On 05.09.2016 18:33, Timofei Durakov wrote: > Hi, folks, > > Thanks, Markus, for doing this job! I'm interested in this activity. > > Timofey Awesome! Thanks a ton! We can use https://appear.in/os-nova-bugs for a kickoff. I'll catch up with you in IRC for finding time and date. I'm in the UTC+1 timezone. > > On Mon, Sep 5, 2016 at 7:20 PM, Sylvain Bauza <sba...@redhat.com> wrote: > >> >> >> Le 05/09/2016 13:19, Markus Zoeller a écrit : >> >>> TL;DR: bug czar role for Nova is vacant from now on >>> >>> >>> After doing bug triage for ~1 year, which was quiet interesting, it's >>> time for me to move to different topics. My tasks within the company >>> internal team are shifting too. Unfortunately less Nova for me in the >>> next (hopefully short) time. That means I'm resigning from the bug czar >>> role as of now. >>> >>> >>> Observations in this timeframe >>> -- >>> >>> * The quality of most of the bug reports could be better. Very often >>> they are not actionable. A bug report which isn't actionable burns >>> resources without any benefit. The pattern I've seen is: >>> * 1/3 : invalid because they are support requests or a wrong >>> understanding >>> * 1/3 : could be reasonable but essential information is missing >>> * 1/3 : sounds reasonable + has a little info, should be looked at >>>Very few follow this template which is shown when you open a new >>> report: https://wiki.openstack.org/wiki/Nova/BugsTeam/BugReportTemplate >>> >>> * We get ~40 new bug reports per week. With the current number of people >>> who do bug triage, the number of overall bug reports doesn't decline. I >>> started collecting data 6 months ago: >>> >>> http://45.55.105.55:3000/dashboard/db/openstack-bugs?from= >>> now-6M=1 >>> >>> * I wish the cores would engage more in bug triaging. If one core every >>> other week would do the bug triage for 1 week, a core would have to do >>> that only once per dev cycle. I'm aware of the review backlog though :/ >>> >>> * I wish more non-cores would engage more in bug triaging. >>> >>> * We don't have contacts for a lot of areas in Nova: >>>https://wiki.openstack.org/wiki/Nova/BugTriage#Tag_Owner_List >>> >>> * Keeping the bug reports in a consistent state is cumbersome: >>>http://45.55.105.55:8082/bugs-dashboard.html#tabInProgressStale >>>We could introduce more automation here. >>> >>> >>> Things we should continue >>> - >>> >>> * Bug reports older that the oldest supported stable release should be >>>expired. Maybe best when the EOL tag gets applied. >>> >>> https://github.com/openstack-infra/release-tools/blob/master >>> /expire_old_bug_reports.py >>>http://lists.openstack.org/pipermail/openstack-dev/2016-May >>> /095654.html >>> >>> * We never came to a real conclusion how the ops communicated the RFEs >>> to us. The way of using "wishlist" bug reports wasn't successful IMO. >>> The last proposal was to use the ops ML to bring an RFE into some >>> actionable shape and then create a backlog spec out of it. >>>http://lists.openstack.org/pipermail/openstack-dev/2016-Mar >>> ch/089365.html >>> >>> >>> >>> Things we should start >>> -- >>> >>> * A cross-project discussion of (easy) ways to collect and send debug >>> data to upstream OpenStack. Almost no bug report in Nova had the result >>> of "sosreport" attached although we ask for that in the report template. >>> >>> >>> >>> Some last words >>> --- >>> >>> * Whoever wants to do the job next, I offer some kind of onboarding. >>> >>> * I'll push a change to remove the IRC meetings in the next few days: >>>http://eavesdrop.openstack.org/#Nova_Bugs_Team_Meeting >>> >>> * The tooling I used will still be available at: >>>https://github.com/markuszoeller/openstack/tree/master/ >>> scripts/launchpad >>> >>> * My server which hosts some dashboards will still be available at: >>>http://45.55.105.55:3000/dashboard/db/openstack-bugs >>>http://45.55.105.55:8082/bugs-dashboard.html >>>http://45.55.105.55:8082/bugs-stats.html >>> &
[openstack-dev] [nova] resignation from bug czar role
TL;DR: bug czar role for Nova is vacant from now on After doing bug triage for ~1 year, which was quiet interesting, it's time for me to move to different topics. My tasks within the company internal team are shifting too. Unfortunately less Nova for me in the next (hopefully short) time. That means I'm resigning from the bug czar role as of now. Observations in this timeframe -- * The quality of most of the bug reports could be better. Very often they are not actionable. A bug report which isn't actionable burns resources without any benefit. The pattern I've seen is: * 1/3 : invalid because they are support requests or a wrong understanding * 1/3 : could be reasonable but essential information is missing * 1/3 : sounds reasonable + has a little info, should be looked at Very few follow this template which is shown when you open a new report: https://wiki.openstack.org/wiki/Nova/BugsTeam/BugReportTemplate * We get ~40 new bug reports per week. With the current number of people who do bug triage, the number of overall bug reports doesn't decline. I started collecting data 6 months ago: http://45.55.105.55:3000/dashboard/db/openstack-bugs?from=now-6M=1 * I wish the cores would engage more in bug triaging. If one core every other week would do the bug triage for 1 week, a core would have to do that only once per dev cycle. I'm aware of the review backlog though :/ * I wish more non-cores would engage more in bug triaging. * We don't have contacts for a lot of areas in Nova: https://wiki.openstack.org/wiki/Nova/BugTriage#Tag_Owner_List * Keeping the bug reports in a consistent state is cumbersome: http://45.55.105.55:8082/bugs-dashboard.html#tabInProgressStale We could introduce more automation here. Things we should continue - * Bug reports older that the oldest supported stable release should be expired. Maybe best when the EOL tag gets applied. https://github.com/openstack-infra/release-tools/blob/master/expire_old_bug_reports.py http://lists.openstack.org/pipermail/openstack-dev/2016-May/095654.html * We never came to a real conclusion how the ops communicated the RFEs to us. The way of using "wishlist" bug reports wasn't successful IMO. The last proposal was to use the ops ML to bring an RFE into some actionable shape and then create a backlog spec out of it. http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html Things we should start -- * A cross-project discussion of (easy) ways to collect and send debug data to upstream OpenStack. Almost no bug report in Nova had the result of "sosreport" attached although we ask for that in the report template. Some last words --- * Whoever wants to do the job next, I offer some kind of onboarding. * I'll push a change to remove the IRC meetings in the next few days: http://eavesdrop.openstack.org/#Nova_Bugs_Team_Meeting * The tooling I used will still be available at: https://github.com/markuszoeller/openstack/tree/master/scripts/launchpad * My server which hosts some dashboards will still be available at: http://45.55.105.55:3000/dashboard/db/openstack-bugs http://45.55.105.55:8082/bugs-dashboard.html http://45.55.105.55:8082/bugs-stats.html * I did an evaluation of Storyboard in July 2016 and it looks promising. Give it a shot at: https://storyboard-dev.openstack.org/#!/project/2 If you don't like something there, push a change, it's Python based. * I'll still hang out in the IRC channels, but don't expect much from me. Thanks a lot to the people who helped making Nova a better project by doing bug triage! Special thanks to auggy who put a lot(!) of effort into that. See you (hopefully) in Barcelona! -- Regards, Markus Zoeller (markus_z) __ 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] no nova bugs team meeting today
Yeah, no meeting again, same reason :/ -- Regards, Markus Zoeller (markus_z) On 23.08.2016 14:21, Markus Zoeller wrote: > I get dragged into some internal stuff recently and didn't have time to > prepare anything or host the meeting. > > One noteworthy thing though, please tag any bug report, which > potentially blocks the RC in a few weeks, with "newton-rc-potential": > > https://bugs.launchpad.net/nova/+bugs?field.tag=newton-rc-potential > > There's less than 3 weeks left until RC1 target week starts. > __ 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] [nova] no nova bugs team meeting today
I get dragged into some internal stuff recently and didn't have time to prepare anything or host the meeting. One noteworthy thing though, please tag any bug report, which potentially blocks the RC in a few weeks, with "newton-rc-potential": https://bugs.launchpad.net/nova/+bugs?field.tag=newton-rc-potential There's less than 3 weeks left until RC1 target week starts. -- Regards, Markus Zoeller (markus_z) __ 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] test strategy for the serial console feature
On 11.08.2016 16:46, Markus Zoeller wrote: > On 11.08.2016 13:31, Daniel P. Berrange wrote: >> On Thu, Aug 11, 2016 at 07:19:42AM -0400, Sean Dague wrote: >>> On 08/11/2016 05:45 AM, Markus Zoeller wrote: >>>> On 26.07.2016 12:16, Jordan Pittier wrote: >>>>> Hi Markus >>>>> You don"t really need a whole new job for this. Just turn that flag to >>>>> True >>>>> on existing jobs. >>>>> >>>>> 30/40 seconds is acceptable. But I am surprised considering a VM usually >>>>> boots in 5 sec or so. Any idea of where that slowdown comes from ? >>>>> >>>>> On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller < >>>>> mzoel...@linux.vnet.ibm.com> wrote: >>> >>> We just had a big chat about this in the #openstack-nova IRC channel. To >>> summarize: >>> >>> The class of bugs that are really problematic are: >>> >>> * https://bugs.launchpad.net/nova/+bug/1455252 - Launchpad bug 1455252 >>> in OpenStack Compute (nova) "enabling serial console breaks live >>> migration" [High,In progress] - Assigned to sahid (sahid-ferdjaoui) >>> >>> * https://bugs.launchpad.net/nova/+bug/1595962 - Launchpad bug 1595962 >>> in OpenStack Compute (nova) "live migration with disabled vnc/spice not >>> possible" [Undecided,In progress] - Assigned to Markus Zoeller >>> (markus_z) (mzoeller) >>> >>> Which are both in the category of serial console breaking live >>> migration. It's the serial device vs. live migration that's most >>> problematic. Serial consoles themselves haven't broken badly recently. >>> Given that we don't do live migration testing in most normal jobs, the >>> Tempest jobs aren't really going to help here. >>> >>> The dedicated live-migration job is being targeted. >>> >>> Serial console support is currently a function at the compute level. >>> Which is actually a little odd. Because it means that all guests on a >>> compute must be serial console, or must not. Imagine a compute running >>> Linux, Windows, FreeBSD guests. It's highly unlikely that you want to >>> force serial console one way or another on all of those the same way. >>> This is probably something that makes sense to add as an image >>> attribute, because images will need guest configuration to support >>> serial consoles. As an image attribute this would also help on testing >>> because we could mix / match in a single run. >> >> There is actually image properties for this, but the way it is all >> implemented right now is just insane. > > You're talking about "hw_serial_port_count" I assume? I'm not aware of > any other property for that. Sean was talking about enabling the serial > console per image/flavor property IIUC. Nvm, I understand it now. The crucial point should be this one: https://github.com/openstack/nova/blob/a059c8453ea3739e45ea1cc56eacc82603a25b0f/nova/virt/libvirt/driver.py#L4101-L4103 in combination with: https://github.com/openstack/nova/blob/ad0047e97b2847412ee28bad6a3bfb48395add35/nova/virt/hardware.py#L198-L198 > >> For QEMU/KVM (on x86) currently, by default you get >> >> - a serial port which is connected to a file >> - a serial port which is connected to a pty >> >> If you turned on the serial_console option in nova.conf you instead get >> >> - one or more serial ports connected to a tcp port >> - a serial port which is connected to a pty >> >> The number of serial ports is based off an image property ( >> hw_serial_port_count), but strangely the code doesn't honour a >> value of 0 for that. In addition the last serial port connected >> to a pty should really not even exist at that point. >> >> We should aim to get to a place where we have 'serial_console.enabled' >> default to True in nova.conf and hw_serial_port_count setting how many >> are created, with 0 being a valid number. Never create any other serial >> ports that were not requested. >> >> Regards, >> Daniel >> > > Allowing '0' as property value sounds like a good approach. > Let me check with a PoC how this could look like. -- Regards, Markus Zoeller (markus_z) __ 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] test strategy for the serial console feature
On 11.08.2016 13:31, Daniel P. Berrange wrote: > On Thu, Aug 11, 2016 at 07:19:42AM -0400, Sean Dague wrote: >> On 08/11/2016 05:45 AM, Markus Zoeller wrote: >>> On 26.07.2016 12:16, Jordan Pittier wrote: >>>> Hi Markus >>>> You don"t really need a whole new job for this. Just turn that flag to True >>>> on existing jobs. >>>> >>>> 30/40 seconds is acceptable. But I am surprised considering a VM usually >>>> boots in 5 sec or so. Any idea of where that slowdown comes from ? >>>> >>>> On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller < >>>> mzoel...@linux.vnet.ibm.com> wrote: >> >> We just had a big chat about this in the #openstack-nova IRC channel. To >> summarize: >> >> The class of bugs that are really problematic are: >> >> * https://bugs.launchpad.net/nova/+bug/1455252 - Launchpad bug 1455252 >> in OpenStack Compute (nova) "enabling serial console breaks live >> migration" [High,In progress] - Assigned to sahid (sahid-ferdjaoui) >> >> * https://bugs.launchpad.net/nova/+bug/1595962 - Launchpad bug 1595962 >> in OpenStack Compute (nova) "live migration with disabled vnc/spice not >> possible" [Undecided,In progress] - Assigned to Markus Zoeller >> (markus_z) (mzoeller) >> >> Which are both in the category of serial console breaking live >> migration. It's the serial device vs. live migration that's most >> problematic. Serial consoles themselves haven't broken badly recently. >> Given that we don't do live migration testing in most normal jobs, the >> Tempest jobs aren't really going to help here. >> >> The dedicated live-migration job is being targeted. >> >> Serial console support is currently a function at the compute level. >> Which is actually a little odd. Because it means that all guests on a >> compute must be serial console, or must not. Imagine a compute running >> Linux, Windows, FreeBSD guests. It's highly unlikely that you want to >> force serial console one way or another on all of those the same way. >> This is probably something that makes sense to add as an image >> attribute, because images will need guest configuration to support >> serial consoles. As an image attribute this would also help on testing >> because we could mix / match in a single run. > > There is actually image properties for this, but the way it is all > implemented right now is just insane. You're talking about "hw_serial_port_count" I assume? I'm not aware of any other property for that. Sean was talking about enabling the serial console per image/flavor property IIUC. > For QEMU/KVM (on x86) currently, by default you get > > - a serial port which is connected to a file > - a serial port which is connected to a pty > > If you turned on the serial_console option in nova.conf you instead get > > - one or more serial ports connected to a tcp port > - a serial port which is connected to a pty > > The number of serial ports is based off an image property ( > hw_serial_port_count), but strangely the code doesn't honour a > value of 0 for that. In addition the last serial port connected > to a pty should really not even exist at that point. > > We should aim to get to a place where we have 'serial_console.enabled' > default to True in nova.conf and hw_serial_port_count setting how many > are created, with 0 being a valid number. Never create any other serial > ports that were not requested. > > Regards, > Daniel > Allowing '0' as property value sounds like a good approach. -- Regards, Markus Zoeller (markus_z) __ 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] test strategy for the serial console feature
On 26.07.2016 12:16, Jordan Pittier wrote: > Hi Markus > You don"t really need a whole new job for this. Just turn that flag to True > on existing jobs. > > 30/40 seconds is acceptable. But I am surprised considering a VM usually > boots in 5 sec or so. Any idea of where that slowdown comes from ? > > On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller < > mzoel...@linux.vnet.ibm.com> wrote: > Hi Jordan, after thinking again about this I think you're right. The mutual exclusive relationship between "serial console" and "console log" is still there, but the test coverage should be OK if I only change * either "gate-tempest-python27-ubuntu-xenial" * or "gate-tempest-python35" I cannot find the right place in the "project-config" right now though. I searched in "devstack-gate.yaml" and "python-jobs.yaml" within the "Jenkins/jobs/" directory but I don't understand where I can change the config options for Nova and Tempest for one of those jobs. The needed config changes would be: # nova.conf [serial_console] enabled=True # tempest.conf [compute_feature_enabled] serial_console=True I'm proceeding to search and understand the project-config, but any pointer would be highly appreciated. -- Regards, Markus Zoeller (markus_z) >> I'd like to discuss a testing strategy which ensures that the "serial >> console" feature in Nova doesn't break. Right now it's broken again [1]. >> This happens every once in a while as we don't test it in our CI >> environment. I pushed [2] which should be the start of a change series >> which checks: >> * does the "get-serial-console" API return the expected result >> * is a connection to the instance via serial console possible >> * is the live-migration still possible >> * are the resources (ports) cleaned up correctly >> >> I can create a new testing job for that which enables the serial console >> in the nova config: >> >> [serial_console] >> enabled = True >> >> My concern is that I could burn unnecessary many testing nodes for that >> and my question is, are there are other ways which are less testing >> resource hungry? >> >> I also noticed that it takes up to 30 seconds (locally) until the >> instance is booted completely and accepts console input, which makes the >> test run for [3] a very long one. >> >> References: >> [1] https://bugs.launchpad.net/nova/+bug/1455252 >> [2] https://review.openstack.org/#/c/346815/1 >> [3] https://review.openstack.org/#/c/346911/1 >> >> -- >> Regards, Markus Zoeller (markus_z) >> >> >> __ >> 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] [nova] [infra] Intel NFV CI voting permission
On 03.08.2016 22:02, Znoinski, Waldemar wrote: > Thanks > Much appreciated > > Making use of the opportunity here... what's the next big thing a CI (like > one testing NFV) should be doing? (multinode or there's something else more > important?) Two tiny nits on the comment the CI is giving a change: "Build failed (check pipeline). To recheck leave a comment with intel-nfv-ci recheck. For more info go to https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-NFV-CI.; 1) Could you put the recheck command in quotation? Like: To recheck leave a comment with 'intel-nfv-ci recheck'. 2) The link to the wiki seems to be wrong (hyphen vs. underscore): https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI -- Regards, Markus Zoeller (markus_z) > >-Original Message- > >From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > >Sent: Wednesday, August 3, 2016 8:28 PM > >To: openstack-dev@lists.openstack.org > >Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission > > > >On 8/3/2016 8:18 AM, Znoinski, Waldemar wrote: > >> [WZ] Hi Matt, do we need, a Gerrit-style, +2 on that from someone? > >> Infra Team doesn't keep these settings in their puppet/config files on > git - > >all the Gerrit changes are done via Gerrit GUI so they rely on Cores to add > CIs > >to the appropriate ci group, nova-ci in this case. > >> > >> > > > >Sorry, I wasn't sure what the next step here was, I guess it was the nova-ci > >membership change, which is done now: > > > >https://review.openstack.org/#/admin/groups/511,members > > > >-- > > > >Thanks, > > > >Matt Riedemann > > > > > >__ > > > >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 > -- > Intel Research and Development Ireland Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > > > This e-mail and any attachments may contain confidential material for the sole > use of the intended recipient(s). Any review or distribution by others is > strictly prohibited. If you are not the intended recipient, please contact the > sender and delete all copies. > > > __ > 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] Nova mascot
On 08.08.2016 13:07, Alexis Lee wrote: > I propose the ant, known for discovering probabilistic graph traversal > algorithms. > > My other thought, the bee, has already been taken by refstack. > > > lxsli > > __ > 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 > AFAIK #infra is going to chose the ant. I propose the "supernova": https://de.wikipedia.org/wiki/Supernova#/media/File:SN1994D.jpg https://en.wikipedia.org/wiki/Nova#/media/File:GKPersei-MiniSuperNova-20150316.jpg -- Regards, Markus Zoeller (markus_z) __ 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] [nova][tempest] testing different configurations by exploiting the mutate attribute?
IIUC, each gate testing job has a *fixed configuration* which will never be changed when executing *all* tempest tests. If I need to test a specific configuration, a new testing job is needed. As we have a limited amount of test nodes, this creates testing gaps as we cannot test all (reasonable/worthy) configuration permutations. In [1] I asked for advice how I can test the Nova serial console feature without creating a new test job and I'm wondering if we can exploit the mutable attribute of config options [2] for testing purposes in general. We already do something similar with the live-migration testing job [3]. This relies on restarting the services after changing the "nova.conf" file however. I'd like to discuss: 1) Do we see the need for more tempest tests with different configurations? 2) If ^ is true, what are the arguments against having a new testing job "gate-tempest-dsvm-full-mutate-configs" + writing tempest tests which send a SIGHUP to trigger the reload of previously changed "nova.conf" file? References: [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/100029.html [2] http://docs.openstack.org/developer/oslo.config/mutable.html [3] https://github.com/openstack/nova/blob/master/nova/tests/live_migration/hooks/run_tests.sh -- Regards, Markus Zoeller (markus_z) __ 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] focused review pipeline of bug fix changes?
We discussed the possible technical solutions but didn't get attention if we see the need to do that. As none of the core reviewers or subteam leaders reacted to the proposal, I conclude that this is not an issue where we need to put our limited resources at. This post is just informational to bring the discussion to a conclusion. -- Regards, Markus Zoeller (markus_z) On 12.07.2016 09:59, Markus Zoeller wrote: > After closing the old (>18months) bug reports nobody is working on a few > days ago [1], it became clear that the "in progress" reports are the > majority [2]. After asking Gerrit how long it usually takes to get a fix > merged [3], this is the result: > > number of merged bug fixes within the last 365 days: 689 > merged within ~1m : 409 (~59%) > merged within ~2m : 102 (~14%) > merged within ~3m : 57 (~ 8%) > merged > 3month : 121 (~17%) > > Note: This doesn't reflect the time a patch might be marked as > "WIP". It also doesn't add up to 100% as I rounded down the > percentages. > > This made me thinking about ways to increase the review throughput of > bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I > *assume* that the fixes in the ">3m" area had inherent problems or > waited for basic structural changes, but that's just guesswork. > > The proposal is this: > * have a TBD list with max 10 items on it (see list possibilities below) > * add new items during nova meeting if slots are free > * Change owners must propose their changes as meeting agenda items > * drop change from list in nova meeting if progress is not satisfying > > List possibilities: > 1) etherpad of doom? maintained by (?|me) > + easy to add/remove from everyone > - hard to query > 2) gerrit: starred by (?|me) > + easy to add/remove from the list maintainer > + easy to query > - No additions/removals when the list maintainer is on vacation > 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX > + easy to add/remove from everyone > + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX) > - once removed with a comment "DROPTOP10BUGFIX", a repeated > addition is not practical anymore. > 4) gerrit: tag a change > + easy to add/remove from everyone > + easy to query > - not yet available in our setup > > Personally I prefer 3, as it doesn't rely on a single person and the > tooling is ready for that. It could be sufficient until one of the next > infra Gerrit updates brings us 4. I'd like to avoid 1+2. > > My hope is, that a focused list helps us to get (few) things done faster > and increase the overall velocity. Is this a feasible proposal from your > point of view? Which concerns do you have? > > References: > [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/098792.html > [2] http://45.55.105.55:3000/dashboard/db/openstack-bugs > [3] > https://github.com/markuszoeller/openstack/blob/master/scripts/gerrit/bug_fix_histogram.py > > __ 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] [nova] bugs team IRC meeting: biweekly-odd timeslot?
2 months ago I moved the biweekly-odd timeslot from 1000 to 0800 UTC [1] in the hope to be more accessible for folks in Asia. After these 2 months it got evident that this didn't work out. The number of participating people decreased. I'd like to move that meeting to another timeslot which fits better for more people. What would fit best for you (1000, 1100, $any_other_time)? References: [1] https://review.openstack.org/#/c/320337/ -- Regards, Markus Zoeller (markus_z) __ 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] [nova][neutron] bug 1608601 - how to proceed?
https://bugs.launchpad.net/nova/+bug/1608601 "create_port is failing for non admin context as Nova neutronclient interactions are not using admin context consistently" IIUC there *could* be issues if the default policy gets changed. I have no idea how to proceed with this bug. Is the mixed use of (non-)admin context even an issue? -- Regards, Markus Zoeller (markus_z) __ 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] [devstack] libvirt/qemu source install plugin.
On 26.07.2016 17:45, Michele Paolino wrote: > I see. In any case, I am open to discuss further contributions and > improvement to the plugin. Let me know! > > In case this can be useful for you, in the early implementations of the > current devstack plugin (i.e., Patch set 1)[1], it was able to download > and install libvirt and qemu from git repositories. The community then > suggested to go for the tar releases, and that's where the current > implementation comes from. > > [1]https://review.openstack.org/#/c/108714/1 > > Regards, If I understand your devstack plugin correctly, the build of the *.deb is part of the installation process. I assume this takes some time. If this is used in a gate test job, it will be done over and over again. That's why the "apr" plugin [1] was build with the assumption that the *.deb is pre-build and stored at a location reachable within a gate test job. The PoC used the Ubuntu Cloud Archives to drill through things. I have to finish other items before mid/end of August. After that I'd like to have some kind of short coding-sprint/meeting with you (and other interested people) to get things up and running. Combining forces and stuff: https://www.youtube.com/watch?v=ZGegECwSiGY References: [1] https://github.com/openstack/devstack-plugin-additional-pkg-repos/ -- Regards, Markus Zoeller (markus_z) > On 07/26/2016 05:23 PM, Mooney, Sean K wrote: >> Hi I was not aware of the >> Plugin tar installer but it would not have been usefully in my case as >> I needed to build from specific git commit id not release tars. >> >> For my use case I also need the ability to apply patches automatically to >> evaluate change >> To qemu and Libvirt before they are merged upstream. >> >> It would be good to see if we could combine the two though to duplicate >> Code to build and install Libvirt and qemu. >> >> If there is no object I think it still makes sense to create a >> openstack/devstack-plugin-libvirt-qemu repo then as the >> devstack-plugin-tar-installer >> expcitly will be using tar files not git repos. >> >> >>> -Original Message- >>> From: Michele Paolino [mailto:m.paol...@virtualopensystems.com] >>> Sent: Tuesday, July 26, 2016 1:40 PM >>> To: OpenStack Development Mailing List (not for usage questions) >>> <openstack-dev@lists.openstack.org> >>> Cc: Kashyap Chamarthy <kcham...@redhat.com>; >>> mzoel...@linux.vnet.ibm.com; Mooney, Sean K <sean.k.moo...@intel.com> >>> Subject: Re: [openstack-dev] [devstack] libvirt/qemu source install >>> plugin. >>> >>> All, >>> >>> the purpose of the devstack-plugin-tar-installer[1] is exactly what you >>> mentioned: a tool needed to test experimental features in libvirt and >>> qemu. I am planning to release a new version next week, addressing some >>> of the comments received, however new testers/developers are more than >>> welcome! Sean, maybe you can have a look at the code and, if you are >>> interested, we can discuss how to proceed further. >>> >>> I also think it would be nice if we can join all together the efforts >>> on this project[2], as I believe this is an interesting feature for >>> devstack. Maybe there is also a way to integrate this work with the >>> gate Markus was mentioning. >>> >>> Thank you Kashyap for pointing this out! >>> >>> Regards, >>> >>> [1]https://review.openstack.org/#/c/313568/ >>> [2]https://review.openstack.org/#/q/project:openstack/devstack-plugin- >>> tar-installer >>> >>> On 07/26/2016 01:13 PM, Kashyap Chamarthy wrote: >>>> On Thu, Jul 21, 2016 at 02:25:46PM +0200, Markus Zoeller wrote: >>>>> On 20.07.2016 22:38, Mooney, Sean K wrote: >>>>>> Hi >>>>>> I recently had the need to test a feature (vhost-user reconnect) >>>>>> that was commit to the qemu source tree a few weeks ago. As there >>>>>> has been no release since then I needed to build from source so to >>>>>> that end I wrote a small devstack plugin to do just that. >>>>>> >>>>>> I was thinking of opening a review to create a new repo to host the >>>>>> plugin under The openstack namespace >>>>>> (openstack/devstack-plugin-libvirt-qemu) but before I do I wanted >>> to >>>>>> ask if others are interested In a devstack plugin that just >>> compiles >>>>>> and installs qemu and Libvirt? >>>>>> >>>>
Re: [openstack-dev] [nova] test strategy for the serial console feature
On 26.07.2016 12:16, Jordan Pittier wrote: > Hi Markus > You don"t really need a whole new job for this. Just turn that flag to True > on existing jobs. > Unfortunately, by enabling the serial console, I disable the console log file. This is due to the decision at: https://github.com/openstack/nova/blob/2099ce73d87038983f01f639ddd1bc8f15b16729/nova/virt/libvirt/driver.py#L4081-L4111 Changing that would increase the number of devices which can then hit the upper bound of 4 serial devices in Qemu. I discussed this with danpb some time ago. This gets resolved when the "virtlogd" change is merged (hopefully in Ocata): https://blueprints.launchpad.net/nova/+spec/libvirt-virtlogd Hence my assumption that we need a new test job which configures tempest with: [compute-feature-enabled] console_output = False # default is 'True' serial_console = True # default is 'False' > 30/40 seconds is acceptable. But I am surprised considering a VM usually > boots in 5 sec or so. Any idea of where that slowdown comes from ? It could be my testing environment. I tested it with a (KVM) guest with 4 VCPUs and 4GB RAM, which is the host for a Devstack environment. -- Regards, Markus Zoeller (markus_z) > On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller < > mzoel...@linux.vnet.ibm.com> wrote: > >> I'd like to discuss a testing strategy which ensures that the "serial >> console" feature in Nova doesn't break. Right now it's broken again [1]. >> This happens every once in a while as we don't test it in our CI >> environment. I pushed [2] which should be the start of a change series >> which checks: >> * does the "get-serial-console" API return the expected result >> * is a connection to the instance via serial console possible >> * is the live-migration still possible >> * are the resources (ports) cleaned up correctly >> >> I can create a new testing job for that which enables the serial console >> in the nova config: >> >> [serial_console] >> enabled = True >> >> My concern is that I could burn unnecessary many testing nodes for that >> and my question is, are there are other ways which are less testing >> resource hungry? >> >> I also noticed that it takes up to 30 seconds (locally) until the >> instance is booted completely and accepts console input, which makes the >> test run for [3] a very long one. >> >> References: >> [1] https://bugs.launchpad.net/nova/+bug/1455252 >> [2] https://review.openstack.org/#/c/346815/1 >> [3] https://review.openstack.org/#/c/346911/1 >> >> -- >> Regards, Markus Zoeller (markus_z) >> __ 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] [nova] test strategy for the serial console feature
I'd like to discuss a testing strategy which ensures that the "serial console" feature in Nova doesn't break. Right now it's broken again [1]. This happens every once in a while as we don't test it in our CI environment. I pushed [2] which should be the start of a change series which checks: * does the "get-serial-console" API return the expected result * is a connection to the instance via serial console possible * is the live-migration still possible * are the resources (ports) cleaned up correctly I can create a new testing job for that which enables the serial console in the nova config: [serial_console] enabled = True My concern is that I could burn unnecessary many testing nodes for that and my question is, are there are other ways which are less testing resource hungry? I also noticed that it takes up to 30 seconds (locally) until the instance is booted completely and accepts console input, which makes the test run for [3] a very long one. References: [1] https://bugs.launchpad.net/nova/+bug/1455252 [2] https://review.openstack.org/#/c/346815/1 [3] https://review.openstack.org/#/c/346911/1 -- Regards, Markus Zoeller (markus_z) __ 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] [devstack] libvirt/qemu source install plugin.
On 20.07.2016 22:38, Mooney, Sean K wrote: > Hi > I recently had the need to test a feature (vhost-user reconnect) that was > commit to the > qemu source tree a few weeks ago. As there has been no release since then I > needed > to build from source so to that end I wrote a small devstack plugin to do > just that. > > I was thinking of opening a review to create a new repo to host the plugin > under > The openstack namespace (openstack/devstack-plugin-libvirt-qemu) but before > I do I wanted to ask if others are interested In a devstack plugin that just > compiles > and installs qemu and Libvirt? > > Regards > Sean. > tonby and I try to make the devstack plugin "additional package repos" (apr) work [1]. What you did is within the scope of that project. We also have an experimental job "gate-tempest-dsvm-nova-libvirt-kvm-apr"[2]. The last time I worked on this I wasn't able to create installable *.deb packages from libvirt + qemu source code. Other work items did then get more important and I had to pause the work on that. I think we can work together to combine our efforts there. References: [1] https://github.com/openstack/devstack-plugin-additional-pkg-repos/ [2] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L565-L595 -- Regards, Markus Zoeller (markus_z) __ 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] [docs][nova] config options help texts: reviews by technical writers?
On 18.07.2016 16:03, Matt Kassawara wrote: > I think we can help. Do you want us to submit patches for config option > descriptions that benefit from rewording? Also, you might want to post to > the -docs list. Awesome, thanks! If you could submit the changes, that would be great. Let me skim through our modules first and filter out those which aren't yet ready for your rewording. I'll post a list of modules in this thread in the next days. In case you don't already know, we have all config options at: https://github.com/openstack/nova/tree/master/nova/conf -- Regards, Markus Zoeller (markus_z) > On Mon, Jul 18, 2016 at 6:29 AM, Markus Zoeller <mzoel...@linux.vnet.ibm.com >> wrote: > >> I'd like to ask the docs team if they see the possibility to have >> reviews of the merged config options help texts Nova has updated in the >> last months. >> >> Background: In Mitaka and Newton, Nova put a lot of effort in providing >> valuable help texts for their config options. They are written from >> developers for operators. My assumption is, that technical writers like >> the docs team look at them differently. As these help texts get >> extracted from the code and will be used directly in the "configuration >> reference" manual, the text "by-passed" the writing expertise of the >> docs team. >> >> Be aware, that this is still an ongoing effort in Nova (see [1], >> especially "needs:fix_opt_description"). >> >> References: >> [1] http://45.55.105.55:8082/config-options.html >> >> -- >> Regards, Markus Zoeller (markus_z) >> >> >> __ >> 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] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0
Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed change [2] is not yet in place, which broke "gate-nova-python27-db"[3]. Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in Portland and won't be available for the next 2h or so. If you can have a look at it and merge it, that would be great. References: [1] https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1 [2] https://review.openstack.org/#/c/342604/1 [3] https://bugs.launchpad.net/nova/+bug/1603979 [4] logstash: http://goo.gl/79yFb9 -- Regards, Markus Zoeller (markus_z) __ 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] [docs][nova] config options help texts: reviews by technical writers?
I'd like to ask the docs team if they see the possibility to have reviews of the merged config options help texts Nova has updated in the last months. Background: In Mitaka and Newton, Nova put a lot of effort in providing valuable help texts for their config options. They are written from developers for operators. My assumption is, that technical writers like the docs team look at them differently. As these help texts get extracted from the code and will be used directly in the "configuration reference" manual, the text "by-passed" the writing expertise of the docs team. Be aware, that this is still an ongoing effort in Nova (see [1], especially "needs:fix_opt_description"). References: [1] http://45.55.105.55:8082/config-options.html -- Regards, Markus Zoeller (markus_z) __ 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] [all][oslo] pbr potential breaking change coming
On 13.07.2016 19:11, Jeremy Stanley wrote:
> On 2016-07-13 13:25:44 +0200 (+0200), Markus Zoeller wrote:
>> For some reason the gate docs job didn't find the issue (wrong json
>> format) which got fixed with change [1]. It doesn't even emit a warning.
>> Locally, the execution of "tox -e docs" does find the issue. Can we make
>> the gate docs job aware of such json format issues?
> [...]
>
> It looks like your "docs" tox env is doing some additional checks[1]
> with the json.tool module. The gate-{name}-docs CI jobs don't call
> `tox -e docs` but `tox -evenv -- python setup.py build_sphinx`
> directly[2]. Changing that has been discussed[3][4] (and
> rejected/withdrawn) by the TC in the past.
>
> I agree with Andreas that if you want additional checking of this
> you probably need it in a different job. The same goes for tests of
> your config/policy generation and API guide/reference builds. The
> goal of gate-{name}-docs is to make sure that the setup.py
> build_sphinx entrypoint works across all covered projects (per the
> CTI[5]) without requiring any extra nonstandard magic.
>
> [1] http://git.openstack.org/cgit/openstack/nova/tree/tox.ini?id=df0aa8a#n97
> [2]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/run-docs.sh
> [3]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-30-20.01.log.html#l-27
> [4] https://review.openstack.org/119875
> [5]
> http://governance.openstack.org/reference/cti/python_cti.html#documentation
>
I understand the reasoning now, thanks. Luckily, Andreas pushed a patch
to change that for Nova: https://review.openstack.org/#/c/341444/1
--
Regards, Markus Zoeller (markus_z)
__
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] [new][oslo] mox3 0.17.0 release (newton)
On 13.07.2016 21:51, Doug Hellmann wrote: > Excerpts from Jeremy Stanley's message of 2016-07-13 17:22:32 +: >> On 2016-07-13 17:10:20 +0200 (+0200), Markus Zoeller wrote: >>> Whoever chooses the wording in these announcements, you're a genius! >> >> You too can be a genius--add some more--there's only ~20 at the >> moment so they repeat pretty often: >> >> > http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py?id=da89264#n33 >> > > > Indeed, I've worn out my thesaurus. Please send synonyms. > > Doug > > __ > 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 > So be it: https://review.openstack.org/342053 :) https://www.youtube.com/watch?v=KrDcAzD6cWM -- Regards, Markus Zoeller (markus_z) __ 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] [new][oslo] mox3 0.17.0 release (newton)
On 13.07.2016 16:01, no-re...@openstack.org wrote: > We are tickled pink to announce the release of: > Whoever chooses the wording in these announcements, you're a genius! -- Regards, Markus Zoeller (markus_z) > mox3 0.17.0: Mock object framework for Python > > This release is part of the newton release series. > > With source available at: > > http://git.openstack.org/cgit/openstack/mox3 > > With package available at: > > https://pypi.python.org/pypi/mox3 > > Please report issues through launchpad: > > http://bugs.launchpad.net/python-mox3 > > For more details, please see below. > > Changes in mox3 0.16.0..0.17.0 > -- > > 2b58961 Updated from global requirements > > > Diffstat (except docs and test files) > - > > test-requirements.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > Requirements updates > > > diff --git a/test-requirements.txt b/test-requirements.txt > index ad30fa2..df05b72 100644 > --- a/test-requirements.txt > +++ b/test-requirements.txt > @@ -20 +20 @@ six>=1.9.0 # MIT > -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD > +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD > > > > __ > 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] The future of OpenStack documentation
On 11.07.2016 00:02, Steve Martinelli wrote: > I personally like this solution, it seems much more scalable. This follows > the same pattern of the API docs (moving the content to project repos), > which puts the onus back on the project team to maintain and create > documentation. I'm also hoping this results in less duplication between the > guides and the keystone developer docs (the latter of which start to stray > from "developer" docs and begin to look like "user" docs. After reading this, the "configuration reference" comes to my mind. Having the api-ref and the config-ref at one place, near the code, seems logical to me. Nova put a lot of effort into providing valuable help text for the config options in the last months. We should also make sure that it will result in a good manual, which could be easier if it's in-tree, near the code. -- Regards, Markus Zoeller (markus_z) > The folks that contribute to the keystone guides today would still be very > welcomed to continue to contribute once/if the switch is made. > > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara <mkassaw...@gmail.com> wrote: > >> Currently, OpenStack provides central documentation (primarily in the >> openstack-manuals repository) for operators and users. The single location >> and consistent structure eases audiences of various technical expertise >> into OpenStack, typically operators and users rather than developers. >> Although I'm not a fan of the word "product", increasingly less technical >> audiences are learning about OpenStack and tend to compare it with other >> cloud infrastructure products. Such audiences expect a coherent, relatively >> mature product to easily evaluate, usually via proof-of-concept. Upon >> deciding to implement OpenStack, the central documentation attempts to >> gracefully lead them toward a production deployment that meets or exceeds >> requirements and expectations. >> >> However, since I began contributing to OpenStack documentation around the >> Havana release, I am seeing many projects, particularly core projects, >> trending toward more independence from other projects including central >> documentation. For operator and user documentation, a couple of projects >> contribute to the central documentation repository, some projects >> contribute to their own repositories, and an alarmingly large number of >> projects simply do not contribute such documentation and assume that all >> audiences involve developers. These differences lead to an increasingly >> negative overall experience for the audiences that OpenStack needs to >> increase adoption/growth and maintain the existing deployment base. >> >> As a contributor to central documentation and one or more other projects >> including neutron, I see the problems from both sides and don't >> particularly blame either party for them. Some politics, some technical, >> some a lack of resources, and some just a general misunderstanding about >> documentation. However, I think we need to develop a solution that works >> for both parties and ultimately benefits our audiences. >> >> One potential solution essentially involves moving operator and user >> documentation into project repositories (similar to developer >> documentation) and using infrastructure to coherently present it on >> docs.openstack.org which achieves the following goals: >> >> 1) Project developers can contribute documentation and code in the same >> patch, thus avoiding two different review queues and reviewers with >> different motivations and guidelines. >> 2) Project developers can either work directly or via liaison with one or >> more documentation team members to improve documentation components during >> development or after merging technically accurate content. >> 3) Rather than attempting to document all projects with little (if any) >> assistance from those projects, the primary role of the documentation team >> becomes managing overall organization/presentation of documentation and >> assisting projects with their contributions. >> >> We're seeing decent adoption of moving API documentation into project >> repositories, so I want to initiate some discussion about moving additional >> documentation (or other options) prior to mid-cycles (including ops) and >> the next summit. >> >> Matt >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/
Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?
On 13.07.2016 09:56, Sahid Orentino Ferdjaoui wrote: > On Tue, Jul 12, 2016 at 06:45:03PM +0200, Markus Zoeller wrote: >> On 12.07.2016 17:39, Sahid Orentino Ferdjaoui wrote: >>> On Tue, Jul 12, 2016 at 09:59:12AM +0200, Markus Zoeller wrote: >>>> After closing the old (>18months) bug reports nobody is working on a few >>>> days ago [1], it became clear that the "in progress" reports are the >>>> majority [2]. After asking Gerrit how long it usually takes to get a fix >>>> merged [3], this is the result: >>>> >>>> number of merged bug fixes within the last 365 days: 689 >>>> merged within ~1m : 409 (~59%) >>>> merged within ~2m : 102 (~14%) >>>> merged within ~3m : 57 (~ 8%) >>>> merged > 3month : 121 (~17%) >>>> >>>> Note: This doesn't reflect the time a patch might be marked as >>>> "WIP". It also doesn't add up to 100% as I rounded down the >>>> percentages. >>>> >>>> This made me thinking about ways to increase the review throughput of >>>> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I >>>> *assume* that the fixes in the ">3m" area had inherent problems or >>>> waited for basic structural changes, but that's just guesswork. >>>> >>>> The proposal is this: >>>> * have a TBD list with max 10 items on it (see list possibilities below) >>>> * add new items during nova meeting if slots are free >>>> * Change owners must propose their changes as meeting agenda items >>>> * drop change from list in nova meeting if progress is not satisfying >>> >>> Considering a raw list of patches would be difficult to maintain, it's >>> time consuming and Nova has contributors working on different areas >>> which are sometimes really differents. How to order this list and how >>> to consider a patch is satisfying the progress policy. >> >> I'm not sure if I understand the concerns correctly. The list >> possibilities below seem to be easy to maintain. My assumption is, that >> minimizing the "wait time" (reviewers wait for new patchsets OR change >> owners wait for new reviews) can increase the throughput. It makes the >> commitment of change owners and reviewers necessary though. >> I don't think that the list needs specific ordering rules. As I want to >> target bug fixes with this proposal, the ordering is given by the impact >> of the bugs. > > How I see that you want to concentrate reviewers to be on 10 patches > every weeks but here the bottleneck would be the authors, no? > > I think we have a pretty good flow, most of the bug fixes which need > to get attention are reviewed quickly. > To be precise, the 10 patches on this list is just an upper bound. It is *not* said that this should be merged within 1 week. *If* a new slot gets freed because one of the changes merged, *then* a new change can be added *if* the authors commit themselves to push new ps quickly. By bringing the changes into the spotlight, there is a little pressure to not be *that person* who stalls the flow. I agree that the flow is already good. The numbers from above show that almost 60% of the fixes merge within 4 weeks, which is good. Trying to increase that is a good thing too, IMO. >>> To make things working we should find some automations and have one >>> list by areas which is probably the purpose of tags in gerrit. >> >> This could result in silo mentality and discussions why list A gets >> preferred over list B. That's why I want to avoid having multiple lists. >> It's about fixing issues in Nova, not fixing issues in >> . > > I don't think that could result in silo mentality and I remember a > initiative in the same way but with etherpad and so difficult to > maitain. > Yes, the etherpad is hard to maintain and makes the the review-workflow a little more cumbersome IMO. What were the reasons the last initiative didn't work out? >>> Since we don't have such feature on our gerrit yet, a possible >>> solution would be to introduce a tag in commit messages which reflects >>> the subteam or area related. Then a simple script could parse reviews >>> in progress to print them somewhere. >> >> Changing the commit message creates a new patchset which triggers the >> gate checks again, that's why I thought making comments with a keyword >> which can be queried is less trouble. > > Gerrit comments are lost when the patch get merged, we may want to >
Re: [openstack-dev] [nova] focused review pipeline of bug fix changes?
On 12.07.2016 20:31, Jeremy Stanley wrote: > On 2016-07-12 10:46:54 -0700 (-0700), Augustina Ragwitz wrote: > [...] >> I like #3 but I worry about the comments getting spammy if things are >> dropped from and added to the list repeatedly. Would tagging the bugs in >> Launchpad work? We can easily remove tags in Launchpad, it's a >> query-able list, and the reviewer would immediately have some context. > > This sounds like another case for reviewday and/or a custom Gerrit > review dashboard dynamically updated like Neutron does... > > http://status.openstack.org/reviews/ > https://review.openstack.org/298779 > The Neutron dashboard is pretty cool. IIUC the link to Gerrit and the query to use are generated/updated automatically after each merged commit. I have to leave Gerrit for it and it cannot be used in "gerrty" though, or can it? Nevertheless, it's a good alternative which can support the whole idea, thanks for bringing that up. -- Regards, Markus Zoeller (markus_z) __ 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] focused review pipeline of bug fix changes?
On 13.07.2016 10:09, Andreas Jaeger wrote: > On 2016-07-12 09:59, Markus Zoeller wrote: >> After closing the old (>18months) bug reports nobody is working on a few >> days ago [1], it became clear that the "in progress" reports are the >> majority [2]. After asking Gerrit how long it usually takes to get a fix >> merged [3], this is the result: >> >> number of merged bug fixes within the last 365 days: 689 >> merged within ~1m : 409 (~59%) >> merged within ~2m : 102 (~14%) >> merged within ~3m : 57 (~ 8%) >> merged > 3month : 121 (~17%) >> >> Note: This doesn't reflect the time a patch might be marked as >> "WIP". It also doesn't add up to 100% as I rounded down the >> percentages. >> >> This made me thinking about ways to increase the review throughput of >> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I >> *assume* that the fixes in the ">3m" area had inherent problems or >> waited for basic structural changes, but that's just guesswork. >> >> The proposal is this: >> * have a TBD list with max 10 items on it (see list possibilities below) >> * add new items during nova meeting if slots are free >> * Change owners must propose their changes as meeting agenda items >> * drop change from list in nova meeting if progress is not satisfying >> >> List possibilities: >> 1) etherpad of doom? maintained by (?|me) >> + easy to add/remove from everyone >> - hard to query >> 2) gerrit: starred by (?|me) >> + easy to add/remove from the list maintainer >> + easy to query >> - No additions/removals when the list maintainer is on vacation >> 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX >> + easy to add/remove from everyone >> + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX) >> - once removed with a comment "DROPTOP10BUGFIX", a repeated >> addition is not practical anymore. >> 4) gerrit: tag a change >> + easy to add/remove from everyone >> + easy to query >> - not yet available in our setup > > You could also use a specific topic for these - instead of the bug/XXX, > use TOP10BUG. > > Another suggestion: Check what neutron has done with their review board > that is available from http://status.openstack.org/reviews/ as "Gerrit > Dashboard links" - a dashboard that takes into account the launchpad bug > status and is generated using a script (see > https://review.openstack.org/298779 ), > > Andreas > Yep, another possible way to support the idea by tooling. What's more important is the commitment of reviewers/authors I guess. If that commitment isn't there, tooling won't help. -- Regards, Markus Zoeller (markus_z) __ 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] [all][oslo] pbr potential breaking change coming
On 23.06.2016 12:21, Andreas Jaeger wrote: > On 06/23/2016 10:43 AM, Markus Zoeller wrote: >> On 21.06.2016 15:01, Doug Hellmann wrote: >>> A while back pbr had a feature that let projects pass "warnerror" >>> through to Sphinx during documentation builds, causing any warnings in >>> that build to be treated as an error and fail the build. This lets us >>> avoid things like links to places that don't exist in the docs, bad but >>> renderable rst, typos in directive or role names, etc. >>> >>> Somewhat more recently, but still a while ago, that feature "broke" >>> with a Sphinx release that was not API compatible. Sachi King has >>> fixed this issue within pbr, and so the next release of pbr will >>> fix the broken behavior and start correctly passing warnerror again. >>> That may result in doc builds breaking where they didn't before. >>> >>> The short-term solution is to turn of warnerrors (look in your >>> setup.cfg), then fix the issues and turn it back on. Or you could >>> preemptively fix any existing warnings in your doc builds before the >>> release, but it's simple enough to turn off the feature if there isn't >>> time. >>> >>> Josh, Sachi, & other Oslo folks, I think we should hold off on >>> releasing until next week to give folks time. Is that OK? >>> >>> Doug >>> >>> PS - Thanks, Sachi, I know that bug wasn't a ton of fun to fix! >> [...] >> >> Thanks for the heads up. I checked Nova, and every sphinx-build command >> we use in our "tox.ini" file already uses the -W flag to treat warnings >> as errors. I guess we're safe with that? >> > > Infra calls the docs job using > tox -e venv -- python setup.py build_sphinx > > And that's where the change comes in... > > So, your docs environment is not used as is in the gate, > > Andreas > For some reason the gate docs job didn't find the issue (wrong json format) which got fixed with change [1]. It doesn't even emit a warning. Locally, the execution of "tox -e docs" does find the issue. Can we make the gate docs job aware of such json format issues? References: [1] https://review.openstack.org/#/c/339295/1 -- Regards, Markus Zoeller (markus_z) __ 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] focused review pipeline of bug fix changes?
On 12.07.2016 19:46, Augustina Ragwitz wrote: > I like the idea of having a list because it makes it easy for people to > see what's up for review. Anything that allows people to easily point > and click will increase visibility and participation. I also prefer the > list maintenance be as automagic as possible so the burden doesn't fall > on one or two people and thus risk it getting out of date. > > I like #3 but I worry about the comments getting spammy if things are > dropped from and added to the list repeatedly. Would tagging the bugs in > Launchpad work? We can easily remove tags in Launchpad, it's a > query-able list, and the reviewer would immediately have some context. > Yeah, the easy access is key IMO. Some people also like to use CLI tools like gerrty [1] which makes it necessary that the query is executed against Gerrit. In the nova-bugs-team meeting some minutes ago we also discussed that we could have a query which checks: * starred changes * by certain people * "closes-bug" in the commit message That allows some kind of control which changes will be in that list. [1] https://github.com/openstack/gertty [2] http://eavesdrop.openstack.org/meetings/nova_bugs_team/2016/nova_bugs_team.2016-07-12-17.59.log.html -- Regards, Markus Zoeller (markus_z) __ 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] focused review pipeline of bug fix changes?
On 12.07.2016 18:19, Chris Friesen wrote: > On 07/12/2016 01:59 AM, Markus Zoeller wrote: >> After closing the old (>18months) bug reports nobody is working on a few >> days ago [1], it became clear that the "in progress" reports are the >> majority [2]. After asking Gerrit how long it usually takes to get a fix >> merged [3], this is the result: >> >> number of merged bug fixes within the last 365 days: 689 >> merged within ~1m : 409 (~59%) >> merged within ~2m : 102 (~14%) >> merged within ~3m : 57 (~ 8%) >> merged > 3month : 121 (~17%) >> >> Note: This doesn't reflect the time a patch might be marked as >> "WIP". It also doesn't add up to 100% as I rounded down the >> percentages. >> >> This made me thinking about ways to increase the review throughput of >> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I >> *assume* that the fixes in the ">3m" area had inherent problems or >> waited for basic structural changes, but that's just guesswork. >> >> The proposal is this: >> * have a TBD list with max 10 items on it (see list possibilities below) >> * add new items during nova meeting if slots are free >> * Change owners must propose their changes as meeting agenda items >> * drop change from list in nova meeting if progress is not satisfying > > What do we hope to gain from this? Is the hope that random developers will > see > this list and review the proposed patches? Or that nova-core developers will > focus their attention on these issues? > > Chris My hope is that subject matter experts and nova-cores will focus on those. It's also about getting commitment of the bug fix owners to create new patchsets faster after getting reviews. My basic assumption behind the proposal is, that the "mental context switches" of change authors|reviewers, while they wait for the other group and start working on other items, costs a lot of time. -- Regards, Markus Zoeller (markus_z) __ 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] focused review pipeline of bug fix changes?
On 12.07.2016 17:39, Sahid Orentino Ferdjaoui wrote: > On Tue, Jul 12, 2016 at 09:59:12AM +0200, Markus Zoeller wrote: >> After closing the old (>18months) bug reports nobody is working on a few >> days ago [1], it became clear that the "in progress" reports are the >> majority [2]. After asking Gerrit how long it usually takes to get a fix >> merged [3], this is the result: >> >> number of merged bug fixes within the last 365 days: 689 >> merged within ~1m : 409 (~59%) >> merged within ~2m : 102 (~14%) >> merged within ~3m : 57 (~ 8%) >> merged > 3month : 121 (~17%) >> >> Note: This doesn't reflect the time a patch might be marked as >> "WIP". It also doesn't add up to 100% as I rounded down the >> percentages. >> >> This made me thinking about ways to increase the review throughput of >> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I >> *assume* that the fixes in the ">3m" area had inherent problems or >> waited for basic structural changes, but that's just guesswork. >> >> The proposal is this: >> * have a TBD list with max 10 items on it (see list possibilities below) >> * add new items during nova meeting if slots are free >> * Change owners must propose their changes as meeting agenda items >> * drop change from list in nova meeting if progress is not satisfying > > Considering a raw list of patches would be difficult to maintain, it's > time consuming and Nova has contributors working on different areas > which are sometimes really differents. How to order this list and how > to consider a patch is satisfying the progress policy. I'm not sure if I understand the concerns correctly. The list possibilities below seem to be easy to maintain. My assumption is, that minimizing the "wait time" (reviewers wait for new patchsets OR change owners wait for new reviews) can increase the throughput. It makes the commitment of change owners and reviewers necessary though. I don't think that the list needs specific ordering rules. As I want to target bug fixes with this proposal, the ordering is given by the impact of the bugs. > To make things working we should find some automations and have one > list by areas which is probably the purpose of tags in gerrit. This could result in silo mentality and discussions why list A gets preferred over list B. That's why I want to avoid having multiple lists. It's about fixing issues in Nova, not fixing issues in . > Since we don't have such feature on our gerrit yet, a possible > solution would be to introduce a tag in commit messages which reflects > the subteam or area related. Then a simple script could parse reviews > in progress to print them somewhere. Changing the commit message creates a new patchset which triggers the gate checks again, that's why I thought making comments with a keyword which can be queried is less trouble. > So each subteams can have a view of the work in progress which could > make things moving faster. > > The point would be to order the lists by importance but we can expect > the lists relatively small. > >> List possibilities: >> 1) etherpad of doom? maintained by (?|me) >> + easy to add/remove from everyone >> - hard to query >> 2) gerrit: starred by (?|me) >> + easy to add/remove from the list maintainer >> + easy to query >> - No additions/removals when the list maintainer is on vacation >> 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX >> + easy to add/remove from everyone >> + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX) >> - once removed with a comment "DROPTOP10BUGFIX", a repeated >> addition is not practical anymore. >> 4) gerrit: tag a change >> + easy to add/remove from everyone >> + easy to query >> - not yet available in our setup >> >> Personally I prefer 3, as it doesn't rely on a single person and the >> tooling is ready for that. It could be sufficient until one of the next >> infra Gerrit updates brings us 4. I'd like to avoid 1+2. >> >> My hope is, that a focused list helps us to get (few) things done faster >> and increase the overall velocity. Is this a feasible proposal from your >> point of view? Which concerns do you have? >> >> References: >> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/098792.html >> [2] http://45.55.105.55:3000/dashboard/db/openstack-bugs >> [3] >> https://github.com/markuszoeller/openstack/blob/master/scripts/gerrit/bug_fix_histogram.py >> >> >> -- >> Regards, Markus Zoeller (markus_z) >> -- Regards, Markus Zoeller (markus_z) __ 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] [nova] focused review pipeline of bug fix changes?
After closing the old (>18months) bug reports nobody is working on a few days ago [1], it became clear that the "in progress" reports are the majority [2]. After asking Gerrit how long it usually takes to get a fix merged [3], this is the result: number of merged bug fixes within the last 365 days: 689 merged within ~1m : 409 (~59%) merged within ~2m : 102 (~14%) merged within ~3m : 57 (~ 8%) merged > 3month : 121 (~17%) Note: This doesn't reflect the time a patch might be marked as "WIP". It also doesn't add up to 100% as I rounded down the percentages. This made me thinking about ways to increase the review throughput of bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I *assume* that the fixes in the ">3m" area had inherent problems or waited for basic structural changes, but that's just guesswork. The proposal is this: * have a TBD list with max 10 items on it (see list possibilities below) * add new items during nova meeting if slots are free * Change owners must propose their changes as meeting agenda items * drop change from list in nova meeting if progress is not satisfying List possibilities: 1) etherpad of doom? maintained by (?|me) + easy to add/remove from everyone - hard to query 2) gerrit: starred by (?|me) + easy to add/remove from the list maintainer + easy to query - No additions/removals when the list maintainer is on vacation 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX + easy to add/remove from everyone + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX) - once removed with a comment "DROPTOP10BUGFIX", a repeated addition is not practical anymore. 4) gerrit: tag a change + easy to add/remove from everyone + easy to query - not yet available in our setup Personally I prefer 3, as it doesn't rely on a single person and the tooling is ready for that. It could be sufficient until one of the next infra Gerrit updates brings us 4. I'd like to avoid 1+2. My hope is, that a focused list helps us to get (few) things done faster and increase the overall velocity. Is this a feasible proposal from your point of view? Which concerns do you have? References: [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/098792.html [2] http://45.55.105.55:3000/dashboard/db/openstack-bugs [3] https://github.com/markuszoeller/openstack/blob/master/scripts/gerrit/bug_fix_histogram.py -- Regards, Markus Zoeller (markus_z) __ 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] I'm going to expire open bug reports older than 18 months.
The expiration of old (stale) bug reports happened right now. Stats: # of bug reports before expiration: 826 # of expired bug reports: 188 # of bug reports after expiration: 638 That affected ~22% of our overall open bug reports and ~36% of bug reports which are not in progress. You can see a graphical impact at [1]. The list of affected bug reports is at [2] and as an attached file. References: [1] http://45.55.105.55:3000/dashboard/db/openstack-bugs [2] http://paste.openstack.org/show/525937/ -- Regards, Markus Zoeller (markus_z) On 21.06.2016 14:43, Markus Zoeller wrote: > A reminder that this will happen in ~2 weeks. > > Please note that you can spare bug reports if you leave a comment there > which says one of these (case-sensitive flags): > * CONFIRMED FOR: NEWTON > * CONFIRMED FOR: MITAKA > * CONFIRMED FOR: LIBERTY > > On 23.05.2016 13:02, Markus Zoeller wrote: >> TL;DR: Automatic closing of 185 bug reports which are older than 18 >> months in the week R-13. Skipping specific bug reports is possible. A >> bug report comment explains the reasons. >> >> >> I'd like to get rid of more clutter in our bug list to make it more >> comprehensible by a human being. For this, I'm targeting our ~185 bug >> reports which were reported 18 months ago and still aren't in progress. >> That's around 37% of open bug reports which aren't in progress. This >> post is about *how* and *when* I do it. If you have very strong reasons >> to *not* do it, let me hear them. >> >> When >> >> I plan to do it in the week after the non-priority feature freeze. >> That's week R-13, at the beginning of July. Until this date you can >> comment on bug reports so they get spared from this cleanup (see below). >> Beginning from R-13 until R-5 (Newton-3 milestone), we should have >> enough time to gain some overview of the rest. >> >> I also think it makes sense to make this a repeated effort, maybe after >> each milestone/release or monthly or daily. >> >> How >> --- >> The bug reports which will be affected are: >> * in status: [new, confirmed, triaged] >> * AND without assignee >> * AND created at: > 18 months >> A preview of them can be found at [1]. >> >> You can spare bug reports if you leave a comment there which says >> one of these (case-sensitive flags): >> * CONFIRMED FOR: NEWTON >> * CONFIRMED FOR: MITAKA >> * CONFIRMED FOR: LIBERTY >> >> The expired bug report will have: >> * status: won't fix >> * assignee: none >> * importance: undecided >> * a new comment which explains *why* this was done >> >> The comment the expired bug reports will get: >> This is an automated cleanup. This bug report got closed because >> it is older than 18 months and there is no open code change to >> fix this. After this time it is unlikely that the circumstances >> which lead to the observed issue can be reproduced. >> If you can reproduce it, please: >> * reopen the bug report >> * AND leave a comment "CONFIRMED FOR: " >> Only still supported release names are valid. >> valid example: CONFIRMED FOR: LIBERTY >> invalid example: CONFIRMED FOR: KILO >> * AND add the steps to reproduce the issue (if applicable) >> >> >> Let me know if you think this comment gives enough information how to >> handle this situation. >> >> >> References: >> [1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired >> > > +-+--+-+ | Bug # | Title | Age (d) | +-+--+-+ | 933498 | "List Volumes" should support filtering |1599 | | 955792 | No public IP addresses listed in server representation |1573 | | 956589 | Device is busy error on lxc instance shutdown |1572 | | 1018253 | No error message prompt during attaching when mountpoint is occupied |1462 | | 1039665 | Creating Neutron L2 networks (without subnets) do
Re: [openstack-dev] [nova] Non-priority feature freeze and FFEs
On 01.07.2016 23:03, Matt Riedemann wrote: > We're now past non-priority feature freeze. I've started going through > some blueprints and -2ing them if they still have outstanding changes. I > haven't gone through the full list yet (we started with 100). > > I'm also building a list of potential FFE candidates based on: > > 1. How far along the change is (how ready is it?), e.g. does it require > a lot of change yet? Does it require a Tempest test and is that passing > already? How much of the series has already merged and what's left? > > 2. How much core reviewer attention has it already gotten? > > 3. What kind of priority does it have, i.e. if we don't get it done in > Newton do we miss something in Ocata? Think things that start > deprecation/removal timers. > > The plan is for the nova core team to have an informal meeting in the > #openstack-nova IRC channel early next week, either Tuesday or > Wednesday, and go through the list of potential FFE candidates. > > Blueprints that get exceptions will be checked against the above > criteria and who on the core team is actually going to push the changes > through. > > I'm looking to get any exceptions completed within a week, so targeting > Wednesday 7/13. That leaves a few days for preparing for the meetup. > FWIW, bp "libvirt-virtlogd" [1] is basically ready to merge. The two changes [2] and [3] did already get a lot of attention from danpb. References: [1] https://blueprints.launchpad.net/openstack/?searchtext=libvirt-virtlogd [2] https://review.openstack.org/#/c/334480/ [3] https://review.openstack.org/#/c/323765/ -- Regards, Markus Zoeller (markus_z) __ 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] Deprecated Configuration Option in Nova Mitaka Release
On 30.06.2016 18:35, HU, BIN wrote: > Hello Nova team, > > I am a newbie of Nova. I read your documentation > http://docs.openstack.org/mitaka/config-reference/tables/conf-changes/nova.html > regarding new, updated and deprecated options in Mitaka for Compute. I have > a few questions: > > > - For those deprecated options, does it mean it won't be supported > in Mitaka and future release at all? Or is there a grace period so that we, > as a user, can gradually transition from Liberty to Mitaka? > No, they are still supported in Mitaka but will removed during Newton or have a new name. See [1] for more information. > - What is the rationale of some deprecated options, for example, > "[DEFAULT] network_api_class". It seems to me that it provides end users with > flexibility in configuring backends. So what is the rationale of deprecating > this option and is there equivalent method in Mitika to replace this option? > The rationales are available at [1]. The option you asked for is explained there. > Thank you very much > Bin > > > > > > __ > 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 > References: [1] http://docs.openstack.org/releasenotes/nova/unreleased.html -- Regards, Markus Zoeller (markus_z) __ 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] libvirt driver: who should create the libvirt.xml file?
On 23.06.2016 11:50, Daniel P. Berrange wrote: > On Mon, Jun 20, 2016 at 05:47:57PM +0200, Markus Zoeller wrote: >> White working on the change series to implement the virtlogd feature I >> got feedback [1] to move code which creates parts of the libvirt.xml >> file from the "driver" module into the "guest" module. I'm a bit >> hesitant to do so as the responsibility of creating a valid libvirt.xml >> file is then spread across 3 modules: >> * driver.py >> * guest.py >> * designer.py >> I'm only looking for a guideline here (The "driver" module is humongous >> and I think it would be a good thing to have the "libvirt.xml" creation >> code outside of it). Thoughts? > > The designer.py file was created as a place which would ultimately hold > all the XML generator logic. > > Ultimately the "_get_guest_xml" (and everything it calls) from driver.py > would move into the designer.py class. Before we could do that though, we > needed to create the host.py + guest.py classes to isolate the libvirt > API logic. > > Now that the guest.py conversion/move is mostly done, we should be able > to start moving the XML generation out of driver.py and into designer.py > > I would definitely *not* put XML generation code into guest.py > > In terms of your immediate patch, I'd suggest just following current > practice and putting your new code in driver.py. We'll move everything > over to designer.py at the same time, later on. > > Regards, > Daniel > Cool, thanks! That was the guideline I hoped for. Count me in when the move to "designer.py" gets tackled. -- Regards, Markus Zoeller (markus_z) __ 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] [all][oslo] pbr potential breaking change coming
On 23.06.2016 12:21, Andreas Jaeger wrote: > On 06/23/2016 10:43 AM, Markus Zoeller wrote: >> On 21.06.2016 15:01, Doug Hellmann wrote: >>> A while back pbr had a feature that let projects pass "warnerror" >>> through to Sphinx during documentation builds, causing any warnings in >>> that build to be treated as an error and fail the build. This lets us >>> avoid things like links to places that don't exist in the docs, bad but >>> renderable rst, typos in directive or role names, etc. >>> >>> Somewhat more recently, but still a while ago, that feature "broke" >>> with a Sphinx release that was not API compatible. Sachi King has >>> fixed this issue within pbr, and so the next release of pbr will >>> fix the broken behavior and start correctly passing warnerror again. >>> That may result in doc builds breaking where they didn't before. >>> >>> The short-term solution is to turn of warnerrors (look in your >>> setup.cfg), then fix the issues and turn it back on. Or you could >>> preemptively fix any existing warnings in your doc builds before the >>> release, but it's simple enough to turn off the feature if there isn't >>> time. >>> >>> Josh, Sachi, & other Oslo folks, I think we should hold off on >>> releasing until next week to give folks time. Is that OK? >>> >>> Doug >>> >>> PS - Thanks, Sachi, I know that bug wasn't a ton of fun to fix! >> [...] >> >> Thanks for the heads up. I checked Nova, and every sphinx-build command >> we use in our "tox.ini" file already uses the -W flag to treat warnings >> as errors. I guess we're safe with that? >> > > Infra calls the docs job using > tox -e venv -- python setup.py build_sphinx > > And that's where the change comes in... > > So, your docs environment is not used as is in the gate, > > Andreas > Interesting, I didn't know that. It runs without warnings in Nova too, so hopefully everything's in a good shape for the pbr release. :) -- Regards, Markus Zoeller (markus_z) __ 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] [all][oslo] pbr potential breaking change coming
On 21.06.2016 15:01, Doug Hellmann wrote: > A while back pbr had a feature that let projects pass "warnerror" > through to Sphinx during documentation builds, causing any warnings in > that build to be treated as an error and fail the build. This lets us > avoid things like links to places that don't exist in the docs, bad but > renderable rst, typos in directive or role names, etc. > > Somewhat more recently, but still a while ago, that feature "broke" > with a Sphinx release that was not API compatible. Sachi King has > fixed this issue within pbr, and so the next release of pbr will > fix the broken behavior and start correctly passing warnerror again. > That may result in doc builds breaking where they didn't before. > > The short-term solution is to turn of warnerrors (look in your > setup.cfg), then fix the issues and turn it back on. Or you could > preemptively fix any existing warnings in your doc builds before the > release, but it's simple enough to turn off the feature if there isn't > time. > > Josh, Sachi, & other Oslo folks, I think we should hold off on > releasing until next week to give folks time. Is that OK? > > Doug > > PS - Thanks, Sachi, I know that bug wasn't a ton of fun to fix! > > __ > 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 > Thanks for the heads up. I checked Nova, and every sphinx-build command we use in our "tox.ini" file already uses the -W flag to treat warnings as errors. I guess we're safe with that? -- Regards, Markus Zoeller (markus_z) __ 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] I'm going to expire open bug reports older than 18 months.
On 21.06.2016 18:24, Adam Young wrote: > On 06/21/2016 08:43 AM, Markus Zoeller wrote: >> A reminder that this will happen in ~2 weeks. >> >> Please note that you can spare bug reports if you leave a comment there >> which says one of these (case-sensitive flags): >> * CONFIRMED FOR: NEWTON >> * CONFIRMED FOR: MITAKA >> * CONFIRMED FOR: LIBERTY >> >> On 23.05.2016 13:02, Markus Zoeller wrote: >>> TL;DR: Automatic closing of 185 bug reports which are older than 18 >>> months in the week R-13. Skipping specific bug reports is possible. A >>> bug report comment explains the reasons. >>> >>> >>> I'd like to get rid of more clutter in our bug list to make it more >>> comprehensible by a human being. For this, I'm targeting our ~185 bug >>> reports which were reported 18 months ago and still aren't in progress. >>> That's around 37% of open bug reports which aren't in progress. This >>> post is about *how* and *when* I do it. If you have very strong reasons >>> to *not* do it, let me hear them. >>> >>> When >>> >>> I plan to do it in the week after the non-priority feature freeze. >>> That's week R-13, at the beginning of July. Until this date you can >>> comment on bug reports so they get spared from this cleanup (see below). >>> Beginning from R-13 until R-5 (Newton-3 milestone), we should have >>> enough time to gain some overview of the rest. >>> >>> I also think it makes sense to make this a repeated effort, maybe after >>> each milestone/release or monthly or daily. >>> >>> How >>> --- >>> The bug reports which will be affected are: >>> * in status: [new, confirmed, triaged] >>> * AND without assignee >>> * AND created at: > 18 months >>> A preview of them can be found at [1]. >>> >>> You can spare bug reports if you leave a comment there which says >>> one of these (case-sensitive flags): >>> * CONFIRMED FOR: NEWTON >>> * CONFIRMED FOR: MITAKA >>> * CONFIRMED FOR: LIBERTY >>> >>> The expired bug report will have: >>> * status: won't fix >>> * assignee: none >>> * importance: undecided >>> * a new comment which explains *why* this was done >>> >>> The comment the expired bug reports will get: >>> This is an automated cleanup. This bug report got closed because >>> it is older than 18 months and there is no open code change to >>> fix this. After this time it is unlikely that the circumstances >>> which lead to the observed issue can be reproduced. >>> If you can reproduce it, please: >>> * reopen the bug report >>> * AND leave a comment "CONFIRMED FOR: " >>>Only still supported release names are valid. >>>valid example: CONFIRMED FOR: LIBERTY >>> invalid example: CONFIRMED FOR: KILO >>> * AND add the steps to reproduce the issue (if applicable) >>> >>> >>> Let me know if you think this comment gives enough information how to >>> handle this situation. >>> >>> >>> References: >>> [1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired >>> >> > DONT TOUCH BUG 968696! > I added a comment in the bug report (like described above) which keeps it open until Newton goes EOL. If you see other bug reports you care about, feel free to add a comment in their bug reports. -- Regards, Markus Zoeller (markus_z) __ 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] I'm going to expire open bug reports older than 18 months.
A reminder that this will happen in ~2 weeks. Please note that you can spare bug reports if you leave a comment there which says one of these (case-sensitive flags): * CONFIRMED FOR: NEWTON * CONFIRMED FOR: MITAKA * CONFIRMED FOR: LIBERTY On 23.05.2016 13:02, Markus Zoeller wrote: > TL;DR: Automatic closing of 185 bug reports which are older than 18 > months in the week R-13. Skipping specific bug reports is possible. A > bug report comment explains the reasons. > > > I'd like to get rid of more clutter in our bug list to make it more > comprehensible by a human being. For this, I'm targeting our ~185 bug > reports which were reported 18 months ago and still aren't in progress. > That's around 37% of open bug reports which aren't in progress. This > post is about *how* and *when* I do it. If you have very strong reasons > to *not* do it, let me hear them. > > When > > I plan to do it in the week after the non-priority feature freeze. > That's week R-13, at the beginning of July. Until this date you can > comment on bug reports so they get spared from this cleanup (see below). > Beginning from R-13 until R-5 (Newton-3 milestone), we should have > enough time to gain some overview of the rest. > > I also think it makes sense to make this a repeated effort, maybe after > each milestone/release or monthly or daily. > > How > --- > The bug reports which will be affected are: > * in status: [new, confirmed, triaged] > * AND without assignee > * AND created at: > 18 months > A preview of them can be found at [1]. > > You can spare bug reports if you leave a comment there which says > one of these (case-sensitive flags): > * CONFIRMED FOR: NEWTON > * CONFIRMED FOR: MITAKA > * CONFIRMED FOR: LIBERTY > > The expired bug report will have: > * status: won't fix > * assignee: none > * importance: undecided > * a new comment which explains *why* this was done > > The comment the expired bug reports will get: > This is an automated cleanup. This bug report got closed because > it is older than 18 months and there is no open code change to > fix this. After this time it is unlikely that the circumstances > which lead to the observed issue can be reproduced. > If you can reproduce it, please: > * reopen the bug report > * AND leave a comment "CONFIRMED FOR: " > Only still supported release names are valid. > valid example: CONFIRMED FOR: LIBERTY > invalid example: CONFIRMED FOR: KILO > * AND add the steps to reproduce the issue (if applicable) > > > Let me know if you think this comment gives enough information how to > handle this situation. > > > References: > [1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired > -- Regards, Markus Zoeller (markus_z) __ 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] [nova] libvirt driver: who should create the libvirt.xml file?
White working on the change series to implement the virtlogd feature I got feedback [1] to move code which creates parts of the libvirt.xml file from the "driver" module into the "guest" module. I'm a bit hesitant to do so as the responsibility of creating a valid libvirt.xml file is then spread across 3 modules: * driver.py * guest.py * designer.py I'm only looking for a guideline here (The "driver" module is humongous and I think it would be a good thing to have the "libvirt.xml" creation code outside of it). Thoughts? References: [1] https://review.openstack.org/#/c/323761/2/nova/virt/libvirt/driver.py@4190 -- Regards, Markus Zoeller (markus_z) __ 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] [nova] bugs team meeting of 2016-06-21 is cancelled
Due to a conflict with a company internal appointment I have to cancel tomorrows (2016-06-21) nova bugs team meeting. If you want to take over the bug skimming duty for this week, please add your name in the table at [1]. References: [1] https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty -- Regards, Markus Zoeller (markus_z) __ 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] Centralize Configuration: ignore service list for newton
On 20.05.2016 11:33, John Garbutt wrote: > Hi, > > The current config template includes a list of "Services which consume this": > http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/centralize-config-options.html#quality-view > > I propose we drop this list from the template. > > I am worried this is going to be hard to maintain, and hard to review > / check. As such, its of limited use to most deployers in its current > form. > > I have been thinking about a possible future replacement. Two separate > sample configuration files, one for the Compute node, and one for > non-compute nodes (i.e. "controller" nodes). The reason for this > split, is our move towards removing sensitive credentials from compute > nodes, etc. Over time, we could prove the split in gate testing, where > we look for conf options accessed by computes that shouldn't be, and > v.v. > > > Having said that, for newton, I propose we concentrate on: > * completing the move of all the conf options (almost there) > * (skip tidy up of deprecated options) > * tidying up the main description of each conf option > * tidy up the Opt group and Opt types, i.e. int min/max, str choices, etc > ** move options to use stevedoor, where needed > * deprecating ones that are dumb / unused > * identifying "required" options (those you have to set) > * add config group descriptions > * note any surprising dependencies or value meanings (-1 vs 0 etc) > * ensure the docs and sample files are complete and correct > > I am thinking we could copy API ref and add a comment at the top of > each file (expecting a separate patch for each step): > * fix_opt_registration_consistency (see sfinucan's tread) > * fix_opt_description_indentation > * check_deprecation_status > * check_opt_group_and_type > * fix_opt_description I pushed [1] which introduced the flags from above. I reordered them from most to least important, which is IMO: # needs:fix_opt_description # needs:check_deprecation_status # needs:check_opt_group_and_type # needs:fix_opt_description_indentation # needs:fix_opt_registration_consistency > Does that sound like a good plan? If so, I can write this up in a wiki page. > > > Thanks, > John > > PS > I also have concerns around the related config options bits and > possible values bit, but thats a different thread. Lets focus on the > main body of the description for now. > > __ > 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 > References: [1] https://review.openstack.org/#/c/322255/1 -- Regards, Markus Zoeller (markus_z) __ 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] [nova] #help: bug skimming for 1 week (R-18)
Nova needs one or more volunteers for the bug skimming duty [1] for the coming week (R-18). Unfortunately no one signed up yet. Let me know if you wanna help in this area. References: [1] https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty -- Regards, Markus Zoeller (markus_z) __ 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] Abandoned old code reviews
On 27.05.2016 11:36, Michael Still wrote: > Hi, > > I've spent some time today abandoning old reviews from the Nova queue. > Specifically, anything which hadn't been updated before February this year > has been abandoned with a message like this: > > "This patch has been idle for a long time, so I am abandoning it to keep > the review clean sane. If you're interested in still working on this patch, > then please unabandon it and upload a new patchset." > > Why do this? Abandoning the reviews means that Nova reviewers can focus on > things where the author is still actively working on the code. > Additionally, it makes it clearer which bugs are currently being worked. Thanks! My script which searches for bug reports "in progress" which are stale [1] is finding a lot more now. > Additionally, unabandoning a review is a fairly cheap operation, so please > let me know if I need to do that anywhere. > > We should probably abandon more patches than those before February, but I > got bored at this point. I'll probably abandon more later. > > Cheers, > Michael > > > > __ > 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 > References: [1] https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/bugs_dashboard.py#L276 -- Regards, Markus Zoeller (markus_z) __ 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] [all] expire old bug reports
FYI, script [1] expires old bug reports. It looks like some projects have done something like this before too. Please leave comments in the review if you think the bug report comment can be improved. Using the same comment (and final status of the bug report) across the projects could be useful. Feel free to use the script in your favorite project. I'll do that in week R-13 for Nova [2]. References: [1] https://review.openstack.org/#/c/321008/ [2] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095654.html -- Regards, Markus Zoeller (markus_z) __ 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] I'm going to expire open bug reports older than 18 months.
On 24.05.2016 19:05, Doug Hellmann wrote: > Excerpts from Markus Zoeller's message of 2016-05-24 11:00:35 +0200: >> On 24.05.2016 09:34, Duncan Thomas wrote: >>> Cinder bugs list was far more manageable once this had been done. >>> >>> It is worth sharing the tool for this? I realise it's fairly trivial to >>> write one, but some standardisation on the comment format etc seems >>> valuable, particularly for Q/A folks who work between different projects. >> >> A first draft (without the actual expiring) is at [1]. I'm going to >> finish it this week. If there is a place in an OpenStack repo, just give >> me a pointer and I'll push a change. >> >>> On 23 May 2016 at 14:02, Markus Zoeller <mzoel...@linux.vnet.ibm.com> wrote: >>> >>>> TL;DR: Automatic closing of 185 bug reports which are older than 18 >>>> months in the week R-13. Skipping specific bug reports is possible. A >>>> bug report comment explains the reasons. >>>> [...] >> >> References: >> [1] >> https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py >> > > Feel free to submit that to the openstack-infra/release-tools repo. We > have some other tools in that repo for managing launchpad bugs. > > Doug Thanks! I pushed https://review.openstack.org/#/c/321008/ -- Regards, Markus Zoeller (markus_z) __ 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] [nova] nova-bugs team meeting (Europe/Asia-friendly) is now earlier
Please be aware that the Europe/Asia-friendly time slot of the nova-bugs-team meeting [1] got moved from 10:00 UTC to 08:00 UTC. I'm doing this because this time slot isn't well attended in the last weeks and I think this new time slot will make it easier for folks in (East) Asia to attend. This takes effect starting from 2016-06-07 [2]. References: [1] https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam [2] https://review.openstack.org/#/c/320337/ -- Regards, Markus Zoeller (markus_z) __ 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] I'm going to expire open bug reports older than 18 months.
On 24.05.2016 09:34, Duncan Thomas wrote: > Cinder bugs list was far more manageable once this had been done. > > It is worth sharing the tool for this? I realise it's fairly trivial to > write one, but some standardisation on the comment format etc seems > valuable, particularly for Q/A folks who work between different projects. A first draft (without the actual expiring) is at [1]. I'm going to finish it this week. If there is a place in an OpenStack repo, just give me a pointer and I'll push a change. > On 23 May 2016 at 14:02, Markus Zoeller <mzoel...@linux.vnet.ibm.com> wrote: > >> TL;DR: Automatic closing of 185 bug reports which are older than 18 >> months in the week R-13. Skipping specific bug reports is possible. A >> bug report comment explains the reasons. >> [...] References: [1] https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py -- Regards, Markus Zoeller (markus_z) __ 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] [nova] I'm going to expire open bug reports older than 18 months.
TL;DR: Automatic closing of 185 bug reports which are older than 18 months in the week R-13. Skipping specific bug reports is possible. A bug report comment explains the reasons. I'd like to get rid of more clutter in our bug list to make it more comprehensible by a human being. For this, I'm targeting our ~185 bug reports which were reported 18 months ago and still aren't in progress. That's around 37% of open bug reports which aren't in progress. This post is about *how* and *when* I do it. If you have very strong reasons to *not* do it, let me hear them. When I plan to do it in the week after the non-priority feature freeze. That's week R-13, at the beginning of July. Until this date you can comment on bug reports so they get spared from this cleanup (see below). Beginning from R-13 until R-5 (Newton-3 milestone), we should have enough time to gain some overview of the rest. I also think it makes sense to make this a repeated effort, maybe after each milestone/release or monthly or daily. How --- The bug reports which will be affected are: * in status: [new, confirmed, triaged] * AND without assignee * AND created at: > 18 months A preview of them can be found at [1]. You can spare bug reports if you leave a comment there which says one of these (case-sensitive flags): * CONFIRMED FOR: NEWTON * CONFIRMED FOR: MITAKA * CONFIRMED FOR: LIBERTY The expired bug report will have: * status: won't fix * assignee: none * importance: undecided * a new comment which explains *why* this was done The comment the expired bug reports will get: This is an automated cleanup. This bug report got closed because it is older than 18 months and there is no open code change to fix this. After this time it is unlikely that the circumstances which lead to the observed issue can be reproduced. If you can reproduce it, please: * reopen the bug report * AND leave a comment "CONFIRMED FOR: " Only still supported release names are valid. valid example: CONFIRMED FOR: LIBERTY invalid example: CONFIRMED FOR: KILO * AND add the steps to reproduce the issue (if applicable) Let me know if you think this comment gives enough information how to handle this situation. References: [1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired -- Regards, Markus Zoeller (markus_z) __ 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] [all] Deprecated options in sample configs?
On 20.05.2016 16:51, Ben Nemec wrote: > On 05/20/2016 04:26 AM, Markus Zoeller wrote: >> On 05/19/2016 09:18 PM, Ben Nemec wrote: >>> On 05/17/2016 07:27 PM, Matt Fischer wrote: >>>> >>>> If config sample files are being used as a living document then that >>>> would be a reason to leave the deprecated options in there. In my >>>> experience as a cloud deployer I never once used them in that manner >>>> so it didn't occur to me that people might, hence my question to the >>>> list. >>>> >>>> This may also indicate that people aren't checking release notes as >>>> we hope they are. A release note is where I would expect to find >>>> this information aggregated with all the other changes I should be >>>> aware of. That seems easier to me than aggregating that data myself >>>> by checking various sources. >>>> >>>> >>>> >>>> One way to think about this is that the config file has to be accurate >>>> or the code won't work, but release notes can miss things with no >>>> consequences other than perhaps an annoyed operator. So they are sources >>>> of truth about the state options on of a release or branch. >>> >>> On this note, I had another thought about an alternative way to handle >>> this. What if we generated one sample file without deprecated opts, and >>> another with them (either exclusively, or in addition to all the other >>> opts)? That way there's a deprecation-free version for new deployers >>> and one for people who want to see all the current deprecations. >>> >> >> I'm not sure if it is well known that the "configuration reference" >> manual provides a summary page of new, updated and deprecated config >> options at [1]. > > Ah, I thought I had heard something about that but I couldn't find it. > I wonder if we could link it from > http://docs.openstack.org/developer/nova/sample_config.html > Sure, should be a simple patch to [1]. >> Also, the release notes have already a section to announce the >> deprecation of a config option and this should be the source of truth >> IMO. From Nova I can tell that it is part of the normal reviews to >> ensure that a reno file (with a good explanation) is part of the change >> when deprecating something (see a updated-per-commit version at [2]). >> Introducing yet another way of telling people what's deprecated would >> weaken the position of the release notes which I'd like to avoid. > > The problem is that the ultimate source of truth is the code, and since > the sample config is generated from the code it's the only method not > subject to human error. As I said earlier in the thread, I personally > agree that this is release note information and would prefer to rely on > the logged deprecation warning to address the human error case, but at > the same time I can understand that some people are not okay with that > so I'm trying to find an alternative that both cleans up the sample > config and still leaves the deprecations somewhere for people to find. > >> >> References: >> [1] >> http://docs.openstack.org/mitaka/config-reference/tables/conf-changes/nova.html >> [2] >> http://docs.openstack.org/releasenotes/nova/unreleased.html#deprecation-notes >> >>>> >>>> >>>> >>>> Anyways, I have no strong cause for removing the deprecated options. >>>> I just wondered if it was a low hanging fruit and thought I would ask. >>>> >>>> >>>> It's always good to have these kind of conversations, thanks for >>>> starting it. References: [1] https://github.com/openstack/nova/blob/master/doc/source/sample_config.rst -- Regards, Markus Zoeller (markus_z) __ 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] Centralize Configuration: ignore service list for newton
On 05/20/2016 11:33 AM, John Garbutt wrote: Hi, The current config template includes a list of "Services which consume this": http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/centralize-config-options.html#quality-view I propose we drop this list from the template. I am worried this is going to be hard to maintain, and hard to review / check. As such, its of limited use to most deployers in its current form. Unfortunately I still haven't found a way to collect this information in an automated way. :( I have been thinking about a possible future replacement. Two separate sample configuration files, one for the Compute node, and one for non-compute nodes (i.e. "controller" nodes). The reason for this split, is our move towards removing sensitive credentials from compute nodes, etc. Over time, we could prove the split in gate testing, where we look for conf options accessed by computes that shouldn't be, and v.v. Having said that, for newton, I propose we concentrate on: * completing the move of all the conf options (almost there) Only one left: https://review.openstack.org/314091 For the sake of completeness, there are two "SubCommandOpt" instances [1][2] which are purely used for CLI options and are *not* part of the "nova.conf" file. I think it's best to leave them where they are. All other config options in "nova/conf/" then share the same behavior of being configurable by the "nova.conf" file. * (skip tidy up of deprecated options) * tidying up the main description of each conf option * tidy up the Opt group and Opt types, i.e. int min/max, str choices, etc ** move options to use stevedoor, where needed * deprecating ones that are dumb / unused * identifying "required" options (those you have to set) * add config group descriptions * note any surprising dependencies or value meanings (-1 vs 0 etc) * ensure the docs and sample files are complete and correct I am thinking we could copy API ref and add a comment at the top of each file (expecting a separate patch for each step): * fix_opt_registration_consistency (see sfinucan's tread) * fix_opt_description_indentation * check_deprecation_status * check_opt_group_and_type * fix_opt_description Does that sound like a good plan? If so, I can write this up in a wiki page. Yes, sounds good. I can prepare a burndown chart like Sean did for the api-ref work [3]. Thanks, John PS I also have concerns around the related config options bits and possible values bit, but thats a different thread. Lets focus on the main body of the description for now. __ 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 References: [1] https://github.com/openstack/nova/blob/d619ad6ba15df1cf7dc92ddf84d1c65af018682f/nova/cmd/dhcpbridge.py#L92-L92 [2] https://github.com/openstack/nova/blob/b8aac794d4620aca341b269c6db71ea9e70d2210/nova/cmd/manage.py#L1397-L1397 [3] http://burndown.dague.org/ -- Regards, Markus Zoeller (markus_z) __ 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] [all] Deprecated options in sample configs?
On 05/19/2016 09:18 PM, Ben Nemec wrote: On 05/17/2016 07:27 PM, Matt Fischer wrote: If config sample files are being used as a living document then that would be a reason to leave the deprecated options in there. In my experience as a cloud deployer I never once used them in that manner so it didn't occur to me that people might, hence my question to the list. This may also indicate that people aren't checking release notes as we hope they are. A release note is where I would expect to find this information aggregated with all the other changes I should be aware of. That seems easier to me than aggregating that data myself by checking various sources. One way to think about this is that the config file has to be accurate or the code won't work, but release notes can miss things with no consequences other than perhaps an annoyed operator. So they are sources of truth about the state options on of a release or branch. On this note, I had another thought about an alternative way to handle this. What if we generated one sample file without deprecated opts, and another with them (either exclusively, or in addition to all the other opts)? That way there's a deprecation-free version for new deployers and one for people who want to see all the current deprecations. I'm not sure if it is well known that the "configuration reference" manual provides a summary page of new, updated and deprecated config options at [1]. Also, the release notes have already a section to announce the deprecation of a config option and this should be the source of truth IMO. From Nova I can tell that it is part of the normal reviews to ensure that a reno file (with a good explanation) is part of the change when deprecating something (see a updated-per-commit version at [2]). Introducing yet another way of telling people what's deprecated would weaken the position of the release notes which I'd like to avoid. References: [1] http://docs.openstack.org/mitaka/config-reference/tables/conf-changes/nova.html [2] http://docs.openstack.org/releasenotes/nova/unreleased.html#deprecation-notes Anyways, I have no strong cause for removing the deprecated options. I just wondered if it was a low hanging fruit and thought I would ask. It's always good to have these kind of conversations, thanks for starting it. __ 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] [nova] config options: current state (R-21)
> From: Michael Still <mi...@stillhq.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 05/09/2016 11:12 PM > Subject: Re: [openstack-dev] config options: current state (R-21) > > On Tue, May 10, 2016 at 2:12 AM, Markus Zoeller <mzoel...@de.ibm.com> wrote: > We're close to have all options moved to "nova/conf/". At the bottom > is a list of the remaining options and their open reviews. > > The documentation of the options in "nova/conf/" is done for ~ 150 > options. Which means ~ 450 are missing. This means there are still > around 80 changes necessary to complete the work. The deadline for this > work is June 30th [1]. Please note that this is 2 weeks shorter than > usual due to the huge backlog of nova work items. > > If you have moved config options, please ensure that a follow up patch > which improves the config option help texts is ready for review. > This is the most important part of this effort. > > For questions, ping me in #openstack-nova > > References > [1] http://releases.openstack.org/newton/schedule.html > > Regards, Markus Zoeller (markus_z) > > I don't know if its useful to others, but I've created a dashboard > for these and put it on https://wiki.openstack.org/wiki/Nova/GerritDashboards > -- there actually aren't all that many reviews out at the moment, so > I guess we're waiting mostly on people to document flags? > > Michael > True, there are a lot of documentation changes missing. Therefore here again, if you moved config options to "nova/conf/", please also push a change with the improvement of their help texts! The dashboard is good, I'm going to use it. Regards, Markus Zoeller (markus_z) __ 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] config options: current state (R-21)
We're close to have all options moved to "nova/conf/". At the bottom is a list of the remaining options and their open reviews. The documentation of the options in "nova/conf/" is done for ~ 150 options. Which means ~ 450 are missing. This means there are still around 80 changes necessary to complete the work. The deadline for this work is June 30th [1]. Please note that this is 2 weeks shorter than usual due to the huge backlog of nova work items. If you have moved config options, please ensure that a follow up patch which improves the config option help texts is ready for review. This is the most important part of this effort. For questions, ping me in #openstack-nova References [1] http://releases.openstack.org/newton/schedule.html Regards, Markus Zoeller (markus_z) Appendix: = nova [1]https://review.openstack.org/314091 --- api [3] https://review.openstack.org/#/c/309192/ et al. -- metadata [4]see above ^^^ -- openstack [6] see above ^^^ - compute [2] see above ^^^ legacy_v2 [2] see above ^^^ --- contrib [6]see above ^^^ --- cmd [2] TODO markus_z --- compute [1] https://review.openstack.org/314123 --- db [4] https://review.openstack.org/#/c/263804/ -- sqlalchemy [13] https://review.openstack.org/#/c/263804/ --- image [7]https://review.openstack.org/314146 -- download [2] TODO markus_z --- network [2] https://review.openstack.org/#/c/274210/ --- servicegroup [1] https://review.openstack.org/#/c/303074 -- libvirt [0] - volume [11]https://review.openstack.org/#/c/309342/5 et al. -- xenapi [3]https://review.openstack.org/#/c/302446/ __ 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] config: deduce related options for config generator?
> From: Doug Hellmann <d...@doughellmann.com>
> To: openstack-dev <openstack-dev@lists.openstack.org>
> Date: 05/03/2016 07:04 PM
> Subject: Re: [openstack-dev] [oslo] config: deduce related options for
> config generator?
>
> Excerpts from Markus Zoeller's message of 2016-05-03 18:26:50 +0200:
> > While working on [1] I came across a config option ("pybasedir")
> > which gets used as a base for many other options, for example
> > "state_path". The option "state_path" shows then a default value
> > "state_path = $pybasedir".
> > My question here is, is it possible/reasonable to enhance oslo.config
> > to add an information to "pybasedir" that is used as a base for other
> > config options?
> > My concern is, that one could change "pybasedir" and expect that only
> > this one single value changes, but actually one changes multiple other
> > config options as well. Making it explicit that "pybasedir" gets used
> > multiple times as a base could prevent confusion.
> >
> > References:
> > [1] https://review.openstack.org/#/c/299236/7/nova/conf/paths.py
> >
> > Regards, Markus Zoeller (markus_z)
> >
>
> (Sorry if this is a dupe, I'm having mail client issues.)
>
> We can detect interpolated values in defaults, but those can also appear
> in user-provided values. There are also plenty of options that are
> related to each other without using interpolation.
>
> Given that we have to handle the explicit cases anyway, and that
> interpolation isn't used all that often, I think it likely makes more
> sense to start with the explicit implementation and see how far that
> takes us before adding any automation.
>
> Doug
>
Yeah, interpolation is rarely used (at least in Nova). I only had the
usage of interpolation in default values in mind. If the effort in
oslo.config would be too big, it probably isn't reasonable to push
this. Thank you Doug, for checking the possibilities.
Regards, Markus Zoeller (markus_z)
__
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] [oslo] config: deduce related options for config generator?
While working on [1] I came across a config option ("pybasedir")
which gets used as a base for many other options, for example
"state_path". The option "state_path" shows then a default value
"state_path = $pybasedir".
My question here is, is it possible/reasonable to enhance oslo.config
to add an information to "pybasedir" that is used as a base for other
config options?
My concern is, that one could change "pybasedir" and expect that only
this one single value changes, but actually one changes multiple other
config options as well. Making it explicit that "pybasedir" gets used
multiple times as a base could prevent confusion.
References:
[1] https://review.openstack.org/#/c/299236/7/nova/conf/paths.py
Regards, Markus Zoeller (markus_z)
__
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] Launchpad bug spring cleaning day Monday 4/18
In case the dashboard is not loading, you can use * query_inconsistent.py * query_stale_incomplete.py from https://github.com/markuszoeller/openstack/tree/master/scripts/launchpad Regards, Markus Zoeller (markus_z) > From: Matt Riedemann <mrie...@linux.vnet.ibm.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 04/05/2016 08:45 PM > Subject: [openstack-dev] [nova] Launchpad bug spring cleaning day Monday 4/18 > > We're going to have a day of just cleaning out the launchpad bugs for > Nova on Monday 4/18. > > This isn't a bug squashing day where people are proposing patches and > the core team is reviewing them. > > This is purely about cleaning the garbage out of launchpad. > > Markus Zoeller has a nice dashboard we can use. I'd like to specifically > focus on trimming these two tabs: > > 1. Inconsistent: > http://45.55.105.55:8082/bugs-dashboard.html#tabInconsistent (142 bugs > today) > > 2. Stale Incomplete: > http://45.55.105.55:8082/bugs-dashboard.html#tabIncompleteStale (59 bugs > today) > > A lot of these are probably duplicates by now, or fixed, or just invalid > and we should close them out. That's what we'll focus on. > > I'd really like to see solid participation from the core team given the > core team should know a lot of what's already fixed or invalid, and > being part of the core team is more than just reviewing code, it's also > making sure our bug backlog is reasonably sane. > > -- > > Thanks, > > Matt Riedemann > > > __ > 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] Launchpad bug spring cleaning day Monday 4/18
A short reminder that this is happening next Monday 04/18 A few stats are at: http://45.55.105.55:8082/bugs-stats.html Regards, Markus Zoeller (markus_z) > From: Matt Riedemann <mrie...@linux.vnet.ibm.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 04/05/2016 08:45 PM > Subject: [openstack-dev] [nova] Launchpad bug spring cleaning day Monday 4/18 > > We're going to have a day of just cleaning out the launchpad bugs for > Nova on Monday 4/18. > > This isn't a bug squashing day where people are proposing patches and > the core team is reviewing them. > > This is purely about cleaning the garbage out of launchpad. > > Markus Zoeller has a nice dashboard we can use. I'd like to specifically > focus on trimming these two tabs: > > 1. Inconsistent: > http://45.55.105.55:8082/bugs-dashboard.html#tabInconsistent (142 bugs > today) > > 2. Stale Incomplete: > http://45.55.105.55:8082/bugs-dashboard.html#tabIncompleteStale (59 bugs > today) > > A lot of these are probably duplicates by now, or fixed, or just invalid > and we should close them out. That's what we'll focus on. > > I'd really like to see solid participation from the core team given the > core team should know a lot of what's already fixed or invalid, and > being part of the core team is more than just reviewing code, it's also > making sure our bug backlog is reasonably sane. > > -- > > Thanks, > > Matt Riedemann > > > __ > 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] [all] [devstack] Adding example "local.conf" files for testing?
> From: Dean Troyer <dtro...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 04/14/2016 08:18 PM > Subject: Re: [openstack-dev] [all] [devstack] Adding example > "local.conf" files for testing? > > On Thu, Apr 14, 2016 at 11:58 AM, Markus Zoeller <mzoel...@de.ibm.com> wrote: > Let me know what you think: https://review.openstack.org/#/c/305967/ > > My only real concern is you've implied a structure that will > potentially have many combinations of configurations and those will > bitrot. How different are x86 and s390 arch in local.conf? (I've > never seen an s390 local.conf!) I do know there are few, if any, > differences between most ubuntu and fedora configs, we abstract most > of that out in the scripts. > > I wonder if the grouping of configs might be better suited along usa- > case lines? nova-net vs neutron, single- vs multi-node, etc. > > Thanks for getting this started! > dt > > -- > > Dean Troyer > dtro...@gmail.com The main difference between x86 and s390x (system z) is that s390x doesn't support nova-network and VNC|RDP|SPICE. Which means s390x depends on Neutron and the "serial console". The rest should work like on x86. I guess having an IF-ELSE block in a "local.conf" is crazy talk? Regards, Markus Zoeller (markus_z) __ 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] [all] [devstack] Adding example "local.conf" files for testing?
> From: Matt Riedemann <mrie...@linux.vnet.ibm.com> > To: openstack-dev@lists.openstack.org > Date: 04/14/2016 04:53 PM > Subject: Re: [openstack-dev] [all] [devstack] Adding example > "local.conf" files for testing? > > > > On 4/14/2016 6:09 AM, Sean Dague wrote: > > On 04/14/2016 05:19 AM, Markus Zoeller wrote: > >>> From: Neil Jerram <neil.jer...@metaswitch.com> > >>> To: "OpenStack Development Mailing List (not for usage questions)" > >>> <openstack-dev@lists.openstack.org> > >>> Date: 04/14/2016 10:50 AM > >>> Subject: Re: [openstack-dev] [all] [devstack] Adding example > >>> "local.conf" files for testing? > >>> > >>> On 14/04/16 08:35, Markus Zoeller wrote: > >>>> Sometimes (especially when I try to reproduce bugs) I have the need > >>>> to set up a local environment with devstack. Everytime I have to look > >>>> at my notes to check which option in the "local.conf" have to be set > >>>> for my needs. I'd like to add a folder in devstacks tree which hosts > >>>> multiple example local.conf files for different, often used setups. > >>>> Something like this: > >>>> > >>>> example-confs > >>>> --- newton > >>>> --- --- x86-ubuntu-1404 > >>>> --- --- --- minimum-setup > >>>> --- --- --- --- README.rst > >>>> --- --- --- --- local.conf > >>>> --- --- --- serial-console-setup > >>>> --- --- --- --- README.rst > >>>> --- --- --- --- local.conf > >>>> --- --- --- live-migration-setup > >>>> --- --- --- --- README.rst > >>>> --- --- --- --- local.conf.controller > >>>> --- --- --- --- local.conf.compute1 > >>>> --- --- --- --- local.conf.compute2 > >>>> --- --- --- minimal-neutron-setup > >>>> --- --- --- --- README.rst > >>>> --- --- --- --- local.conf > >>>> --- --- s390x-1.1.1-vulcan > >>>> --- --- --- minimum-setup > >>>> --- --- --- --- README.rst > >>>> --- --- --- --- local.conf > >>>> --- --- --- live-migration-setup > >>>> --- --- --- --- README.rst > >>>> --- --- --- --- local.conf.controller > >>>> --- --- --- --- local.conf.compute1 > >>>> --- --- --- --- local.conf.compute2 > >>>> --- mitaka > >>>> --- --- # same structure as master branch. omitted for brevity > >>>> --- liberty > >>>> --- --- # same structure as master branch. omitted for brevity > >>>> > >>>> Thoughts? > >>> > >>> Yes, this looks useful to me. Only thing is that you shouldn't need the > >> > >>> per-release subtrees, though; the DevStack repository already has > >>> per-release stable/ branches, which you need to check out in > >>> order to do a DevStack setup of a past release. So I would expect the > >>> local.confs for each past release to live in the corresponding branch. > >>> > >>> Regards, > >>> Neil > >> > >> My intention was to avoid that there is a folder "current" or "trunk" > >> or similar, which doesn't get updated. That's the issue Steve talked > >> about. > >> > >> The workflow could be, at every new cycle: > >> * create a new "release folder" (Newton, Ocata, ...) > >> * copy the "setup folders" (minimum-setup, ...) to the new folder > >> * clean up the "local.conf" file(s) of deprecated options > >> * delete a "release folder" if the release is EOL > >> > >> I also assume that this would make potential backports easier. > > > > I think this would be useful, and accepted easily. > > > > I *don't* think we want per release directories. Because it confuses the > > issue on whether or not devstack master can install liberty (which it > > can't). > > > > Every local.conf should include a documentation page as well that > > describes the scenario, which means these would be easy to snag off the > > web docs. > > > >-Sean > > > > +1 to add example scenarios (I have a copy of a basic neutron + ovs that > I got from a co-worker) and -1 on release-specific directories, we don't > need them as pointed out already, that's what the branches are for in > the git repo. The trunk local.confs should be updated naturally as > people try to use them and hit issues. > > -- > > Thanks, > > Matt Riedemann > Let me know what you think: https://review.openstack.org/#/c/305967/ __ 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] [all] [devstack] Adding example "local.conf" files for testing?
> From: Neil Jerram <neil.jer...@metaswitch.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 04/14/2016 10:50 AM > Subject: Re: [openstack-dev] [all] [devstack] Adding example > "local.conf" files for testing? > > On 14/04/16 08:35, Markus Zoeller wrote: > > Sometimes (especially when I try to reproduce bugs) I have the need > > to set up a local environment with devstack. Everytime I have to look > > at my notes to check which option in the "local.conf" have to be set > > for my needs. I'd like to add a folder in devstacks tree which hosts > > multiple example local.conf files for different, often used setups. > > Something like this: > > > > example-confs > > --- newton > > --- --- x86-ubuntu-1404 > > --- --- --- minimum-setup > > --- --- --- --- README.rst > > --- --- --- --- local.conf > > --- --- --- serial-console-setup > > --- --- --- --- README.rst > > --- --- --- --- local.conf > > --- --- --- live-migration-setup > > --- --- --- --- README.rst > > --- --- --- --- local.conf.controller > > --- --- --- --- local.conf.compute1 > > --- --- --- --- local.conf.compute2 > > --- --- --- minimal-neutron-setup > > --- --- --- --- README.rst > > --- --- --- --- local.conf > > --- --- s390x-1.1.1-vulcan > > --- --- --- minimum-setup > > --- --- --- --- README.rst > > --- --- --- --- local.conf > > --- --- --- live-migration-setup > > --- --- --- --- README.rst > > --- --- --- --- local.conf.controller > > --- --- --- --- local.conf.compute1 > > --- --- --- --- local.conf.compute2 > > --- mitaka > > --- --- # same structure as master branch. omitted for brevity > > --- liberty > > --- --- # same structure as master branch. omitted for brevity > > > > Thoughts? > > Yes, this looks useful to me. Only thing is that you shouldn't need the > per-release subtrees, though; the DevStack repository already has > per-release stable/ branches, which you need to check out in > order to do a DevStack setup of a past release. So I would expect the > local.confs for each past release to live in the corresponding branch. > > Regards, >Neil My intention was to avoid that there is a folder "current" or "trunk" or similar, which doesn't get updated. That's the issue Steve talked about. The workflow could be, at every new cycle: * create a new "release folder" (Newton, Ocata, ...) * copy the "setup folders" (minimum-setup, ...) to the new folder * clean up the "local.conf" file(s) of deprecated options * delete a "release folder" if the release is EOL I also assume that this would make potential backports easier. Regards, Markus Zoeller (markus_z) __ 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 API doc import, and next steps
> From: Sean Dague <s...@dague.net>
> To: openstack-dev@lists.openstack.org
> Date: 04/13/2016 05:08 PM
> Subject: [openstack-dev] [nova] Nova API doc import, and next steps
>
> I think we've gotten the automatic converters for the wadl files to
> about as good as we're going to get. The results right now are here -
> https://review.openstack.org/#/c/302500/
>
> There remain many issues in the content (there are many issues in the
> source content, and a few crept in during imperfect translation),
> however at some point we need to just call the automatic translation
> effort "good enough", commit it, and start fixing the docs in chunks. I
> think we are at that stage.
>
> Once we get those bits committed, it's time to start fixing what
> remains. I started an etherpad for the rough guide here -
> https://etherpad.openstack.org/p/nova-api-docs-in-rst there are a few
> global level things, but a bunch of this is a set of verifications and
> fixes that will have to happen for every *.inc file.
>
> for every file in api-ref/sources/*.inc
>
> 1. Verify methods
> 1. Do all methods of the resource currently exist?
> 2. Rearange methods in order (sorted by url)
> 1. GET
> 2. POST
> 3. PUT
> 4. DELETE
> 5. i.e. for servers.inc GET /servers, POST /servers, GET
> /servers/details, GET /servers/{id}, PUT /servers/{id},
> DELETE /servers/{id}
> 2. Verify all parameters
> 1. Are all parameters that exist in the resource are listed
> 2. Are all parameters referencing the right lookup value in
> parameters.yaml
> 1. name, id are common issues, will need $foo_name and
$foo_id
> created
> 3. Add microversion parameters at the end of the table in order
of
> introduction
> 1. min_ver: 2.10 is a valid parameter key
> 3. Examples
> 1. Is there an example response for all request / response that
> have
> a body
> 2. Is there an english description of the change in question
> explaining the action that it would have
> 4. Body Text
> 1. Is formatting of the introduction text for each section well
> formatted (lists and headers were stripped in the
processing)
>
> My feeling is that we should probably create a fleet of bugs which is 1
> per source file and phase, with a set of api-ref tags. This will give us
> easy artifacts to hand off to people, and know which ones are getting
> done and which ones remain. A lot of this work is pretty easy, just
> takes some time.
>
> I'd like to get the base patches landed in the next day or so so that we
> can start chugging through these fixes pre summit, and do a virtual doc
> sprint post summit to push through to completion.
>
>-Sean
>
> --
> Sean Dague
> http://dague.net
The rendered output looks pretty neat. I like that all is on one page:
http://docs-draft.openstack.org/00/302500/9/check/gate-nova-api-ref/81d644c/api-ref/build/html/
One bug report per source-file sounds reasonable. Adding the
"low-hanging-fruit" tag will maybe get you some volunteers.
Regards, Markus Zoeller (markus_z)
__
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] [all] [devstack] Adding example "local.conf" files for testing?
Sometimes (especially when I try to reproduce bugs) I have the need to set up a local environment with devstack. Everytime I have to look at my notes to check which option in the "local.conf" have to be set for my needs. I'd like to add a folder in devstacks tree which hosts multiple example local.conf files for different, often used setups. Something like this: example-confs --- newton --- --- x86-ubuntu-1404 --- --- --- minimum-setup --- --- --- --- README.rst --- --- --- --- local.conf --- --- --- serial-console-setup --- --- --- --- README.rst --- --- --- --- local.conf --- --- --- live-migration-setup --- --- --- --- README.rst --- --- --- --- local.conf.controller --- --- --- --- local.conf.compute1 --- --- --- --- local.conf.compute2 --- --- --- minimal-neutron-setup --- --- --- --- README.rst --- --- --- --- local.conf --- --- s390x-1.1.1-vulcan --- --- --- minimum-setup --- --- --- --- README.rst --- --- --- --- local.conf --- --- --- live-migration-setup --- --- --- --- README.rst --- --- --- --- local.conf.controller --- --- --- --- local.conf.compute1 --- --- --- --- local.conf.compute2 --- mitaka --- --- # same structure as master branch. omitted for brevity --- liberty --- --- # same structure as master branch. omitted for brevity Thoughts? Regards, Markus Zoeller (markus_z) __ 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] [all][stackalytics] Gaming the Stackalyticsstats
> From: Masayuki Igawa <masayuki.ig...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 04/11/2016 03:20 AM > Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats > > 2016-04-11 9:46 GMT+09:00 Matt Riedemann <mrie...@linux.vnet.ibm.com>: > > > > > > On 4/10/2016 6:37 PM, Clint Byrum wrote: > >> > >> Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700: > >>> > >>> There is also disincentive in +1ing a change that you don't understand > >>> and is wrong and then a core comes along and -1s it (you get dinged for > >>> the disagreement). And there is disincentive in -1ing a change for the > >>> wrong reasons (silly nits or asking questions for understanding). I ask > >>> a lot of questions in a lot of changes and I don't vote on those because > >>> it would be inappropriate. > >>> > >> > >> Why is disagreement a negative thing? IMO, reviewers who agree too much > >> are just part of the echo chamber. > >> > >> __ > >> 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 > >> > > > > I'm not saying disagreement is a negative thing, I was saying there are > > times when I've seen people -1 for crazy nits, e.g. there should be a blank > > line between the bug ref and change-id in the commit message, or for asking > > questions for understanding (which, btw, I'm fine with -1 for 'add a comment > > because this is complicated and I didn't get it at first'). And I'm also not > > crazy about piling on or agreeing with everything either. My point is I > > think it's appropriate in a lot of cases to just not vote but still comment. > > I think we have some/many implicit rules for our review. There's a > document[1] for review > but it doesn't mention crazy nits. So should we add what we don't want > to see people -1 for? > > [1] http://docs.openstack.org/infra/manual/developers.html#peer-review My basic rule of thumb for voting is: vote | translates to - -1 | "I understand the code and your change and I'd rather not | maintain it. My reasons are [...] and suggestions are [...]." +1 | "I understand the code and your change. It improves the project and I'd maintain it." 0 | "I don't get the code or your change. My questions are [...]." If it already has at least one +2, I (usually) ignore it. The change already has attention from the cores, it is unlikely that I can add more valuable feedback to that change. I don't break (-1) for typos/nits. Ask the author for a follow-up patch. Regards, Markus Zoeller (markus_z) > > > > -- > > > > Thanks, > > > > Matt Riedemann > > > > > > > > __ > > 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] [nova][glance] Proposal to remove `nova image-*` commands from novaclient
"Steve Martinelli" <steve...@ca.ibm.com> wrote on 04/06/2016 06:45:42 AM: > From: "Steve Martinelli" <steve...@ca.ibm.com> > To: "OpenStack Development Mailing List \(not for usage questions\)" > <openstack-dev@lists.openstack.org> > Date: 04/06/2016 06:46 AM > Subject: Re: [openstack-dev] [nova][glance] Proposal to remove `nova > image-*` commands from novaclient > > +1000. Totally in favor of this, if anything it seems overdue, I'm a > bit surprised that they aren't already deprecated. Two alternatives > exist for the CLI (osc and glanceclient), and two alternatives exist > for python API bindings (SDK and glanceclient). > > This should follow the same case with the nova volume-* commands, > deprecate for 2 releases [1] and then remove [2]. The deprecation > message can point users to OSC and glanceclient. > > [1] https://github.com/openstack/python-novaclient/commit/ > 23f13437dd64496fcbc138bbaa9b0ac615a3cf23 > [2] https://github.com/openstack/python-novaclient/commit/ > a42570268915f42405ed0b0a67c25686b5db22ce > > Thanks, > > Steve Martinelli > OpenStack Keystone Project Team Lead +1 for deprecation and removal To be honest, when I started with Nova during Kilo, I didn't get why we have those passthrough APIs. They looked like convenience APIs. A short history lesson, why they got introduced, would be cool. I only found commit [1] which looks like they were there from the beginning. References: [1] https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33 Regards, Markus Zoeller (markus_z) > [image removed] Matt Riedemann ---2016/04/05 03:49:05 PM---As we > discuss the glance v2 spec for nova, questions are coming up around > what to do about the nova > > From: Matt Riedemann <mrie...@linux.vnet.ibm.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 2016/04/05 03:49 PM > Subject: [openstack-dev] [nova][glance] Proposal to remove `nova > image-*` commands from novaclient > > > > As we discuss the glance v2 spec for nova, questions are coming up > around what to do about the nova images API which is a proxy for glance v1. > > I don't want to add glance v2 support to the nova API since that's just > more proxy gorp. > > I don't think we can just make the nova images API fail if we're using > glance v2 in the backend, but we'll need some translation later for: > > user->nova-images->glance.v2->glance.v1(ish)->user > > But we definitely want people to stop using the nova images API. > > I think we can start by deprecating the nova images-* commands in > python-novaclient, and probably the python API bindings in novaclient too. > > People should be using python-glanceclient or python-openstackclient for > the CLI, and python-glanceclient or some SDK for the python API bindings. > > We recently removed the deprecated nova volume-* stuff from novaclient, > this would be the same idea. > > Does anyone have an issue with this? > > -- > > Thanks, > > Matt Riedemann > > > __ > 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] [nova] the bugs team needs (more) members
> From: Adam Lawson <alaw...@aqorn.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 04/01/2016 09:58 PM > Subject: Re: [openstack-dev] [nova] the bugs team needs (more) members > > Markus, > > If you van connect me with someone who can tell me what needs the most > attention and how to get started, I'd be happy to help. > > //adam Checking new bug reports if they can be reproduced is an important and valuable task. For example: https://bugs.launchpad.net/nova/+bug/1564905 https://bugs.launchpad.net/nova/+bug/1524301 https://bugs.launchpad.net/nova/+bug/1484081 It's a bit intimidating at the beginning, so don't worry if it doesn't bring results immediately. Just add the link to the bug and your name at [1] to signal others that you're working on that and give it a try. A bit easier is the task to double-check the current status of "stale in progress" bug reports [2]. It's mainly pinging the current assignees in IRC (or in a comment) if they are still working on this. If you have questions, ping me in IRC (my name is "markus_z"). References: [1] https://etherpad.openstack.org/p/nova-bugs-team [2] http://45.55.105.55:8082/bugs-dashboard.html#tabInProgressStale > > Adam Lawson > > AQORN, Inc. > 427 North Tatnall Street > Ste. 58461 > Wilmington, Delaware 19801-2230 > Toll-free: (844) 4-AQORN-NOW ext. 101 > International: +1 302-387-4660 > Direct: +1 916-246-2072 > > On Fri, Apr 1, 2016 at 3:46 AM, Markus Zoeller <mzoel...@de.ibm.com> wrote: > TL;DR: * The Nova bugs team needs more members >* Tasks: https://wiki.openstack.org/wiki/BugTriage >* Cleanup: http://45.55.105.55:8082/bugs-dashboard.html >* Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam >* Etherpad: https://etherpad.openstack.org/p/nova-bugs-team > > > The Nova project has a large backlog of open bug reports. Around 5 new > bug reports get created everyday. It is not possible to make a > reasonable progress with the current number of people. The nova bugs > team needs to play a more active role and it needs more people for that. > > > What's in for you? > -- > As bugs are in every software in every place, you will get around a lot. > Having a specific issue makes it also easier to ping other folks to > discuss this issue. Bug fixes also don't have the hard deadlines > imposed on feature patches. Being once on the bug triage side will > improve the quality of your future bug reports which will make them > more likely to get solved. > > > Current Status > -- > The main issue which slows down all following steps are bug reports > without the essential informations [1]: > * versions (nova, hypervisor, database, ...) > * steps-to-reproduce (with actual data) > * expected behavior > * actual observed behavior > * logs (in debug mode) > * topology (for example: nova-network vs. neutron) > Although this gets asked for when creating a bug report, the vast > majority of bug reports lack this information. Usually it takes one > to three roundtrips to get this information from the reporter. This > is time consuming. As we focus less on new features in Newton [2] I > have the hope that the bug list will get more attention. > > > Tasks > - > The tasks are listed in the wiki [3]. They "just" need to be done. > Repeatedly. Some on a daily basis, some less frequently. The cleanup > dashboard [4] is a tool I use personally but can be used by you too. > > The Neutron folks introduced a weekly rotating bug skimming duty and > they've made good experiences with it. This involves 1-3 people who > check new bugs reports if they are valid and provide the essential > information. We should adapt that [5]. > > In general we should aim for: > * respond to new bugs in a timely manner to get high quality reports > * clean up the "old stuff" (>= 1.5 years) > * spread the effort to multiple shoulders > * rotate the different efforts to prevent exhaustion and tunnel vision > > There is an ongoing effort to move the RFEs (request for feature > enhancements) away from the bug list [6] to allow us to be more > focused on faulty behavior of existing features people already rely on. > > > Organization > > * The nova bugs team has an IRC meeting [7] which allows us to sync > with each other. > * The cleanup dashboard [4] shows bug reports which need a check > based on the tasks [3]. > * The etherpad [8] can be used to avoid an overlap of efforts of > different people. > > > Education > ---
[openstack-dev] [nova] the bugs team needs (more) members
TL;DR: * The Nova bugs team needs more members * Tasks: https://wiki.openstack.org/wiki/BugTriage * Cleanup: http://45.55.105.55:8082/bugs-dashboard.html * Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam * Etherpad: https://etherpad.openstack.org/p/nova-bugs-team The Nova project has a large backlog of open bug reports. Around 5 new bug reports get created everyday. It is not possible to make a reasonable progress with the current number of people. The nova bugs team needs to play a more active role and it needs more people for that. What's in for you? -- As bugs are in every software in every place, you will get around a lot. Having a specific issue makes it also easier to ping other folks to discuss this issue. Bug fixes also don't have the hard deadlines imposed on feature patches. Being once on the bug triage side will improve the quality of your future bug reports which will make them more likely to get solved. Current Status -- The main issue which slows down all following steps are bug reports without the essential informations [1]: * versions (nova, hypervisor, database, ...) * steps-to-reproduce (with actual data) * expected behavior * actual observed behavior * logs (in debug mode) * topology (for example: nova-network vs. neutron) Although this gets asked for when creating a bug report, the vast majority of bug reports lack this information. Usually it takes one to three roundtrips to get this information from the reporter. This is time consuming. As we focus less on new features in Newton [2] I have the hope that the bug list will get more attention. Tasks - The tasks are listed in the wiki [3]. They "just" need to be done. Repeatedly. Some on a daily basis, some less frequently. The cleanup dashboard [4] is a tool I use personally but can be used by you too. The Neutron folks introduced a weekly rotating bug skimming duty and they've made good experiences with it. This involves 1-3 people who check new bugs reports if they are valid and provide the essential information. We should adapt that [5]. In general we should aim for: * respond to new bugs in a timely manner to get high quality reports * clean up the "old stuff" (>= 1.5 years) * spread the effort to multiple shoulders * rotate the different efforts to prevent exhaustion and tunnel vision There is an ongoing effort to move the RFEs (request for feature enhancements) away from the bug list [6] to allow us to be more focused on faulty behavior of existing features people already rely on. Organization * The nova bugs team has an IRC meeting [7] which allows us to sync with each other. * The cleanup dashboard [4] shows bug reports which need a check based on the tasks [3]. * The etherpad [8] can be used to avoid an overlap of efforts of different people. Education - It's possible to use the nova bugs team IRC meeting for education sessions if this helps you. I will also attend the summit in Austin in a few weeks. We can do an unofficial "bugs mgmt process" crash course there if you like. Just talk to me there (or beforehand in IRC) and we will find the time and space. At last I can offer a Google Hangout session if some are interested in that. How to Join? * Join the nova-bugs Launchpad group [9] * Familiarize with the process [10] * Attend the bugs meeting [7] With a few people who are willing to spent a few hours per week we can create a well maintained bug list where issues get addressed in a timely manner to consistently improve the quality of Nova. References -- [1] "working on bug reports; what blocks you?": http://lists.openstack.org/pipermail/openstack-dev/2016-March/089677.html [2] "No spec approvals for new things until after the summit": http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html [3] https://wiki.openstack.org/wiki/BugTriage [4] http://45.55.105.55:8082/bugs-dashboard.html [5] https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty [6] "Wishlist bugs == (trivial) blueprint?": http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html [7] https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam [8] https://etherpad.openstack.org/p/nova-bugs-team [9] https://launchpad.net/~nova-bugs [10] http://markuszoeller.github.io/posts/2015/12/01/openstack-bugs/ Regards, Markus Zoeller (markus_z) __ 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] Bug for image_cache_manager refactoring
> From: Augustina Ragwitz <augustina.ragw...@hpe.com> > To: <openstack-dev@lists.openstack.org> > Date: 03/25/2016 08:52 PM > Subject: [openstack-dev] [nova] Bug for image_cache_manager refactoring > > I came across a bug filed back in August [1] that brought up a > potential issue with the image_cache_manager in that the loop for > building the BlockDeviceMappingList has the potential to generate > enough messages to take down nova-conductor. There is a TODO comment > in the code that indicates it needs to be refactored. It looks like > there was a fix proposed that was recently abandoned and the bug has > now been relabeled as "New". > > Currently there is a comment that we should reassess this bug. Should > I go ahead and mark this bug as confirmed to get it into the Triage > pipeline? To me it seems legit, but maybe someone with more context > has a different opinion? > > [1] https://bugs.launchpad.net/nova/+bug/1484847 > > --- > Augustina Ragwitz > Sr Systems Software Engineer, HPE Cloud > Hewlett Packard Enterprise > --- > irc: auggy For the sake of completeness, Hans Lindgren pushed a patch [1] 2 days after your ML post, which makes me believe the bug is still a valid issue. References: [1] https://review.openstack.org/#/c/298023/ Regards, Markus Zoeller (markus_z) __ 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] [nova] bug 1550250: delete_on_termination" flag: how to proceed?
The discussion around Bug 1550250 [1] doesn't show a clear path on how to proceed. In short, it's about if we want to keep the flag "delete_on_termination" for volumes which get migrated. Right now that flag gets reset during the migration process. The patch [2] is stalled by the missing decision. Would be great if we could come to a conclusion. References: [1] https://bugs.launchpad.net/nova/+bug/1550250 [2] https://review.openstack.org/#/c/288433/ Regards, Markus Zoeller (markus_z) __ 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
