Re: Tests do not pass with go1.7

[John Meinel]

Given the error message,  I think this is our "prevent us from contacting
real websites in the test run" failing. This is one of those "global state
is bad" cases because we had to patch global state during the run of the
tests but prob 1.7 changes what global state we need to touch.

John
=:->
On Jun 9, 2016 6:34 AM, "Nate Finch"  wrote:

> Just FYI, in case anyone was like me and decided they wanted to jump on
> the faster compile times in 1.7... some of our tests do not pass in go 1.7:
>
> https://bugs.launchpad.net/juju-core/+bug/1589350
>
> --
> 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: Model config

[Mark Shuttleworth]

On 09/06/16 11:35, Andrew Wilkins wrote:
> On Wed, Jun 8, 2016 at 9:01 PM Mark Shuttleworth  > wrote:
>
>
>  juju set-model-defaults
>
>
> I was mostly wondering whether we should have model defaults, or
> things that that we'd set at a common level *without* the ability to
> set on a per-model basis to keep things compartmentalised. Once
> cloud/region/endpoint and credential attributes are separated from
> model config, there aren't *that* many things that make sense to have
> common across models.
>

I think there are some things that would be set globally and not
per-model, and those would be controller properties. There are other
things where it's good to have defaults for every model, but still
override per model if you want.

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

Re: Model config

[Andrew Wilkins]

On Wed, Jun 8, 2016 at 9:01 PM Mark Shuttleworth  wrote:

>
>  juju set-model-defaults
>

I was mostly wondering whether we should have model defaults, or things
that that we'd set at a common level *without* the ability to set on a
per-model basis to keep things compartmentalised. Once
cloud/region/endpoint and credential attributes are separated from model
config, there aren't *that* many things that make sense to have common
across models.

Anyway, based on Nicolas's response and other discussions the dev team has
had internally, we'll go ahead with defaults with the ability to override.

Thanks,
Andrew


>  juju set-model-config
>  juju set-controller-config
>
> Have we a strong preference for get/set names, or could we just use
> "model-config" and "model-defaults" as read/write commands?
>
>
> Mark
>
>
> On 08/06/16 18:41, Andrew Wilkins wrote:
>
> Hi folks,
>
> We're in the midst of making some changes to model configuration in Juju
> 2.0, separating out things that are not model specific from those that are. 
> For
> many things this is very clear-cut, and for other things not so much.
>
> For example, api-port and state-port are controller-specific, so we'll be
> moving them from model config to a new controller config collection. The
> end goal is that you'll no longer see those when you type "juju
> get-model-config" (there will be a separate command to get controller
> attributes such as these), though we're not quite there yet.
>
> We also think there are some attributes that people will want to set
> across all models, but are not necessarily related to the *controller*. For
> example, http-proxy, apt-http-proxy, and their siblings. I expect that if
> anyone is setting these particular attributes, they are doing so for *all*
> models, as they're operating within a private cloud with limited network
> access.
>
> Does anyone have a real, uncontrived use-case for configuring proxy
> settings on a per-model basis?
>
> Cheers,
> Andrew
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Tests do not pass with go1.7

[Nate Finch]

Just FYI, in case anyone was like me and decided they wanted to jump on the
faster compile times in 1.7... some of our tests do not pass in go 1.7:

https://bugs.launchpad.net/juju-core/+bug/1589350
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Conjure-up, an Introduction

[Adam Stokes]

Hi all,

We've recently released the next version of conjure-up. If you are not
familiar with conjure-up and how it can make your life that much more
productive please have a look at this blog post:

https://insights.ubuntu.com/2016/06/09/conjure-up-an-introduction/

We will be on a weekly release schedule until a GA release so now is the
perfect time to get involved and file bugs to help make this product the
go-to tool for deploying any and all big software. :)

Thanks,
Ubuntu Solutions Engineering Team
Adam Stokes, Mike McCracken, Daniel Westervelt
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: A cautionary tale - mgo asserts

[Menno Smits]

On 8 June 2016 at 22:36, John Meinel  wrote:

