OS 7.1 to CentOS 7.2 anyways.
> >
> > We can do it now for more or less free, later in release cycle for higher
> > risk and QA efforts and after the release for 2x price because of
> additional
> > QA cycle we'll need to pass through.
> >
> >
> >
nk it'd be better to reduce risk of
> regressions that affects so many developers by postponing CentOS 7.2
> till Fuel 10.
>
> Thanks,
> Igor
>
>
> On Mon, Feb 29, 2016 at 7:13 PM, Dmitry Teselkin
> wrote:
> > I'd like to ask for a feature freeze exception for
/etherpad.openstack.org/p/r.a7fe0b575d891ed81206765fa5be6630
[5] https://review.fuel-infra.org/#/c/17400/
--
Thanks,
Dmitry Teselkin
Mirantis
http://www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
Hi,
There was a request to deliver updates to master node some time ago. As
a result of subsequent discussion in email thread and several offline
discussions a document [1] was created that describes existing
situation with repositories on master node, and a proposal on
delivering updates. Please
pment Mailing List (not for usage questions)
> >> >> Unsubscribe:
> >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>
> >> >
> >> >
> >
e ISO.
>
> One way or the other, we will be able to resume bugfixing on Monday
> morning MSK time, and will have lost 2 business days (Thu-Fri) during
> which we won't be able to merge bugfixes. In addition to that, someone
> from QA and everyone from CentOS7 support team has
At this point CI team will
> need to update the Fuel ISO used for deployment tests in our CI to
> this same ISO.
>
> One way or the other, we will be able to resume bugfixing on Monday
> morning MSK time, and will have lost 2 business days (Thu-Fri) during
> which we won't be
the regression is acceptable, we lift the merge freeze straight
> away and proceed with bugfixing as usual. At this point CI team will
> need to update the Fuel ISO used for deployment tests in our CI to
> this same ISO.
>
> One way or the other, we will be a
> One way or the other, we will be able to resume bugfixing on Monday
> morning MSK time, and will have lost 2 business days (Thu-Fri) during
> which we won't be able to merge bugfixes. In addition to that, someone
> from QA and everyone from CentOS7 support team has to work on
> Saturday
ht
> away and proceed with bugfixing as usual. At this point CI team will
> need to update the Fuel ISO used for deployment tests in our CI to
> this same ISO.
>
> One way or the other, we will be able to res
ISO
good enough
According to this plan on Monday, Dec 7 we should either get CentOS7
based ISO, or revert all incompatible changes.
--
Thanks,
Dmitry Teselkin
__
OpenStack Development Mailing List (not for usage questions)
U
ISO
good enough
According to this plan on Monday, Dec 7 we should either get CentOS7
based ISO, or revert all incompatible changes.
--
Thanks,
Dmitry Teselkin
__
OpenStack Development Mailing List (not for usage questions)
U
. If
not - we will revert breaking changes.
[0]
https://review.openstack.org/#/q/status:open+topic:centos7-master-node,n,z
--
Thanks,
Dmitry Teselkin
__
OpenStack Development Mailing List (not for usage questions)
mur Sufiev
> >> >
> >> > ___
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> &
Hi,
I'm going to update devstack on Murano CI server. This should take approx
2-3 hrs, if no obstacles.
During that period CI jobs will be disabled to avoid -1 scores with
NOT_REGISTERED status.
--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.miranti
of
this is the regexp in OpenStack's zuul which triggers each time it sees
'recheck' word, so the only fast way to fix it is to get rid of that
ambiguous keyword.
--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
ts.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/lis
cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Thanks,
Dmitry Teselkin
Deployment Enginee
t; I want to take this opportunity to remind everyone that we should
> adhere to the global-requirements.txt in order to avoid such
> conflicts.
Hopefully our developers decided to get rid of kombu.five usage what looks
an easy task.
Thanks, everyone.
On Mon, Apr 7, 2014 at 8:33 PM
ble, I'm awaiting answer from our developers.
Which is the most suitable variant, or are there any other solutions for
the problem?
--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
Open
es such heavy dependencies as Java. :)
I'm not shure that writing our own tool worth it, however I might be wrong
here.
--
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
OpenStack-
t.png
> >
> >--
> >Timur Sufiev
> >
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
gt;
>
> And one more nit correction:
> OpenStack has it's own git repository [1]. We shoul avoid referring to
> github
> since it's just a convinient mirror, while [1] is an official
> OpenStack repository.
>
> [0]
> https://blueprints.launchpad.net/murano/+spec/repository-reorganization
> [1] http://git.
t/neutron/+spec/allowed-address-pairs
> [3]
> http://docs.openstack.org/admin-guide-cloud/content/section_allowed_address_pairs_workflow.html
> --
> Regards,
> Alexander Tivelkov
>
> ___
> OpenStack-dev mailing list
> OpenStac
24 matches
Mail list logo
