Re: Be very careful in assumptions in tests

[William Reade]

Indeed, and to expand on all that: test-first or test-last, it's smart to
purposely break your code and make sure that your test *fails* semi-cleanly
(rather than, e.g., deadlocking).

On Fri, Dec 4, 2015 at 3:32 AM, Nate Finch  wrote:

> I'll definitely +1 the need for gc.HasLen ... I've seen a ton of panics in
> tests if the code starts erroneously returning nil slices.  Obviously this
> is less bad, since the tests still fail, but they're really ugly annoying
> failures.
>
> And +1000 to making tests that fail before fixing the code (or at least,
> purposely re-breaking the code if you forget and fix the bug first)... I've
> caught so many invalid tests that way... it is the only way to prove to
> yourself that your test actually work correctly both in proving correct
> behavior, and signalling bad behavior.
>
> On Thu, Dec 3, 2015 at 5:24 PM Tim Penhey 
> wrote:
>
>> Hi folks,
>>
>> I came across an interesting bug yesterday and during investigation
>> found that there was a very comprehensive test that covered the situation.
>>
>> The problem is that the asserts were not actually running.
>>
>> The asserts were inside a loop where the expectation was that the loop
>> would run exactly once as a previous call returned an array of items
>> with one value in it.
>>
>> Except it didn't.
>>
>> It returned an empty list.
>>
>> So, if you see something like this, a simple line like:
>>
>>   c.Assert(someList, gc.HasLen, 1)
>>
>> Is sufficient to have caught this particular issue.
>>
>>
>> Remember a key step when writing tests is to have the test fail first,
>> then make it pass.
>>
>> One trick I use is to assert checks against data I know is wrong. If the
>> test passes then I know I have other problems.
>>
>> Tim
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: After deploying openstack,I can't create vm instance

[Mark Shuttleworth]

Hi Yuanyou

Will reply separately to put you in touch with the OpenStack charm team.
However, you might want to try the "openstack" package in Ubuntu 15.10
(wily) which ensures all the charms are correctly configured, then work
backwards to a manual configuration that suits you for your cluster.

Mark

