[
https://issues.apache.org/jira/browse/JCLOUDS-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064989#comment-16064989
]
Christopher Dancy commented on JCLOUDS-1166:
Any updates here and/or is anyone actively
Thanks for merging @nacx! More of a pain in my butt than anything else ;)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1072#issuecomment-283988174
Add netbeans generated IDE folder to .gitignore
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds/pull/1072
-- Commit Summary --
* Update .gitignore
-- File Changes --
M .gitignore (3)
-- Patch Links --
[
https://issues.apache.org/jira/browse/JCLOUDS-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy closed JCLOUDS-782.
-
Resolution: Fixed
Assignee: Christopher Dancy
Code was previously removed from
Christopher Dancy created JCLOUDS-1238:
--
Summary: Add support for unix sockets and windows named pipes
Key: JCLOUDS-1238
URL: https://issues.apache.org/jira/browse/JCLOUDS-1238
Project: jclouds
[
https://issues.apache.org/jira/browse/JCLOUDS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy resolved JCLOUDS-833.
---
Resolution: Won't Fix
provider is no longer supported.
> Implement Service Key
[
https://issues.apache.org/jira/browse/JCLOUDS-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy resolved JCLOUDS-882.
---
Resolution: Won't Fix
Provider is no longer supported
> Implement Accounts
…m/cdancy/etcd-rest.
Project is/was not a good fit for inclusion within jclouds. As such it's now
being hosted elsewhere.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds-labs/pull/266
-- Commit Summary --
* Remove project etcd. Project is
Closed #239.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/239#event-652779344
[
https://issues.apache.org/jira/browse/JCLOUDS-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15156871#comment-15156871
]
Christopher Dancy commented on JCLOUDS-1086:
I completely get it and agree. I don't think we
[
https://issues.apache.org/jira/browse/JCLOUDS-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15156279#comment-15156279
]
Christopher Dancy commented on JCLOUDS-1086:
I see your point and that's fair. We were more
[
https://issues.apache.org/jira/browse/JCLOUDS-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-1086:
---
Description:
Much like the on-going work we're doing with the jclouds-labs/etcd
> @@ -94,6 +94,40 @@ public void testDeleteNonExistentKey() {
>assertNull(deletedKey);
> }
>
> + @Test
> + public void testWaitKey() {
> + String localKey = randomString();
> + String localValue = randomString();
> + Key createdKey = api().createKey(localKey,
Christopher Dancy created JCLOUDS-1086:
--
Summary: Thoughts on an Artifactory provider
Key: JCLOUDS-1086
URL: https://issues.apache.org/jira/browse/JCLOUDS-1086
Project: jclouds
Issue
Christopher Dancy created JCLOUDS-1085:
--
Summary: KeysApi: support for waiting on key state change
Key: JCLOUDS-1085
URL: https://issues.apache.org/jira/browse/JCLOUDS-1085
Project: jclouds
[
https://issues.apache.org/jira/browse/JCLOUDS-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy resolved JCLOUDS-1076.
Resolution: Fixed
Fix Version/s: 2.0.0
Ground work has been laid
KeysApi gained the ability to wait on changes in key state.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds-labs/pull/239
-- Commit Summary --
* ADDED: support for waiting on key changes
-- File Changes --
M
Very awesome. Thanks @nacx. Now for round 2...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-185732689
@nacx done!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-185441164
@nacx squash-and-rebase and we can call it done then?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-185431888
@nacx latest comments should all be addressed.
On a side/separate note: any suggestions on how to force a specific live
test-class to run AFTER all other live tests are completed? In this case the
MembersApiLiveTest needs to run last or risk fudging up the other tests while
they are attempting
@nacx for this initial PR lets keep things simple and leave those other methods
out. I want to get a good foundation built and going to make the subsequent
PR's easier on not only myself but others reviewing.
---
Reply to this email directly or view it on GitHub:
> + */
> +@Test(groups = "unit", testName = "KeysApiMockTest")
> +public class KeysApiMockTest extends BaseEtcdMockTest {
> +
> + public void testCreateKey() throws Exception {
> + MockWebServer server = mockEtcdJavaWebServer();
> +
> + server.enqueue(new
>
> + String localValue = UUID.randomUUID().toString().replaceAll("-", "");
> + Key createdKey = api().createKey(localKey, localValue, 1);
> + assertNotNull(createdKey);
> + assertNotNull(createdKey.node().expiration());
> +
> + try {
> + Thread.sleep(3000);
> +
> + * limitations under the License.
> + */
> +package org.jclouds.etcd.features;
> +
> +import static org.testng.Assert.assertNotNull;
> +import static org.testng.Assert.assertNull;
> +import static org.testng.Assert.assertTrue;
> +
> +import java.util.UUID;
> +
> +import
@nacx I've addressed the issues you noted above. I removed some of the
functionality, specifically pertaining to the various path params, as they are
relevant only to code that not yet been added but will come in later commits.
Thought this was the best route instead of trying to explain away
Thanks @nacx. Going over these now. Yea I wanted to flesh out any issues here
before adding tests so as not to make the initial review seem monstrous.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-184226288
[
https://issues.apache.org/jira/browse/JCLOUDS-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146168#comment-15146168
]
Christopher Dancy commented on JCLOUDS-1076:
I will take on the work here.
> Initial w
Christopher Dancy created JCLOUDS-1076:
--
Summary: Initial work on etcd Keys API
Key: JCLOUDS-1076
URL: https://issues.apache.org/jira/browse/JCLOUDS-1076
Project: jclouds
Issue Type
Initial implementation surrounding the etcd keys API. This initial commit is
purposely leaving out tests so as to give reviewers less to chew on. Not too
much special is going on here more just laying the groudwork the API itself and
future commits to come.
@nacx you were working with me here
@nacx can we merge this? I'm going to backtrack on statements I made above
about requiring builders. If it's not necessary at this point I'd rather leave
it out. I was not having great success in implementing it and would like to
continue moving forward and circle back at some later date to
+
+@AutoValue
+public abstract class CreateMember {
+
+ @Nullable
+ public abstract String name();
+
+ public abstract ListString peerURLs();
+
+ public abstract ListString clientURLs();
+
+ CreateMember() {
+ }
+
+ @SerializedNames({ name, peerURLs, clientURLs })
+
+
+@AutoValue
+public abstract class CreateMember {
+
+ @Nullable
+ public abstract String name();
+
+ public abstract ListString peerURLs();
+
+ public abstract ListString clientURLs();
+
+ CreateMember() {
+ }
+
+ @SerializedNames({ name, peerURLs, clientURLs })
+
+import com.google.auto.value.AutoValue;
+import com.google.common.collect.ImmutableList;
+
+@AutoValue
+public abstract class Member {
+
+ public abstract String id();
+
+ @Nullable
+ public abstract String name();
+
+ public abstract ListString peerURLs();
+
+ public
@nacx should be good to go. Thanks for the reviews and helpful comments getting
the members API fleshed out.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196#issuecomment-133246567
@nacx all comments should be addressed but it looks like the jdbc provider is
having issues.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196#issuecomment-132312032
+
+ switch (response.getStatusCode()) {
+case 404:
+ if (command.getCurrentRequest().getMethod().equals(DELETE))
{
+ if
(command.getCurrentRequest().getEndpoint().getPath().startsWith(
+/ +
+
+ public void handleError(HttpCommand command, HttpResponse response) {
+
+ String message = parseMessage(response);
+ Exception exception = null;
+ try {
+
+ message = message != null ? message
+ : String.format(%s - %s,
+ * Handle errors and propagate exception
+ */
+public class EtcdErrorHandler implements HttpErrorHandler {
+ @Resource
+ protected Logger logger = Logger.NULL;
+
+ public void handleError(HttpCommand command, HttpResponse response) {
+
+ String message =
+* peerURLs, from the CreateMember class present.
+*/
+ @Named(members:add)
+ @Fallback(NullOnAddExistingMemberAnd409.class)
+ @POST
+ Member add(@BinderParam(BindToJsonPayload.class) CreateMember
memberToCreate);
+
+ /**
+* @param memberID
+*
+*/
+ @Named(members:list)
+ @SelectJson(members)
+ @GET
+ ListMember list();
+
+ /**
+* @param member
+* non-existing member to add to cluster
+* @return newly created member or null if member previously existed.
Because
+* this call
+import org.testng.annotations.Test;
+
+import com.google.common.collect.ImmutableList;
+
+@Test(groups = live, testName = MembersApiLiveTest)
+public class MembersApiLiveTest extends BaseEtcdApiLiveTest {
+
+ private String selfID;
+ private Member nonSelfMember;
+ private Member
Members API has been added with mock and integration tests of which all pass
successfully. I refactored/formatted some code so a few more files than I would
have liked were touched and made this PR just a little bit bigger than I would
have liked.
Please pick it apart and let me know how
+* @return list of members within cluster
+*/
+ @Named(members:list)
+ @SelectJson(members)
+ @GET
+ ListMember list();
+
+ /**
+* @param member
+* non-existing member to add to cluster
+* @return newly created member or null if member previously
@nacx done!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/195#issuecomment-127961800
Fixed last minute typo
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/195#issuecomment-127972940
[
https://issues.apache.org/jira/browse/JCLOUDS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-971:
--
Summary: On adding an etcd (of coreos fame) provider (was: On adding an
etcd
[
https://issues.apache.org/jira/browse/JCLOUDS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy resolved JCLOUDS-971.
---
Resolution: Done
Fix Version/s: 2.0.0
On adding an etcd (of coreos fame
Christopher Dancy created JCLOUDS-985:
-
Summary: Add members API to etcd provider
Key: JCLOUDS-985
URL: https://issues.apache.org/jira/browse/JCLOUDS-985
Project: jclouds
Issue Type: New
[
https://issues.apache.org/jira/browse/JCLOUDS-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658399#comment-14658399
]
Christopher Dancy commented on JCLOUDS-985:
---
I'll take on the work for creating
+ }
+
+ protected EtcdApiMetadata(Builder builder) {
+ super(builder);
+ }
+
+ public static Properties defaultProperties() {
+ Properties properties = BaseHttpApiMetadata.defaultProperties();
+ return properties;
+ }
+
+ public static class Builder extends
+ }
+
+ public static Properties defaultProperties() {
+ Properties properties = BaseHttpApiMetadata.defaultProperties();
+ return properties;
+ }
+
+ public static class Builder extends BaseHttpApiMetadata.BuilderEtcdApi,
Builder {
+
+ protected Builder() {
+
+ }
+
+ public static Properties defaultProperties() {
+ Properties properties = BaseHttpApiMetadata.defaultProperties();
+ return properties;
+ }
+
+ public static class Builder extends BaseHttpApiMetadata.BuilderEtcdApi,
Builder {
+
+ protected Builder() {
+
+ }
+
+ public static Properties defaultProperties() {
+ Properties properties = BaseHttpApiMetadata.defaultProperties();
+ return properties;
+ }
+
+ public static class Builder extends BaseHttpApiMetadata.BuilderEtcdApi,
Builder {
+
+ protected Builder() {
+
+ }
+
+ public static Properties defaultProperties() {
+ Properties properties = BaseHttpApiMetadata.defaultProperties();
+ return properties;
+ }
+
+ public static class Builder extends BaseHttpApiMetadata.BuilderEtcdApi,
Builder {
+
+ protected Builder() {
+
@nacx identityName and credentialName are now set to Optional ... with
defaultIdentity and defaultCredential set to 'N/A'. Will this suffice?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/195#issuecomment-127806414
@nacx on your comments:
1.) All comments should be addressed. And you're right about the DELETE method,
no request I could find uses a body when issuing a delete. All tests proved
successful so it looks like we are good on that end.
2.) Comments have been addressed.
3.) I've added one more
Failures due to jdbc provider not etcd.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/195#issuecomment-125918791
@nacx I've removed the ErrorHandler as it's not used with this PR and will make
things less confusing and easier to digest. I've addressed the style issues
(forgot to use the jclouds eclipse formatter) and added live tests. Live tests
are not doing anything special as they are just GET requests
Hmmm ... not exactly sure why the whitespace changes are not getting propagated
to github when I commit
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/194#issuecomment-125622198
Failure not related to my changes. Code formatting issues are now solved.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/194#issuecomment-125702730
Closed #194.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/194#event-367539973
Aaa ... issued a force push and I believe it closed this PR. @nacx created
another PR which references this but is more direct and to the point:
https://github.com/jclouds/jclouds-labs/pull/195
---
Reply to this email directly or view it on GitHub:
continuing from https://github.com/jclouds/jclouds-labs/pull/194#event-367539973
statistics and version API have both been fleshed out. Both are very small
which is why they are being included in this PR. Mock and integration tests
have been written and pass against latest etcd version: 2.1.1.
ADDED: version and statistics API as well as mock tests for each. Both APIS are
very simple as they are all GET requests and do not require any parameters. 5
methods total between the 2. This should be a good starting point for us to
break apart the API into smaller chunks for others/reviewers
Not sure how you want to go about breaking this into chunks but the API as a
whole can be broken down into these features (ordered from smallest to
biggest): VersionApi, StatisticsApi, MembersApi, and KeysApi. This PR covers
the first 2 (Version and Statistics) as both are very small and not
Christopher Dancy created JCLOUDS-971:
-
Summary: On adding an etcd (or coreos fame) provider
Key: JCLOUDS-971
URL: https://issues.apache.org/jira/browse/JCLOUDS-971
Project: jclouds
…ntially superceded by kubernetes. With the developer no longer making updates,
and the newer v3 api on indefinite hold, I've no motivation to continue
supporting the API, in it's half-completed state, if the developers themselves
are no longer supporting it.
You can view, comment on, or merge
@nacx we can remove this PR. Project is more/less dead and I've just submitted
a PR to remove it from jclouds-labs.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/165#issuecomment-124882951
[
https://issues.apache.org/jira/browse/JCLOUDS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-971:
--
Description:
We've already got a full (all API/features, mock and integration tests
+ public abstract RoleInfo role();
+
+ CreateAccount() {
+ }
+
+ @SerializedNames({ username, password, role})
+ public static CreateAccount create(String username, String password,
RoleInfo role) {
+ checkArgument(username.length() 0, username must not be empty
+ public abstract String password();
+
+ public abstract RoleInfo role();
+
+ CreateAccount() {
+ }
+
+ @SerializedNames({ username, password, role})
+ public static CreateAccount create(String username, String password,
RoleInfo role) {
+
@nacx comments have been addressed and things look good on my end. Now that
JCLOUDS-886 has been merged we are good to go here. This is the last piece of
work I wanted to get in before tackling the compute API.
---
Reply to this email directly or view it on GitHub:
@nacx very awesome and thanks!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/166#issuecomment-95581166
@nacx fixed minor edit, squashed and rebased, and latest cloudbees build looks
good. I think we're a go.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/166#issuecomment-94492625
}
- }
- assertTrue(serviceKeyFound, Expected but could not find ServiceKey
amongst + possibleServiceKeys.size() + found);
Maybe instead just use the overloaded version and supply the default null
value? I think that would make things more readable IMO and is what I
+ RoleInfo role = api().getRole(roleName);
+ assertNotNull(role, Role was not set);
+ assertTrue(role.name().equals(roleName), Found Role name does not
match expected name: found= + role.name() + , expected= + roleName);
+ }
+
+ @Test (dependsOnMethods = testGetRole)
@nacx all comments should be addressed.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/166#issuecomment-93610419
@nacx failure here is due to docker CME not this PR. I'm not entirely sure what
to do about it as all code on my end is up-to-date. @andreaturli any thoughts?
The line in question in labs-docker seems to be pretty straightforward:
ContainerApi api = api(DockerApi.class,
@nacx @andreaturli looks to be a flaky test after all as the most recent build
was successful:
https://jclouds.ci.cloudbees.com/job/jclouds-labs-pull-requests/681/
Not sure if it's worth the extra investigation or not...
---
Reply to this email directly or view it on GitHub:
Christopher Dancy created JCLOUDS-886:
-
Summary: Implement Roles API for jclouds-labs-shipyard
Key: JCLOUDS-886
URL: https://issues.apache.org/jira/browse/JCLOUDS-886
Project: jclouds
[
https://issues.apache.org/jira/browse/JCLOUDS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14491077#comment-14491077
]
Christopher Dancy commented on JCLOUDS-886:
---
I'll take on the work
[
https://issues.apache.org/jira/browse/JCLOUDS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-886:
--
Issue Type: New Feature (was: Bug)
Implement Roles API for jclouds-labs-shipyard
Initial impl of Roles API.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds-labs/pull/166
-- Commit Summary --
* Initial implementation of Roles API
-- File Changes --
M shipyard/src/main/java/org/jclouds/shipyard/ShipyardApi.java (4)
@nacx let's please merge PR 166 before this as the Accounts API has a minor
dependency on the Roles API. Both are fairly simple and straight forward so I
don't imagine too much churn.
---
Reply to this email directly or view it on GitHub:
[
https://issues.apache.org/jira/browse/JCLOUDS-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486360#comment-14486360
]
Christopher Dancy commented on JCLOUDS-882:
---
I'll take on the work
@nacx can we merge? Release is out the door so I figure I'd start bothering
again ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/149#issuecomment-89755923
https://issues.apache.org/jira/browse/JCLOUDS-833
ServiceKeys API has been fully implemented. Mock and Live tests both pass with
latest Shipyard version 2.0.8.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds-labs/pull/149
-- Commit Summary
As far as adding a new test for the fallback does it make sense to create a
separate class or add the test functionality elsewhere? The refactor of the
fallbacks is going to leave me with a class 'BooleanOnServiceKeyNotFoundAnd500'
which is already going to be exercised as part of
For now I've put the new fallback tester inside ServiceKeysApiMockTest as
'testDeleteNonExistentServiceKeyWithErroneousData' as it's using the
ServiceKeys delete call to stress that an exception is thrown upon erroneous
body and return code data.
---
Reply to this email directly or view it on
@@ -69,6 +70,12 @@ public void handleError(HttpCommand command, HttpResponse
response) {
if (command.getCurrentRequest().getMethod().equals(POST)) {
if
(command.getCurrentRequest().getEndpoint().getPath().endsWith(/engines)) {
@@ -64,6 +66,7 @@
void restartContainer(@PathParam(id) String id);
@Named(containers:deploy)
+ @Fallback(NullOnContainerResourceUnavailableAnd500.class)
Exactly as I have it. That is literally the content from the jclouds-wire.log I
posted.
---
Reply to this email directly
@@ -64,6 +66,7 @@
void restartContainer(@PathParam(id) String id);
@Named(containers:deploy)
+ @Fallback(NullOnContainerResourceUnavailableAnd500.class)
+@Consumes(MediaType.APPLICATION_JSON)
+@Produces(MediaType.APPLICATION_JSON)
+@RequestFilters({ ServiceKeyAuthentication.class })
+@Path(/api/servicekeys)
+public interface ServiceKeysApi {
+
+ @Named(servicekeys:list)
+ @GET
+ ListServiceKey listServiceKeys();
+
+
@@ -64,6 +66,7 @@
void restartContainer(@PathParam(id) String id);
@Named(containers:deploy)
+ @Fallback(NullOnContainerResourceUnavailableAnd500.class)
This is a funny one and an open bug for Shipyard. The deployContainer call only
deploys a single container but returns a
@nacx all looks well. I believe all your comments have been addressed and for
the better. Specifically the fallbacks should now address the 500's returned
both from the ServiceKeysApi and The ContainersApi
---
Reply to this email directly or view it on GitHub:
+ ListServiceKey possibleServiceKeys = api().listServiceKeys();
+ assertNotNull(possibleServiceKeys, possibleServiceKeys was not set);
+ assertTrue(possibleServiceKeys.size() 0, Expected at least 1
ServiceKey but list was empty);
+ boolean serviceKeyFound = false;
+
@nacx review when you get a chance. Thanks ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/149#issuecomment-78145833
+
+import org.jclouds.json.SerializedNames;
+
+import com.google.auto.value.AutoValue;
+
+@AutoValue
+public abstract class CreateServiceKey {
+
+ public abstract String description();
+
+ CreateServiceKey() {
+ }
+
+ @SerializedNames({ description })
+ public
+@Consumes(MediaType.APPLICATION_JSON)
+@RequestFilters({ ServiceKeyAuthentication.class })
+@Path(/api/servicekeys)
+public interface ServiceKeysApi {
+
+ @Named(servicekeys:list)
+ @GET
+ ListServiceKey listServiceKeys();
+
+ @Named(servicekeys:create)
+ @POST
+
1 - 100 of 193 matches
Mail list logo