> ...
>>
>
>
>>
>>   ops := []txn.Op{{
>>   C: "collection",
>>   Id: ...,
>>   Assert: bson.M{
>>   "some-field.A": "foo",
>>   "some-field.B": 99,
>>   },
>>   Update: ...
>>   }
>>
>> ...
>>
>>
> If loading into a bson.M is the problem, wouldn't using a bson.M to start
> with also be a problem?
>

No this is fine. The assert above defines that each field should match the
values given. Each field is checked separately - order doesn't matter.

This would be a problem though:

  ops := []txn.Op{{
  C: "collection",
  Id: ...,
  Assert: bson.M{"some-field": bson.M{
  "A": "foo",
  "B": 99,
  },
  Update: ...
  }

>
In this case, mgo is being asked to assert that some-field is an embedded
document equal to a document defined by the bson.M{"A": "foo", "B": 99}
map. This is what's happening now when you provide a struct value to
compare against a field because the struct gets round-tripped through
bson.M. That bson.M eventually gets converts to actual bson and sent to
mongodb but you have no control of the field ordering that will ultimately
be used.

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

Re: A cautionary tale - mgo asserts

[Menno Smits]

On 9 June 2016 at 03:44, Gustavo Niemeyer 
wrote:

> Is it mgo/txn that is internally unmarahalling onto that?
>
> Let's get that fixed at its heart.
>

That would be ideal. The root of the problem is that the Assert, Insert and
Update fields of txn.Op are of type interface{} and the bson unmarshalling
uses bson.M for these. This means when a transaction is loaded from the
txns collection the contents of these fields are loaded into bson.M and
field ordering is lost.

It looks trivial to change the bson unmarshalling code to default to bson.D
but naively changing this will likely break existing users of the bson
package. That's probably not the right solution here. Perhaps transactions
which are written to/loaded from the database by mgo/txn should use a
private txn.Op analogue where Assert, Insert and Update are bson.D instead
of interface{}?

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

Apache Bigtop Juju Charming Effort

[Cory Johns]

[NB: cross posted to Juju and Bigtop lists]

I wanted to introduce the wiki page that we, the Juju Big Software team,
created to coordinate the community effort to create Juju charms for the
various Apache Bigtop components:
https://github.com/juju-solutions/bigdata-community/wiki/Apache-Bigtop

We want to continue with the community the effort that was started when the
first set of charms, for Apache Hadoop, was accepted into the Apache Bigtop
project.  Bigtop comprises over 30 different components.  We have an idea
of which ones we think should be prioritized, but we want to get the
community involved in both setting those priorities as well as getting
these components charmed so that they can be easily deployed, scaled,
tested, and benchmarked across clouds, bare metal, and local dev
environments.

Please join us by choosing a component that you care about to start
creating a charm for.  We are more than happy to help you get started!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Displaying dashboard URL in juju status

[Rick Harding]

Yes, there's some discussions we've had around letting charms provide
helpful data such as what sub path a url would be on and such. Just
providing a link to the machine:open-port isn't often enough to get the
user directly where they need to be. This also would be best if it could
transfer through things like proxy charms where that information is
transformed as it goes through connections. We don't have it currently
scheduled but we agree with you and it's great to hear others would find
that useful as well.

On Wed, Jun 8, 2016 at 3:48 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> +1 for a feature like this! This would be really usefull for my
> port-forwarded charms and for all the big data dashboards such as zeppelin.
>
> Op woensdag 8 juni 2016 heeft Nobuto Murata 
> het volgende geschreven:
> > Hi,
> >
> > After an OpenStack deployment, its dashboard URL needs to be composed
> > like below in my head.
> >
> > [http or https if "ssl_cert" and "ssl_key" are set]://[unit's address
> > or "vip" if it's set]/[horizon or "webroot" if it's set]
> >
> > It's doable, but it would be nice if we could get the URL more
> > handily. Is there a good field in juju status to expose the URL?
> > OpenStack dashboard is the first thing in my mind, but it would also
> > be helpful for other charms having WebUI.
> >
> > Thanks,
> >
> > --
> > Nobuto Murata / 村田信人
> >
> > --
> > 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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Displaying dashboard URL in juju status

[Merlijn Sebrechts]

+1 for a feature like this! This would be really usefull for my
port-forwarded charms and for all the big data dashboards such as zeppelin.

Op woensdag 8 juni 2016 heeft Nobuto Murata  het
volgende geschreven:
> Hi,
>
> After an OpenStack deployment, its dashboard URL needs to be composed
> like below in my head.
>
> [http or https if "ssl_cert" and "ssl_key" are set]://[unit's address
> or "vip" if it's set]/[horizon or "webroot" if it's set]
>
> It's doable, but it would be nice if we could get the URL more
> handily. Is there a good field in juju status to expose the URL?
> OpenStack dashboard is the first thing in my mind, but it would also
> be helpful for other charms having WebUI.
>
> Thanks,
>
> --
> Nobuto Murata / 村田信人
>
> --
> 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: The CI build time continue to rise alarmingly

[Christian Muirhead]

Hi Torsten -

That fix shouldn't have increased build times unless we also changed the
test run to be against Mongo 3.2. If builds are still against 2.4 then the
change will have made them slightly faster (because we only drop and
recreate the database at the suite level).

I don't think we've switched runs to be against 3.2 because there were
other problems that were unrelated to the slow state tests - these two that
I know about:
https://bugs.launchpad.net/juju-core/+bug/1588784
https://bugs.launchpad.net/juju-core/+bug/1573286

Cheers,
Christian


On Wed, 8 Jun 2016, 16:06 Torsten Baumann, 
wrote:

> Hi David,
>
> Thanks for raising the inefficiency.
>
> From what I understand there was a change introduced in and around June
> 1st for https://bugs.launchpad.net/juju-core/+bug/1573294 that may have
> increased the time again. :-( As regrettable as this is we did review this
> with the tech board and it was accepted as part of the fix.
>
>
> I discussed with a few people and there is some time we can shave off on
> the tarball assembly (2-4 minutes) if we spent a few days work there.
>
> I also believe we can save time if we ran the tests in LXC containers but
> there may be some reliability issues there. we can always switch the jobs
> to use lxc and see what happens?
>
> Other than that I am open to seeing who else on this list has ideas as to
> what we can do to reduce the time? I would rather we go after the most
> important ones first if we can identify them.
>
> thanks everyone,
>
> Torsten
>
>
>
> -- Forwarded message --
> From: David Cheney 
> Date: Thu, Jun 2, 2016 at 9:49 PM
> Subject: The CI build time continue to rise alarmingly
> To: "juju-dev@lists.ubuntu.com" 
>
>
> CI build times are now an average of 36 minutes. That means in a
> typical 8 hour work day, assuming doing nothing other than landing
> branches, less than 16 commits can be landed.
>
> While bugs can be worked on and reviewed in parallel, landing is a
> sequential action that blocks everyone, and given the landing bot is
> batting less than 0.500, this limits the practical number of changes
> that can be landed in a day, a sprint, a iteration, or a development
> cycle.
>
> I cannot make it any clearer than this, the speed of CI limits the
> velocity of this team.
>
> Dave
>
> --
> 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: A cautionary tale - mgo asserts

[roger peppe]

On 8 June 2016 at 16:44, Gustavo Niemeyer
 wrote:
> Is it mgo/txn that is internally unmarahalling onto that?
>
> Let's get that fixed at its heart.

Yes, good plan.

> On Jun 8, 2016 12:27 PM, "roger peppe"  wrote:
>>
>> The Assert field in mgo/txn.Op is an interface{}, so
>> when it's marshaled and unmarshaled, the order
>> can change because unmarshaling unmarshals as bson.M
>> which does not preserve key order.
>>
>> https://play.golang.org/p/_1ZPl7iMyn
>>
>> On 8 June 2016 at 15:55, Gustavo Niemeyer
>>  wrote:
>> > Is it mgo itself that is changing the order internally?
>> >
>> > It should not do that.
>> >
>> > On Wed, Jun 8, 2016 at 8:00 AM, roger peppe  wrote:
>> >>
>> >> OK, I understand now, I think.
>> >>
>> >> The underlying problem is that subdocument searches in MongoDB
>> >> are order-sensitive.
>> >>
>> >> For example, I just tried this in a mongo shell:
>> >>
>> >> > db.foo.insert({_id: "one", x: {a: 1, b: 2}})
>> >> > db.foo.find({x: {a: 1, b: 2}})
>> >> { "_id" : "one", "x" : { "a" : 1, "b" : 2 } }
>> >> > db.foo.find({x: {b: 2, a: 1}})
>> >> >
>> >>
>> >> The second find doesn't return anything even though it contains
>> >> the same fields with the same values as the first.
>> >>
>> >> Urk. I did not know about that. What a gotcha!
>> >>
>> >> So it *could* technically be OK if the fields in the struct (and
>> >> any bson.D) are lexically ordered to match the bson Marshaler,
>> >> but well worth avoiding.
>> >>
>> >> I think things would be considerably improved if mgo/bson preserved
>> >> order by default (by using bson.D) when unmarshaling.
>> >> Then at least you'd know that the assertion you specify
>> >> is exactly the one that gets executed.
>> >>
>> >>   cheers,
>> >> rog.
>> >>
>> >>
>> >>
>> >>
>> >> On 8 June 2016 at 10:42, Menno Smits  wrote:
>> >> >
>> >> >
>> >> > On 8 June 2016 at 21:05, Tim Penhey  wrote:
>> >> >>
>> >> >> Hi folks,
>> >> >>
>> >> >> tl;dr: not use structs in transaction asserts
>> >> >>
>> >> >> ...
>> >> >>
>> >> >> The solution is to not use a field struct equality, even though it
>> >> >> is
>> >> >> easy
>> >> >> to write, but to use the dotted field notation to check the embedded
>> >> >> field
>> >> >> values.
>> >> >
>> >> >
>> >> >
>> >> > To give a more concrete example, asserting on a embedded document
>> >> > field
>> >> > like
>> >> > this is problematic:
>> >> >
>> >> >   ops := []txn.Op{{
>> >> >   C: "collection",
>> >> >   Id: ...,
>> >> >   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
>> >> >   Update: ...
>> >> >   }
>> >> >
>> >> > Due to the way mgo works[1], the document the transaction operation
>> >> > is
>> >> > asserting against may have been written with A and B in reverse
>> >> > order,
>> >> > or
>> >> > the Thing struct in the Assert may have A and B swapped by the time
>> >> > it's
>> >> > used. Either way, the assertion will fail randomly.
>> >> >
>> >> > The correct approach is to express the assertion like this:
>> >> >
>> >> >   ops := []txn.Op{{
>> >> >   C: "collection",
>> >> >   Id: ...,
>> >> >   Assert: bson.D{
>> >> >   {"some-field.A", "foo"},
>> >> >   {"some-field.B", 99},
>> >> >   },
>> >> >   Update: ...
>> >> >   }
>> >> >
>> >> > or this:
>> >> >
>> >> >   ops := []txn.Op{{
>> >> >   C: "collection",
>> >> >   Id: ...,
>> >> >   Assert: bson.M{
>> >> >   "some-field.A": "foo",
>> >> >   "some-field.B": 99,
>> >> >   },
>> >> >   Update: ...
>> >> >   }
>> >> >
>> >> >>
>> >> >> Yet another thing to add to the list of things to check when doing
>> >> >> reviews.
>> >> >
>> >> >
>> >> > I think we can go a bit further and error on attempts to use structs
>> >> > for
>> >> > comparison in txn.Op asserts in Juju's txn layers in state. Just as
>> >> > we
>> >> > already do some munging and checking of database operations to ensure
>> >> > correct multi-model behaviour, we should be able to do this same for
>> >> > this
>> >> > issue and prevent it from happening again.
>> >> >
>> >> > - Menno
>> >> >
>> >> > [1] If transaction operations are loaded and used from the DB (more
>> >> > likely
>> >> > under load when multiple runners are acting concurrently), the
>> >> > Insert,
>> >> > Update and Assert fields are loaded as bson.M (this is what the bson
>> >> > Unmarshaller does for interface{} typed fields). Once this happens
>> >> > field
>> >> > ordering is lost.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > 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: A cautionary tale - mgo asserts

[Gustavo Niemeyer]

Is it mgo/txn that is internally unmarahalling onto that?

Let's get that fixed at its heart.
On Jun 8, 2016 12:27 PM, "roger peppe"  wrote:

> The Assert field in mgo/txn.Op is an interface{}, so
> when it's marshaled and unmarshaled, the order
> can change because unmarshaling unmarshals as bson.M
> which does not preserve key order.
>
> https://play.golang.org/p/_1ZPl7iMyn
>
> On 8 June 2016 at 15:55, Gustavo Niemeyer
>  wrote:
> > Is it mgo itself that is changing the order internally?
> >
> > It should not do that.
> >
> > On Wed, Jun 8, 2016 at 8:00 AM, roger peppe  wrote:
> >>
> >> OK, I understand now, I think.
> >>
> >> The underlying problem is that subdocument searches in MongoDB
> >> are order-sensitive.
> >>
> >> For example, I just tried this in a mongo shell:
> >>
> >> > db.foo.insert({_id: "one", x: {a: 1, b: 2}})
> >> > db.foo.find({x: {a: 1, b: 2}})
> >> { "_id" : "one", "x" : { "a" : 1, "b" : 2 } }
> >> > db.foo.find({x: {b: 2, a: 1}})
> >> >
> >>
> >> The second find doesn't return anything even though it contains
> >> the same fields with the same values as the first.
> >>
> >> Urk. I did not know about that. What a gotcha!
> >>
> >> So it *could* technically be OK if the fields in the struct (and
> >> any bson.D) are lexically ordered to match the bson Marshaler,
> >> but well worth avoiding.
> >>
> >> I think things would be considerably improved if mgo/bson preserved
> >> order by default (by using bson.D) when unmarshaling.
> >> Then at least you'd know that the assertion you specify
> >> is exactly the one that gets executed.
> >>
> >>   cheers,
> >> rog.
> >>
> >>
> >>
> >>
> >> On 8 June 2016 at 10:42, Menno Smits  wrote:
> >> >
> >> >
> >> > On 8 June 2016 at 21:05, Tim Penhey  wrote:
> >> >>
> >> >> Hi folks,
> >> >>
> >> >> tl;dr: not use structs in transaction asserts
> >> >>
> >> >> ...
> >> >>
> >> >> The solution is to not use a field struct equality, even though it is
> >> >> easy
> >> >> to write, but to use the dotted field notation to check the embedded
> >> >> field
> >> >> values.
> >> >
> >> >
> >> >
> >> > To give a more concrete example, asserting on a embedded document
> field
> >> > like
> >> > this is problematic:
> >> >
> >> >   ops := []txn.Op{{
> >> >   C: "collection",
> >> >   Id: ...,
> >> >   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
> >> >   Update: ...
> >> >   }
> >> >
> >> > Due to the way mgo works[1], the document the transaction operation is
> >> > asserting against may have been written with A and B in reverse order,
> >> > or
> >> > the Thing struct in the Assert may have A and B swapped by the time
> it's
> >> > used. Either way, the assertion will fail randomly.
> >> >
> >> > The correct approach is to express the assertion like this:
> >> >
> >> >   ops := []txn.Op{{
> >> >   C: "collection",
> >> >   Id: ...,
> >> >   Assert: bson.D{
> >> >   {"some-field.A", "foo"},
> >> >   {"some-field.B", 99},
> >> >   },
> >> >   Update: ...
> >> >   }
> >> >
> >> > or this:
> >> >
> >> >   ops := []txn.Op{{
> >> >   C: "collection",
> >> >   Id: ...,
> >> >   Assert: bson.M{
> >> >   "some-field.A": "foo",
> >> >   "some-field.B": 99,
> >> >   },
> >> >   Update: ...
> >> >   }
> >> >
> >> >>
> >> >> Yet another thing to add to the list of things to check when doing
> >> >> reviews.
> >> >
> >> >
> >> > I think we can go a bit further and error on attempts to use structs
> for
> >> > comparison in txn.Op asserts in Juju's txn layers in state. Just as we
> >> > already do some munging and checking of database operations to ensure
> >> > correct multi-model behaviour, we should be able to do this same for
> >> > this
> >> > issue and prevent it from happening again.
> >> >
> >> > - Menno
> >> >
> >> > [1] If transaction operations are loaded and used from the DB (more
> >> > likely
> >> > under load when multiple runners are acting concurrently), the Insert,
> >> > Update and Assert fields are loaded as bson.M (this is what the bson
> >> > Unmarshaller does for interface{} typed fields). Once this happens
> field
> >> > ordering is lost.
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >
> >
> >
> >
> > --
> > gustavo @ http://niemeyer.net
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A cautionary tale - mgo asserts

[roger peppe]

The Assert field in mgo/txn.Op is an interface{}, so
when it's marshaled and unmarshaled, the order
can change because unmarshaling unmarshals as bson.M
which does not preserve key order.

https://play.golang.org/p/_1ZPl7iMyn

On 8 June 2016 at 15:55, Gustavo Niemeyer
 wrote:
> Is it mgo itself that is changing the order internally?
>
> It should not do that.
>
> On Wed, Jun 8, 2016 at 8:00 AM, roger peppe  wrote:
>>
>> OK, I understand now, I think.
>>
>> The underlying problem is that subdocument searches in MongoDB
>> are order-sensitive.
>>
>> For example, I just tried this in a mongo shell:
>>
>> > db.foo.insert({_id: "one", x: {a: 1, b: 2}})
>> > db.foo.find({x: {a: 1, b: 2}})
>> { "_id" : "one", "x" : { "a" : 1, "b" : 2 } }
>> > db.foo.find({x: {b: 2, a: 1}})
>> >
>>
>> The second find doesn't return anything even though it contains
>> the same fields with the same values as the first.
>>
>> Urk. I did not know about that. What a gotcha!
>>
>> So it *could* technically be OK if the fields in the struct (and
>> any bson.D) are lexically ordered to match the bson Marshaler,
>> but well worth avoiding.
>>
>> I think things would be considerably improved if mgo/bson preserved
>> order by default (by using bson.D) when unmarshaling.
>> Then at least you'd know that the assertion you specify
>> is exactly the one that gets executed.
>>
>>   cheers,
>> rog.
>>
>>
>>
>>
>> On 8 June 2016 at 10:42, Menno Smits  wrote:
>> >
>> >
>> > On 8 June 2016 at 21:05, Tim Penhey  wrote:
>> >>
>> >> Hi folks,
>> >>
>> >> tl;dr: not use structs in transaction asserts
>> >>
>> >> ...
>> >>
>> >> The solution is to not use a field struct equality, even though it is
>> >> easy
>> >> to write, but to use the dotted field notation to check the embedded
>> >> field
>> >> values.
>> >
>> >
>> >
>> > To give a more concrete example, asserting on a embedded document field
>> > like
>> > this is problematic:
>> >
>> >   ops := []txn.Op{{
>> >   C: "collection",
>> >   Id: ...,
>> >   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
>> >   Update: ...
>> >   }
>> >
>> > Due to the way mgo works[1], the document the transaction operation is
>> > asserting against may have been written with A and B in reverse order,
>> > or
>> > the Thing struct in the Assert may have A and B swapped by the time it's
>> > used. Either way, the assertion will fail randomly.
>> >
>> > The correct approach is to express the assertion like this:
>> >
>> >   ops := []txn.Op{{
>> >   C: "collection",
>> >   Id: ...,
>> >   Assert: bson.D{
>> >   {"some-field.A", "foo"},
>> >   {"some-field.B", 99},
>> >   },
>> >   Update: ...
>> >   }
>> >
>> > or this:
>> >
>> >   ops := []txn.Op{{
>> >   C: "collection",
>> >   Id: ...,
>> >   Assert: bson.M{
>> >   "some-field.A": "foo",
>> >   "some-field.B": 99,
>> >   },
>> >   Update: ...
>> >   }
>> >
>> >>
>> >> Yet another thing to add to the list of things to check when doing
>> >> reviews.
>> >
>> >
>> > I think we can go a bit further and error on attempts to use structs for
>> > comparison in txn.Op asserts in Juju's txn layers in state. Just as we
>> > already do some munging and checking of database operations to ensure
>> > correct multi-model behaviour, we should be able to do this same for
>> > this
>> > issue and prevent it from happening again.
>> >
>> > - Menno
>> >
>> > [1] If transaction operations are loaded and used from the DB (more
>> > likely
>> > under load when multiple runners are acting concurrently), the Insert,
>> > Update and Assert fields are loaded as bson.M (this is what the bson
>> > Unmarshaller does for interface{} typed fields). Once this happens field
>> > ordering is lost.
>> >
>> >
>> >
>> >
>> > --
>> > 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
>
>
>
>
> --
> gustavo @ http://niemeyer.net

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

Re: The CI build time continue to rise alarmingly

[Torsten Baumann]

Hi David,

Thanks for raising the inefficiency.

>From what I understand there was a change introduced in and around June 1st
for https://bugs.launchpad.net/juju-core/+bug/1573294 that may have
increased the time again. :-( As regrettable as this is we did review this
with the tech board and it was accepted as part of the fix.


I discussed with a few people and there is some time we can shave off on
the tarball assembly (2-4 minutes) if we spent a few days work there.

I also believe we can save time if we ran the tests in LXC containers but
there may be some reliability issues there. we can always switch the jobs
to use lxc and see what happens?

Other than that I am open to seeing who else on this list has ideas as to
what we can do to reduce the time? I would rather we go after the most
important ones first if we can identify them.

thanks everyone,

Torsten



-- Forwarded message --
From: David Cheney 
Date: Thu, Jun 2, 2016 at 9:49 PM
Subject: The CI build time continue to rise alarmingly
To: "juju-dev@lists.ubuntu.com" 


CI build times are now an average of 36 minutes. That means in a
typical 8 hour work day, assuming doing nothing other than landing
branches, less than 16 commits can be landed.

While bugs can be worked on and reviewed in parallel, landing is a
sequential action that blocks everyone, and given the landing bot is
batting less than 0.500, this limits the practical number of changes
that can be landed in a day, a sprint, a iteration, or a development
cycle.

I cannot make it any clearer than this, the speed of CI limits the
velocity of this team.

Dave

--
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

Announcing the Juju Charmer Summit, 12-14 Sept

[Jorge O. Castro]

Hello everyone,

We are happy to announce our third Juju Charmer Summit! We've had a
large number of requests to hit the west coast of the US, so this time
we'll be in lovely Pasadena, California, 12-14 September:

http://summit.juju.solutions

As mentioned on the site, this free-to-attend event is concentrated on
teaching those new to charming, discussing the latest charm best
practices, and workshops for all things Juju and Charming. In addition
to the ~charmer community, we will also have representatives from the
Juju Core engineering team, designers, and field engineers supporting
massive Juju deployments.

In the past Antonio, Marco, and I have put together the schedule and
the ecosystem team give the talks. This time we're going to go with a
more traditional, open CFP process. This will allow the attendees to
shape the conference in a way that's more useful to attendees.

We've also set aside an entire room for ongoing workshops so that if
something in the main track doesn't interest you, you can spend more
time doing peer-peer training with a charmer - on real hardware -
instead of sitting through my talks :D

If you've never been to a summit I highly encourage you to come for a
few reasons:

a) Get bootstrapped writing a charm and learn advanced charm design
and authoring techniques, to accelerate your charms completion.
b) Dedicated track time to big software problems such as NFV,
OpenStack and Big Data
c) Learn from other users who are using Juju in production.
d) Stay ahead of upcoming new features and help shape the future of
Juju and Charming.
e) Face to face, hands on, workshop time with Juju and Charm experts.

As usual if you have any questions feel free to reach out to me, and
like before, we do have a limited number of sponsorships for those who
need assistance to attend, so ping me offlist if you’re interested in
that.

-- 
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: A cautionary tale - mgo asserts

[Gustavo Niemeyer]

Is it mgo itself that is changing the order internally?

It should not do that.

On Wed, Jun 8, 2016 at 8:00 AM, roger peppe  wrote:

> OK, I understand now, I think.
>
> The underlying problem is that subdocument searches in MongoDB
> are order-sensitive.
>
> For example, I just tried this in a mongo shell:
>
> > db.foo.insert({_id: "one", x: {a: 1, b: 2}})
> > db.foo.find({x: {a: 1, b: 2}})
> { "_id" : "one", "x" : { "a" : 1, "b" : 2 } }
> > db.foo.find({x: {b: 2, a: 1}})
> >
>
> The second find doesn't return anything even though it contains
> the same fields with the same values as the first.
>
> Urk. I did not know about that. What a gotcha!
>
> So it *could* technically be OK if the fields in the struct (and
> any bson.D) are lexically ordered to match the bson Marshaler,
> but well worth avoiding.
>
> I think things would be considerably improved if mgo/bson preserved
> order by default (by using bson.D) when unmarshaling.
> Then at least you'd know that the assertion you specify
> is exactly the one that gets executed.
>
>   cheers,
> rog.
>
>
>
>
> On 8 June 2016 at 10:42, Menno Smits  wrote:
> >
> >
> > On 8 June 2016 at 21:05, Tim Penhey  wrote:
> >>
> >> Hi folks,
> >>
> >> tl;dr: not use structs in transaction asserts
> >>
> >> ...
> >>
> >> The solution is to not use a field struct equality, even though it is
> easy
> >> to write, but to use the dotted field notation to check the embedded
> field
> >> values.
> >
> >
> >
> > To give a more concrete example, asserting on a embedded document field
> like
> > this is problematic:
> >
> >   ops := []txn.Op{{
> >   C: "collection",
> >   Id: ...,
> >   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
> >   Update: ...
> >   }
> >
> > Due to the way mgo works[1], the document the transaction operation is
> > asserting against may have been written with A and B in reverse order, or
> > the Thing struct in the Assert may have A and B swapped by the time it's
> > used. Either way, the assertion will fail randomly.
> >
> > The correct approach is to express the assertion like this:
> >
> >   ops := []txn.Op{{
> >   C: "collection",
> >   Id: ...,
> >   Assert: bson.D{
> >   {"some-field.A", "foo"},
> >   {"some-field.B", 99},
> >   },
> >   Update: ...
> >   }
> >
> > or this:
> >
> >   ops := []txn.Op{{
> >   C: "collection",
> >   Id: ...,
> >   Assert: bson.M{
> >   "some-field.A": "foo",
> >   "some-field.B": 99,
> >   },
> >   Update: ...
> >   }
> >
> >>
> >> Yet another thing to add to the list of things to check when doing
> >> reviews.
> >
> >
> > I think we can go a bit further and error on attempts to use structs for
> > comparison in txn.Op asserts in Juju's txn layers in state. Just as we
> > already do some munging and checking of database operations to ensure
> > correct multi-model behaviour, we should be able to do this same for this
> > issue and prevent it from happening again.
> >
> > - Menno
> >
> > [1] If transaction operations are loaded and used from the DB (more
> likely
> > under load when multiple runners are acting concurrently), the Insert,
> > Update and Assert fields are loaded as bson.M (this is what the bson
> > Unmarshaller does for interface{} typed fields). Once this happens field
> > ordering is lost.
> >
> >
> >
> >
> > --
> > 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
>



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

Re: Juju coming to a DevOpsDays near you

[Greg Mason]

On Tue, 7 Jun 2016 09:35:38 -0400
"Jorge O. Castro"  wrote:
> 
> And just another friendly reminder to the list that we do have a
> sponsorship budget for these events, so if you have a talk about how
> you're using Juju in your field is accepted at a conference please get
> in touch with me, thanks!

Hi Jorge,

I'm in Lansing, so I'm definitely interested in helping out in Detroit. I'm not 
sure what all I can give a talk on yet, but I'm happy to speak with folks as to 
how Canonical is using Juju in production, CI, etc.

-Greg

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

Re: Model config

[Ian Booth]

On 08/06/16 23:59, roger peppe wrote:
> On 8 June 2016 at 10:41, Andrew Wilkins  wrote:
>> Hi folks,
>>
>> We're in the midst of making some changes to model configuration in Juju
>> 2.0, separating out things that are not model specific from those that are.
>> For many things this is very clear-cut, and for other things not so much.
>>
>> For example, api-port and state-port are controller-specific, so we'll be
>> moving them from model config to a new controller config collection. The end
>> goal is that you'll no longer see those when you type "juju
>> get-model-config" (there will be a separate command to get controller
>> attributes such as these), though we're not quite there yet.
> 
> Interesting - seems like a good change.
> 
> Will this change the internal and API representations too, so there
> are two groups
> of mutually-exclusive attributes? Does this also mean that the

Internally there will be three groups of mutually exclusive attributes:
- controller
- cloud
- model

Initially, we'll maintain internal API compatibility by combining all these to
produce the result of state.ModelConfig()

We'll then be able to consider things like config inheritance / overrides etc.
eg if cloud config (specified in the clouds.yaml file) defines an apt-mirror,
should we allow a model to also have that value, which will take precedence over
the cloud value.

> really-not-very-nice
> ConfigSkeleton API method will go too?
> 

I hope so. But we're rushing to get everything done for beta9 and are focusing
first on the data model since it will be harder to upgrade if that's not right
first up.

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

Re: Regarding Synnefo environment provider for Juju

[Alexis Bruemmer]

Thodoris,

Also feel free to join #juju-dev on freenode (IRC) for dynamic assistance.
You can reach out to me directly (alexisb) and I will ensure someone
provides some help.

We look forward to working with you on getting a Juju provider for Synnefo!

Alexis

On Wed, Jun 8, 2016 at 4:28 AM, Thodoris Sotiropoulos <
theo...@admin.grnet.gr> wrote:

> Hi all,
>
> You may remember previous e-mails sent by my partner Stavros Sachtouris
> regarding
> the case of implementing a Juju environment provider for our open source
> IaaS called
> Synnefo.
>
> We have started implementation of the basics (configuration schema,
> instance creation,
> instance queries, preparation of environment, etc). Our goal is to make a
> proof
> of concept implementation of the bootstrap command and that's why we have
> ignored
> networking and storage configuration, a.k.a mocked.
>
> So far, we have managed to create and communicate with a machine instance.
> However,
> during the last step of bootstrap process (insertion of the admin model to
> database)
> we are facing an unexpected problem (method `NewModel` of
> `state/model.go`).
>
> Here is the corresponding log file:
> https://pithos.okeanos.grnet.gr/public/8EHM5jpEm2W7bSwly9wFG
>
> I tried to investigate the problem but I cannot figure out why I get the
> `model %s for %q already exists`. What am I missing? I would appreciate any
> help or guidance.»
>
> Thank you in advance
>
> Thodoris Sotiropoulos
> Developer @ GRNET
> theo...@grnet.gr
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>



-- 
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

Re: Model config

[roger peppe]

On 8 June 2016 at 10:41, Andrew Wilkins  wrote:
> Hi folks,
>
> We're in the midst of making some changes to model configuration in Juju
> 2.0, separating out things that are not model specific from those that are.
> For many things this is very clear-cut, and for other things not so much.
>
> For example, api-port and state-port are controller-specific, so we'll be
> moving them from model config to a new controller config collection. The end
> goal is that you'll no longer see those when you type "juju
> get-model-config" (there will be a separate command to get controller
> attributes such as these), though we're not quite there yet.

Interesting - seems like a good change.

Will this change the internal and API representations too, so there
are two groups
of mutually-exclusive attributes? Does this also mean that the
really-not-very-nice
ConfigSkeleton API method will go too?

  cheers,
rog.

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

issue for other charms after installing mariadb 5.5

[Rajith P Venkata]

Hi

Thanks for below information, after deploying Mariadb 5.5 , we are not 
able to add any new charm we are getting  below error if we deploy any 
charm after Mariadb 5.5 charm.

http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/dists/trusty/InRelease 
Unable to find expected entry 'main/binary-ppc64el/Packages' in Release 
file (Wrong sources.list entry or malformed file)

As a workaround I  had tried to comment the below url, in 
/etc/apt/sources.list, which helped to proceed with my charm.
deb http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu trusty main

and in sources.list we have below url commented: 
# deb-src http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu trusty main

please help us in fixing this issue.

Rajith

IBM AIX Certified, OCPCertified


Cell- 9901966577
Email: rajith...@in.ibm.com



From:   Daniel Bartholomew 
To: Rajith P Venkata/India/IBM@IBMIN
Cc: juju 
Date:   03-06-16 10:55 PM
Subject:Re: error with mariadb



On Fri, Jun 3, 2016 at 6:18 AM, Rajith P Venkata  
wrote:
> I am trying to use  Mariadb 5.5 on  Ubuntu 14.x on Power 8 Little Endian
> with this we are getting error as unexpected token,
> Token I have used form https://mariadb.com/my_portal
>
> With verision Mariadb 10.05 we do not get this error but the plugin we 
are
> installing needs Mariadb 5.5.
>
> Please refer the logs below and let us know if Mariadb 5.5 works on 
Ubuntu
> 14.x on Power 8 Little Endian

MariaDB 5.5 does work on Ubuntu 14.x on Power 8 Little Endian.
However, after looking at the logs, I'm not sure what your error is.

In the unit-mariadb-5.log file, I see one error where something is
trying to connect to MariaDB when MariaDB isn't running, but I'm not
sure exactly what is trying to connect. A few lines further down in
the log MariaDB is started again, so if whatever was trying to access
MariaDB had waited a few seconds I would assume the connection attempt
would have succeeded. During installation and upgrades MariaDB is
stopped and started at various points as needed to apply updates to
internal system tables and other tasks.

In the unit-ibm-platform-rtm-4.log I see that line 203 of the
ibm-prtm.sh script has a syntax error, but I don't know anything about
that script that would enable me to comment further. I also see that
the script runs a ibm-prtm-mariadb.available test several times, but
again I don't know anything about that test or what it is checking
for.

I don't know if it will help you or not, but I recently pushed some
updates to my personal launchpad tree -
lp:~dbart/charms/trusty/mariadb/trunk - that sets the MariaDB charm to
use the MariaDB Foundation repositories by default if the MariaDB Inc
EULA and token are not provided as specified in the README. This new
version of the charm is not in the charm store yet, but hopefully it
will be soon.

I can confirm that the MariaDB Foundation repositories do have
packages for MariaDB 5.5 for Trusty on Power 8 Little Endian. The only
caveat I would add is that you'll get much better performance on Power
8 using MariaDB 10.0 or 10.1.


Also, the choice of which series to use should be changed using a
local config.yaml file with the series variable set to one of "5.5",
"10.0", or "10.1" (the default in the charm store is currently 10.0,
but my new update bumps the default up to 10.1). For example:

mariadb:
series: "5.5"

When using my repository locally I can then deploy MariaDB 5.5 with:
juju deploy --config ./mariadb.yaml
--repository="/home/${USER}/src/charms/" local:trusty/mariadb


And FYI, using something like:

juju set mariadb series="5.5"

...after the initial deployment to downgrade MariaDB from the default
series to 5.5 does not work. It has to be set using a yaml file as
described above and used during the initial deployment. Using the set
command to upgrade MariaDB, from say 5.5 to 10.0, does work, it's just
downgrades that don't work.

I'm not sure if any of the above will be of help, but hopefully some
of it will. If you have additional questions or comments, please let
me know.

Thanks.

-- 
Daniel Bartholomew, MariaDB Release Manager
MariaDB | http://mariadb.com





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

Re: Regarding Synnefo environment provider for Juju

[Katherine Cox-Buday]

Hey Thodoris,

Congratulations on beginning your provider! :)

Do you have your code visible anywhere? It would help with diagnosing any 
issues.

-
Katherine

Thodoris Sotiropoulos  writes:

> Hi all,
>
> You may remember previous e-mails sent by my partner Stavros
> Sachtouris regarding the case of implementing a Juju environment
> provider for our open source IaaS called Synnefo.
>
> We have started implementation of the basics (configuration schema,
> instance creation, instance queries, preparation of environment,
> etc). Our goal is to make a proof of concept implementation of the
> bootstrap command and that's why we have ignored networking and
> storage configuration, a.k.a mocked.
>
> So far, we have managed to create and communicate with a machine
> instance. However, during the last step of bootstrap process
> (insertion of the admin model to database) we are facing an unexpected
> problem (method `NewModel` of `state/model.go`).
>
> Here is the corresponding log file:
> https://pithos.okeanos.grnet.gr/public/8EHM5jpEm2W7bSwly9wFG
>
> I tried to investigate the problem but I cannot figure out why I get
> the `model %s for %q already exists`. What am I missing? I would
> appreciate any help or guidance.»
>
> Thank you in advance
>
> Thodoris Sotiropoulos Developer @ GRNET theo...@grnet.gr

-- 
Katherine

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

Re: Model config

[Mark Shuttleworth]

On 08/06/16 22:05, Rick Harding wrote:
> The danger I think we've tried to avoid with the get/set is that if
> you have just model-config you can accidentally mutate the state by
> messing up your arguments you pass in via scripts/etc. It also keeps
> it consistent across the read/write across the many things that can
> change now, applications, models, controller, etc. 
>

I guess it also allows permission checks to happen once up front and not
in the middle of command processing.

Mark

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

Re: Model config

[Rick Harding]

The danger I think we've tried to avoid with the get/set is that if you
have just model-config you can accidentally mutate the state by messing up
your arguments you pass in via scripts/etc. It also keeps it consistent
across the read/write across the many things that can change now,
applications, models, controller, etc.

On Wed, Jun 8, 2016 at 9:02 AM Mark Shuttleworth  wrote:

>
>  juju set-model-defaults
>  juju set-model-config
>  juju set-controller-config
>
> Have we a strong preference for get/set names, or could we just use
> "model-config" and "model-defaults" as read/write commands?
>
>
> Mark
>
>
> On 08/06/16 18:41, Andrew Wilkins wrote:
>
> Hi folks,
>
> We're in the midst of making some changes to model configuration in Juju
> 2.0, separating out things that are not model specific from those that are. 
> For
> many things this is very clear-cut, and for other things not so much.
>
> For example, api-port and state-port are controller-specific, so we'll be
> moving them from model config to a new controller config collection. The
> end goal is that you'll no longer see those when you type "juju
> get-model-config" (there will be a separate command to get controller
> attributes such as these), though we're not quite there yet.
>
> We also think there are some attributes that people will want to set
> across all models, but are not necessarily related to the *controller*. For
> example, http-proxy, apt-http-proxy, and their siblings. I expect that if
> anyone is setting these particular attributes, they are doing so for *all*
> models, as they're operating within a private cloud with limited network
> access.
>
> Does anyone have a real, uncontrived use-case for configuring proxy
> settings on a per-model basis?
>
> Cheers,
> Andrew
>
>
>
> --
> 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: Model config

[Mark Shuttleworth]

 juju set-model-defaults
 juju set-model-config
 juju set-controller-config

Have we a strong preference for get/set names, or could we just use
"model-config" and "model-defaults" as read/write commands?

Mark
 
On 08/06/16 18:41, Andrew Wilkins wrote:
> Hi folks,
>
> We're in the midst of making some changes to model configuration in
> Juju 2.0, separating out things that are not model specific from those
> that are. For many things this is very clear-cut, and for other things
> not so much.
>
> For example, api-port and state-port are controller-specific, so we'll
> be moving them from model config to a new controller config
> collection. The end goal is that you'll no longer see those when you
> type "juju get-model-config" (there will be a separate command to get
> controller attributes such as these), though we're not quite there yet.
>
> We also think there are some attributes that people will want to set
> across all models, but are not necessarily related to the
> *controller*. For example, http-proxy, apt-http-proxy, and their
> siblings. I expect that if anyone is setting these particular
> attributes, they are doing so for *all* models, as they're operating
> within a private cloud with limited network access.
>
> Does anyone have a real, uncontrived use-case for configuring proxy
> settings on a per-model basis?
>
> Cheers,
> Andrew
>
>

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

Regarding Synnefo environment provider for Juju

[Thodoris Sotiropoulos]

Hi all,

You may remember previous e-mails sent by my partner Stavros Sachtouris 
regarding
the case of implementing a Juju environment provider for our open source 
IaaS called

Synnefo.

We have started implementation of the basics (configuration schema, 
instance creation,
instance queries, preparation of environment, etc). Our goal is to make 
a proof
of concept implementation of the bootstrap command and that's why we 
have ignored

networking and storage configuration, a.k.a mocked.

So far, we have managed to create and communicate with a machine 
instance. However,
during the last step of bootstrap process (insertion of the admin model 
to database)
we are facing an unexpected problem (method `NewModel` of 
`state/model.go`).


Here is the corresponding log file:
https://pithos.okeanos.grnet.gr/public/8EHM5jpEm2W7bSwly9wFG

I tried to investigate the problem but I cannot figure out why I get the
`model %s for %q already exists`. What am I missing? I would appreciate any
help or guidance.»

Thank you in advance

Thodoris Sotiropoulos
Developer @ GRNET
theo...@grnet.gr

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

Re: A cautionary tale - mgo asserts

[David Cheney]

You had me at "ruins mongodb", actually just "ruins'.

On Wed, Jun 8, 2016 at 9:04 PM, roger peppe  wrote:
> This is also relevant (but probably only for larger documents):
>
> https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/
>
> Another reason to avoid entire-subdocument matches.
>
> On 8 June 2016 at 10:42, Menno Smits  wrote:
>>
>>
>> On 8 June 2016 at 21:05, Tim Penhey  wrote:
>>>
>>> Hi folks,
>>>
>>> tl;dr: not use structs in transaction asserts
>>>
>>> ...
>>>
>>> The solution is to not use a field struct equality, even though it is easy
>>> to write, but to use the dotted field notation to check the embedded field
>>> values.
>>
>>
>>
>> To give a more concrete example, asserting on a embedded document field like
>> this is problematic:
>>
>>   ops := []txn.Op{{
>>   C: "collection",
>>   Id: ...,
>>   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
>>   Update: ...
>>   }
>>
>> Due to the way mgo works[1], the document the transaction operation is
>> asserting against may have been written with A and B in reverse order, or
>> the Thing struct in the Assert may have A and B swapped by the time it's
>> used. Either way, the assertion will fail randomly.
>>
>> The correct approach is to express the assertion like this:
>>
>>   ops := []txn.Op{{
>>   C: "collection",
>>   Id: ...,
>>   Assert: bson.D{
>>   {"some-field.A", "foo"},
>>   {"some-field.B", 99},
>>   },
>>   Update: ...
>>   }
>>
>> or this:
>>
>>   ops := []txn.Op{{
>>   C: "collection",
>>   Id: ...,
>>   Assert: bson.M{
>>   "some-field.A": "foo",
>>   "some-field.B": 99,
>>   },
>>   Update: ...
>>   }
>>
>>>
>>> Yet another thing to add to the list of things to check when doing
>>> reviews.
>>
>>
>> I think we can go a bit further and error on attempts to use structs for
>> comparison in txn.Op asserts in Juju's txn layers in state. Just as we
>> already do some munging and checking of database operations to ensure
>> correct multi-model behaviour, we should be able to do this same for this
>> issue and prevent it from happening again.
>>
>> - Menno
>>
>> [1] If transaction operations are loaded and used from the DB (more likely
>> under load when multiple runners are acting concurrently), the Insert,
>> Update and Assert fields are loaded as bson.M (this is what the bson
>> Unmarshaller does for interface{} typed fields). Once this happens field
>> ordering is lost.
>>
>>
>>
>>
>> --
>> 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: A cautionary tale - mgo asserts

[roger peppe]

This is also relevant (but probably only for larger documents):

https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/

Another reason to avoid entire-subdocument matches.

On 8 June 2016 at 10:42, Menno Smits  wrote:
>
>
> On 8 June 2016 at 21:05, Tim Penhey  wrote:
>>
>> Hi folks,
>>
>> tl;dr: not use structs in transaction asserts
>>
>> ...
>>
>> The solution is to not use a field struct equality, even though it is easy
>> to write, but to use the dotted field notation to check the embedded field
>> values.
>
>
>
> To give a more concrete example, asserting on a embedded document field like
> this is problematic:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
>   Update: ...
>   }
>
> Due to the way mgo works[1], the document the transaction operation is
> asserting against may have been written with A and B in reverse order, or
> the Thing struct in the Assert may have A and B swapped by the time it's
> used. Either way, the assertion will fail randomly.
>
> The correct approach is to express the assertion like this:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.D{
>   {"some-field.A", "foo"},
>   {"some-field.B", 99},
>   },
>   Update: ...
>   }
>
> or this:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.M{
>   "some-field.A": "foo",
>   "some-field.B": 99,
>   },
>   Update: ...
>   }
>
>>
>> Yet another thing to add to the list of things to check when doing
>> reviews.
>
>
> I think we can go a bit further and error on attempts to use structs for
> comparison in txn.Op asserts in Juju's txn layers in state. Just as we
> already do some munging and checking of database operations to ensure
> correct multi-model behaviour, we should be able to do this same for this
> issue and prevent it from happening again.
>
> - Menno
>
> [1] If transaction operations are loaded and used from the DB (more likely
> under load when multiple runners are acting concurrently), the Insert,
> Update and Assert fields are loaded as bson.M (this is what the bson
> Unmarshaller does for interface{} typed fields). Once this happens field
> ordering is lost.
>
>
>
>
> --
> 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: A cautionary tale - mgo asserts

[roger peppe]

OK, I understand now, I think.

The underlying problem is that subdocument searches in MongoDB
are order-sensitive.

For example, I just tried this in a mongo shell:

> db.foo.insert({_id: "one", x: {a: 1, b: 2}})
> db.foo.find({x: {a: 1, b: 2}})
{ "_id" : "one", "x" : { "a" : 1, "b" : 2 } }
> db.foo.find({x: {b: 2, a: 1}})
>

The second find doesn't return anything even though it contains
the same fields with the same values as the first.

Urk. I did not know about that. What a gotcha!

So it *could* technically be OK if the fields in the struct (and
any bson.D) are lexically ordered to match the bson Marshaler,
but well worth avoiding.

I think things would be considerably improved if mgo/bson preserved
order by default (by using bson.D) when unmarshaling.
Then at least you'd know that the assertion you specify
is exactly the one that gets executed.

  cheers,
rog.

On 8 June 2016 at 10:42, Menno Smits  wrote:
>
>
> On 8 June 2016 at 21:05, Tim Penhey  wrote:
>>
>> Hi folks,
>>
>> tl;dr: not use structs in transaction asserts
>>
>> ...
>>
>> The solution is to not use a field struct equality, even though it is easy
>> to write, but to use the dotted field notation to check the embedded field
>> values.
>
>
>
> To give a more concrete example, asserting on a embedded document field like
> this is problematic:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
>   Update: ...
>   }
>
> Due to the way mgo works[1], the document the transaction operation is
> asserting against may have been written with A and B in reverse order, or
> the Thing struct in the Assert may have A and B swapped by the time it's
> used. Either way, the assertion will fail randomly.
>
> The correct approach is to express the assertion like this:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.D{
>   {"some-field.A", "foo"},
>   {"some-field.B", 99},
>   },
>   Update: ...
>   }
>
> or this:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.M{
>   "some-field.A": "foo",
>   "some-field.B": 99,
>   },
>   Update: ...
>   }
>
>>
>> Yet another thing to add to the list of things to check when doing
>> reviews.
>
>
> I think we can go a bit further and error on attempts to use structs for
> comparison in txn.Op asserts in Juju's txn layers in state. Just as we
> already do some munging and checking of database operations to ensure
> correct multi-model behaviour, we should be able to do this same for this
> issue and prevent it from happening again.
>
> - Menno
>
> [1] If transaction operations are loaded and used from the DB (more likely
> under load when multiple runners are acting concurrently), the Insert,
> Update and Assert fields are loaded as bson.M (this is what the bson
> Unmarshaller does for interface{} typed fields). Once this happens field
> ordering is lost.
>
>
>
>
> --
> 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: A cautionary tale - mgo asserts

[roger peppe]

OK, I understand now, I think.

The underlying problem is that subdocument searches in MongoDB
are order-sensitive.

For example, I just tried this in a mongo shell:

> db.foo.insert({_id: "one", x: {a: 1, b: 2}})
> db.foo.find({x: {a: 1, b: 2}})
{ "_id" : "one", "x" : { "a" : 1, "b" : 2 } }
> db.foo.find({x: {b: 2, a: 1}})
>

The second find doesn't return anything even though it contains
the same fields with the same values as the first.

Urk. I did not know about that. What a gotcha!

So it *could* technically be OK if the fields in the struct (and
any bson.D) are lexically ordered to match the bson Marshaler,
but well worth avoiding.

I think things would be considerably improved if mgo/bson preserved
order by default (by using bson.D) when unmarshaling.
Then at least you'd know that the assertion you specify
is exactly the one that gets executed.

  cheers,
rog.




On 8 June 2016 at 10:42, Menno Smits  wrote:
>
>
> On 8 June 2016 at 21:05, Tim Penhey  wrote:
>>
>> Hi folks,
>>
>> tl;dr: not use structs in transaction asserts
>>
>> ...
>>
>> The solution is to not use a field struct equality, even though it is easy
>> to write, but to use the dotted field notation to check the embedded field
>> values.
>
>
>
> To give a more concrete example, asserting on a embedded document field like
> this is problematic:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
>   Update: ...
>   }
>
> Due to the way mgo works[1], the document the transaction operation is
> asserting against may have been written with A and B in reverse order, or
> the Thing struct in the Assert may have A and B swapped by the time it's
> used. Either way, the assertion will fail randomly.
>
> The correct approach is to express the assertion like this:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.D{
>   {"some-field.A", "foo"},
>   {"some-field.B", 99},
>   },
>   Update: ...
>   }
>
> or this:
>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.M{
>   "some-field.A": "foo",
>   "some-field.B": 99,
>   },
>   Update: ...
>   }
>
>>
>> Yet another thing to add to the list of things to check when doing
>> reviews.
>
>
> I think we can go a bit further and error on attempts to use structs for
> comparison in txn.Op asserts in Juju's txn layers in state. Just as we
> already do some munging and checking of database operations to ensure
> correct multi-model behaviour, we should be able to do this same for this
> issue and prevent it from happening again.
>
> - Menno
>
> [1] If transaction operations are loaded and used from the DB (more likely
> under load when multiple runners are acting concurrently), the Insert,
> Update and Assert fields are loaded as bson.M (this is what the bson
> Unmarshaller does for interface{} typed fields). Once this happens field
> ordering is lost.
>
>
>
>
> --
> 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: Model config

