Add tag support in the CLI that provides the ability to query CCI's (and anything else that supports tags as they get implemented) based on the provided tags.

Instead of having to invoke sl cci dns sync -a -y yolo01 twice, once for -a to set the A record, and again with --ptr to set the PTR record, it'd be ideal if these weren't mutually exclusive options as described in the help.

For instance, updating both the A and PTR records thusly:

sl cci dns sync -a --ptr -y yolo01

We'd obviously still want to keep them separate as they are now to maintain backward compatibility, but even if it requires an additional API call—which are fairly quick on these—it seems to be the most intuitive use case.

At the top of the example.py file there should be a

#!/usr/bin/env python
# -*- coding: utf-8 -*-

I'm pulling out this command until it is implemented. This issue is to track the progress of that.

sl cci dns doppleganger <identifier> [options]

This issue is for human readable memory columns.

Instead of showing 1024, 2048, etc. show 1G, 2G, etc. This might require a -h flag convention so that automated tools wouldn't have to parse that out.

It would be beneficial to users if the CLI could import DNS zone files from bind or similar programs. This would make it easier for clients to migrate their DNS management to our platform or to perform massive updates.

This issue is to track adding the ability paginate through a result list in chunks in order to possibly reduce the amount of memory and to add the ability to stream result listings without ties to the actual API calls being made.

There are a couple of proposed interfaces for this.
Prefix or postfix the method name with iter_ or _iter:

cci_iter = client['Account'].iter_getVirtualGuests(chunk=100, ...)
# or
cci_iter = client['Account'].getVirtualGuests_iter(chunk=100, ...)
for cci in cci_iter:
    print cci['fqdn']

Add an additional argument to the XML-RPC method signature:

cci_iter = client['Account'].getVirtualGuests(iter=True, chunk=100, ...)
for cci in cci_iter:
    print cci['fqdn']

Both of these examples would return a generator that yields each result. When it reaches the given limit or the final API call returns zero results it will stop. The 'chunk' param will decide how many results to bring down on each API call. Tweaking this number will adjust latency/throughput/memory usage.

Would it be possible to set defaults in the config?

Unless I'm missing it, I don't see a place to set a default for datacenter. I imagine the bulk of a lot of folks' cci orders are in the same datacenter, with the same OS.

Also, once there is support for configuring the storage options (san/local), I would think a user would have a preference for one of those.

Is the config just an ini file? If so, I'd propose naming a section after the CLI module:

[cci]
default_os = UBUNTU_LATEST
default_datacenter = dal05
default_storage = local

[dns]
default_domain = some_domain.xxx

If you name the section the same name as the module, it's probably possible to make a generalized solution that works for all parameters and just strips the "default" off

The CLI shows the following help, but it does not match up with this usage text:

usage: sl cci dns sync <identifier> [options]

DNS related actions for a CCI

Options:
  -a, -A        Sync only the A record
  --ptr, --PTR  Sync only the PTR record

Prompt Options:
  -y, --really  Confirm all prompt actions

Standard Options:
  --format=ARG           Output format. [Options: table, raw] [Default: table]
  -C FILE --config=FILE  Config file location. [Default: ~/.softlayer]
  --debug=LEVEL          Specifies the debug noise level
                           1=warn, 2=info, 3=debug
  --timings              Time each API call and display after results
  -h --help              Show this screen

Upon running with the shown usage format, I always receive an "Unknown argument(s)" error:

$ sl cci dns sync 2695793 -a --ptr -y
usage: sl cci dns sync <identifier> [options]

Unknown argument(s), use -h or --help for available options

If I omit -a and --ptr entirely, I receive the same.

Moving -y before the identifier seems to work:

$ sl cci dns sync -y 2695793

If I attempt to use the -a and/or --ptr flags before the identifier where -y works, even independently of one another, I receive another unknown arguments error:

$ sl cci dns sync -a -y 2695795
usage: sl cci dns sync <identifier> [options]

Unknown argument(s), use -h or --help for available options

need to able to list and filter the images available for creating CCI's.

Future support will probably include creating, deleting, and making public, editing details, setting data center availability. So the implementation should take this into consideration.

I was thinking for the CLI of doing sl image to the base and sl image list [--public|--private] [--flex|--disk] for listing of images and the options would work as filters. The default behavior would list all the images available to the account, including public ones by default.

Thoughts ?
edit: s/images/image/g

Needed in CCIManager and in the CLI.

Looks like rebooting hardware works via the CLI, but vomits all over the screen.

$ sl hardware reboot xx.xx.xx.xx
This will power off the server with id mmmmm. Continue? [y/N]: y
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/SoftLayer-3.0.0-py2.7.egg/SoftLayer/CLI/core.py", line 182, in main
    env.out(s)
  File "/usr/local/lib/python2.7/dist-packages/SoftLayer-3.0.0-py2.7.egg/SoftLayer/CLI/environment.py", line 78, in out self.stdout.write(s)
TypeError: expected a character buffer object

$ sl hardware reboot xx.xx.xx.xx
This will power off the server with id mmmmmm. Continue? [y/N]: y
SoftLayerAPIError(SoftLayer_Exception_Public): Cannot issue command at this time.  A Remote management command has recently been issued for server something.something.xyz.

I'm ripping out this since it's un-implemented. This issue is to track progress on implementing this feature. It will print out network details of a CCI.

sl cci network details <identifier> [options]

Implement basic hardware support:

• Listing hardware. sl hardware list
• Detail hardware. sl hardware detail 1234

Ordering and other functions will be more involved and not be covered in this issue.

This issue is to track moving the code from the BSD-based license to the MIT license.

I've anchored this on the v3 milestone.

Add support for an "sl me" command that utilizes the metadata service to output specifics for the server or CCI on which the command is run.

SSL management for sl ssl and SSLManager should include the following

certs meaning all things related to SSL certificates

• List certs
• delete certs
• add certs
• download certs

Per our roadmap meeting, there are a number of minor changes that we want to make to the CLI to improve consistency and usability. Since these are all small, I'm going to create this single issue in order to track them all.

• Change bmetal to bmc
• Change hardware to server
• Rename iSCSI to ?
• Needs consistent spacing, ordering (alphabetical). Also the style should be documented
• Document style guidelines to make contribution easier

We should probably have some type of sane way of dealing with limiting the number of objects returned.

Something like limiting the default to 200 and allowing the client to specify --offset/--from.

Or maybe expose --limit and default is for everything.

More discussion is needed

We need a way to view and edit NAS and iSCSI options from the CLI

When a user uses sl config setup to generate their ~/.softlayer config file, it currently writes a group- and world-readable file. The script should set permissions on it to 0600 once it's written.

This is to track the remaining work that needs to be done from #56.

Currently static subnets cannot be created, so that needs to be added. We also need to determine how to best support RIR registration functionality.

Now that the API itself supports SSH key management, we should add that functionality into both the Python bindings and the CLI.

The current firewall support is limited only to listing. We should expose more functionality in order to make this manager (and related CLI module) more useful.

Would be useful to be able to list somehow the records in a zone without requesting the BIND export, with the ability to optionally specify record types.

I'll tackle this one -- want to familiarize myself with the CLI stuff -- but wanted to get this in to track it.

Hi, the package on cheese shop (pypi) is not latest and lacks NetworkManager, please upload and release latest/stable library to cheese shop.

When using sl hardware detail hostname, the resulting table shows a number of the same PTR lines (usually around 6-7).

Example output:

