Re: Blocking and unblocking merges

[John Meinel]

...


> > 3. How do merges get unblocked?
> >
> > Merges are unblocked when no bugs are returned with the above
> > criteria. The bugs should be updated only after the committed fix
> > has successfully passed the CI tests which discovered the
> > regression. This will most often mean setting the status to 'Fix
> > Released' when the solution involves code changes or removing the
> > regression and/or CI tag, if the issue is discovered to be a test
> > or CI issue.
>

Note that being "just a test issue" doesn't entirely excuse it, because it
means that the test suite will just fail again, and we won't have
visibility into real problems. (We get into a mode where we expect the test
suite to fail, and stop trusting it.)


> >
> >
> > 4, If the unblock process involves manual steps, whose
> > responsibility is it to perform those steps?
> >
> > The person or team that marked the bug as a regression is
> > responsible for updating the bug, once they are satisfied with the
> > fix. Most often this will be the Juju-QA team but if others
> > discover a regression they too should have the power to block
> > merges.
>
> The problem often is nobody from QA is around to ask for help in
> certain times during the day. So there should be at least a person in
> each team knowing how (and having permissions as well, if needed) to
> re-run jobs that are stuck, mark the bug as Fix Released once the CI
> job passes after the fix lands. Another REALLY NEEDED feature is to
> re-queue PRs set for merging but bounced due to a CI block. This
> wastes days sometimes, or at the very least hours.
>
>
One thing Tim mentioned was whether we could have the bot comment "I'm not
merging this now because of a CI failure", but leave the request in the
Queue, so it is automatically retried when the branch is unblocked. I'm not
sure if there is an efficiency/event problem (we got an event that the
$MERGE$ message was set, we wouldn't get another one unless someone pokes
the branch.) But it does seem possible.

John
=:->

>
> >
> > Based on experience and observation, I think I know how at least
> > some of this works but could we please have some authoritative
> > answers?
> >
> > Thanks, Menno
> >
> >
> >
> > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
> >  Modify settings or unsubscribe
> > at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
>
>
> - --
> Dimiter Naydenov 
> juju-core team
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUkkBzAAoJENzxV2TbLzHwflIH+wQM8s8oV2i7b1PzsDzh9Zyu
> DhfkyIhxFQxTJGsV8RamcTDkjWeDhRZKB49UPzMdqNJr0XG/KvVy1SyqICxJ5qoz
> uWnnrdumzUhF0k/hjsUEnOpNDBOnubUIoGHBVyyx6UEMRgW+G0pFTIhUQGqEPhhU
> 7YMqn/r3GpiSnkmnknB/U4yk9TEYViDBRuPzSmhJiSwBGqkpOW+ISkWstUgbqYO+
> o9KzxREWcvEDQ0+v0RLpaF2HsUWwktn7HL2BuoemhU4hoS5/ohD0VR5AemXwUyky
> ISEiqu4atjPcCxJts5UpPhhznBSVHFlOm4ROkH1ku+x671WZEZZXoUt4CjWbxvo=
> =l5mJ
> -END PGP SIGNATURE-
>
> --
> 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

Automatic multi-environment collection handling

[Menno Smits]

I've landed several big changes recently which automate handling of
multi-environment concerns when accessing Juju's collections. These both
simplify DB queries and updates as well as reducing the risk of unintended
data leakage between environments. Although in most cases you won't even
know that anything has changed, it's worth understanding what's been done.

*Collections*

MongoDB queries against collections which contain data for multiple
environments are now automatically modified to ensure they return records
for only the environment tied to State being queried against. Queries
against collections which do not contain data for multiple environments
pass through untouched.

Some examples ...

machines.FindId("2")
becomes
machines.FindId(":2").One(&doc)

machines.Find(bson.D{{"series", "trusty"}}}
becomes
machines.Find(bson.D{{"series", "trusty"}, {"env-uuid", ""}})

machines.Find(bson.D{{"_id", "4"}}}
becomes
machines.Find(bson.D{{"_id", ":4"}, {"env-uuid", ""}})

Where "" is the environment UUID of the State instance the collection
was obtained from (using getCollection()).