On 03/12/15 03:04, zhangyuanyou wrote:
> Hi Artur Tyloch,
>   I'm working on deploying openstack-kilo using Juju,now I can deploy 
> openstack successfully and create network in openstack-dashboard.
> But when I create a vm instance, I find the nova-compute shutdown.
> I login the controller node and show the nova service-list,I find there is 
> not nova-consoleauth.
> So I do this: apt-get install nova-consoleauth,but how can I reboot the 
> nova-compute? Any assistance is greatly appreciated.
> ++++--+-+---++-+
> | Id | Binary | Host   | Zone | Status  | 
> State | Updated_at | Disabled Reason |
> ++++--+-+---++-+
> | 1  | nova-cert  | onos-local-machine-1-lxc-3 | internal | enabled | up  
>   | 2015-12-02T09:56:38.00 | -   |
> | 2  | nova-conductor | onos-local-machine-1-lxc-3 | internal | enabled | up  
>   | 2015-12-02T09:56:39.00 | -   |
> | 3  | nova-scheduler | onos-local-machine-1-lxc-3 | internal | enabled | up  
>   | 2015-12-02T09:56:39.00 | -   |
> | 4  | nova-compute   | onos-local-machine-3   | nova | enabled | 
> down  | 2015-12-02T09:47:43.00 | -   |
> ++++--+-+---++-+
>
> nova-conductor.log:
> 2015-12-02 08:59:00.341 11084 INFO nova.openstack.common.service 
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11249
> 2015-12-02 08:59:00.348 11084 INFO nova.openstack.common.service 
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11250
> 2015-12-02 08:59:00.358 11248 INFO nova.service [-] Starting conductor node 
> (version 2015.1.2)
> 2015-12-02 08:59:00.358 11084 INFO nova.openstack.common.service 
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11251
> 2015-12-02 08:59:00.367 11250 INFO nova.service [-] Starting conductor node 
> (version 2015.1.2)
> 2015-12-02 08:59:00.367 11249 INFO nova.service [-] Starting conductor node 
> (version 2015.1.2)
> 2015-12-02 08:59:00.372 11251 INFO nova.service [-] Starting conductor node 
> (version 2015.1.2)
> 2015-12-02 08:59:00.413 11084 WARNING oslo_config.cfg 
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Option "lock_path" from 
> group "DEFAULT" is deprecated. Use option "lock_path" from group 
> "oslo_concurrency".
> 2015-12-02 08:59:00.734 11244 INFO oslo_messaging._drivers.impl_rabbit 
> [req-70fa0b3e-71d8-4171-9d63-83757938f02d - - - - -] Connecting to AMQP 
> server on localhost:5672
> 2015-12-02 08:59:00.753 11244 ERROR oslo_messaging._drivers.impl_rabbit 
> [req-70fa0b3e-71d8-4171-9d63-83757938f02d - - - - -] AMQP server on 
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
> seconds.
> 2015-12-02 08:59:00.774 11247 INFO oslo_messaging._drivers.impl_rabbit 
> [req-2447759d-c90b-41d0-90a0-ec7a23551b86 - - - - -] Connecting to AMQP 
> server on localhost:5672
> 2015-12-02 08:59:00.778 11245 INFO oslo_messaging._drivers.impl_rabbit 
> [req-7db8bff8-46ae-4f14-ad0a-11506c858369 - - - - -] Connecting to AMQP 
> server on localhost:5672
> 2015-12-02 08:59:00.783 11247 ERROR oslo_messaging._drivers.impl_rabbit 
> [req-2447759d-c90b-41d0-90a0-ec7a23551b86 - - - - -] AMQP server on 
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
> seconds.
> 2015-12-02 08:59:00.783 11242 INFO oslo_messaging._drivers.impl_rabbit 
> [req-a0bab9d4-e8c4-4674-9fd9-d355a7137a1a - - - - -] Connecting to AMQP 
> server on localhost:5672
> 2015-12-02 08:59:00.787 11245 ERROR oslo_messaging._drivers.impl_rabbit 
> [req-7db8bff8-46ae-4f14-ad0a-11506c858369 - - - - -] AMQP server on 
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
> seconds.
> 2015-12-02 08:59:00.791 11242 ERROR oslo_messaging._drivers.impl_rabbit 
> [req-a0bab9d4-e8c4-4674-9fd9-d355a7137a1a - - - - -] AMQP server on 
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
> seconds.
> 2015-12-02 08:59:00.801 11251 INFO oslo_messaging._drivers.impl_rabbit 
> [req-5af923e7-722a-4552-a788-f426c43dc916 - - - - -] Connecting to AMQP 
> server on localhost:5672
> 2015-12-02 08:59:00.806 11249 INFO oslo_messaging._drivers.impl_rabbit 
> [req-1b0fa84e-c4fa-4a83-8398-25280ec1386c - - - - -] Connecting to AMQP 
> server on localhost:5672
> 2015-12-02 08:59:00.813 11243 INFO 

Plan for new charms?

[Tom Barber]

Hello folks,

Just a quick question out of curiosity more than anything else as its stuff
we use in our day jobs, are there plans to bring either PDI or Talend to
the Charm store (preferably PDI its less like pulling teeth), also on a
different tangent, Apache Ignite?

I seen Phoenix is available, also in the Hadoop world, is there a plan for
Kylin?

Not trying to get other people to do the work, I'm more than happy to look
into these next year, just making sure I'm not duplicating effort.

Thanks

Tom


--

Director Meteorite.bi - Saiku Analytics Founder

Tel: +44(0)5603641316
Email: tom.bar...@meteorite.bi

(Help create the next generation reporting and analytics platform by
sponsoring our Saiku Reporting Kickstarter http://meteorite.bi/kickstart -
only 2 days left!)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] zulu8, mysql, bird, calico, apache2, postgresql, and ethercalc

[Konstantinos Tsakalozos]

Hi all,

A late addition to the list of reviewed charms:


   -

   Autotest
   -

  https://bugs.launchpad.net/charms/+bug/1516654
  -

  This is a new charm for the Autotest framework
  -

  The charm is deployable and working
  -

  The tests need more work. We spotted two issues with them:
  -

 The deployment configuration used by bundletester references a
 local copy of the charm
 -

 The units from sentry should be accessed in this way:
 d.sentry[‘autotest’’][0]
 - Will not move forward with this charm at this point. At least
  the charm tests should be passing


