Re: [OpenStack-Infra] Zuul feature/zuulv3 branch to be rewound
Darragh Bailey writes: >> The abandon/restore steps are required by Gerrit in order to delete the >> branch. We could force-push the branch tip, but this is the procedure >> we have asked and would ask any other project to use in a similar >> situation, in order to reduce the risk of error. > > Can you elaborate more on how this reduces risk/errors? Curious in case we > run into a similar scenario in the future. Deleting/creating branches entails granting fewer permissions in Gerrit, so there is less opportunity to accidentally commit an error such as pushing to the wrong branch, or accidentally pushing local tags, etc. Creating a branch through the Gerrit web UI is also a very deliberate step, arguably easier to verify than a push. It's not a lot of extra safety. Just some. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Zuul feature/zuulv3 branch to be rewound
On 21 Sep 2017 6:38 pm, "James E. Blair" wrote: Hi, Snipped 1) Abandon all open changes on feature/zuulv3. 2) Delete the feature/zuulv3 branch. 3) Re-create the feature/zuulv3 branch at the commit before the Sem-Ver change: 027ba992595d23e920a9cf84f67c87959a4b2a13. 4) Restore all the changes abandoned in step 1. The abandon/restore steps are required by Gerrit in order to delete the branch. We could force-push the branch tip, but this is the procedure we have asked and would ask any other project to use in a similar situation, in order to reduce the risk of error. Can you elaborate more on how this reduces risk/errors? Curious in case we run into a similar scenario in the future. -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool" - unknown ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Zuul feature/zuulv3 branch to be rewound
Hi, A change recently landed on the feature/zuulv3 branch of Zuul with a Sem-Ver commit message footer. This is used by PBR to alter the way it constructs version numbers. It's pretty nifty, but in my opinion, it has a fundamental flaw: it can't be undone. I think use of this by a project should be very carefully considered, and that hasn't happened in the case of Zuul. Meanwhile, I think that during a development phase, in order to feel comfortable merging any change, we need to know that we can revert it if we make a mistake. That isn't possible with Sem-Ver footers -- they will always be parsed by PBR once they exist in the commit history. To correct this situation, the commit with the Sem-Ver footer needs to be removed from the branch. To accomplish this, I will do the following within the next hour or so: 1) Abandon all open changes on feature/zuulv3. 2) Delete the feature/zuulv3 branch. 3) Re-create the feature/zuulv3 branch at the commit before the Sem-Ver change: 027ba992595d23e920a9cf84f67c87959a4b2a13. 4) Restore all the changes abandoned in step 1. The abandon/restore steps are required by Gerrit in order to delete the branch. We could force-push the branch tip, but this is the procedure we have asked and would ask any other project to use in a similar situation, in order to reduce the risk of error. After this is complete, if you have updated your copy of the feature/zuulv3 branch within the past day, you will probably not be able to fast-forward any more. You will need to run "git reset --hard origin/feature/zuulv3" on your local feature/zuulv3 branch to correct the situation. Anyone deploying continuously from the branch tip may need to perform similar repairs. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] First member of networking-lagopus gerrit group
On 2017/09/21 23:10, Paul Belanger wrote: On Thu, Sep 21, 2017 at 10:17:20AM +0900, Hirofumi Ichihara wrote: Hi Infra team, I proposed networking-lagopus project[1] and then it looks like the project was created[2, 3]. Could you add me into the groups? [1]: https://review.openstack.org/#/c/501730/ [2]: https://review.openstack.org/#/admin/groups/1837,members [3]: https://review.openstack.org/#/admin/groups/1838,members Thanks, Hirofumi Done! Thank you! :) ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] First member of networking-lagopus gerrit group
On Thu, Sep 21, 2017 at 10:17:20AM +0900, Hirofumi Ichihara wrote: > Hi Infra team, > > I proposed networking-lagopus project[1] and then it looks like the project > was created[2, 3]. > Could you add me into the groups? > > [1]: https://review.openstack.org/#/c/501730/ > [2]: https://review.openstack.org/#/admin/groups/1837,members > [3]: https://review.openstack.org/#/admin/groups/1838,members > > Thanks, > Hirofumi > Done! ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [incident] OVH-BHS1 mirror disappeared
On Thu, Sep 21, 2017 at 12:58:58PM +1000, Ian Wienand wrote: > > At around Sep 21 02:30UTC mirror01.bhs1.ovh.openstack.org became > uncontactable and jobs in the region started to fail. > > The server was in an ACTIVE state but uncontactable. I attempted to > get a console but either a log or url request returned 500 (request > id's below if it helps). > > ... console url show ... > The server has either erred or is incapable of performing the requested > operation. (HTTP 500) (Request-ID: req-5da4cba2-efe8-4dfb-a8a7-faf490075c89) > ... console log show ... > The server has either erred or is incapable of performing the requested > operation. (HTTP 500) (Request-ID: req-80beb593-b565-42eb-8a97-b2a208e3d865) > > I could not figure out how to log into the web console with our > credentials. > > I attempted to hard-reboot it, and it currently appears stuck in > HARD_REBOOT. Thus I have placed nodepool.o.o in the emergency file > and set max-servers for the ovh-bhs1 region to 0 > > I have left it at this, as hopefully it will be beneficial for both > OVH and us to diagnose the issue since the host was definitely not > expected to disappear. After this we can restore or rebuild it as > required. > > Thanks, > http://mirror01.bhs1.ovh.openstack.org/ appears to be back online, I'll confirm if we want to remove nodepool from the emergency file. And try to reach out to OVH. > -i > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra