00:01:27  * chorrelljoined
00:13:02  * chorrellquit (Quit: My Mac has gone to sleep. ZZZzzz…)
00:57:23  * bahamatjoined
00:58:24  * bahamatquit (Client Quit)
01:20:01  * ed209quit (Remote host closed the connection)
01:20:08  * ed209joined
01:20:37  * chorrelljoined
01:50:02  * chorrellquit (Quit: Textual IRC Client: www.textualapp.com)
01:53:52  * therealkoopajoined
02:01:18  * therealkoopaquit (Remote host closed the connection)
02:16:37  * therealkoopajoined
02:32:23  * therealkoopaquit (Remote host closed the connection)
02:35:21  * _Tenchi_quit (Ping timeout: 244 seconds)
02:45:56  * _Tenchi_joined
06:57:27  * bahamatjoined
07:46:22  * bahamatquit (Quit: Leaving.)
09:18:55  * bahamatjoined
10:20:00  * ed209quit (Remote host closed the connection)
10:20:08  * ed209joined
11:35:29  * therealkoopajoined
14:03:21  * bahamatquit (Quit: Leaving.)
14:08:24  * pmooneyjoined
14:26:33  * echelog-1quit (Remote host closed the connection)
14:32:02  * chorrelljoined
14:58:32  * chorrellquit (Quit: Textual IRC Client: www.textualapp.com)
15:21:12  * marselljoined
15:25:18  * ryancnelsonjoined
15:42:49  * chorrelljoined
15:56:28  * fredkjoined
16:22:13  * dap_joined
16:27:19  * trentmjoined
16:37:17  * _Tenchi_quit (Read error: Connection reset by peer)
16:38:44  * ryancnelson1joined
16:39:06  * _Tenchi_joined
16:41:00  * ryancnelsonquit (Quit: Leaving.)
16:42:21  * ryancnelson1quit (Client Quit)
17:08:47  * ryancnelsonjoined
17:11:45  * cxe1joined
17:12:02  <cxe1>Hello to all good people
17:22:52  <cxe1>have anyone succeed to run setup_manta_zone.sh not in the CoaL environment?
17:34:42  <cxe1>looks like script is assuming your are running on the CoaL
17:35:05  <dap_>cxe1: I definitely run that on lab machines, though I haven't reflashed my lab machine in a few months.
17:36:37  <cxe1>script is deploying manta0 on one of the compute nodes and after that running vmadm lookup -j alias alias=${ZONE_ALIAS}
17:36:56  <cxe1>this is will always fail as VM is running on another node
17:37:32  <cxe1>I tried to deploy it on the headed and it refuse to install it on the not-compute node
17:37:35  <cxe1>catch 22
17:38:24  <dap_>Ah, it may assume a single-node system, as that's the common development environment. (Though we do have many non-single-node deployments, so I'm not sure how they did that.) Is it using SAPI to deploy the zone?
17:41:57  <cxe1>yes
17:42:35  <cxe1>dap_:yes
17:43:02  <dap_>THis is probably further fallout from the SAPI change that previously deployed zones on the HN if the server_uuid was not specified.
17:44:27  <cxe1>looks like nobody would be able to run it in milti-node environment. Manta documentation is casually asking to run this script and everything else based on this
17:45:36  <dap_>Yup. Sorry for the breakage. How did you try to get it to deploy on the headnode, and how did that fail?
17:51:24  <dap_>cxe1: ^
17:53:00  <dap_>FWIW, I've filed https://smartos.org/bugview/MANTA-2633 for this issue.
17:54:17  <cxe1>Set up SDC in each datacenter, including the headnode, all SDC services, and all compute nodes you intend to use. For easier management of hosts, we reccommend that the hostname reflect the type of server and, possibly, the intended purpose of the host. For example, we use the the "RA" or "RM" prefix for "Richmond-A" hosts and "MS" prefix for "Mantis Shrimp" hosts.
17:54:17  <cxe1>In the global zone of the headnode, set up a manta deployment zone using:
17:54:17  <cxe1>I ran /usbkey/scripts/setup_manta_zone.sh
17:54:53  <cxe1>and obviously it is failing on MANTA_ZONE=$(vmadm lookup -1 alias=${ZONE_ALIAS})
17:58:21  <dap_>cxe1: Right. But you said after that: "I tried to deploy it on the headed and it refuse to install it on the not-compute node". Do you mean that you changed the script to deploy the zone on the headnode somehow, but that failed?
17:58:50  <cxe1>no sir
17:59:13  <cxe1>Script run and deploys it on the computenode (compute node1)
18:01:02  <cxe1>I tried to shutdown all compute nodes
18:01:26  <cxe1>and got a message that not available compute nodes found to deploy
18:01:58  <dap_>Right. That all makes sense. This looks all like fallout from the issue I mentioned above. I should be able to give you a patched setup_manta_zone.sh to fix this. Could you test that?
18:02:15  <cxe1>by all means!!!!
18:02:30  <dap_>Okay. Should be like 10 minutes :)
18:03:34  <cxe1>wow
18:03:44  <cxe1>I am thrilled.
18:09:33  <dap_>cxe1: this gist has both a patch and the whole script — use whichever one is easier: https://gist.github.com/davepacheco/0172f5f73f2a82d140cf. Unfortunately, I don't have a quick way to test this myself, even on a single-node system, but I do think it should work. If you're willing to give it a shot, that would be very helpful.
18:10:39  <cxe1>let me test it
18:10:40  <cxe1>Is Manta S3 compliant or swift compliant?
18:11:02  <rmustacc>As in API complaint or something else?
18:11:09  <dap_>It is neither, to the extent that I understand what that means. It does not implement any API other than its own.
18:11:10  <rmustacc>s/compliant/compatible
18:14:41  <cxe1>script finished successfully
18:14:57  <dap_>That's good. The Manta zone is present on the HN?
18:16:02  <cxe1>yes. Up and running
18:16:21  <cxe1>I need to test it somehow. I have only 1HN and 2 CN
18:16:38  <cxe1>no VLANs, External and Admin network
18:16:41  <cxe1>vanilla
18:17:09  <dap_>If you haven't already, I would remove the zone that was deployed on the non-HN.
18:20:00  <cxe1>I've done it already
18:20:43  <cxe1>dap_ would it be possible to deploy it in my environment ?
18:20:52  <dap_>deploy Manta?
18:21:58  <cxe1>yes
18:22:10  <dap_>The hardware isn't a problem. We deploy it on single system all the time, though I wouldn't recommend it for anything where performance or availability is important. It's fine for a PoC or playing around. The lack of networks is a problem, though.
18:22:36  * pmooneyquit (Ping timeout: 240 seconds)
18:22:40  <cxe1>this is strictly POC
18:23:06  <dap_>You may be able to make it work without any VLANs (using the admin or external networks), but there's no docs for doing that (it's not supported) and I don't know offhand what changes would be required.
18:23:42  <cxe1>I can create VLANs on my switch but they won't be routable
18:25:05  * pmooneyjoined
18:26:29  <rmustacc>cxe1: The resulting VLAN network doesn't need to be routable to anything else. As long as all your machines can talk to it.
18:27:03  <rmustacc>It's not assumed to be routeable to other parts of the network (unless you're doing a deployment across multiple data centers).
18:27:15  <cxe1>I can do it in a heartbeat
18:27:56  <cxe1>but would than mean I need to use additional NIC on each node or O have to configure thank?
18:28:00  <cxe1>trank
18:28:58  <rmustacc>So nothing wrong with having the manta network be a non-routable network. The marlin network will still need to have a NAT / gateway provided, but it could be something as simple as running a NAT with two interfaces, one on the marlin network and one on an external.
18:29:34  <rmustacc>The admin network is the only access-mode VLAN in the system.
18:29:52  <rmustacc>The OS will take care of tagging different VLANs appropriately across a single device.
18:30:21  <rmustacc>You should just have to allow thost VLANs on the physical ports of your switch.
18:31:05  <cxe1>so we are changing from access mode to a trunk?
18:31:50  <cxe1>right now my interfaces (admin and external) just connected to two different VLAN groups
18:32:15  <cxe1>they are separated by port allocation to the VLANS but have no tagging.
18:32:43  <cxe1>I have 192.168.11.X for external and 10.10.10.X for admin
18:32:44  <ryancnelson>admin is the only network that's *required* to be access-mode. the others can be either 802.1q-tagged, or access-mode
18:33:04  <ryancnelson>so your admin and external being access-mode is fine
18:33:09  <cxe1>ok
18:33:25  <ryancnelson>it's just that 4 access-mode vlans means "4 sepearate nics"
18:33:30  <ryancnelson>if you have them
18:33:43  <cxe1>:-) short on cables
18:34:57  <rmustacc>Right, most folks only do access-mode on admin (as that's required), and do 802.1q tagging on the rest.
18:36:18  <cxe1>going to configure 802.1q tagging on the external network
18:36:41  <cxe1>can a HN be a marlin_node?
18:37:01  <cxe1>and two CN will be manta_nodes
18:39:43  <dap_>I'd probably not recommend using the HN as a marlin node
18:40:09  <cxe1>I only have HN and 2 CN
18:40:24  <cxe1>where should I put what?
18:41:27  <dap_>I'd probably make both CNs into storage nodes and put metadata services across the two CNs and the HN. There's a discussion about this general issue at http://joyent.github.io/manta/#planning-a-manta-deployment.
18:42:43  <cxe1>Yea. I am reading it
18:43:07  <cxe1>How Do I add a VLAN (tag interface ) on the running node?
18:43:27  <cxe1>(Sorry if you are laughing at my question )
18:43:51  <dap_>No, I just don't know the answer :) rm might, and there's probably docs somewhere.
18:44:22  <cxe1>I can tag interface on the switch side with let say VLAN 100, but how do I create VLAN 100 and passing it to the NIC ?
18:44:44  <cxe1>nevermind
18:44:46  <cxe1>found it
18:47:02  <cxe1>network tab, change VLAN. You would cut yourself off though.
18:48:07  <cxe1>looks like there is no way to change it once it is up and running.
18:49:05  <ryancnelson>man sysinfo
18:49:11  <ryancnelson>-f will update the cache
18:49:21  <ryancnelson>... the nic_tags are part of that cache
18:49:26  <ryancnelson>oh
18:49:33  <ryancnelson>you're *changing* it?
18:49:38  <ryancnelson>not adding a new one
18:53:55  <cxe1>changing /usb/config and rebooting it. Need to configure switch first
19:04:50  <cxe1>ryancnelson: how do I update it from CLI
19:04:51  <cxe1>?
19:06:19  <cxe1>n/m https://wiki.smartos.org/display/DOC/Managing+NICs
20:08:59  * chorrellquit (Quit: Textual IRC Client: www.textualapp.com)
20:20:00  * ed209quit (Remote host closed the connection)
20:20:07  * ed209joined
22:52:58  * therealkoopaquit (Remote host closed the connection)
23:25:43  * therealkoopajoined