Thanks

On Thu, Dec 3, 2015 at 11:20 PM, Cory Johns 
wrote:

> Greetings!
>
> The big data team, including myself, Kevin, Andrew, and Konstantinos, hit
> the Review Queue today:
>
>
>-
>
>zulu8
>-
>
>   https://bugs.launchpad.net/charms/+bug/1519858
>   -
>
>   Refactor to use java interface
>   -
>
>  https://github.com/juju-solutions/interface-java
>  -
>
>   Discovered issue when charm-building on one architecture and
>   deploying to another:
>   -
>
>  https://github.com/juju/charm-tools/issues/58
>  -
>
>   This charm could not be successfully deployed, but we suggested
>   README and reactive changes to fix this.
>   -
>
>   We also ran into a source control issue that may affect other
>   layered-charm authors. The *source* for a charm can be committed 
> anywhere
>   (launchpad, github, etc), but it must not interfere with where the charm
>   store will look for deployable charms:
>   -
>
>  lp:~/charms///trunk
>  -
>
>mysql
>-
>
>
>   
> https://code.launchpad.net/~tvansteenburgh/charms/trusty/mysql/fix-tests/+merge/277053
>   -
>
>   Fixes for tests d.sentry[‘mysql’][0] vs d.sentry[‘mysql/0’]
>   -
>
>   All tests are passing
>   -
>
>   +1 this has been merged
>   -
>
>Ping for follow-up: bird, Calico, apache2/hostname-resolution-fix
>-
>
>   https://bugs.launchpad.net/charms/+bug/1431445
>   -
>
>   https://bugs.launchpad.net/charms/+bug/1421230
>   -
>
>
>   
> https://code.launchpad.net/~verterok/charms/trusty/apache2/hostname-resolution-fix/+merge/272127
>   -
>
>   These were all given approval conditional upon some minor feedback
>   and were awaiting response by the submitter, so we pinged them again to
>   keep the process moving.
>   -
>
>postgresql/fix-test-returncode
>-
>
>
>   
> https://code.launchpad.net/~stub/charms/trusty/postgresql/fix-test-returncode/+merge/277312
>   -
>
>   +1 merged
>   -
>
>ethercalc
>-
>
>   https://bugs.launchpad.net/charms/+bug/1486247
>   -
>
>   +1 for promulgation, but the copyright is still assigned to
>   Canonical
>   - Going to give one last chance to reclaim the copyright
>
>
> Questions/comments? We're in #juju on irc.freenode.net
>
> Thanks!
> - Cory
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>


-- 
Konstantinos Tsakalozos
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] zulu8, mysql, bird, calico, apache2, postgresql, and ethercalc

[Marco Ceppi]

On Thu, Dec 3, 2015 at 6:21 PM Cory Johns  wrote:

> Greetings!
>
> The big data team, including myself, Kevin, Andrew, and Konstantinos, hit
> the Review Queue today:
>
>
>-
>
>zulu8
>-
>
>   https://bugs.launchpad.net/charms/+bug/1519858
>   -
>
>   Refactor to use java interface
>   -
>
>  https://github.com/juju-solutions/interface-java
>  -
>
>   Discovered issue when charm-building on one architecture and
>   deploying to another:
>   -
>
>  https://github.com/juju/charm-tools/issues/58
>  -
>
>   This charm could not be successfully deployed, but we suggested
>   README and reactive changes to fix this.
>   -
>
>   We also ran into a source control issue that may affect other
>   layered-charm authors. The *source* for a charm can be committed 
> anywhere
>   (launchpad, github, etc), but it must not interfere with where the charm
>   store will look for deployable charms:
>   -
>
>  lp:~/charms///trunk
>
>
This is one of the first charms submitted to the review queue which is in
reactive. This is amazing, but it's caught us a bit off guard. Yes, the
generated charm needs to be in this branch format. However, `charm upload`
has entered private beta, which will streamline this experience soon. Just
wanted to make everyone aware of that, esp those making charms with
Reactive.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju 1.26-alpha3 moving to 2.0-alpha1

