You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by bostko <gi...@git.apache.org> on 2017/03/14 21:48:05 UTC
[GitHub] brooklyn-docs pull request #156: Suggest using unique custom.machine.namer.m...
GitHub user bostko opened a pull request:
https://github.com/apache/brooklyn-docs/pull/156
Suggest using unique custom.machine.namer.machine
Notes on using unique VM name to avoid duplicated names in cloud.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bostko/brooklyn-docs custom.machine.namer.machine
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/brooklyn-docs/pull/156.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #156
----
commit 771bbb08b40493e92cd347c3ac08dc557b87cd44
Author: Valentin Aitken <bo...@gmail.com>
Date: 2017-03-14T21:47:40Z
Suggest using unique custom.machine.namer.machine
Notes on using unique VM name to avoid duplicated names in cloud.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-docs pull request #156: Suggest using unique custom.machine.namer.m...
Posted by aledsage <gi...@git.apache.org>.
Github user aledsage commented on a diff in the pull request:
https://github.com/apache/brooklyn-docs/pull/156#discussion_r106133221
--- Diff: guide/ops/locations/_clouds.md ---
@@ -278,7 +278,10 @@ The name that Apache Brooklyn generates for your virtual machine will, by defaul
If you have created a lot of virtual machines, this kind of naming may not be helpful. This can be changed using the following YAML in your location's `brooklyn.config`:
--- End diff --
I think we should change the wording in this doc. I think it's wrong to say "this kind of naming may not be helpful". The point is more that:
However, some organization have their own naming convention for VMs. The naming strategy used by
Brooklyn can be configured using the following YAML in your location's `brooklyn.config`:
If you have created a lot of virtual machines, this kind of naming may not be helpful. This can be changed using the following YAML in your location's brooklyn.config:
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-docs issue #156: Suggest using unique custom.machine.namer.machine
Posted by aledsage <gi...@git.apache.org>.
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-docs/pull/156
Instead of this change, I think it would be better to add to `guide/ops/locations/_azure-ARM.md`, to say that the cloud-machine-namer needs to give a unique name for each VM (which is different from other clouds)! In aws for example, jclouds appends some randomly generated suffix for the security group it creates (I believe).
If I'm right about that difference, then @bostko can you please open an issue in jclouds so that it behaves the same as other clouds for appending a random name (cc @andreaturli).
See https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions for azure's guidelines on naming.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-docs issue #156: Suggest using unique custom.machine.namer.machine
Posted by bostko <gi...@git.apache.org>.
Github user bostko commented on the issue:
https://github.com/apache/brooklyn-docs/pull/156
@aledsage I think problem I had was that I used machine location namer which was specifiying a constant machine name. Thus I hit an error in Azure ARM where the first problem was when jclouds was creating resource group since it got the a name which already existed.
@aledsage thanks for naming convention suggestion. It seems good to have `-rg` suffix for resource group names, `-sg` suffix for security group names, however I do not find the need for it at the moment.
Closing the PR for now.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-docs issue #156: Suggest using unique custom.machine.namer.machine
Posted by ahgittin <gi...@git.apache.org>.
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-docs/pull/156
@bostko ping
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] brooklyn-docs pull request #156: Suggest using unique custom.machine.namer.m...
Posted by bostko <gi...@git.apache.org>.
Github user bostko closed the pull request at:
https://github.com/apache/brooklyn-docs/pull/156
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---