bc:~/dev/slapi-client% sl hardware detail test02
:............:.................................:
:       Name : Value                           :
:............:.................................:
:         id : 9999963338                      :
:   hostname : test02.sub.example.com          :
:     status : ACTIVE                          :
: datacenter : sjc01                           :
:      cores : 24                              :
:     memory : 32G                             :
:  public_ip : 108.xxx.xxx.xxx                 :
: private_ip : 10.xxx.xxx.xxx                  :
:         os : Ubuntu                          :
:    created : 2013-06-14T13:20:03-05:00       :
:      notes : Shared Example                  :
:       tags : example                         :
:        ptr : sub.example.com.                :
:        ptr : sub.example.com.                :
:        ptr : sub.example.com.                :
:        ptr : sub.example.com.                :
:        ptr : sub.example.com.                :
:        ptr : sub.example.com.                :
:        ptr : sub.example.com.                :
:............:.................................:

Transcoding jobs should be easily managed via the CLI. Thoughts on uploading/downloading directly from the CLI tool itself. Limitation is no additional modules other than what is already imported today.

Easy low-hanging fruit for the next milestone...

For folks with IPv6 addresses on their CCIs, having sl cci dns sync perform a sync of the AAAA record would be a useful addition as well.

Would be as simple as adding another --AAAA option to the existing command.

This would not include the full /64 block of addresses that is provided to them if they select at order time, only the single IPv6 address we provide to them if they chose it.

about half of the commands for sl metadata are broken.

# sl my network public
Traceback (most recent call last):
  File "/usr/local/bin/sl", line 9, in <module>
    load_entry_point('SoftLayer==2.1.0', 'console_scripts', 'sl')()
  File "/usr/local/lib/python2.7/dist-packages/SoftLayer/CLI/core.py", line 190, in main
    data = action.execute(client, submodule_args)
  File "/usr/local/lib/python2.7/dist-packages/SoftLayer/CLI/modules/metadata.py", line 211, in execute
    'router', network['routers']])
KeyError: 'routers'

# sl my datacenter
usage: sl metadata name [options]

# sl my user_data 
SoftLayerAPIError(500): Internal Server Error

running sl cci create-options --os no longer only displays just the OS. Same for all the other filtering options.

At the moment I'm working on issue #34 and the metadata service requires us to use the REST endpoint since the mechanism for authenticating is only enabled for the REST API. I've been using urllib2 and have come across some issues with fully testing it. I had to add simplejson as a requirement for anything less than 2.6 since a json parser wasn't included in the standard library until then.

I think we should consider not supporting python 2.5. Doing this would cut out the need for separate transport layers for XML-RPC (the xmlrpclib version having several hacks) and would allow us to unify on using requests.

So the question I have is, should we do one of the following?:

1. Ignore python 2.5 support for new functionality. The API code would still work the same but certain managers and CLI commands would fail with 2.5.
2. Drop python 2.5 support altogether
3. Keep python 2.5 support for the foreseeable future

Thoughts?

Would be great if we could set the TTL that gets created on a sl cci dns sync. It looks like the default is currently 2 hours.

Mayhap something like:

$ sl cci dns sync -a --ptr --ttl=300 yolo-01

CCI's have additional capabilities that are missing from CCIManager and sl cci

Required

• Power Off
• Power On
• Force Off
• Pause
• Unpause
• Migrate to SAN/Local disk

Maybe (should be in v2.2.0?)

• Port control
• Create image
• manage tags
• upgrade (links/cpu/ram/disks)

In addition to allowing the large number of flags and arguments, it would be helpful if the CLI also provided a wizard-based interface for performing various actions. This will decrease the learning curve even further and allow a larger audience base to take advantage of the CLI.

Splitting the entangled conversation from #25 (RIP)

We obviously don't want huge result sets, the servers don't want to serve them, it'd be nice to be able to filter ccis with some precision.

I was thinking "sl cci list" could take parameters like "sl cci create":

sl cci list --datacenter "dal05" --hostname "tim*"

sl cci detail takes in --name and --public-ip but they currently don't do anything.