[Alexis Bruemmer]

Hi All,

Juju 2.0 has been a long time coming and we will see it release in April
2016 with Ubuntu 16.04!  Among many other improvements, the 2.0 release
will have a better bootstrap experience that leverages all the great work
done around multi-model solutions.  Juju 2.0 bootstrapping will
automatically create a controller (previously known as a Juju State Server)
with a hosted model (previously known as an environment); the new behavior
automatically provides the user with a usable model and a clear path for
adding more models to the bootstrapped controller.  This improvement
however, changes the expected functionality of the current 1.X bootstrap
command.  Our commitment to Juju users on LTS releases states clearly that
we do not break backwards compatibility on point releases (including
changing base expected behavior).  For this reason we will be dropping the
1.26.0 release and turning the current 1.26-alpha3 into 2.0-alpha1.

This is an update to our current release plans (
https://github.com/juju/juju/wiki/Juju-Release-Schedule) which has a 1.26.0
release scheduled for January.  Although this means waiting a little longer
for features, moving to a 2.0 enables the development team to deliver a
strong and correct 2.0 user experience.  The Juju team will continue to
release alphas and betas on a regular cadence so that new features will be
available in the devel ppa (ppa:juju/devel).  The first 2.0-alpha1 is
scheduled to release the week of December 7th.

If you have any questions please do not hesitate to ask.

Thanks!
Alexis

-- 
Alexis Bruemmer
Juju Core Manager, Canonical Ltd.
(503) 686-5018
alexis.bruem...@canonical.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 1.26-alpha3 moving to 2.0-alpha1

[Alexis Bruemmer]

Hi All,

Juju 2.0 has been a long time coming and we will see it release in April
2016 with Ubuntu 16.04!  Among many other improvements, the 2.0 release
will have a better bootstrap experience that leverages all the great work
done around multi-model solutions.  Juju 2.0 bootstrapping will
automatically create a controller (previously known as a Juju State Server)
with a hosted model (previously known as an environment); the new behavior
automatically provides the user with a usable model and a clear path for
adding more models to the bootstrapped controller.  This improvement
however, changes the expected functionality of the current 1.X bootstrap
command.  Our commitment to Juju users on LTS releases states clearly that
we do not break backwards compatibility on point releases (including
changing base expected behavior).  For this reason we will be dropping the
1.26.0 release and turning the current 1.26-alpha3 into 2.0-alpha1.

This is an update to our current release plans (
https://github.com/juju/juju/wiki/Juju-Release-Schedule) which has a 1.26.0
release scheduled for January.  Although this means waiting a little longer
for features, moving to a 2.0 enables the development team to deliver a
strong and correct 2.0 user experience.  The Juju team will continue to
release alphas and betas on a regular cadence so that new features will be
available in the devel ppa (ppa:juju/devel).  The first 2.0-alpha1 is
scheduled to release the week of December 7th.

If you have any questions please do not hesitate to ask.

Thanks!
Alexis

-- 
Alexis Bruemmer
Juju Core Manager, Canonical Ltd.
(503) 686-5018
alexis.bruem...@canonical.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Using maas+juju to deploy openstack,I can't run 02-maasdeploy.sh successfully.

[zhangyuanyou]

Hi  Artur Tyloch,
   I'm working on maas+juju to deploy openstack,now I edit the 02-maasdeploy.sh 
and excute it.
But this line "maas-deployer -c deployment.yaml -d --force" can't pass ,it 
always let me to input the password like this:

2015-12-04 17:45:54,032 DEBUG Executing: 'virt-install --connect qemu:///system 
--name opnfv-maas-intel --ram 4096 --vcpus 4 --disk 
vol=default/opnfv-maas-intel-root.img,format=qcow2,bus=virtio,io=native --disk 
vol=default/opnfv-maas-intel-seed.img,format=raw,bus=virtio,io=native --network 
bridge=brAdm,model=virtio --network bridge=brData,model=virtio --network 
bridge=brPublic,model=virtio --noautoconsole --vnc --import' stdin=''
2015-12-04 17:45:55,145 DEBUG Executing: 'virsh -c qemu:///system autostart 
opnfv-maas-intel' stdin=''
2015-12-04 17:45:55,162 DEBUG Waiting for MAAS vm to come up for ssh..
2015-12-04 17:45:55,163 DEBUG Using ip address specified: 192.168.212.140
2015-12-04 17:45:55,163 DEBUG Executing: 'ssh -i /root/.ssh/id_maas -o 
UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no 
root@192.168.212.140 true' stdin=''
root@192.168.212.140's password:

I edited the file deployment.yaml like this:
demo-maas:
maas:
# Defines the general setup for the MAAS environment, including the
# username and password for the host as well as the MAAS server.
user: root
password: root

# Contains the virtual machine parameters for creating the MAAS virtual
# server. Here you can configure the name of the virsh domain, the
# parameters for how the network is attached.
name: opnfv-maas-intel
interfaces: 
['bridge=brAdm,model=virtio','bridge=brData,model=virtio','bridge=brPublic,model=virtio']
memory: 4096
vcpus: 4
arch: amd64
pool: default
disk_size: 160G

# Apt http proxy setting(s)
apt_http_proxy:

apt_sources:
  - ppa:maas/stable
  - ppa:juju/stable

# Virsh power settings
# Specifies the uri and keys to use for virsh power control of the
# juju virtual machine. If the uri is omitted, the value for the
# --remote is used. If no power settings are desired, then do not
# supply the virsh block.
virsh:
rsa_priv_key: /home/ubuntu/.ssh/id_rsa
rsa_pub_key: /home/ubuntu/.ssh/id_rsa.pub
#uri: qemu+ssh://ubuntu@10.4.1.1/system

# Defines the IP Address that the configuration script will use to
# to access the MAAS controller via SSH.
ip_address: 192.168.212.140

Could you help me to resolve the question ? Any assistance is greatly 
appreciated.

Thanks.
Yuanyou


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Using maas+juju to deploy openstack, I can't run 02-maasdeploy.sh successfully.

[Narinder Gupta]

Hi Yuanyou,
Will you please let me know your host environment and I am wondering you
are using root user? I have not tested 02-maasdeploy.sh script with root
user yet. Will you please try it with ubuntu user?

Will you please try this with latest git repository as i checked in few
changes recently within couple of days for JOID.

In new version i have added default lab which is very much like you
are trying the MAAS on.  I tried to configure the ssh appropriately in
script before i copy the values. So may be running as ubuntu user should be
good. Also in yaml file try the ubuntu user.

Same was tested by 4 different labs so far it is working.


Thanks and Regards,
Narinder Gupta (PMP)   narinder.gu...@canonical.com
Canonical, Ltd.narindergupta [irc.freenode.net]
+1.281.736.5150narindergupta2007[skype]

Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com


On Fri, Dec 4, 2015 at 8:35 PM, zhangyuanyou 
wrote:

> Hi  Artur Tyloch,
>I'm working on maas+juju to deploy openstack,now I edit the
> 02-maasdeploy.sh and excute it.
> But this line "maas-deployer -c deployment.yaml -d --force" can't pass ,it
> always let me to input the password like this:
>
> *2015-12-04 17:45:54,032 DEBUG Executing: 'virt-install --connect
> qemu:///system --name opnfv-maas-intel --ram 4096 --vcpus 4 --disk
> vol=default/opnfv-maas-intel-root.img,format=qcow2,bus=virtio,io=native
> --disk
> vol=default/opnfv-maas-intel-seed.img,format=raw,bus=virtio,io=native
> --network bridge=brAdm,model=virtio --network bridge=brData,model=virtio
> --network bridge=brPublic,model=virtio --noautoconsole --vnc --import'
> stdin=''*
> *2015-12-04 17:45:55,145 DEBUG Executing: 'virsh -c qemu:///system
> autostart opnfv-maas-intel' stdin=''*
> *2015-12-04 17:45:55,162 DEBUG Waiting for MAAS vm to come up for ssh..*
> *2015-12-04 17:45:55,163 DEBUG Using ip address specified: 192.168.212.140*
> *2015-12-04 17:45:55,163 DEBUG Executing: 'ssh -i /root/.ssh/id_maas -o
> UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
> root@192.168.212.140  true' stdin=''*
>
>
> *root@192.168.212.140's  password: *I edited the
> file deployment.yaml like this:
> *demo-maas:*
> *maas:*
> *# Defines the general setup for the MAAS environment, including
> the*
> *# username and password for the host as well as the MAAS server.*
> *user: root*
> *password: root*
>
> *# Contains the virtual machine parameters for creating the MAAS
> virtual*
> *# server. Here you can configure the name of the virsh domain,
> the*
> *# parameters for how the network is attached.*
> *name: opnfv-maas-intel*
> *interfaces:
> ['bridge=brAdm,model=virtio','bridge=brData,model=virtio','bridge=brPublic,model=virtio']*
> *memory: 4096*
> *vcpus: 4*
> *arch: amd64*
> *pool: default*
> *disk_size: 160G*
>
> *# Apt http proxy setting(s)*
> *apt_http_proxy:*
>
> *apt_sources:*
> *  - ppa:maas/stable*
> *  - ppa:juju/stable*
>
> *# Virsh power settings*
> *# Specifies the uri and keys to use for virsh power control of
> the *
> *# juju virtual machine. If the uri is omitted, the value for the*
> *# --remote is used. If no power settings are desired, then do not*
> *# supply the virsh block.*
> *virsh:*
> *rsa_priv_key: /home/ubuntu/.ssh/id_rsa*
> *rsa_pub_key: /home/ubuntu/.ssh/id_rsa.pub*
> *#uri: qemu+ssh://ubuntu@10.4.1.1/system
> *
>
> *# Defines the IP Address that the configuration script will use
> to*
> *# to access the MAAS controller via SSH.*
> ip_address: 192.168.212.140
>
> Could you help me to resolve the question ? Any assistance is greatly
> appreciated.
>
> Thanks.
> Yuanyou
>
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 1.26-alpha3 moving to 2.0-alpha1

[Jorge O. Castro]

On Fri, Dec 4, 2015 at 4:06 PM, Alexis Bruemmer
 wrote:
> If you have any questions please do not hesitate to ask.

Is there a feature mapping to what's landing in each Alpha?

For example we really need native bundles and series-in-metadata,
which were due in 1.26. Does this mean these will land in an alpha
around the time the original 1.26 was released or is there a feature
shuffle we should be aware of? Thanks!


-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - The fastest way to model your service

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 1.26-alpha3 moving to 2.0-alpha1

[Jorge O. Castro]

On Fri, Dec 4, 2015 at 4:06 PM, Alexis Bruemmer
 wrote:
> If you have any questions please do not hesitate to ask.

Is there a feature mapping to what's landing in each Alpha?

For example we really need native bundles and series-in-metadata,
which were due in 1.26. Does this mean these will land in an alpha
around the time the original 1.26 was released or is there a feature
shuffle we should be aware of? Thanks!


-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - The fastest way to model your service

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Using maas+juju to deploy openstack, I can't run 02-maasdeploy.sh successfully.

[Billy Olsen]

So what this seems to be indicating is either a) the ssh key isn't properly
setup as part of the MAAS cloud unit script, b) the private key doesn't
match the public key installed, c) something else I can't think of at the
moment.

Can we get the full maas-deployer logs? That may shed some light on what's
going on.

Artur, perhaps something else comes to mind? It's almost as if it's not
fully cleaned up...

Billy

 The maas-deployer should be creating/using the ssh key that's available in
/root/.ssh/id_maas according to the logs, because it's running as root. I
don't currently have access to the script for this (02-maasdeploy.sh) so
I'm not 100% sure of the context you are running this.

If you don't have another maas environment setup on the same host,
something you can try is to remove the /root/.ssh/id_maas* keys

On Friday, December 4, 2015, zhangyuanyou  wrote:

> Hi  Artur Tyloch,
>I'm working on maas+juju to deploy openstack,now I edit the
> 02-maasdeploy.sh and excute it.
> But this line "maas-deployer -c deployment.yaml -d --force" can't pass ,it
> always let me to input the password like this:
>
> *2015-12-04 17:45:54,032 DEBUG Executing: 'virt-install --connect
> qemu:///system --name opnfv-maas-intel --ram 4096 --vcpus 4 --disk
> vol=default/opnfv-maas-intel-root.img,format=qcow2,bus=virtio,io=native
> --disk
> vol=default/opnfv-maas-intel-seed.img,format=raw,bus=virtio,io=native
> --network bridge=brAdm,model=virtio --network bridge=brData,model=virtio
> --network bridge=brPublic,model=virtio --noautoconsole --vnc --import'
> stdin=''*
> *2015-12-04 17:45:55,145 DEBUG Executing: 'virsh -c qemu:///system
> autostart opnfv-maas-intel' stdin=''*
> *2015-12-04 17:45:55,162 DEBUG Waiting for MAAS vm to come up for ssh..*
> *2015-12-04 17:45:55,163 DEBUG Using ip address specified: 192.168.212.140*
> *2015-12-04 17:45:55,163 DEBUG Executing: 'ssh -i /root/.ssh/id_maas -o
> UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
> root@192.168.212.140 
> true' stdin=''*
>
>
> *root@192.168.212.140's
>  password: *I
> edited the file deployment.yaml like this:
> *demo-maas:*
> *maas:*
> *# Defines the general setup for the MAAS environment, including
> the*
> *# username and password for the host as well as the MAAS server.*
> *user: root*
> *password: root*
>
> *# Contains the virtual machine parameters for creating the MAAS
> virtual*
> *# server. Here you can configure the name of the virsh domain,
> the*
> *# parameters for how the network is attached.*
> *name: opnfv-maas-intel*
> *interfaces:
> ['bridge=brAdm,model=virtio','bridge=brData,model=virtio','bridge=brPublic,model=virtio']*
> *memory: 4096*
> *vcpus: 4*
> *arch: amd64*
> *pool: default*
> *disk_size: 160G*
>
> *# Apt http proxy setting(s)*
> *apt_http_proxy:*
>
> *apt_sources:*
> *  - ppa:maas/stable*
> *  - ppa:juju/stable*
>
> *# Virsh power settings*
> *# Specifies the uri and keys to use for virsh power control of
> the *
> *# juju virtual machine. If the uri is omitted, the value for the*
> *# --remote is used. If no power settings are desired, then do not*
> *# supply the virsh block.*
> *virsh:*
> *rsa_priv_key: /home/ubuntu/.ssh/id_rsa*
> *rsa_pub_key: /home/ubuntu/.ssh/id_rsa.pub*
> *#uri: qemu+ssh://ubuntu@10.4.1.1/system
> *
>
> *# Defines the IP Address that the configuration script will use
> to*
> *# to access the MAAS controller via SSH.*
> ip_address: 192.168.212.140
>
> Could you help me to resolve the question ? Any assistance is greatly
> appreciated.
>
> Thanks.
> Yuanyou
>
>
>
>
>


