maas-devel team mailing list archive

[Diogo Matsubara <matsubara@xxxxxxxxxxxxx>]

On Fri, Apr 20, 2012 at 12:57 PM, Michael Hughes <itismike@xxxxxxxxx> wrote:
> You're welcome! Just one more question:
>
>> What, if any, PPAs do you guys run? Or do you recommend sticking with
>> what is available directly through 12.04 repositories?

I run from this one: https://launchpad.net/~maas-maintainers/+archive/testing

If you find any problems with it, let us know

>
> On Fri, Apr 20, 2012 at 10:50 AM, Diogo Matsubara
> <matsubara@xxxxxxxxxxxxx> wrote:
>> On Fri, Apr 20, 2012 at 12:36 PM, Michael Hughes <itismike@xxxxxxxxx> wrote:
>>> That fixed my bootstrap error. Nice work Francis!
>>>
>>> But now my nodes are in several different states:
>>>
>>> MAC     Status
>>> ..9d:5a (clusterNode5_9D5A)     Retired
>>> ..b7:95 (clusterNode4_B795)     Allocated to mike
>>> ..65:f8 (clusterNode365F8)      Retired
>>> ..dd:27 (clusterNode2DD27)      Ready
>>> ..86:f0 (clusterNode186F0)      Declared
>>>
>>> The only one that will let me delete it through the webgui is the one
>>> marked as "Ready."  Running the previous script to reset the nodes is
>>> not working:
>>> http://pastebin.ubuntu.com/938421/
>>>
>>> Stick a fork in me. I'm done. I'll try rebuilding from the beginning
>>> in a little bit.
>>>
>>> What, if any, PPAs do you guys run? Or do you recommend sticking with
>>> what is available directly through 12.04 repositories?
>>>
>>> Thanks for all your help with this. I'm hoping a fresh start with the
>>> current work-arounds is more successful.
>>
>> Thank you!
>>
>>>
>>> -Mike
>>>
>>>
>>> On Fri, Apr 20, 2012 at 10:09 AM, Francis J. Lacoste
>>> <francis.lacoste@xxxxxxxxxxxxx> wrote:
>>>> Hi Michael,
>>>>
>>>> From the log:
>>>>
>>>>  File "/usr/lib/python2.7/dist-packages/maasserver/models.py", line 667,
>>>> in acquire
>>>>    assert self.owner is None
>>>>
>>>> That's a fixed bug. Commissioning didn't reset the owner. It should be
>>>> fixed in the latest maas version released in the archive.
>>>>
>>>> But that won't fixed the problematic instance. You can either remove all
>>>> nodes and re-enlist them (once you have upgraded maas). Or you can use
>>>> the workaround documented in the bug (using the maas shell to clear the
>>>> nodes owner).
>>>>
>>>> https://bugs.launchpad.net/maas/+bug/981068
>>>>
>>>> (The workaround is http://pastebin.ubuntu.com/928418/, you should
>>>> execute that through the maas shell.)
>>>>
>>>> Cheer
>>>>
>>>> On 12-04-20 10:44 AM, Michael Hughes wrote:
>>>>> maas.log ==> http://pastebin.ubuntu.com/938350/
>>>>>
>>>>> On Fri, Apr 20, 2012 at 9:34 AM, Diogo Matsubara
>>>>> <matsubara@xxxxxxxxxxxxx> wrote:
>>>>>> On Fri, Apr 20, 2012 at 11:24 AM, Michael Hughes <itismike@xxxxxxxxx> wrote:
>>>>>>> It didn't like that either:
>>>>>>>
>>>>>>> $ juju bootstrap
>>>>>>> 2012-04-20 09:16:46,063 INFO Bootstrapping environment 'maas' (origin:
>>>>>>> distro type: maas)...
>>>>>>> Unexpected Error interacting with provider: 500 INTERNAL SERVER ERROR
>>>>>>> 2012-04-20 09:16:46,526 ERROR Unexpected Error interacting with
>>>>>>> provider: 500 INTERNAL SERVER ERROR
>>>>>>>
>>>>>>
>>>>>> What do you have in your maas.log?
>>>>>>
>>>>>>> I got the same results after rebooting my MAAS server. Are we at the
>>>>>>> point of performing a fresh install yet? :)
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 20, 2012 at 9:15 AM, Diogo Matsubara
>>>>>>> <matsubara@xxxxxxxxxxxxx> wrote:
>>>>>>>> On Fri, Apr 20, 2012 at 11:09 AM, Michael Hughes <itismike@xxxxxxxxx> wrote:
>>>>>>>>> Nice catch Francis. That was a c/p error on my part. After editing
>>>>>>>>> that file what do I need to do to refresh the parameters?
>>>>>>>>>
>>>>>>>>
>>>>>>>> You can try juju bootstrap again. It'll catch the changes in your
>>>>>>>> environment.yaml files automatically, but since your nodes are in
>>>>>>>> somewhat broken state due to maas shell commands I asked you to run,
>>>>>>>> it might not work or you might run into the ProtocolError again you
>>>>>>>> pasted.
>>>>>>>>
>>>>>>>>> On Fri, Apr 20, 2012 at 9:03 AM, Diogo Matsubara
>>>>>>>>> <matsubara@xxxxxxxxxxxxx> wrote:
>>>>>>>>>> On Fri, Apr 20, 2012 at 11:02 AM, Michael Hughes <itismike@xxxxxxxxx> wrote:
>>>>>>>>>>> Hi Francis. Here's my environments.yaml file:
>>>>>>>>>>>
>>>>>>>>>>> $ cat ~/.juju/environments.yaml
>>>>>>>>>>> environments:
>>>>>>>>>>>  maas:
>>>>>>>>>>>    type: maas
>>>>>>>>>>>    maas-server: 'http://172.23.1.1/MAAS:80/MAAS'
>>>>>>>>>>
>>>>>>>>>> This should be 'http://172.23.1.1:80/MAAS
>>>>>>>>>>
>>>>>>>>>>>    maas-oauth: 'fQzecEPwaZmHjPF9YM:Mx[..]5CAfGH3qSmh2KWeepcMZy3d4s7CX'
>>>>>>>>>>>    admin-secret: 'nothing'
>>>>>>>>>>>    default-series: precise
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 20, 2012 at 8:58 AM, Francis J. Lacoste
>>>>>>>>>>> <francis.lacoste@xxxxxxxxxxxxx> wrote:
>>>>>>>>>>>> On 12-04-19 12:22 PM, Michael Hughes wrote:
>>>>>>>>>>>>> Thanks Diogo! I added the reference to the Ephemeral bug to the troubleshooter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Verbose provides a few more lines at the bottom:
>>>>>>>>>>>>> ~$ juju --verbose bootstrap
>>>>>>>>>>>>> 2012-04-19 10:43:15,254 DEBUG Initializing juju bootstrap runtime
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>>>>> Failure: juju.errors.ProviderInteractionError: Unexpected TimeoutError
>>>>>>>>>>>>> interacting with provider: User timeout caused connection failure.
>>>>>>>>>>>>> 2012-04-19 10:43:45,297 ERROR Traceback (most recent call last):
>>>>>>>>>>>>> Failure: juju.errors.ProviderInteractionError: Unexpected TimeoutError
>>>>>>>>>>>>> interacting with provider: User timeout caused connection failure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unexpected TimeoutError interacting with provider: User timeout caused
>>>>>>>>>>>>> connection failure.
>>>>>>>>>>>>> 2012-04-19 10:43:45,299 ERROR Unexpected TimeoutError interacting with
>>>>>>>>>>>>> provider: User timeout caused connection failure.
>>>>>>>>>>>>> ~$
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What is maas-server set to in your .juju/environment.yaml file. Make
>>>>>>>>>>>> sure, that the hostname/IP you use there can be reached by the network
>>>>>>>>>>>> on which the nodes run. Basically, you need a URL that will work for
>>>>>>>>>>>> both the juju client and the juju agents on the nodes running in the MAAS.
>>>>>>>>>>>>
>>>>>>>>>>>> (For example, that's why http://localhost is never going to work.)
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Francis J. Lacoste
>>>>>>>>>>>> francis.lacoste@xxxxxxxxxxxxx
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Mailing list: https://launchpad.net/~maas-devel
>>>>>>>>>>>> Post to     : maas-devel@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~maas-devel
>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Mailing list: https://launchpad.net/~maas-devel
>>>>>>>>>>> Post to     : maas-devel@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~maas-devel
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Diogo M. Matsubara
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Diogo M. Matsubara
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Diogo M. Matsubara
>>>>>
>>>>
>>>> --
>>>> Francis J. Lacoste
>>>> francis.lacoste@xxxxxxxxxxxxx
>>>>
>>
>>
>>
>> --
>> Diogo M. Matsubara



-- 
Diogo M. Matsubara