The Remove, RemoveId and RemoveAll methods on collections also have similar
handling and the collection Count method returns only the number of records
in the collection for a single environment.

The main benefit of this is that you don't need to remember to wrap ids in
State.docID() calls or remember to add the "env-uuid" field to queries. In
fact, I recommend you leave them out to reduce noise from code that does DB
queries.

There are some limited cases where you might really need to query across
multiple environments or don't want the automatic munging in place for some
reason. For these scenarios you can get hold of a *mgo.Collection by
calling State.getRawCollection(). This is currently only being used by a
few database migration steps.

Note that query selectors using MongoDB operators with the _id field will
be left untouched. In these cases you need to know that there's a UUID
prefix on the _id and handle it yourself. For example, to query all the
machines with ids starting with "4" you might consider doing:

machines.Find(bson.D{{"_id", bson.D{"$regex": "^4.*"
which is transformed to:
machines.Find(bson.D{{"_id", bson.D{"$regex": "^4.*", {"env-uuid",
""}})

Note how the _id selector is left alone but the env-uuid selector is still
added. It's left up to the developer to account for the environment UUID in
_id regex (the regex above won't work as is).


*Transactions*

Changes have also been made for automatically modifying transaction
operations to account for multi-environment collections.

For example:

st.runTransaction([]txn.Op{{
C: machinesC,
Id: "1"
Remove: true,
}, {
C: machinesC,
Id: "2",
Insert: bson.D{
{"series", "trusty"},
},
}, {
C: machinesC,
Id: "3",
Insert: &machineDoc{
Series: "trusty",
},
}, {
C: otherC,
Id: "foo",
Insert: bson.D{},
}})

automatically becomes:

st.runTransaction([]txn.Op{{
C: machinesC,
Id: ":1",
Remove: true,
}, {
C: machinesC,
Id: ":2",
Insert: bson.D{
{"_id", ":2"},
{"env-uuid", ""},
{"series", "trusty"},
},
}, {
C: machinesC,
Id: ":3",
Insert: &machineDoc{
DocID: ":3",
EnvUUID: "",
Series: "trusty",
}
}, {
C: otherC,
Id: "foo",
Insert: bson.D{},
}})

Note how the environment UUID is prefixed onto ids for operations for
multi-environment collections. Also see how the _id and env-uuid field on
documents defined using bson.D or structs (bson.M supported too) are
automatically populated. A panic will occur if you provide the environment
UUID but it doesn't match what was expected as this indicates a likely bug.

Any document updates are made in place so that the caller sees them once
the transaction completes. This makes it safe for the caller to a document
struct used with a transaction operation for further work - the struct will
match what was written to the DB. Note that if a struct is passed by value
and needs updating, a panic will occur. This won't normally be a problem as
we tend to use pointers to document structs with transaction operations,
and the panic is a helpful indication that the document provided isn't
multi-environment safe.

Note that only the Id and Insert fields of txn.Op are touched. The Update
and Assert fields are left alone.

In some cases you may need to run a transaction without invoking automatic
multi-environment munging. State now has a rawTxnRunner() and
runRawTransaction() methods for the rare situations where this is
necessary. Please use these sparingly.

*Performance*

With the extra work being done to implement automatic multi-environment
support, the performance impact was a concern. I have compared multiple
runs of the state package unit tests, with and without these changes and
the difference is lost in the noise.

If you see any problems or ha

Re: Blocking and unblocking merges

[Dimiter Naydenov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18.12.2014 04:20, John George wrote:
> On Wed, Dec 17, 2014 at 4:26 PM, Menno Smits
> mailto:menno.sm...@canonical.com>>
> wrote:
> 
> There seems to be some confusion as to how merges gets blocked and 
> unblocked. Specifically:
> 
> 1. How do merges get blocked?
> 
> Juju-core bugs with the following criteria will block merges: a.
> status: 'Triaged', 'In Progress' or 'Fix Committed' b. importance:
> 'Critical' c. tags: 'regression' and 'ci'
> 
> 2. Who/what decides to unblock merges? The Jenkins
> github-merge-juju job 
> (http://juju-ci.vapour.ws:8080/job/github-merge-juju) is configured
> to call the check_blockers.py script, maintained by the Juju-QA
> team. check_blockers.py queries Launchpad for bugs with the above
> criteria.
> 
> master example: 
> https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All
>
>  1.20 example: 
> https://api.launchpad.net/devel/juju-core/1.20?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All
>
>  Most often the Juju QA team will open these bugs and set the tags,
> when a test failure demonstrates a regression.
> 
> If the pull request body includes "fixes-, where BUG
> NUMBER is in the blocking list, the merge will go through.
> 
> 
> 
> 3. How do merges get unblocked?
> 
> Merges are unblocked when no bugs are returned with the above
> criteria. The bugs should be updated only after the committed fix
> has successfully passed the CI tests which discovered the
> regression. This will most often mean setting the status to 'Fix
> Released' when the solution involves code changes or removing the
> regression and/or CI tag, if the issue is discovered to be a test
> or CI issue.
> 
> 
> 4, If the unblock process involves manual steps, whose 
> responsibility is it to perform those steps?
> 
> The person or team that marked the bug as a regression is
> responsible for updating the bug, once they are satisfied with the
> fix. Most often this will be the Juju-QA team but if others
> discover a regression they too should have the power to block
> merges.

The problem often is nobody from QA is around to ask for help in
certain times during the day. So there should be at least a person in
each team knowing how (and having permissions as well, if needed) to
re-run jobs that are stuck, mark the bug as Fix Released once the CI
job passes after the fix lands. Another REALLY NEEDED feature is to
re-queue PRs set for merging but bounced due to a CI block. This
wastes days sometimes, or at the very least hours.

> 
> 
> Based on experience and observation, I think I know how at least 
> some of this works but could we please have some authoritative
> answers?
> 
> Thanks, Menno
> 
> 
> 
> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
>  Modify settings or unsubscribe
> at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 


- -- 
Dimiter Naydenov 
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUkkBzAAoJENzxV2TbLzHwflIH+wQM8s8oV2i7b1PzsDzh9Zyu
DhfkyIhxFQxTJGsV8RamcTDkjWeDhRZKB49UPzMdqNJr0XG/KvVy1SyqICxJ5qoz
uWnnrdumzUhF0k/hjsUEnOpNDBOnubUIoGHBVyyx6UEMRgW+G0pFTIhUQGqEPhhU
7YMqn/r3GpiSnkmnknB/U4yk9TEYViDBRuPzSmhJiSwBGqkpOW+ISkWstUgbqYO+
o9KzxREWcvEDQ0+v0RLpaF2HsUWwktn7HL2BuoemhU4hoS5/ohD0VR5AemXwUyky
ISEiqu4atjPcCxJts5UpPhhznBSVHFlOm4ROkH1ku+x671WZEZZXoUt4CjWbxvo=
=l5mJ
-END PGP SIGNATURE-

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

Re: Blocking and unblocking merges

[John George]

On Wed, Dec 17, 2014 at 4:26 PM, Menno Smits 
wrote:
>
> There seems to be some confusion as to how merges gets blocked and
> unblocked. Specifically:
>
> 1. How do merges get blocked?
>
Juju-core bugs with the following criteria will block merges:
a. status: 'Triaged', 'In Progress' or 'Fix Committed'
b. importance: 'Critical'
c. tags: 'regression' and 'ci'

2. Who/what decides to unblock merges?
The Jenkins github-merge-juju job (
http://juju-ci.vapour.ws:8080/job/github-merge-juju) is configured to call
the check_blockers.py script, maintained by the Juju-QA team.
check_blockers.py queries Launchpad for bugs with the above criteria.

master example:
https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All

1.20 example:
https://api.launchpad.net/devel/juju-core/1.20?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All
Most often the Juju QA team will open these bugs and set the tags, when a
test failure demonstrates a regression.

If the pull request body includes "fixes-, where BUG NUMBER is
in the blocking list, the merge will go through.


>
> 3. How do merges get unblocked?
>
Merges are unblocked when no bugs are returned with the above criteria. The
bugs should be updated only after the committed fix has successfully passed
the CI tests which discovered the regression. This will most often mean
setting the status to 'Fix Released' when the solution involves code
changes or removing the regression and/or CI tag, if the issue is
discovered to be a test or CI issue.

>
> 4, If the unblock process involves manual steps, whose responsibility is
> it to perform those steps?
>
The person or team that marked the bug as a regression is responsible for
updating the bug, once they are satisfied with the fix. Most often this
will be the Juju-QA team but if others discover a regression they too
should have the power to block merges.

>
> Based on experience and observation, I think I know how at least some of
> this works but could we please have some authoritative answers?
>
> Thanks,
> Menno
>
>
>
> --
> 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

Blocking and unblocking merges

[Menno Smits]

There seems to be some confusion as to how merges gets blocked and
unblocked. Specifically:

1. How do merges get blocked?

2. Who/what decides to unblock merges?

3. How do merges get unblocked?

4, If the unblock process involves manual steps, whose responsibility is it
to perform those steps?

Based on experience and observation, I think I know how at least some of
this works but could we please have some authoritative answers?

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

Re: Reviewboard - dependant branches

[Jesse Meek]

On 18/12/14 03:01, John Weldon wrote:
Can someone remind me of the process for proposing branches that 
depend on another branch that is still in review?


I know it's been discussed here and on irc before, but I don't recall 
the specifics.


I think that the steps are:

 1. Just propose the branch in github, which will trigger the 
automatic reviewboard integration
 2. run some rbt command line invocation to update reviewboard with 
the upstream branch name


I just don't recall the exact invocation for #2 and I don't want to 
experiment and muck something up :)


rbt post -u --parent 



Cheers,

--
John Weldon




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

juju devel 1.21-beta4 is released

[Curtis Hovey-Canonical]

juju-core 1.21-beta4

A new development release of Juju, juju-core 1.21-beta4, is now available.
This release replaces 1.21-beta3.


Getting Juju

juju-core 1.21-beta4 is available for utopic and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/devel

The devel packages in this archive use the devel simple-streams.
You must configure the 'agent-stream' option in your
environments.yaml to use the matching juju agents.

agent-stream: devel

Upgrading from stable releases to development releases is not
supported. You can upgrade test environments to development releases
to test new features and fixes, but it is not advised to upgrade
production environments to 1.21-beta4.


Notable Changes

This releases addresses stability and performance issues.


Resolved issues

* 1.20 client can't destroy a 1.21 or 1.22 environment
  Lp 1394450

* Jujuc symlink creation broken on upgrade to 1.21.beta4
  Lp 1396792

* Container scoped relations between 2 subordinates broken in 1.20.12
  Lp 1396625

* 1.21b3: juju status isn't filtering by service
  Lp 1397995

* Maas provider: 1.21b3 removes ip from api-endpoints
  Lp 1397376

* Upgrade fails because product json is renamed
  Lp 1396981

* Joyent instances sometimes can't communicate via the internal
  network
  Lp 1401130

* 1.21 cannot "add-machine lxc" to 1.18.1
  Lp 1402826

* Jujud constantly spews `juju.worker runner.go:219 exited "identity-
  file-writer": stateservinginfo not available and we need it`
  Lp 1395564

* Local provider all-machines.log has only machine-0
  Lp 1396796

* Destroying azure environment took down other environment
  Lp 1398820

* Ec2 - allocate all instance stores
  Lp 1399169

* Testupgradestepsfailure intermittent test failure
  Lp 1389389

* Instructions for migrating to provisioner-harvest-mode are wrong
  Lp 1394751

* Local provider fails when an unrelated /home/ubuntu directory exists
  Lp 1328958


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

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

Reviewboard - dependant branches

[John Weldon]

Can someone remind me of the process for proposing branches that depend on
another branch that is still in review?

I know it's been discussed here and on irc before, but I don't recall the
specifics.

I think that the steps are:

 1. Just propose the branch in github, which will trigger the automatic
reviewboard integration
 2. run some rbt command line invocation to update reviewboard with the
upstream branch name

I just don't recall the exact invocation for #2 and I don't want to
experiment and muck something up :)

Cheers,

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