-- 
Billy Olsen

billy.ol...@canonical.com
Software Engineer
Canonical USA
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Plan for new charms?

[Tom Barber]

Thanks Jorge

We don't have the bandwidth pre Christmas but we do have a post Christmas
requirement for it so I'll touch base with you in the new year and see if
we can help out.

Tom
On 5 Dec 2015 02:49, "Jorge O. Castro"  wrote:
>
> On Fri, Dec 4, 2015 at 4:23 AM, Tom Barber 
wrote:
> > Apache Ignite?
>
> I can't speak for the other ones, but I am actively pursuing
> volunteers for Ignite. If you know someone keen who is willing to help
> us with Ignite we'd love to mentor them.
>
> --
> Jorge Castro
> Canonical Ltd.
> http://jujucharms.com/ - The fastest way to model your service
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Using maas+juju to deploy openstack, I can't run 02-maasdeploy.sh successfully.

[Narinder Gupta]

For more information about ATT recent setup please follow this link which
works well https://wiki.opnfv.org/copper/academy/joid



Thanks and Regards,
Narinder Gupta (PMP)   narinder.gu...@canonical.com
Canonical, Ltd.narindergupta [irc.freenode.net]
+1.281.736.5150narindergupta2007[skype]

Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com


On Sat, Dec 5, 2015 at 12:34 AM, Narinder Gupta <
narinder.gu...@canonical.com> wrote:

