EC2 VPC firewall rules
Ian Booth
ian.booth at canonical.com
Fri Feb 19 00:21:17 UTC 2016
Login was bumped to v3 to prevent accidental logins from older Juju clients
which may appear to connect successfully but then fail later depending on what
operations are performed.
It also allows the "this version is incompatible message". This was done for 1.x
clients logging into Juju 2.0 servers, but the other way around was missed out.
We'll fix that for beta2.
On 18/02/16 20:51, John Meinel wrote:
> Shouldn't we at least be giving a "juju 2.0 cannot operate with a juju 1.X
> API server, please install juju-1.25 if you want to use this system", or
> something along tohse lines. Admin(3).Login is not implemented sounds like
> a poor way for them to discover that.
>
> John
> =:->
>
>
> On Thu, Feb 18, 2016 at 2:49 PM, John Meinel <john at arbash-meinel.com> wrote:
>
>> Looks like the changes to Login broke compatibility. We are adding a Login
>> v3, but it looks like the new code will refuse to try to Login to v2. I'm a
>> bit surprised, but it means you'll need to bootstrap again if you want to
>> test it out with current trunk.
>>
>> John
>> =:->
>>
>>
>> On Thu, Feb 18, 2016 at 2:47 PM, Tom Barber <tom at analytical-labs.com>
>> wrote:
>>
>>> Hey Dimiter,
>>>
>>> Thanks for that. As am running trunk I wanted to make sure I was fully up
>>> to date before progressing further. I pulled trunk locally and ran juju
>>> upgrade-juju --upload-tools
>>>
>>> That gives me:
>>>
>>> WARNING no addresses found in space "default"
>>> WARNING using all API addresses (cannot pick by space "default"):
>>> [public:52.30.224.20 local-cloud:172.31.2.38]
>>> WARNING discarding API open error: no such request - method
>>> Admin(3).Login is not implemented (not implemented)
>>> ERROR no such request - method Admin(3).Login is not implemented (not
>>> implemented)
>>>
>>>
>>> I assume the ERROR portion is pretty critical. So here's a slightly off
>>> topic question, which I suspect has a very simple yes/no answer. Can I
>>> either a) force a bootstrapped environment upgrade b) manually upgrade an
>>> environment by passing the error but making the bootstrap node up to date
>>> c) export the existing nodes it manages and import them back into a new
>>> bootstrap node without having to recreate them as well?
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>> --------------
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> On 18 February 2016 at 10:42, Dimiter Naydenov <
>>> dimiter.naydenov at canonical.com> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 18.02.2016 12:01, Tom Barber wrote:
>>>>> Hello folks
>>>>>
>>>>> I'm not sure if my tinkering has broken something, the fact I'm
>>>>> running trunk has broken something or I just don't understand
>>>>> something.
>>>>>
>>>>> Until last week we've been running EC2 classic, but we have now
>>>>> switched to EC2-VPC and have launched a few machines.
>>>>>
>>>>> juju ssh to these machines works fine and I've been configuring
>>>>> them to suit our needs.
>>>>>
>>>>> Then I came to look at external access, `juju expose mysqldb` for
>>>>> example, I would then expect to be able to access it from the
>>>>> outside world, but can't unless go into my VPC settings and open
>>>>> the port in one of the juju security groups, at which point
>>>>> external access works fine.
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>> Hey Tom,
>>>>
>>>> What you're describing sounds like a bug, as "juju expose <service>"
>>>> should trigger the firewaller worker to open the ports the service has
>>>> declared (with open-ports within the charm) using the security group
>>>> assigned to the host machine for all units of that service.
>>>>
>>>> Have you changed the "firewall-mode" setting by any chance?
>>>> Can you provide some logs from /var/log/juju/*.log on the bootstrap
>>>> instance (machine 0)?
>>>>
>>>> Cheers,
>>>> - --
>>>> Dimiter Naydenov <dimiter.naydenov at canonical.com>
>>>> Juju Core Sapphire team <http://juju.ubuntu.com>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
>>>> i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
>>>> Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
>>>> JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
>>>> R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
>>>> /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
>>>> =kPA7
>>>> -----END PGP SIGNATURE-----
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
More information about the Juju
mailing list