Duplicate of https://bugs.launchpad.net/nova/+bug/1303360 which has been
merged
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
** Changed in: nova
Status: Opinion = Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1357453
Title:
Resource tracker should create compute node record
** Changed in: nova
Assignee: Sylvain Bauza (sylvain-bauza) = (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1376751
Title:
Policy rule
This change requires a spec as it involves DB migrations
** Changed in: nova
Status: In Progress = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1357491
Public bug reported:
Base class for tests is not providing helpers for managing mock objects
as it does for mox ones (self.mox)
At the moment, the only way to create a mock object and use it is to
decorate a test method which is not handy and doesn't allow new
contributors to cleary identify
Fix has to be provided on Blazar side.
** Changed in: keystone
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1324861
Title:
Pythonclient middleware
The mirror URL is incorrect, it should be
http://pypi.openstack.org/openstack/;
** Changed in: neutron
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1213987
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Status: New = Confirmed
** Changed in: nova
Importance: Undecided = Low
** Tags added: network
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
duplicate of https://bugs.launchpad.net/nova/+bug/1405131
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1417595
Title:
Public bug reported:
In
https://github.com/openstack/nova/commit/9db1642e867deb2bea54a3c1a76e52b0480cc30c
we missed to provide a list instead of None, so six.iteritems() can
provide an Exception.
** Affects: nova
Importance: High
Assignee: Sylvain Bauza (sylvain-bauza)
Status
Assignee: Sylvain Bauza (sylvain-bauza)
Status: New
** Tags: cells
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1438601
Title:
Cells Response serialization
Duplicate of https://bugs.launchpad.net/nova/+bug/1438514
** Changed in: nova
Status: In Progress = Invalid
** Changed in: nova
Milestone: kilo-rc1 = None
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
I would rather mark it as invalid now that the design changed.
I really would like to keep fix committed to match with Gerrit changes
** Changed in: nova
Status: Fix Committed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Public bug reported:
The API RBAC is done using a policy.json file which allows fine-grained control
over each API endpoint by setting specific rules.
Consequently, some defaulted admin-only endpoints can be opened by modifying
their corresponding policy rules to be for anyone.
Unfortunately,
check should be removed.
** Affects: nova
Importance: Medium
Assignee: Sylvain Bauza (sylvain-bauza)
Status: New
** Tags: conductor
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https
As discussed on IRC, the issue you mention comes from the fact that
default_schedule_zone conf flag is set to None by default.
As it's defaulted to None, then the instance has no AZ unless the user
specifically asks for one, so the AZFilter doesn't care about it.
If you want to have a default AZ
Not sure I understand but this is the pattern for any unique key we add
: since we don't remove any row from a table but just updates the
deleted col, we need to make sure that 2 or more same rows are accepted.
** Changed in: nova
Status: New = Invalid
--
You received this bug
Not sure something needs to be fixed on Nova. Please change the status
back to New if you think yes and explain why.
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Not sure it's Nova related, since the connection is managed by MySQLdb here.
That's all due to the configuration done on SQLA like said in
http://docs.sqlalchemy.org/en/rel_1_0/core/engines.html
Please check your connection option for the nova.conf file as this is
how it's called.
** Changed
Not sure it's a bug (even wishlist), you should create a blueprint
instead.
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
It's not a bug as it is explained : there is no current way to rescue a
volume-backend instance, even with the latest code.
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
I don't think it's a problem, that just means the method took more time
than the periodic one. Can you see it repeatively ?
** Changed in: nova
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1453675
Title:
Live migration fails
Status in OpenStack Compute (Nova):
Nova is only user of oslo.log, there is nothing in Nova that can be
changed for fixing that.
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
nova.scheduler.ibm.ego.ego_manager is not an upstream module
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1456871
Not sure it's a Nova problem but rather a MySQLdb problem as per the
log. Could you please try to see the config differences between the 13
good nodes and this one ?
** Changed in: nova
Status: New = Opinion
** Changed in: nova
Status: Opinion = Incomplete
--
You received this
Sorry but this is not a bug, that just means the spec is not fully
complete. In order to do that, please repropose the missing bits in a
separate spec (and blueprint) for Liberty
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of
Public bug reported:
http://logs.openstack.org/28/145528/22/check/gate-nova-
python27/a818283/console.html
2015-06-23 14:13:01.268 | ==
2015-06-23 14:13:01.268 | Failed 1 tests - output below:
2015-06-23 14:13:01.268 | ==
2015-06-23
The TrustedFilter filter actually doesn't check by itself but rather
calls the Attestation API to know if the destination host is correct or
not. That way, it's just when the instance is scheduled that it goes to
the scheduler, then finds an acceptable destination (so calls the
Attestation API for
Sorry, hitted tab too fast.
So, was saying that in general, we recommend to run 'nova reset-state
vm' to set the state to the desired option and then delete it again.
Could you please try it ?
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you
Public bug reported:
For some reason not yet identified, local master branches fail with this
check
==
FAIL:
nova.tests.unit.objects.test_objects.TestObjEqualPrims.test_object_not_equal
Just wondering if the solution has to be part of Nova. Are you thinking
of any check in Nova verifying that the instance is running before
calling libvirt ?
** Changed in: nova
Status: New = Opinion
** Tags added: libvirt
--
You received this bug notification because you are a member of
But tox.ini has both requirements.txt and test-requirements.txt as
dependencies, so you need to pull all the packages.
** Changed in: nova
Status: New = Invalid
** Changed in: oslo.config
Status: New = Invalid
--
You received this bug notification because you are a member of
@Kashayp, fair point, we should then prevent Nova to call libvirt if the
instance is not in a correct state.
** Changed in: nova
Status: Opinion = Triaged
** Changed in: nova
Importance: Undecided = Low
** Tags added: low-hanging-fruit
--
You received this bug notification because
Bill, the logging capabilities are managed by the oslo.log library that
Nova is pulling. All the options you showed in the bug desc are related
to that package, not coming from internal Nova configuration flags (even
if defined in nova.conf)
** Changed in: nova
Status: New = Invalid
--
Public bug reported:
2015-07-17 12:11:00.987 | ==
2015-07-17 12:11:00.987 | Failed 2 tests - output below:
2015-07-17 12:11:00.987 | ==
2015-07-17 12:11:00.987 |
2015-07-17 12:11:00.988 |
Public bug reported:
There is still one place where the Scheduler does direct DB access
instead of using the oslo.versionedobjects layer
https://github.com/openstack/nova/blob/af2d6c9576b1ac5f3b3768870bb15d9b5cf1610b/nova/scheduler/driver.py#L54
Instead of calling db.service_get_all_by_topic(),
Public bug reported:
It seems that all gate-tempest-dsvm-cells runs against the liberty
branch fail because of
2015-11-16 04:50:15.334 | ==
2015-11-16 04:50:15.334 | Failed 1 tests - output below:
2015-11-16 04:50:15.334 | ==
2015-11-16
Related change https://review.openstack.org/#/c/189560/
** Changed in: nova
Importance: Undecided = Wishlist
** Changed in: nova
Status: Fix Released = In Progress
** Changed in: nova
Milestone: liberty-1 = None
--
You received this bug notification because you are a member of
ks": []}
2015-09-04 11:41:29.480 |
Occurring since 10.30am GMT :
http://logstash.openstack.org/#eyJzZWFyY2giOiJidWlsZF9uYW1lOlwiZ2F0ZS10ZW1wZXN0LWRzdm0tY2VsbHNcIiBBTkQgbWVzc2FnZTpcIk5vIG5ldHdvcmtzIGZvdW5kXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MT
Okay, so I feel the bug should be marked as Invalid. Why ? Let me
explain :
While any instance can be shown with an AZ, it doesn't mean that the
instance.az field is set with that value but rather showing the value of
CONF.default_availability_zone if that field is left blank.
How to the
I feel that request for feature would need a huge effort for changing
the current situation and would be better provided as a blueprint, see
that wikipage for more explanation :
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_do_I_get_my_code_merged.3F
** Changed in: nova
** Changed in: nova
Importance: Undecided => High
** Changed in: nova
Status: New => Confirmed
** Also affects: python-novaclient
Importance: Undecided
Status: New
** Changed in: nova
Status: Confirmed => Invalid
** Changed in: python-novaclient
Status: New =>
So, my take on that is that this is not technically a bug, rather a
current limitation (hence Opinion/Wishlist)
That needs at least a blueprint to be created and possibly some
discussion around the implementation design, see
I'm really not sure what needs to be done in Nova to fix that problem.
Feel free to reopen the bug to New if you come up with a described
description of any Nova-related issue coming in.
** Changed in: nova
Status: New => Invalid
** Changed in: nova
Status: Invalid => Opinion
--
Public bug reported:
gate-tempest-dsvm-large-ops error rate is spiking since the last 24
hours (http://goo.gl/G9Zazy) with the following stacktrace :
2015-09-28 15:02:50.954 | Traceback (most recent call last):
2015-09-28 15:02:50.954 | File "tempest/test.py", line 127, in wrapper
2015-09-28
I'm tagging the bug as Invalid, as it would require to write a spec file for
explaining the change you want to provide.
That's IMHO not a bug, rather a feature request, see
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_do_I_get_my_code_merged.3F
** Changed in: nova
FWIW, I'm changing the tags to match the implementation.
So, that's an expected behaviour, see
https://github.com/openstack/nova/blob/875594ad26da46c773892a901511547b86a9568c/nova/scheduler/host_manager.py#L515-L518
When providing a request using the --az hint, it goes into the Compute API
So, it's pretty hard to explain in one small comment how the model is
behaving, but please consider that we have 'sort of' two-phase commits
when booting an instance.
When a request comes in, you're right, the instances are elected
iteratively by decrementing the resource usage of the elected
t iterable
http://logs.openstack.org/05/226805/2/check/gate-ironic-inspector-
dsvm/5cd5071/logs/screen-n-cond.txt.gz?level=WARNING
** Affects: nova
Importance: Critical
Assignee: Sylvain Bauza (sylvain-bauza)
Status: In Progress
** Tags: liberty-rc-potential low-hanging-fruit
We assume by design that the AZ information is only a specific key/value
pair of the metadata dict (where the key is 'availability_zone').
Trying to access the AZ info if the metadata field is unset goes against
that design decision because it makes no sense to persist it differently
at the
Public bug reported:
Python unittests and functional tests are trampled by our Translation
system, and in particular the gettext module.
For example :
2016-05-30 05:45:25.217 |
nova.tests.unit.virt.libvirt.test_driver.LibvirtConnTestCase.test_create_images_and_backing_images_exist
2016-05-30
Okay, I think I found the root case.
https://review.openstack.org/#/c/294751/ was introduced on 2016-04-12
but only tagged for 1.7.0 on http://git.openstack.org/cgit/openstack
/python-cinderclient/commit/?id=0cdcfb5988f57da80551b1a11fcd3d96d0baf1d8
(which was reverted quickly) and then only
I actually opened a blueprint for that feature request. Since it's a
scheduler-related effort, it is part of our Nova Priorities so it's not
impacted by the non-priority Feature Freeze for Mitaka.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification
that the signature between ComputeTaskAPI methods and (RPC) CellsAPI
needs to be the same for live-migrate and evacuate.
Unshelve was also modified, but Cells V1 has a different behaviour (not
calling ComputeTaskAPI) so we're good.
** Affects: nova
Importance: High
Assignee: Sylvain Bauza
** Tags removed: race-condition
** Changed in: ubuntu
Status: New => Invalid
** Changed in: nova
Status: New => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Yeah the backport was merged too.
https://review.openstack.org/#/q/Icc71e36f4ecb015dff9e806caacd31262f7e17f7,n,z
** Changed in: nova
Status: Incomplete => Fix Released
** Changed in: nova
Importance: Undecided => Low
** Changed in: nova
Importance: Low => High
** Changed in: nova
That sounds a glance.conf issue with it unable to verify that the token
you're passing by Nova is valid.
Marking it as Opinion because I don't really see what Nova should fix.
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of
The stack shows an issue with the ironicclient. That can possibly be a
configuration problem, but either way it's not related to Nova.
** Also affects: python-ironicclient
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug
As explained in IRC, that looks like a configuration problem :
-
https://github.com/openstack/python-ironicclient/blob/master/ironicclient/client.py#L78
takes the endpoint value from ironic_url in parameters
- whose value is taken from a config opt
Per the n-api logs, it seems the problem is related to glanceclient
rather than Nova.
** Also affects: python-glanceclient
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
That's a design discussion IMHO, not really a bug. In case you want to
have a better performance because of the DB queries, please use the
CachingScheduler instead of the FilterScheduler.
The CachingScheduler is good for not calling by every request the host
states.
** Changed in: nova
I think it's rather a discussion we should do in a spec (and a
blueprint).
Please help us reducing the number of open bugs :-)
** Changed in: nova
Importance: Undecided => Wishlist
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a
*** This bug is a duplicate of bug 1518200 ***
https://bugs.launchpad.net/bugs/1518200
** This bug has been marked a duplicate of bug 1518200
instance is not destroyed on source host after a successful evacuate
--
You received this bug notification because you are a member of Yahoo!
Not sure I get your problem. The error message is self-explicit :
"Server disk was unable to be resized because: Resize to zero disk
flavor is not allowed."
It seems the flavor you want for resizing your instance has a root_gb
variable equals to 0. In that case, Nova doesn't accept to resize from
I don't feel it's a bug. You should just provide a change, without
really needing to add this one.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute
** No longer affects: nova/kilo
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1533876
Title:
plug_vhostuser may fail due to device not found error when setting mtu
Not sure I understand your problem. I don't want Nova to have a
different behaviour between different drivers. When resizing, it will go
to the scheduler anyway so it could have a different destination.
If you want to only have the same destination for resizing, that looks
like a new feature that
Not sure it's a bug ? Is it rather something that we don't support yet ?
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
You don't need to open a bug report for refactoring actions. Just
provide a change and we'll look thru this.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
You don't need to open a bug report for this. Just provide the change
and we'll look thru this.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
That's a very clear design decision that was made in the past between
image-based instances and volume-based instances.
Snapshotting an image-based instance will only backup your root partition and
won't take in account all the attached secondary disks to it (for many reasons,
including
Sorry, this is not a bug, but rather a new feature you're going to add
for when an admin provides a destination host to the live-migrate
command.
To be clear, the live-migrate command doesn't require a destination to
be provided, and then calls the scheduler (which will do what you ask).
That's
Well, the resize operation implies to reschedule the instance to a new
host (given the flavor is different) than can possibly be the same host
if the config option allow_resize_to_same_host is set to True (defaulted
to False).
So, it's perfectly normal to have the hypervisor_hostname changed if
Public bug reported:
Some regression seemed to have been introduced yesterday with all
Tempest negative tests for Keystone unauthenticated users.
Eg.
2016-05-04 08:12:02.993 |
As John mentioned in the earlier comment, that effort has been properly
tracked by a spec http://specs.openstack.org/openstack/nova-
specs/specs/newton/approved/check-destination-on-migrations-newton.html
The last bits will be merged soon in Newton, and we keep track of those
by the blueprint,
Jay, given we're working actively towards reducing the number of open
bugs, I'd prefer to close that one as Invalid/Wishlist and leave you
upload the change directly without adding this bug note.
You can put the change in https://etherpad.openstack.org/p/newton-nova-
priorities-tracking for
That bug report is still accurate, but given the fact that we're working
towards having new resource providers for the scheduler and discussing
actively on the implementation details, I'd by far prefer to close that
bug and leave a spec better describing the problem.
** Changed in: nova
(meh, tab+space posted my comment)
I was saying :
Maybe we could change the API behaviour to return a 401 when someone is asking
to reset-state when the instance is not in ERROR state?
** Changed in: nova
Status: New => Opinion
** Changed in: nova
Importance: Undecided => Low
--
MessagingTimeout is most of the time due to a configuration error where
the request from the API is not able to go to the compute node for
creating the instance, hence the error (because the message queue is
maybe not there, or because the creds are not good, etc.)
Please make sure your
Public bug reported:
When creating the allocation for the instance, we lookup the flavor to
know the disk sizes for root, ephemeral and gb and we basically sum
them.
https://github.com/openstack/nova/blob/7d04c78c1e2c26125eff5b1a8543b1ac5d027107/nova/scheduler/client/report.py#L129-L131
We already discussed about that, and a change was also provided
https://review.openstack.org/#/c/420079/ but if you see the status of
that change, it was abandoned.
If you look at the reason why it was abandoned, it is because we made a
consensus on leaving simple_cells_setup() as much simple and
Nova has a process specifying that RFEs need to be documented using
Launchpad's blueprints. We only use Launchpad bugs for getting the list
of *bugs* that are existing (or existed) and we don't generally use the
Wishlist status for getting the list of features we want to work on
(even if we still
Not sure I get your problem. Microversion 2.14 specifically removed
onSharedStorage flag, but previous versions were having it mandatory on
the API : https://github.com/openstack/nova/commit/c01d16e8
Novaclient was defaulting the onSharedStorage to False previously (see
Marking the bug as invalid as it was explained in c#12 and also as the
doc describes the problem which is a configuration issue
https://docs.openstack.org/developer/nova/aggregates.html#availability-
zones-azs
** Changed in: nova
Status: Confirmed => Invalid
--
You received this bug
Doesn't look like the master version has this problem.
Which version are you using ?
Can't even find the problem in stable/mitaka :
https://github.com/openstack/nova/blob/stable/mitaka/nova/servicegroup/drivers/mc.py
If the problem is not present in a supported release (Mitaka and younger
Something is messed up with your deployment since you don't have all the
needed python packages :
2017-02-15 17:15:00.658 20804 ERROR stevedore.extension
[req-627d9817-74d4-4669-b817-f51625ca4ff1 b84bf912c35a40c6a780f71b1f9a21c1
097640358bc14bd594b9d91e933b6e4c - - -] Could not load 'file':
Well, the guest shouldn't know which hypervisor type it's running IMHO.
That looks like a security concern at least.
That said, it could be possible for operators explicitely wanting to
pass that information to their guest OS that they use cloud-init for
sure, but that doesn't look like something
All the discussion can be found in
https://bugs.launchpad.net/neutron/+bug/1302080
Basically, it was possible to reach from a guest perspective the
hypervisor in case the bridge was also IPv6. The solution was rather to
stop using IPv6 for that bridge automatically.
That doesn't mean that you
Public bug reported:
We have a long list of Nova unit tests that fail for the py35 job with
this pattern :
ft2.9:
nova.tests.unit.api.openstack.compute.test_create_backup.CreateBackupTestsV21.test_create_backup_raises_conflict_on_invalid_state_StringException:
Empty attachments:
Not sure how you ended up with that, but I'd recommend you to
./unstack.sh, ./clean.sh, do a fresh devstack git pull to get the latest
master, wipe the /opt/stack repositories, ./stack.sh again and see
whether you have a 2nd DB being created as "nova_api".
The stack.sh log you mention doesn't
I'm not really sure we should gracefully handle configuration issues
where operators did a typo with the PCI whitelist. I mean, most of our
conf opts are needed to be right and not wrong, because if so, Nova
could be trampled, right? So, here, you propose to only strip() the
strings for your
That's definitly not a bug, rather a nit about the option.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1621379
I guess you should provide the glance-api logs.
** No longer affects: python-openstackclient
** Also affects: glance
Importance: Undecided
Status: New
** Changed in: glance
Status: New => Incomplete
--
You received this bug notification because you are a member of Yahoo!
That doesn't sound a Nova problem, rather an OSC issue.
** Also affects: python-openstackclient
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
So, after a bit of investigation, I found that's actually not a
regression and we had other bug reports about that. The one I could
refer is https://bugs.launchpad.net/nova/+bug/1526715 which is
technically not a duplicate but where the proposal is very close to the
one you wrote :
*** This bug is a duplicate of bug 1621257 ***
https://bugs.launchpad.net/bugs/1621257
** This bug has been marked a duplicate of bug 1621257
VNC console keeps reporting "setkeycodes 00" exception
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
Sorry, but technically I don't see a bug here, rather some behaviour
that should be modified, right?
I mean, you're providing support for detaching an interface in the
ironic driver, that's not a bug then.
If so, please follow the existing process where you should fill in a blueprint
and ask
You don't need to write a bug report for that. Rather, you should just
provide a change and discuss with the API subteam about your change,
that's it.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering
Like I said on the review, you should rather modify the translation like
it's described in https://wiki.openstack.org/wiki/I18nTeam
No need to submit a bug report for this, register yourself on the Zanata
tool and just go straight using it.
** Changed in: nova
Status: In Progress =>
1 - 100 of 285 matches
Mail list logo
