This bug lacks the necessary information to effectively reproduce and
fix it, therefore it has been closed. Feel free to reopen the bug by
providing the requested information and set the bug status back to
''New''.
** Changed in: nova
Status: Incomplete => Invalid
--
You received this
As we use the "direct-release" model in Nova we don't use the
"fix comitted" status for merged bug fixes anymore. I'm setting
this manually to "fix-released" to be consistent.
[1] "[openstack-dev] [release][all] bugs will now close automatically
when patches merge"; Doug Hellmann; 2015-12-07;
As we use the "direct-release" model in Nova we don't use the
"fix comitted" status for merged bug fixes anymore. I'm setting
this manually to "fix-released" to be consistent.
[1] "[openstack-dev] [release][all] bugs will now close automatically
when patches merge"; Doug Hellmann; 2015-12-07;
As we use the "direct-release" model in Nova we don't use the
"fix comitted" status for merged bug fixes anymore. I'm setting
this manually to "fix-released" to be consistent.
[1] "[openstack-dev] [release][all] bugs will now close automatically
when patches merge"; Doug Hellmann; 2015-12-07;
As we use the "direct-release" model in Nova we don't use the
"fix comitted" status for merged bug fixes anymore. I'm setting
this manually to "fix-released" to be consistent.
[1] "[openstack-dev] [release][all] bugs will now close automatically
when patches merge"; Doug Hellmann; 2015-12-07;
This bug lacks the necessary information to effectively reproduce and
fix it, therefore it has been closed. Feel free to reopen the bug by
providing the requested information and set the bug status back to
''New''.
** Changed in: nova
Status: Incomplete => Invalid
--
You received this
Public bug reported:
"No config generator hooks should ever be registered with a name that
belongs to another project. In this case, using oslo.middleware.cors
means that *every other project* that loads the middleware gets this
application's defaults when the generator is run on a system with
As we use the "direct-release" model in Nova we don't use the
"fix release" status for merged bug fixes anymore. I'm setting
this manually to "fix-released" to be consistent.
[1] "[openstack-dev] [release][all] bugs will now close automatically
when patches merge"; Doug Hellmann; 2015-12-07;
Addition:
POST /servers//migrations//action
doesn't have a response body
** Tags added: api
** Project changed: nova => openstack-manuals
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
According to the api-ref [1], the used amount of keypairs is not in the
response body. That's why the python-novaclient shows a "-" instead of
a zero. In Horizon (the other consumer of the nova REST API) you will
see that there is no pie-chart in "Project -> Compute -> Overview".
This means this
As already described in comments #3 and #5 this is a feature request
and not a bug. I'm closing this bug report as "Invalid".
** Changed in: nova
Status: In Progress => Invalid
** Changed in: nova
Assignee: Shuquan Huang (shuquan) => (unassigned)
--
You received this bug
This bug report is specifically about the log into Horizon with a
nova service user. That the nova user has the admin rights is
covered in bug 1445199. That the admin role is not properly scoped is
handled in bug 968696. Nova cannot prevent/influence log ins to
Horizon. => Invalid for Nova
**
It looks like this got fixed meanwhile. At [1] is the description:
"Give each device a unique boot index starting from 0. To disable
a device from booting, set the boot index to a negative value or
use the default boot index value, which is None."
Which makes the bug report
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
** Changed in: nova
Status: Incomplete => Won't Fix
** Changed in: nova
Assignee: Padmakanth (padmakanth-chandrapati) => (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
@Cristian:
The "tenant_id" is part of the URI and *not* part of the parameters in
the request body. The value "URI" in the "Style" column explains that.
It's especially good to see when querying server details [1]:
GET /v2.1/{tenant_id}/servers/{server_id}
Parameter Style
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
It looks like the Nova API provides the requested fields. So I remove
it from the list of affected projects. I also remove the "api" tag.
This is now a python-novaclient only bug report. To be specific, it is
a RFE which are usually done via blueprints [1][2] and not via bug reports.
References:
Public bug reported:
Commit [1] ("Introducing a new library to retrieve information from
libosinfo database.") declared a DocImpact in its commit message
but doesn't provide information which documents are affected in
which way. Is it:
* a release note for the deployers/ops?
* an information
** Also affects: cinder
Importance: Undecided
Status: New
** Also affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
It looks like this only affected "oslo.messaging" and not Nova, that's
why I switch the status to "Invalid".
** Changed in: nova
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
Cleanup
===
This bug report has the status "Incomplete" since more than 30 days
and it looks like that there are no open reviews for it. To keep
the bug list sane, I close this bug with "won't fix". This does not
mean that it is not a valid bug report, it's more to acknowledge that
no
bug skimming
--
It looks like the python-openstackclient handles empty values different than
the python-novalient CLI. As the Nova API returns the values as is and the
python-novaclient handles it as expected, I thing the issue (if any) is in the
python-openstackclient.
** Also
@Kumar:
bug skimming
The Juno release has reached EOL [1] which means we don't do fixes
for that anymore. Because of this I close it as "invalid".
If you see the issue in one of the later, still supported releases,
please reopen this issue and provide the version details of your
@Christian Berendt:
Bug skimming
This is a topic which is better discussed on the ML. You will get better
feedback there. This bug report also doesn't describe a fault/error in the
behavior of Nova and is rather a change request/discussion which is not the
focus of the issue
nit: Nova uses the "direct release model" which means solved bugs get
the "fix released" status.
** Changed in: nova
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute
*** This bug is a duplicate of bug 1508230 ***
https://bugs.launchpad.net/bugs/1508230
@Krzysztof Kwiecień:
Bug skimming
This should be a duplicate to bug 1508230
Please double-check that and if you think it's not the same remove the
duplication notice so that we can check that
Bug skimming
This is most likely a configuration issue. This report is a support
request and not a bug. That's why I change the status to "Invalid".
It also lacks the necessary information to do an analysis of the issue
(steps to reproduce, exact version, configuration details,
@BM Shukla:
Bug skimming
This bug report lacks the necessary information to do an analysis of
the issue (steps to reproduce, exact version, configuration details,
...), that's why I change the status to "Invalid".
If you want to reopen this bug, consider using a template [1].
@leye:
Bug skimming
This bug report lacks the necessary information to do an analysis of
the issue (steps to reproduce, exact version, configuration details,
...), that's why I change the status to "Invalid".
If you want to reopen this bug, consider using a template [1].
Bug skimming
The REST API of Nova only accepts IDs. The translation from instance
name to instance ID happens in the "python-novaclient" CLI.
The translation seems to have an issue with soft deleted instances.
** Also affects: python-novaclient
Importance: Undecided
@leehom:
Bug skimming result
===
Juno has reached end of life (EOL) [1] and won't get any updates
anymore. That's why I close this bug as "Invalid".
If you observe the issue(s) in one or more of the supported releases
(kilo, liberty, mitaka=master), then reopen the bug report
@BM Shukla:
Bug skimming result
===
See the line:
Architecture name 'CentOS-7-x86_64' is not valid
You tried to use "CentOS-7-x86_64" as a name for an architecture.
I guess it's clear that it is not. You find valid architecture names
in [1].
I'm changing the status of this
Commit 793f4b7c711236f50dbebd8739f08604bff0af14 which solved this
bug is merged. It didn't contain the "fixes-bug" keyword as it was
an open review which should have been merged before the bug occured.
As we use the "direct-release" model in Nova we don't use the
"fix release" status for merged
As we use the "direct-release" model in Nova we don't use the
"fix release" status for merged bug fixes anymore. I'm setting
this manually to "fix-released" to be consistent.
[1] "[openstack-dev] [release][all] bugs will now close automatically
when patches merge"; Doug Hellmann; 2015-12-07;
As we use the "direct-release" model in Nova we don't use the
"fix release" status for merged bug fixes anymore. I'm setting
this manually to "fix-released" to be consistent.
[1] "[openstack-dev] [release][all] bugs will now close automatically
when patches merge"; Doug Hellmann; 2015-12-07;
This bug report doesn't describe a failure in the behavior of Nova.
It's a personal todo item which doesn't need the overhead of a bug
report. Because of this, I'm closing this report as invalid. This
shouldn't stop you though to do your item and push it as a review.
** Changed in: nova
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1526675
Title:
We changed the release management from a "delayed-release" to a
"direct-release" model [1]. It seems that the fix for this bug merged
in the timeframe where we made the transition to the new model and
therefore wasn't closed with "Fix-Released" at it should be.
=> Manually closing this bug with
We changed the release management from a "delayed-release" to a
"direct-release" model [1]. It seems that the fix for this bug merged
in the timeframe where we made the transition to the new model and
therefore wasn't closed with "Fix-Released" at it should be.
=> Manually closing this bug with
We changed the release management from a "delayed-release" to a
"direct-release" model [1]. It seems that the fix for this bug merged
in the timeframe where we made the transition to the new model and
therefore wasn't closed with "Fix-Released" at it should be.
=> Manually closing this bug with
@Vilobh Meshram:
It seems that this is a feature request. Feature requests for nova are
done with blueprints [1] and with specs [2]. I'll recommend to read [3]
if not yet done. To focus here on bugs which are a failures/errors/faults
I close this one as "Invalid". The effort to implement the
@Tracy Jones: For your information. Please correct the project
assignment if I were wrong.
** Also affects: cinder
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering
Public bug reported:
Description
===
The following unit tests fail **randomly** in the "gate-nova-python34" check
queue:
*
nova.tests.unit.network.test_neutronv2.TestNeutronv2.test_deallocate_for_instance_2_with_requested
*
@Dan Yocum:
IIUC in comment #5, there is no need anymore for this bug as the effort
for this will be driven by the blueprint mentioned in comment #4. => I'm
setting this bug to "invalid", I don't see a status which fits better.
** Changed in: nova
Status: New => Invalid
--
You received
@Michael Duncan:
We need additional information to do a proper bug triage.
Would you please provide the following information:
* What was the result you expected? The error indicates that there is
an issue with your certificates (and I'm guessing that OpenStack does
not setup certificates).
AFAIK the flavor extra specs are free form string values and there is
no defined list of allowed values. That's why it's not possible to
check if the provided input is sane. The code 201 the REST API returns
just says that your request (create/update an extra spec) got fulfilled.
It doesn't say
@yuntongjin:
It seems that this is a feature request. Feature requests for nova are
done with blueprints [1] and with specs [2]. I'll recommend to read [3]
if not yet done. To focus here on bugs which are a failures/errors/faults
I close this one as "Invalid". The effort to implement the
@Rong Han:
The Icehouse release has reached its end of life [1], which means there will be
no upstream fixes for that anymore. That's why I switch the bug status to
"won't fix". If you've seen this behavior in Juno and newer releases, please
open a new bug report.
[1]
The REST API of Nova only accepts UUIDs [1]. The translation from object
name to its UUID (like volume name to its UUID) is usually done via the
novaclient. That's why I added the python-novaclient as affected project
and marked it as invalid for the Nova project.
[1]
@ venkatamahesh:
That's not a bug, it's a best practice in my opinion. When you do the
refactoring of such unit tests you don't need a bug number to verify a patch
set which changes that. A bug report should represent a failure in behavior.
Would be cool if you still work on the refactoring but
IMO the DocImpact key word in the commit message of review [1] which
generated this bug report for the docs team wasn't necessary. That's why
I'm setting this bug status to "invalid".
[1] https://review.openstack.org/201436
** Changed in: nova
Status: In Progress => Invalid
--
You
@palbhan:
> [...] we checked the share storage is true or not before migrating.
So, did you do a resize which results in a cold-migration (=rebuild) of
the instance to another server?
> I think checking the share storage using " shared_storage =
> (dest == self.get_host_ip_addr())" is not the
@tangyi:
> vm occur i/o blocked about every five days.
I wouldn't say that this is an issue within Nova or can be solved in
Nova, that's why I think this bug report is invalid.
Nevertheless, if I understand [1] correctly, you can tweak your servers
to handle that IO blocking.
> can we do that?
For Nova, this is a "Liberty" release only bug which is fixed with
https://review.openstack.org/234166. This got merged in RC3 of
"Liberty".
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
@jingtao liang:
Because the RPC API calls the "remove_volume_connection" method of
the manager with named arguments, the order of the arguments is not
important. The flow is this:
nova/compute/manager.py (on the source host)
def _rollback_live_migration(self, context, instance,
This seems to go the same direction as bug 1472999. I guess the
novaclient has to encode the input as well as the nova api. Whoever
takes this bug could maybe also update the wiki page from 2013:
https://wiki.openstack.org/wiki/Encoding
** Also affects: python-novaclient
Importance: Undecided
This is not a bug. If you need data at boot time, you can use the
"config drive" [1] or pass in a "block device mapping" [2].
[1] http://docs.openstack.org/user-guide/cli_config_drive.html
[2] http://docs.openstack.org/openstack-ops/content/attach_block_storage.html
** Changed in: nova
As Joel wrote in comment #4, the comments in review [1] tend to see this
bug as invalid.
** Changed in: nova
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
@ Hiroyuki Eguchi:
I assume that this is a thing which needs a blueprint [1] and a spec file [2]
to discuss it.
I'll recommend to read [3] if not yet done. To focus here on bugs which are a
failures/errors/faults
I close this one as "Invalid". The effort to implement the requested
feature is
As Shuquan Huang said in comment #2, this has to be fixed in nova =>
Invalid for "openstack-manuals".
** Tags added: config-options documentation
** Changed in: openstack-manuals
Status: In Progress => Invalid
** Changed in: openstack-manuals
Assignee: Shuquan Huang (shuquan) =>
AFAIK this is the way OpenStack does it. I can imagine that this
behavior is useful for audits, for example. Nova provides a way to
archive deleted rows:
nova-manage db archive_deleted_rows --max_rows 1
This has to be applied manually though.
** Changed in: nova
Status: New =>
@javeme:
It seems that this is a feature request. Feature requests for nova are
done with blueprints [1] and with specs [2]. I'll recommend to read [3]
if not yet done. To focus here on bugs which are a failures/errors/faults
I close this one as "Invalid". The effort to implement the requested
@Nick Jones:
It seems that this setup is not a supported model [1]:
No, that's not valid behaviour. You need to upgrade the controller
infrastructure (conductor, API nodes, etc) before any compute nodes.
I'll close this bug as Invalid and remove the assignee because of
this.
[1]
** Tags added: documentation network
** Also affects: python-novaclient
Importance: Undecided
Status: New
--
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/1484001
@hiyonger-ZTE_TECS (huanghuayong):
IIUC, you agreed that this is not an issue which has to be solved by Nova. I'll
change the status of this bug to Invalid.
Thanks Zhenzan Zhou for your input.
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you
The configuration reference[1] has a short entry for that. But you
have to read carefully to see the connection to a cold migration.
[1] http://docs.openstack.org/kilo/config-reference/content/configuring-
resize.html
** No longer affects: nova
--
You received this bug notification because you
** Also affects: cinder
Importance: Undecided
Status: New
--
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/1471810
Title:
Support host type specific block
@huangpengtaohw:
It seems that this is a feature request. Feature requests for nova are
done with blueprints [1] and with specs [2]. I'll recommend to read [3]
if not yet done. To focus here on bugs which are a failures/errors/faults
I close this one as Invalid. The effort to implement the
@gs-opencos-zte:
Sounds like an issue with facter from PuppetLabs which configures
OpenStack. Their issue tracker is at [1] and not at Launchpad, so I
cannot add it as affected project. OpenStack doesn't have control over
facter. I think it makes sense to open an issue at [1] and close this
one
@Divya K Konoor (dikonoor):
This sounds more like a change request than an actual bug. Change
requests are done via blueprints in Launchpad [1] and their design get
reviewed in spec files in Gerrit [2]. The process is described in [3].
The current Liberty cycle has reached feature freeze [4],
@huangpengtaohw:
Thanks for this bug report. Naming variables in a readable and
understandable way is important and improves a lot the maintainability
of the code. The change you suggested is a refactoring and doesn't need
a bug report in my opinion. I'll close this bug report as Invalid
Public bug reported:
This bug is based on Daniel Berrange's comment on [1].
There is a limit of 4 serial ports on x86, [...] guest will have
5 consoles and will fail to boot with a QEMU error.
The number of serial ports a guest will have can be influenced by
* the image properties:
Public bug reported:
When doing a migration/resize to another host without having a shared
storage, the compute nodes need SSH access to each other[1], which is
not documented in the admin guide [2]. Right now one has to search for
blogs which describe how to solve this [3]. I think this should
It does sound more like a configuration problem and less like an issue
within OpenStack, that's why I close this bug. You could try the
resources below to solve your problem. If you still think this is an
issue within OpenStack, feel free to reopen this bug by setting its
status to New.
*
@Henry (zhiqzhao):
As you already noted, this is a feature request. Feature requests for
nova are done with blueprints [1] (you've already done this) and with
specs [2]. I'll recommend to read [3] if not yet done. To focus here
on bugs which are a failures/errors/faults I close this one as
I added oslo.messaging as affected project.
** Tags added: oslo
** Also affects: oslo.messaging
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
** Tags added: api novaclient
** Also affects: python-novaclient
Importance: Undecided
Status: New
--
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/1470219
** Also affects: python-novaclient
Importance: Undecided
Status: New
** Tags added: novaclient
--
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/1471041
Title:
@Moonlight -shadow (1403383953-h):
The error Unexpected vif_type=binding_failed could be caused by a
misconfiguration of Neutron. You could try [1] to resolve this. Also the
nova.conf configuration option vif_plugging_is_fatal=False [2] could
help you, depending on the purpose of your OpenStack
@yjx (yjx1991):
The version 2013.2.b1 you've referenced to has reached
End-Of-Life [1]. I tried to reproduce the issue as you described with
the current master branch [2]:
* launch an instance (in Horizon)
* log in to mysql database
* in the table instances set the field host to NULL
* delete
@javeme (javaloveme):
Thanks for reporting this issue. There is a blueprint which intents
to implement that [1]. To avoid redundant work on the same task I'll
close this issue. Feel free to offer the assignee of the blueprint your
assistance.
[1]
** Also affects: python-novaclient
Importance: Undecided
Status: New
--
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/1463372
Title:
nova secgroup-list-rules
Public bug reported:
Issue
=
The image metadata update view doesn't search for the key names of image
metadata key name (like os_command_line). It only searches for the image
metadata *display* names.
Steps to reproduce
==
* start devstack
* login to horizon as admin
* go
This bug has the status incomplete for more than 30 days. It is unclear if
this is an invalid bug or if it is an opinion. I set it to won't fix.
Feel free to reopen the bug by providing the requested information and set the
bug status back to New.
** Changed in: nova
Status: Incomplete
I added Keystone as possible affected project. I'm not sure if the
responsibility of checking this is in Nova.
** Also affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Public bug reported:
AFAIK the serial console will only work if a websocket URL is returned,
e.g. ws://127.0.0.1:6083/ [1]
The API unit tests use http as scheme name [2], which could lead to
misinterpretation of the capabilities of this feature.
IMO they should use ws in the tests to avoid
Public bug reported:
Issue
=
It's not possible anymore to switch between the tabs in the Instance details
view.
Steps to reproduce
==
* launch an instance
* go to the details view of that instance
* click on tab console
Expected behavior
=
The tab console
Public bug reported:
The sphinx-extension which renders the support_matrix.ini file into HTML [1]
does not recognize URLs in the notes which have to be written as an HTML anchor
element.
I tried to use the sphinx notation with a backquote and the direct use of the
HTML anchor element, but
401 - 500 of 509 matches
Mail list logo
