juju api-endpoints has no way to distinguish public and private addresses

alternatively differ output by user if this is also being consumed by agents and admin or return a mapping of state server to addresses with the address type also denoted.

This is pretty much a duplicate of bug 1310258
There's a branch in review which excludes all IP6 addresses and machine local addresses from the API list. However, the other non-local IP4 addresses are still listed. I think this is by design by am not across the specifics of why it has been necessary to do it that way.

It's not a dupe IMO.. Ones about the API, ones about the cli regression
which specifically wants only addresses that can be connected to.. The uses
of the API I guess include agents though there are regressions there as
well.

On Tuesday, April 22, 2014, Ian Booth <email address hidden> wrote:

> This is pretty much a duplicate of bug 1310258
> There's a branch in review which excludes all IP6 addresses and machine
> local addresses from the API list. However, the other non-local IP4
> addresses are still listed. I think this is by design by am not across the
> specifics of why it has been necessary to do it that way.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1311227
>
> Title:
> juju api-endpoints cli regression on trunk/1.19
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1311227/+subscriptions
>

How do you know which addresses can be connected to? That's relative to the client. We should be pruning out the loopback addresses and IPv6 (for now), but otherwise I don't see how it is an error to add additional networks.

The duplicate comment was referring to the need to remove IP6 and machine local addresses from the list

The branch to remove the IP6 and machine local addresses has now landed. So that bit has been addressed.

re api, returning all is fine, re cli (which this bug is filed out), re the
client, thats partly why i was interested in customizing results, remote
peer is one of two types, its either on a subnet or routed, the server
socket connection has a reasonable guess primarily based on context of the
login agent or user, in which case it can direct appropriately to network
name/role classification (ext, int, named, mgmt). even with the multiple
addresses, its relatively simple to keep compatibility with the cli output
via exposing api results output via cli flags (--ipv6, --network). i don't
think we want to filter ipv6 addresses, thats a valid form of connecting,
the consumer should determine usage of the endpoints.

incidentally this also brought up a regression in machine agents, whereby
in a cross region env using manual provider, the machines would come up
connect to the public ip address of the state server, then commit suicide
by requesting the current set of addresses for the state servers via the
same api-endpoints api, go ahead and determine they should re-connect on
their cloud-local address/net, rewrite their agent.conf and effectively not
able to come again on restart or their reconnect attempt, and marked down
in status.

one of the machine agent's logs http://paste.ubuntu.com/7308797/

which goes to the point of presumption re network name/role.. but afaics
for almost every provider except maas, the address the client should
contact a server is well known, and with maas we assume connectivity by at
least one vlan. That is the entire point of this cli command namely to
resolve an address for each state server in the environment for api
programs to utilize. Although wrt to the api consumer suicide bug in MA
perhaps it should be a note on canaries and rollback with regard to
upgrades, ie fallback to known working ip address.

cheers,

Kapil

On Tue, Apr 22, 2014 at 8:04 PM, Ian Booth <email address hidden> wrote:

> The duplicate comment was referring to the need to remove IP6 and
> machine local addresses from the list
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1311227
>
> Title:
> juju api-endpoints cli regression on trunk/1.19
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1311227/+subscriptions
>

Meant to bring this up at the sprint. API end points command is somewhat
useless. Any client API program that wants to connect needs to parse a jenv
file. ie endpoint, credentials, cert

On Thursday, May 1, 2014, Curtis Hovey <email address hidden> wrote:

> ** Changed in: juju-core
> Milestone: 2.0 => 1.20.0
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1311227
>
> Title:
> juju api-endpoints has no way to distinguish public and private
> addresses
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1311227/+subscriptions
>

This issue needs to be reopened against trunk, compatibility with 1.18 was never verified and isn't correct, the rendering on trunk simply turns the list of state server addresses into a scalar when should be a list of public addresses per state server.

This incompatible change means in a multi-state server environment each client has to distinguish if the output contains a scalar or a list, where as previously it was always at least a single entry list.

ie. note the delta

http://pastebin.ubuntu.com/7894639/