[Nicolas Thomas ]

Hello all,

I am testing/validating with apt-mirror atm. Doing so my expectation
would be to set this at the controller level and have the capacity to
override per model (or user).

Why ? response staging.

People taking the burden of managing mirrors do so to control their
environment. Which means they will need to test an update before
committing to prod. This is the reason there is a
transactionnal/staging in https://launchpad.net/ubuntu-cloud-mirrors
which the way I manage the mirrors themselves.

Hope this helps,


On Wed, Jun 8, 2016 at 11:41 AM, Andrew Wilkins
 wrote:
> Hi folks,
>
> We're in the midst of making some changes to model configuration in Juju
> 2.0, separating out things that are not model specific from those that are.
> For many things this is very clear-cut, and for other things not so much.
>
> For example, api-port and state-port are controller-specific, so we'll be
> moving them from model config to a new controller config collection. The end
> goal is that you'll no longer see those when you type "juju
> get-model-config" (there will be a separate command to get controller
> attributes such as these), though we're not quite there yet.
>
> We also think there are some attributes that people will want to set across
> all models, but are not necessarily related to the *controller*. For
> example, http-proxy, apt-http-proxy, and their siblings. I expect that if
> anyone is setting these particular attributes, they are doing so for *all*
> models, as they're operating within a private cloud with limited network
> access.
>
> Does anyone have a real, uncontrived use-case for configuring proxy settings
> on a per-model basis?
>
> Cheers,
> Andrew
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Best Regards,
   Nicolas Thomas
http://insights.ubuntu.com/?p=889
EMEA Solution Architect  Canonical
GPG FPR: D592 4185 F099 9031 6590 6292 492F C740 F03A 7EB9

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

Re: A cautionary tale - mgo asserts

[John Meinel]

>
> ...
>


>
>   ops := []txn.Op{{
>   C: "collection",
>   Id: ...,
>   Assert: bson.M{
>   "some-field.A": "foo",
>   "some-field.B": 99,
>   },
>   Update: ...
>   }
>
> ...
>
>

> [1] If transaction operations are loaded and used from the DB (more likely
> under load when multiple runners are acting concurrently), the Insert,
> Update and Assert fields are loaded as bson.M (this is what the bson
> Unmarshaller does for interface{} typed fields). Once this happens field
> ordering is lost.
>
> If loading into a bson.M is the problem, wouldn't using a bson.M to start
with also be a problem?

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

Re: A cautionary tale - mgo asserts

[Menno Smits]

On 8 June 2016 at 21:05, Tim Penhey  wrote:

> Hi folks,
>
> tl;dr: not use structs in transaction asserts
>
> ...
>
> The solution is to not use a field struct equality, even though it is easy
> to write, but to use the dotted field notation to check the embedded field
> values.
>


To give a more concrete example, asserting on a embedded document field
like this is problematic:

  ops := []txn.Op{{
  C: "collection",
  Id: ...,
  Assert: bson.D{{"some-field", Thing{A: "foo", B: 99}}},
  Update: ...
  }

Due to the way mgo works[1], the document the transaction operation is
asserting against may have been written with A and B in reverse order, or
the Thing struct in the Assert may have A and B swapped by the time it's
used. Either way, the assertion will fail randomly.

The correct approach is to express the assertion like this:

  ops := []txn.Op{{
  C: "collection",
  Id: ...,
  Assert: bson.D{
  {"some-field.A", "foo"},
  {"some-field.B", 99},
  },
  Update: ...
  }

or this:

  ops := []txn.Op{{
  C: "collection",
  Id: ...,
  Assert: bson.M{
  "some-field.A": "foo",
  "some-field.B": 99,
  },
  Update: ...
  }


> Yet another thing to add to the list of things to check when doing reviews.


I think we can go a bit further and error on attempts to use structs for
comparison in txn.Op asserts in Juju's txn layers in state. Just as we
already do some munging and checking of database operations to ensure
correct multi-model behaviour, we should be able to do this same for this
issue and prevent it from happening again.

- Menno

[1] If transaction operations are loaded and used from the DB (more likely
under load when multiple runners are acting concurrently), the Insert,
Update and Assert fields are loaded as bson.M (this is what the bson
Unmarshaller does for interface{} typed fields). Once this happens field
ordering is lost.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Model config

[Andrew Wilkins]

Hi folks,

We're in the midst of making some changes to model configuration in Juju
2.0, separating out things that are not model specific from those that are. For
many things this is very clear-cut, and for other things not so much.

For example, api-port and state-port are controller-specific, so we'll be
moving them from model config to a new controller config collection. The
end goal is that you'll no longer see those when you type "juju
get-model-config" (there will be a separate command to get controller
attributes such as these), though we're not quite there yet.

We also think there are some attributes that people will want to set across
all models, but are not necessarily related to the *controller*. For
example, http-proxy, apt-http-proxy, and their siblings. I expect that if
anyone is setting these particular attributes, they are doing so for *all*
models, as they're operating within a private cloud with limited network
access.

Does anyone have a real, uncontrived use-case for configuring proxy
settings on a per-model basis?

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

Re: A cautionary tale - mgo asserts

[roger peppe]

On 8 June 2016 at 10:05, Tim Penhey  wrote:
> Hi folks,
>
> tl;dr: not use structs in transaction asserts
>
> I have spent the last two days looking at this bug:
> https://bugs.launchpad.net/juju-core/+bug/1537585
>
> It was one where the instance poller got itself in a knot, and couldn't get
> out. Transaction asserts were failing, and often hard to reproduce.
>
> Nate spent last week on it, and I pulled Menno in for his mgo expertise
> yesterday and today because I was getting stumped.
>
> Here is what was happening:
>
> The machine document was being read, and we were wanting to update the
> preferred public and private addresses. An assert was added to make sure
> that the value was either what we expected it to be (from reading the doc),
> or unset. Now, really, it wouldn't be unset, but that is a different story.
>
> The problem is that the assert was failing. Logging was added to check what
> the db had, and what the asserts were transformed to with the multi model
> layer. All the asserts matched. The data was there, everything was good,
> except it wasn't.
>
> This morning, I pulled the data out with a bson.D, and it became readily
> apparent that the address structure ordering was different in the times it
> failed. Now normally we are guaranteed ordering. When the struct is
> marshalled to bson, it is as a bson.D with the order defined in by the order
> of the members.  However when using the struct in the assert, it was
> matching different orders, so the assert failed.

This is interesting and not something I was aware of. I had been under
the impression that bson.D could almost always be used interchangeably
with bson.M or structs and that key order wasn't relevant when comparing
objects.

Could you provide a simple example (preferably not involving mgo/txn)
where the results are different depending on member ordering?

  cheers,
rog.

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

Re: A cautionary tale - mgo asserts

[roger peppe]

On 8 June 2016 at 10:05, Tim Penhey  wrote:
> Hi folks,
>
> tl;dr: not use structs in transaction asserts
>
> I have spent the last two days looking at this bug:
> https://bugs.launchpad.net/juju-core/+bug/1537585
>
> It was one where the instance poller got itself in a knot, and couldn't get
> out. Transaction asserts were failing, and often hard to reproduce.
>
> Nate spent last week on it, and I pulled Menno in for his mgo expertise
> yesterday and today because I was getting stumped.
>
> Here is what was happening:
>
> The machine document was being read, and we were wanting to update the
> preferred public and private addresses. An assert was added to make sure
> that the value was either what we expected it to be (from reading the doc),
> or unset. Now, really, it wouldn't be unset, but that is a different story.
>
> The problem is that the assert was failing. Logging was added to check what
> the db had, and what the asserts were transformed to with the multi model
> layer. All the asserts matched. The data was there, everything was good,
> except it wasn't.
>
> This morning, I pulled the data out with a bson.D, and it became readily
> apparent that the address structure ordering was different in the times it
> failed. Now normally we are guaranteed ordering. When the struct is
> marshalled to bson, it is as a bson.D with the order defined in by the order
> of the members.  However when using the struct in the assert, it was
> matching different orders, so the assert failed.

This is interesting and not something I was aware of. I had been under
the impression that bson.D could almost always be used interchangeably
with bson.M or structs and that key order wasn't relevant when comparing
objects.

Could you provide a simple example (preferably not involving mgo/txn)
where the results are different depending on member ordering?

  cheers,
rog.

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

ceilometer charm issues.

[ed bond]

I originally opened a bug for not having a 5.0.3 version.

https://bugs.launchpad.net/charms/+source/ceilometer/+bug/1590257 


However it was recommended for me to use the proposed branch to test it out.

It doesn’t work, I am getting a timeout when horizon is trying to connect to 
ceilometer:
[Wed Jun 08 08:51:33.842764 2016] [:error] [pid 33907:tid 140299577837312] 
raise ConnectionError(err, request=request)
[Wed Jun 08 08:51:33.842769 2016] [:error] [pid 33907:tid 140299577837312] 
ConnectionError: ('Connection aborted.', BadStatusLine("''",))
[Wed Jun 08 08:51:33.842773 2016] [:error] [pid 33907:tid 140299577837312] 
[Wed Jun 08 08:51:44.504590 2016] [:error] [pid 33908:tid 140300790765312] 
Recoverable error: ('Connection aborted.', BadStatusLine("''",))



Does anyone have a bundle with versions that they use with ceilometer in a real 
world example?

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