sl cci detail (--id=ID | --name=NAME | --public-ip=PUBLIC_IP) ...

I think we should implement this using a helper in the cci module like I described here: #34 (comment)

cci details should include the attached notes. And maybe the createDate. For dates, we should decide on a date format to display in. ISO-18601 seems like the best to use in my opinion..

[prompt>]% python example.py                                                      
File "example.py", line 100                                            
  print "Update ticket 123456. The new update's id is %.", update{'id'}

It should be:

print "Update ticket 123456. The new update's id is %s" % update['id']

When running python2.6 there are warnings raised using anything that uses "help"

python -V
Python 2.6.6

sl metadata: error: argument action: invalid choice: 'userdata' (choose from 'datacenter', 'backend_mac', 'primary_ip', 'network', 'tags', 'id', 'primary_backend_ip', 'fqdn', 'user_data', 'datacenter_id', 'frontend_mac', 'provision_state', 'hostname')
/usr/local/lib/python2.6/dist-packages/SoftLayer/CLI/core.py:155: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  if hasattr(e, 'message') and str(e.message):
/usr/local/lib/python2.6/dist-packages/SoftLayer/CLI/core.py:156: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  sys.stderr.write(str(e.message))
2

In discussing #70, @sudorandom and I determined that allowing defaulting certain parameters such as data center and CPUs wasn't going to be terribly useful, but that allowing the import of file templates would be. This would allow users to create various CCI or hardware templates and then use them to rapidly create new objects like so:

sl cci create -H myhost -D mydomain -f small_cci.txt

This issue should create the import mechanism for CCIs as well as a couple of sample templates. If time permits, it should be expanded to BMC and dedicated servers as well.

The image management that exists within the API is functional, but needs some work. The data displayed does not match what appears in the Manage portal and some columns, such as type, are blank. We need to see if we can make things more consistent with the portals and also improve the functionality available through the bindings.

I think this should output all options.

sl cci options 

Also, providing multiple flags should be able to display all the options specified instead of just one. So...

sl cci options --cpu --datacenter --os

would output the cpu, datacenter, and os options.

We should be able to manage monitoring, though I don't know if it should be its own module or not. Leaning towards it honestly with maybe some reporting via cci and hardware details ?

Goals

1. Have a basic CLI
2. Have a few basic Manager classes to simplify basic usage
3. Have 100% test coverage

sl metadata network public --format=raw
 [u'06:d0:13:6f:c8:f5']  fcr01.sng01  [1384]  [205808] 

This makes it hard to use awk when grabbing the output.

The managers are all in the top namespace. They interweave with other types of modules like utils, transport, and consts. As the count of managers increases it will become pretty confusing to find anything. Therefore, I think managers should go in their own namespace. The proper way to import a manager should be from SoftLayer import SomeManager, but there may be cases where they're being imported directly, particularly in the CLI code and the tests. Also, the module names should be lower-case so we might as well fix that too.

Current Layout

• SoftLayer
  • CLI
    • ...
  • tests
    • ...
  • API
  • CCI
  • consts
  • DNS
  • exceptions
  • firewall
  • hardware
  • metadata
  • SSL
  • transport
  • utils

Proposed

• SoftLayer
  • CLI
    • ...
  • managers
    • cci
    • dns
    • firewall
    • hardware
    • metadata
    • ssl
  • tests
    • ...
  • API
  • consts
  • exceptions
  • transport
  • utils

Thoughts? Opinions?

Should be able to view and manage network IP addresses. Maybe view by VLAN or something of the like.

Before we can release v3, we should make a best effort to update all references to the old style to the newer style introduced in v2 since the old stuff has been deprecated in v2 and is now removed in master and will be in v3.

Here's a list of pages that need modification:

• http://sldn.softlayer.com/article/Getting-Started
• http://sldn.softlayer.com/article/Python

This issue is to track the progress and scope of this even though it's not directly related to this git repo.