> Hi Yuanyou,
> Will you please let me know your host environment and I am wondering you
> are using root user? I have not tested 02-maasdeploy.sh script with root
> user yet. Will you please try it with ubuntu user?
>
> Will you please try this with latest git repository as i checked in few
> changes recently within couple of days for JOID.
>
> In new version i have added default lab which is very much like you
> are trying the MAAS on.  I tried to configure the ssh appropriately in
> script before i copy the values. So may be running as ubuntu user should be
> good. Also in yaml file try the ubuntu user.
>
> Same was tested by 4 different labs so far it is working.
>
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta 
> [irc.freenode.net]+1.281.736.5150
> narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Fri, Dec 4, 2015 at 8:35 PM, zhangyuanyou 
> wrote:
>
>> Hi  Artur Tyloch,
>>I'm working on maas+juju to deploy openstack,now I edit the
>> 02-maasdeploy.sh and excute it.
>> But this line "maas-deployer -c deployment.yaml -d --force" can't
>> pass ,it always let me to input the password like this:
>>
>> *2015-12-04 17:45:54,032 DEBUG Executing: 'virt-install --connect
>> qemu:///system --name opnfv-maas-intel --ram 4096 --vcpus 4 --disk
>> vol=default/opnfv-maas-intel-root.img,format=qcow2,bus=virtio,io=native
>> --disk
>> vol=default/opnfv-maas-intel-seed.img,format=raw,bus=virtio,io=native
>> --network bridge=brAdm,model=virtio --network bridge=brData,model=virtio
>> --network bridge=brPublic,model=virtio --noautoconsole --vnc --import'
>> stdin=''*
>> *2015-12-04 17:45:55,145 DEBUG Executing: 'virsh -c qemu:///system
>> autostart opnfv-maas-intel' stdin=''*
>> *2015-12-04 17:45:55,162 DEBUG Waiting for MAAS vm to come up for ssh..*
>> *2015-12-04 17:45:55,163 DEBUG Using ip address specified:
>> 192.168.212.140*
>> *2015-12-04 17:45:55,163 DEBUG Executing: 'ssh -i /root/.ssh/id_maas -o
>> UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
>> root@192.168.212.140  true' stdin=''*
>>
>>
>> *root@192.168.212.140's  password: *I edited the
>> file deployment.yaml like this:
>> *demo-maas:*
>> *maas:*
>> *# Defines the general setup for the MAAS environment, including
>> the*
>> *# username and password for the host as well as the MAAS server.*
>> *user: root*
>> *password: root*
>>
>> *# Contains the virtual machine parameters for creating the MAAS
>> virtual*
>> *# server. Here you can configure the name of the virsh domain,
>> the*
>> *# parameters for how the network is attached.*
>> *name: opnfv-maas-intel*
>> *interfaces:
>> ['bridge=brAdm,model=virtio','bridge=brData,model=virtio','bridge=brPublic,model=virtio']*
>> *memory: 4096*
>> *vcpus: 4*
>> *arch: amd64*
>> *pool: default*
>> *disk_size: 160G*
>>
>> *# Apt http proxy setting(s)*
>> *apt_http_proxy:*
>>
>> *apt_sources:*
>> *  - ppa:maas/stable*
>> *  - ppa:juju/stable*
>>
>> *# Virsh power settings*
>> *# Specifies the uri and keys to use for virsh power control of
>> the *
>> *# juju virtual machine. If the uri is omitted, the value for the*
>> *# --remote is used. If no power settings are desired, then do
>> not*
>> *# supply the virsh block.*
>> *virsh:*
>> *rsa_priv_key: /home/ubuntu/.ssh/id_rsa*
>> *rsa_pub_key: /home/ubuntu/.ssh/id_rsa.pub*
>> *#uri: qemu+ssh://ubuntu@10.4.1.1/system
>> *
>>
>> *# Defines the IP Address that the configuration script will use
>> to*
>> *# to access the MAAS controller via SSH.*
>> ip_address: 192.168.212.140
>>
>> Could you help me to resolve the question ? Any assistance is greatly
>> appreciated.
>>
>> Thanks.
>> Yuanyou
>>
>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju